SQL Server Security Database and OS Level Audit

8/12/2019 SQL Server Security Database and OS Level Audit

1/19


2/19

SQL Server Security Database and OS Level

Wipro Technologies | Confidential

SQL Server Security Audit - Database Level Audit

Once the Server Level audits are complete, databases should be considered next. A number of steps can

be taken to audit database level security.

Database owners

A database owner can perform any action in the database. This includes granting access rights to the

database to other users. Every database has a built-in user account called the dbo. This is the database

owner. By default, this user account is mapped to the login that created the database. There is also a

fixed database role called db_owner whose members have database ownership privilege.

Just like finding out who has system administrator privilege in your SQL Server, you may want to find out

who has ownership rights in each database.

Executing the following script against each database will give you a list of user accounts that are

members of the db_owner role:

USE-- Run against each database

GO

SELECTc.name ASDB_Owner_Role_Member

FROM sys.database_principalsa

INNERJOINsys.database_role_membersb

ONa.principal_id =b.role_principal_id ANDa.is_fixed_role =1 ANDa.name ='db_owner'

INNERJOINsys.database_principalsc

ONb.member_principal_id =c.principal_id

If you want to find out the login that is mapped to the built-in dbo user, you can use the following

query:

USE-- Execute for each database

GO

SELECTb.name ASLogin_Mapped_to_DBO



3/19



INNERJOINsys.server_principalsb

ONa.sid =b.sid

WHEREa.name ='dbo'

Guest user account

Just like dbo, the guest account is also a special built-in database user. This user is disabled by default,

but you can enable it or create it manually. The guest account does not correspond to any SQL Server

login. In fact its purpose is to serve as an ad-hoc user for any login. What this means is that any login

that does not have a corresponding database user account can still get into the database provided the

database has the guest user enabled. Guest user exists in the system databasesand they are there for

a reason. But if you have a guest account enabled in your production database, you need to know why it

is there and what access it has got.

A code snippet like the following can help you identify the rights of the guest user.


GO

SELECT c.name ASObjectName,

c.type_desc ASObject_Type,

b.permission_name ASPermission_Type,

b.state_desc ASPermission_Status

FROM sys.database_principals a

INNERJOINsys.database_permissions b

ONa.principal_id =b.grantee_principal_id

INNERJOINsys.objectsc

ONb.major_id =c.object_id

WHERE a.name ='guest'

ORDERBYc.name


4/19



Orphan users

Strictly speaking, this is not a security hole, but one that needs to be looked at nevertheless. Sometimes

SQL Server logins are deleted without dropping the associated database users first. Often databases are

restored from another system and the user accounts in them do not correspond to any local logins. Your

database is said to have orphan users in such cases. The security audit should pick up these orphanusers in each database. The following query can be run in each database for this purpose.


GO

SELECT a.name ASOrphanUserName,a.type_desc ASUserType


LEFTOUTERJOIN sys.server_principals b

ON a.sid =b.sid

WHEREb.sid ISNULL

AND a.type In('S','U','G')

AND a.name NOTin('sys','INFORMATION_SCHEMA','guest')

Database object permissions

We could go down to more granular level and find out the access rights explicitly granted to each

database user for each database object. This can be a quite large report, with probably not much value.

But if you are still interested, you can execute a query like the following:


GO

SELECTa.name ASDatabase_Principal_Name,

a.type_desc ASDatabase_Principal_Type,

c.name ASObjectName,

c.type_desc ASObject_Type,

b.permission_name ASPermission_Type,


5/19



b.state_desc ASPermission_Status

FROM sys.database_principals a

INNERJOINsys.database_permissionsb

ONa.principal_id =b.grantee_principal_id

INNERJOINsys.objectsc

ONb.major_id =c.object_id

WHEREa.name NOTIN('sys','INFORMATION_SCHEMA','public','guest')

ORDERBYa.name

Instead, you will probably be interested to find out the non-default schemas that exist in your databaseand the owners of those schemas:


GO

-- List of non-standard schemas and their owners

SELECT a.name ASDatabase_Schema_Name,b.name ASSchema_Owner

FROM sys.schemasa

INNERJOINsys.database_principalsb

ONa.principal_id =b.principal_id

WHEREa.schema_ida.principal_id

AND b.type 'R'

-- List of users and their default schemas

SELECTnameASDatabase_User,Default_Schema_Name

FROM sys.database_principals

WHEREtype'R'


6/19



Certificates, symmetric and asymmetric keys

From version 2005, a new feature of data security has been added to SQL Server. Individual table

columns can now be encrypted using asymmetric keys, symmetric keys or certificates. Data traffic

between SQL Servers can be encrypted using certificates and login accounts can be mapped to

certificates or asymmetric keys.

When it comes to encryption, there is a hierarchical relationship between these three entities. A data

field can be encrypted using a symmetric key, which in turn can be encrypted by an asymmetric key or a

certificate. Certificates can also encrypt asymmetric keys. At the root of all encryption mechanism is the

service master key.

When using certificates, SQL Server does not necessarily need a certificate issued by a third party like

VeriSign. In fact it can issue a self signed certificate itself.

If you want to see if there are asymmetric keys, symmetric keys of certificates installed in your database,

you can either use the Management Studio or use a query like the following:

USE-- Change for each database


7/19



GO

SELECT*FROMsys.certificates

SELECT*FROMsys.symmetric_keys

SELECT*FROMsys.asymmetric_keys

Operating system level audits

Typically, most DBAs have remote access privilege to the Windows machine hosting the database server.

If you have administrator privilege in the Windows box (or VM), you can take some time to try the

following:

Windows security log

This should be actually a part of the DBAs daily checks. However, as part of your initial audit, check theWindows security log. The security log in the Event Viewer can show you the unsuccessful login

attempts to your SQL Server.

You can filter the security log with various options. For example, you may be only interested in failed

login attempts.


8/19



If there are a large number of unsuccessful login attemptseither from same or multiple sourcespay

attention, note it down; this needs to be looked at. However, this does not necessarily mean somebody

is trying to hack into your server: it may be due to a service accounts being locked out.

Local administrator group

Members of the Local Administrators group are also by default members of the sysadmin fixed server

role. Even if the role privilege has been explicitly revoked, local administrators still have full access to the

Windows environment.

If you have administrator privilege in the Windows machine hosting the SQL Server, you may be

interested to know who else has that privilege. To find out, start the Computer Management applet

from the Administrative Tools program group and then browse to the Local Users and Groups node.


9/19



If you double click on the Administrators group, it will show you a list of local administrators of the

machine.


10/19



By default, only the built-in administrator account and the Domain Admins group should be listed

here. You may also find your account (as the DBA) or a Windows group for DBAs listed here. However, if

you see accounts or groups that you know should not have this privilegenote it down.

Shared folders

Database applications often import and export data contained in text files. This can happen from within

stored procedure codes, SSIS packages or hard coded scripts within SQL Server jobs. Often these data

files are located in shared folders in the database servers file system. If you see such shared folders in

your SQL Server machine, take a minute to check its permission level. It is common to see the

Everyone group having full access to shared folders.


11/19



You may also want to explicitly check the folder permissions for directories holding data, backup or

replication files.

Security Configuration and Analysis Tool

The Security Configuration and Analysis tool is an MMC snap-in that can make use of customised

security templates (created as .INF files) to check the status of your servers security. There are some

standard security template files that ship with Windows by default (see figure below).


12/19



These templates are configured for domain controllers, member servers etc. There is no specific

template that applies to SQL Server database servers. However as a standard practice, most companies

have domain level policies that automatically overwrite any server specific changes on a regular interval.

If your organisation has any such customised template that is used for member servers and the server is

not automatically refreshed with the security policies, you can use that template to verify the current

status of security.

You can invoke the Security Configuration and Analysis tool by starting the MMC application from the

command prompt, then adding the relevant snap-in (see below).


13/19



Once you have the snap-in into place you can create a security database (not in the traditional sense of

SQL Server database). This database will have all the details of the current Windows server security

configurations. The database creation is a fairly straightforward process: all you have to do is right click

on the snap-in under the MMC console root and choose Open Database and provide a name for it.

Security databases have an extension of .sdb. Once you provide the name, you need to select the

appropriate template file.


14/19



Next, you need to choose Analyze Computer Now... from the pop-up menu by right clicking on the

snap-in again.

The application will take some time to analyse the security status of your server against the template.

Once the analysis is complete, it will show you with visual flags where the current security status is not

consistent with the template settings. In the example below, we had used the tool with the

hisecws.inf template file.


15/19



Working with the Security Configuration and Analysis tool is primarily a server administrator or

infrastructure engineers work not a DBAs. This is where you need to be a bit careful as not to give the

impression that you are treading into the responsibility area of another person or department. If

needed, work closely with your server administrators for this audit.

Microsoft Baseline Security Analyzer

Microsoft Baseline Security Analyzer (MBSA) is a freely downloadable tool from the Microsoft web site.

You can run it against your target SQL Server machine to get a detailed report on security vulnerabilities.

MBSA can be configured to check for security updates for Windows Server 2003 or 2008. The updates

can be checked either from the Microsoft web site or from a WSUS server. It can also check IIS or SQL

Server for vulnerabilities. The automated audits are saved as reports that you can refer back to later.

The tool also lets you check a range of machines in one single session.

Provided you have administrator privileges in the machine, it may be worthwhile to run the MBSA tool

against the SQL Servers installed.


16/19




17/19



You may get a report like the following:


18/19



Probably many of your findings in the security audit so far will also be picked up the MBSA. Neverthelessit is a good idea to run the application to see if you have missed anything.

Virus Protection

Check with your system administrators to see if the SQL Server machine has the latest anti-virus

software installed and enabled and if the virus definitions are automatically updated. This may sound

obvious since most organisations will have anti-virus software running on their servers, but this is for

completeness sake.

Conclusion

You would not probably want to include your development and test servers in the security audit

described here since there will be little value in doing so. Ideally, at the very beginning, the audit should

include one or few critical SQL Servers in the enterprise. Depending on time, budget and scope, you may

not want to include everything in your audit and everything discussed here may not apply to your

environment either. But once you have the process ready through scripts, manual checks and

documentationit can easily be repeated.

Another point to remember is that you will probably perform the audit for management presentation. In

such cases you would want to keep it as free of technicalities as possible. This often means you will have

to prepare a second birds eye-view report based on your initial findings. You should be ready to back

this high level audit report with all the screenshots and query outputs wherever necessary.

Also, once you have the initial audit readywith all the Excel spreadsheets, Word documents,

screenshots and reportsyou need to start working with developers, system administrators, team

leaders and business stakeholders to find out the reasons behind any anomalies that you identified.


19/19



So for example, if your audit shows the accounting team user Joe Blogg has sysadmin privilege in your

SQL Server and after talking with the stakeholders you establish that he should not have this access,

present the fact in an understandable format. Instead of showing the account MYCOMAPNY\JBlogg

listed under a column titled sysadmins, make sure your final report only highlights the fact that some

of the accounting department personnel have system administrator privilege in the database server and

this is against the business rules.

Please send your feedback [email protected]@microsoft.com
mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]

SQL Server Security Database and OS Level Audit

Documents

Transcript of SQL Server Security Database and OS Level Audit