MS_SQL_Server.doc.doc.doc.doc.doc

MICROSOFT SQL SERVER MASTER AUDIT PROGRAM

I. Description

Microsoft SQL Server is a multiuser relational database management system for PC-based local area networks (LANs). A relational database is a collection of information organized into tables that can be queried by using data in specified columns of one table to find additional data in another table. The creator of a relational database is the owner of the database (DBO). The DBO has full privileges inside the database that he or she owns.

Relational databases are comprised of database objects including tables, indexes, views, defaults, triggers, rules and procedures. The user who creates a database object is the database object owner. The database owner must first grant to the user permission to create a particular type of object. The database object owner can then create an object and grant permission to other users.

SECURITY UNDER WINDOWS NT

SQL Server uses two levels of user identification: server and database level. At the server level, it maintains and authenticates passwords, although password expiration management is optional. Unlike previous versions SQL Server encrypts passwords for storage, and users may request that passwords be encrypted when traversing over the network using Multiprotocol Net-Libraries. Passwords in SQL do not automatically expire and minimum password lengths cannot be set. Windows NT Integrated Security eliminates the password management shortcoming of SQL Server in that the Windows NT password policy settings are used for password management.

With Windows NT integrated security, users are required to log on to Windows NT before they can perform any activities on the local machine. With SQL Server for Windows NT, there is a way to integrate SQL Server login security with Windows NT security. Thus authorized users (in Windows NT) do not have to have separate SQL Server login IDs and passwords.

In order to review the controls for account security you must first determine the type of security in place. With SQL Server for Windows NT, log in accounts can be set up in one of three different ways: standard, integrated and mixed. With standard security, SQL Server users must specify an ID and password to access the server and authenticate themselves in the SQL Server System Table SYSLOGINS. With integrated security, users bypass the SQL Server log in process (Syslogins Table) completely because the server uses Windows NT security to authenticate users. With this mode of security passwords are not sent across the network.

For SQL versions other than SQL 7.0, integrated security is available only for clients using the default Named Pipes protocol or Multiprotocol Net-Libraries. SQL Server 7.0 is able to use Windows NT Authentication Mode over all the network libraries. If your SQL Server is set-up to use different protocols in addition to named pipes, you can still use the controls available in integrated security for your named pipe clients by using mixed security.

of 27


Mixed security allows anyone access to the SQL Server if they have a valid ID and password. When mixed security is used, for trusted (named pipes) connections, SQL Server examines the log in name. If this log in name matches the user's network user name or if the log in name is blank or spaces, SQL Server uses the Windows NT integrated rules. If the requested log in name is any other value, the user must supply the correct SQL Server login ID and password. In this case, SQL Server uses its own log in validation process.

The security administrator must perform the following steps to set up Integrated Login Security.

1. Set up Windows NT users and groups.2. Add SQL Server login IDs.3. Set SQL Server Server security mode appropriately.4. Grant Windows NT users and groups access to SQL Server.

CONFIGURING SQL SECURITY

There are several options to choose from when the SQL Server for Windows NT is being configured. The Default Login is applicable to trusted connections and is the login name that is used if the Windows NT user name does not appear in Syslogins. For example if Travis tries to log in to SQL Server in integrated security and Travis does not appear in the Syslogins Table and the SQL Server default login ID is set to NTguest, then the login ID for Travis is set to NTguest. If no default login ID is specified in the SQL Server, access for Travis is denied.

NT INTEGRATED SECURITY

To use NT Integrated Security, an account must be set up on the NT Domain for each SQL Server user. The passwords must be synchronized with the requesting domain. Assuming the user is already an SQL user and has an account in the Syslogins Table, this is the only step necessary to move the user to an NT integrated security account. If the user is not an SQL Server user, then the object security must be set up in the system tables, Syslogins and Sysusers.

ENSURING ADEQUATE SEPARATION OF DUTIES

One user may grant privileges to another to delegate responsibilities. The person who creates the object, such as a table or view, establishing the definition for it subsequently maintains control over it. This means that the technician who established the object can thereafter access and change all the data - not necessarily a level of power that should be given to that person.

APPLICATION SERVERS

SQL Server SNA Server EMS 3rd PartyServer

Applications

of 27


OPEN DATABASE SERVICES - THE SERVER INTERFACE

Open Database Services (ODSI) is a standard in the Microsoft Windows operating system that provides a generic application interface to database systems that have a service provider interface (SPI) available in the architecture. Venders or third parties may provide additional SPIs.

APPLICATION

API (Application Program Interface)

Driver Manager (ODBC Interface)

SPI (Service Provider Interface)

xBase Database

driver

DEC RDB onVAX

DatabaseDriver

SQL ServerDatabase

Driver

IBM DB 2Database Driver

Focus DatabaseDriver

xBase FileServer

DEC RDB onVAX Server

SQL Server forWindows NT

LAN Gateway

IBM Mainframe

Login Process

SQL Server for Windows NT integrated security allows a network user to log in to a SQL Server without supplying a separate login ID or password. This allows users to maintain one login ID and password for both Windows NT and SQL Server. When a user of integrated security logs in to the SQL Server, the user is either mapped to a SQL Server login ID, the SQL Server default login (usually guest) or to SA if the user has administrative privileges. Assignments are made through Security Manager or stored procedures. The Windows NT local administrators group is the only group assigned to SA by default.

If multiple SQL Server computers participate in a domain managed by a Windows NT Advanced Server, a single network login is sufficient to enable access to all of the SQL Servers. For users defined in other domains, SQL Server provides map characters to map the domain name and username to a SQL Server login ID. See Appendix A for an explanation of the system tables.

Managing Security:

To manage SQL Server security, the administrator must set the server logon security mode, authorize Windows NT users to access SQL Server, Manage SQL Server login Ids, manage database users, manage object and statement permissions, change database ownership, and use the security management tools providedEXPLANATION OF SYSTEM TABLES

of 27


System tables define the structure of the database. All system tables are found in the Master Database. Some system tables are found in all databases; they are automatically when the CREATE DATABASE statement is executed. The Master Database and each user database contain system tables that keep track of information about SQL Server as a whole and about each user database.

All of the SQL Server supplied tables in the Master Database (the controlling database) are considered system tables. In addition, each user database is created with a subset of these system tables. The Master Database and its tables are created when SQL Server is installed. The Master Database contains global catalog system tables as well as the database specific system tables, contained in all databases. The system tables in the database are automatically created when the database is created. The names of all system tables begin with sys. Permissions for system tables are controlled by the database owner, just like the permissions for all database objects.

II. Applicable Rules, Regulations and Reference Material

References applicable to this function include:

1. Information Security Manual (ISM)

2. Data Processing System Support Manual (DP)

3. Microsoft SQL Server Administrator’s Companion

III. Audit Software

Tools such as SQL and ISQL are available for querying SQL server objects. There are also some third party tools that may enable the auditor to query (i.e. ISS Database Scanner, BindView, etc.).

IV. Objectives and Scope

Objectives

Determine the:

1. Reliability and integrity of reported information.

2. Compliance with policies, procedures, laws and regulations.

3. Adequacy of procedures and processes to safeguard assets.

4. Accomplishment of established goals and objectives.

5. Economical and efficient use of resources.

of 27


The procedures as stated in the following Scope section are presented as either Standards, or Guidelines. The Standards (bold and italicized) are intended to represent the core issues that should be addressed on Windows NT audits. The Guidelines (a number followed by a decimal point and a number) are suggested steps that may be taken in order to meet the criteria established in the Standards.

Scope

The scope of this audit includes a review of SQL servers to ensure compliance with the applicable ISM policies and safeguards.

V. Detailed Audit Tests

1. Risk Certification: Determine the level of compliance with ISM Policies and Safeguards through the review of the Risk Certification and Compliance Assessment processes and documentation.

1.1 Obtain a copy of the Risk Certification performed for SQL ensuring that it has been reviewed, updated and approved.

Source Identifier: ISM Policy 8.10, ISM 8.20.41, ISM Appendix C

1.2 Obtain a copy of the most current ISM Compliance Review Summary and/or Software Security Review ensuring that it has been reviewed, updated (if necessary), and approved within the past year (12 months). In addition, evaluate whether any substantial change in business functions or major new application systems would have necessitated an update to the Assessment.

Source Identifier: ISM 2.30.20, ISM Appendix A, ISM Appendix C

1.3 Evaluate the compliance review(s) for completeness and reasonableness against the information in Appendix A of the ISM. Also ensure that the assessments indicate that a data classification process has been completed for the function.

Source Identifier: ISM Appendix A, ISM Appendix B

1.4 Determine that any non-compliance is properly documented to include a waiver signed by both department management and the Information Security Officer. Documentation should also include a list of compensating controls that have been put in place or some statement as to why compensating controls cannot be used.

Source Identifier: ISM Policy 2.30

1.5 Obtain the Data Classification Matrix and determine if any of the SQL databases contain classified information.

1.5.1 The Syslogins table should be classified Restricted FR since it contains encrypted passwords.

of 27



1.6 Determine whether a security review of the current release of Microsoft SQL Server software has been performed.

Source Identifier: ISM 8.20.40

2. Authorizing Access: Determine that only authorized users have logical access to SQL Server.

When SQL Server is first installed, the permissions on system tables are set up so that all users in user databases have permission to read the system tables. However, no update permissions (INSERT, UPDATE, and DELETE) are granted to any user including the DBA. This is done to prevent direct updates to a system table, which could inadvertently comprise integrity. All updates to the system tables should be made either as a direct result of DDL statements or through system procedures that guarantee the integrity of their updates. A configuration option must be set to allow system updates.

2.1 Review the entries in the SYSLOGINS Table.

2.1.1 Connect to the appropriate server. Login and reference the Master database. Generate the following command:

Select “SERVER NAME=[place server name here]”Select suid, status, accdate, dbname, name from master.dbo.syslogins where suid=1

Locate the user account with a suid of 1. This account is usually called “SA” or “DBO” but may have another name. Determine who has access to this ID and how access (password) is controlled. Ensure

of 27


that only users who are responsible for system or security administration of the SQL Server have been granted access to any of the system tables.

The system administrator ID (SA) is specified when the server is first installed and the privilege cannot be revoked. Other users can be granted many of the SA privileges, but these privileges can be revoked. There are no restrictions on what the SA ID can do with SQL Server. The SA always has an suid of 1.


2.1.2 Determine if access to system tables is appropriately controlled in accordance with the ‘business need to know’ concept. Generate the following query containing extracts from the SYSPROTECTS Table and SYSOBJECTS Table. Review the TYPE column of the SYSOBJECTS Table:

Select "SERVER NAME=[place server name here]”"RUN from each Database..." Select "DATABASE NAME=",db_name(),getdate()Select b.name"OBJECT NAME",b.uid"OBJECT OWNER",a.uid"GROUP",a.action"ACTION" from sysprotects a, sysobjects b where a.id=b.id order by a.uid,a.action

It will have one of eight object types, “S”, indicates that it is a System Table. Review the column of the SYSPROTECTS Table titled “Uid” and identify all the user and group ids who have been granted any type of access to the System Tables.


2.2 Review the “ALLOW UPDATES column of the SYSCONFIGURES Table. If the value is “0,” no one including the SA can directly update the system tables. If the value is “1” direct updates to system tables cannot be made by anyone other than the System Administrator (SA).

SYSCONFIGS TABLE FORMAT

The SQL Server setup program gives permissions to all users to read the system tables, except for a few fields (such as syslogins.password). By default, direct updates to system tables are not allowed, even for the database owner, because SQL Server has supplied system procedures to make any updates and additions to system tables that are normally needed. However, changes can be made to the default to allow direct updates to the system tables. To do this, changes are made to the SYSCONFIGURES Table; however, the current configuration values are stored in the SYSCONFIGS Table. The format of this table is set forth on the page to follow.

of 27


COLUMN VALUE DESCRIPTION

Config value Configuration variable number.

Value init User-modifiable value for the variable (being used by SQL server only if RECONFIGURE has been executed).

Comment varchar(255)

Explanation of the Configuration Option.

Status smallinit 1 for dynamic - the variable takes effect when RECONFIGURE is executed. 0 for static - THE VARIABLE TAKES EFFECT WHEN SQL SERVER IS RESTARTED.


2.3 Determine if the Setuser command is being used appropriately. Review the output generated by the following query:

Select "SERVER NAME=[place server name here]”"RUN from each Database..." Select "DATABASE NAME=",db_name(),getdate()Select b.name"OBJECT NAME",b.uid"OBJECT OWNER",a.uid"GROUP",a.action"ACTION" from sysprotects a, sysobjects b where a.id=b.id order by a.uid,a.actionSelect name,dbid,suid,mode,status,version,logptr,crdate,dumptrdate from sysdatabases

Note: With the setuser statement, a database owner can impersonate another user's identity and permission status in the current database. The setuser statement allows a database owner to access an object owned by another user, to grant permissions on an object owned by another user, to create an object that will be owned by another user, and to temporarily take on the permissions of another user.

SETUSER permission defaults to the database owner and cannot be transferred. The SA can use setuser to create objects that will be owned by another user. However, since the SA operates outside the permissions system, he or she cannot acquire another user’s permissions with setuser. No matter what setuser statements have been issued, the SA always retains permission to do everything. The setuser command defaults to the database owner and cannot be transferred.

of 27


SYSDATABASES Table

Column Data Type Description

Name Sysname Name of the database.

Dbid Smallinit Database ID.

Suid Smallinit Server user id of the database creator.

Mode Smallinit Used internally for locking database while it is being created.

Status Smallinit Status bits.

Version Smallinit Version of SQL

Logpr Init Pointer to transaction log.

Crdate Datetime Creation date.

Dumptrdate Datetime Date of the last dump transaction.


2.4 Review ownership of System Tables. Ensure that the suid of the server user id of the creator (SA) for the master database is 1. Only the system administrator should have permission to change system tables in the master database. Run the query below which creates a three column table/workpaper, with columns titled: name of the database id and server id of the database creator/owner, respectively.

Select "SERVER NAME=[place server name here]”"RUN from each Database..." Select "DATABASE NAME=",db_name(),getdate()Select b.name"OBJECT NAME",b.uid"OBJECT OWNER",a.uid"GROUP",a.action"ACTION" from sysprotects a, sysobjects b where a.id=b.id order by a.uid,a.action Select name,dbid,suid,mode,status,version,logptr,crdate,dumptrdate from sysdatabases


2.5 Determine whether the use of utility programs is restricted to only those persons responsible for maintaining the SQL Server.

of 27


Note: Utility programs are available at the command line and from the SQL Server Program Group.

Utility Program Function

SQL Service Manager Starts, pauses and stops SQL Server

SQL Tape Utility Reads information from a tape. Backup operators require this utility.

SQL Client Configuration Configures the SQL client

Library Sets the default Net-Library and server connection information on clients. It also displays the DB-Library version number and searches for multiple copies of DB-Library and Net-Library in the path.

SQL Security Manager Allows the administrator to manage users who are accessing the SQL Server under integrated or mixed security.

IS./w Allows a user to enter Transact-SQL statements and system procedures in a graphical query interface. ISL./w also provides the capability for graphically analyzing queries.

The following utility programs are available from the command line:

Utility Program Function

Bcp Bulk Copy Program

Bldmastr Builds the master database, or restored default configuration values. Only the SA can run this utility.

Console Prompts the operator while a database is being backed up to or restored from diskettes or tape.

Isql or isqlw Executes batch files that contain one or more SQL statements.

Makepipe and readpipe

Tests the integrity of the network named pipe services


2.6 Determine if the ability to execute System Procedures is adequately controlled.

of 27


Note: When MS SQL Server is first installed, there is a new set of system procedures referred to as Catalog Stored Procedures, that provides a standard catalog interface to SQL Server and provides for database gateways. System catalog procedures are created in the master database and owned by the SA. They can be run from any database (including other system databases and user databases).

Permissions on system procedures are set up and controlled in the master database. Certain system procedures can be executed only by the SA or DBO. These procedures are mostly administrative in nature. However, other system procedures can be executed by users at large. A user is granted a permission to execute a system procedure in all databases or none.


2.7 Ensure that access to extended stored procedures is limited based upon a business need running sp_helprotect.

Unauthorized access to extended stored procedures can increase the risk of SQL Server users gaining unauthorized access to the operating system. The xp_cmdshell extended stored procedure, for example, allows users to execute “any operating-system command at the Windows NT command shell that the account running SQL Server (usually a local system account) has the privilege to execute.”

2.7.1 If using SQL 6.5, ensure the SQLExecutiveCmdExec account option in “Server Options” is in use to limit the rights when non-sa users use xp_cmdshell.

2.7.2 Determine whether the OLE automation stored procedures have been dropped to minimize unauthorized access. Note, some Enterprise Manager features may be lost when the stored procedures are removed.

OLE automation stored procedures include:

Sp_OACreateSp_OADestroySp_OAGetErrorInfoSp_OAGetPropertySp_OAMethodSp_OASetPropertySp_OAStop

2.7.3 Determine whether the following registry access procedures have been dropped, if not required:

Xp_regaddmultistringXp_regdeletekeyXp_regdeletevalue

of 27


Xp_regenumvaluesXp_regremovemultistringXp_regwrite

Source Identifier: ISM 5.10.10, Best Practices

2.8 Ensure that built-in system stored procedures (e.g., sp_password, sp_addlogin, sp_adduser) have not changed from those deployed with SQL by comparing built-in procedures to a copy of the stored procedures deployed with SQL. Built-in procedures may allow opportunities for Trojan horses to be built into the system.

Source Identifier: Best Practice

2.9 Ensure that all SQL files are protected by the operating system by reviewing file permissions (system and database table spaces) at the operating system level. Source Identifier: ISM Policy 5.10

3. Authenticating Access: Ensure that appropriate authentication is enforced to provide identification, authorization and accountability for SQL servers.

3.1 Determine whether the server login security mode is set to mixed, integrated or standard. If LOGIN MODE integrated security is used or if mixed mode is used, review NT account security.

To view login configuration information, review the configuration report generated from command: xp loginconfig [“config name”]. Note, for some xp_ commands you need to have system administrator privileges.

Where config name specifies the configuration value about which to display information. If no config name is specified, all are reported. The configuration values correspond to the values set for security with Setup. The following example reports on all configuration values:

Name config value---------------------------------------------------------------------------LOGIN MODE MIXEDdefault login NULLdefault domain NULLaudit level noneset hostname falsemap domain separatormap$ NULLmap #

“NULL” does not appear as the password of the user. For each column in the SYSLOGINS table the administrator can indicate whether null values are to be

of 27


allowed. A null value is not the same as a zero or blank. Null means no entry has been made and usually implies that the value is either unknown or inapplicable. It indicates that the user did not make an entry. If the user does not make an entry to a column defined with the keyword NULL SQL Server supplies the null value.


3.2 If SQL Server security is Standard or Mixed, verify that the NULL Option has not been specified for any passwords in the SYSLOGINS TABLE by executing the following command:

Select “SERVER NAME=[place server name here]”Select suid, status, dbname, name from syslogins where password=NULL

When standard or mixed security is used a NULL password should not be defined. When integrated security is used there is no need to maintain passwords.

NOTE: “NULL” does not appear as the password of the user. For each column in the SYSLOGINS table the administrator can indicate whether null values are to be allowed. A null value is not the same as a zero or blank. Null means no entry has been made and usually implies that the value is either unknown or inapplicable. It indicates that the user did not make an entry. If the user does not make an entry to a column defined with the keyword NULL SQL Server supplies the null value.


3.3 Review the entries in the SYSLOGINS Table by generating the following command:

Select “SERVER NAME=[place server name here]”Select suid, status, accdate,dbname, name from syslogins where suid=1

Locate the user account with a suid of 1. It is usually called System Administrator SA, or Database Owner DBO, but may have another name. Per inquiry determine who has access to this SA ID which can be gained by anyone knowing the SA password. Determine how the (password) is controlled, since it must be shared between primary and backup administrators.

Note: The system administrator ID (SA) is specified when the server is first installed and the privilege cannot be revoked. Other users can be granted many of the (SA) privileges, but theirs can be revoked. This ID handles tasks not specific to an application. There are no restrictions on what the SA can do within SQL Server. This gives the SA the ability to repair any damage inadvertently done to the permissions system. The SA always has a suid of 1. When SQL Server is installed with integrated or mixed security, the NT

of 27


Administrators Group on the local computer is automatically granted access to the SQL Server as SA. If this presents an incompatible combination of duties and the office does not want the Windows NT Administrators Group to have access to SQL Server, first create a user or group in Windows NT that will have access to SQL Server as SA. Then grant that user or group access to SQL Server with xp grantlogin and the Admin option. Finally, revoke system administrator privilege to the Administrators Group by using xp revokelogin.


3.4 Ensure that only the SA ID is being used to perform the following nine functions:

1) DISK INIT,2) DISK REFIT,3) DISK REINIT,4) DISK MIRROR,5) DISK REMIRROR,6) DISK UNMIRROR,7) KILL,8) RECONFIGURE,9) SHUTDOWN.

Review the report generated from the following command:

Select “SERVER NAME=[place server name here]”Select suid, status, accdate,dbname, name from syslogins where suid=1

NOTE: The above functions cannot be granted to any other user. Security Administrators should be assigned other IDs with only the privileges necessary to perform security administration functions. It should not be necessary for a Security Administrator to perform any of these tasks if adequate separation of duties is in place.


3.5 Determine that a notification process is in place to remove employees that are terminating employment or transferring to other areas. Assess whether the process is working by verify that there are no active accounts for terminated or transferred employees. This can be determined by comparing the login ID in the name field of the SYSLOGINS Table to a valid list of current employee login Ids. To perform this function, generate the following query:

Select “SERVER NAME=[place server name here]”Select suid,name,dbname from syslogins

Remember that the SYSLOGINS Table is in the master database only and contains names for all active users on the logical server.

of 27


Source Identifier: ISM Policy 6.30, ISM 6.30.10, ISM 6.30.20

3.6 Determine whether any Visitor or Guest accounts are set up and in use by looking for these entries in the SYSLOGINS Table generated by the following query:


If the System Administrator feels guest or visitor accounts are necessary, the number should be limited, and the accounts should be disabled when not in use.

Note: When SQL Server is initially installed, master.sysusers contains three entries: dbo, with an suid of 1 and uid of 1; guest, with a suid of -1 and uid of 2; and public, with an suid of -2 and uid of 0. The guest user account provides access to the database to users not explicitly listed in the sysusers table, with a restricted set of permissions. The guest entry in master means that any user with an account on SQL Server (that is, with an entry in syslogins) can access the master database.

If a default login was specified in the Sysconfigures table when the login security mode was set to integrated or mixed, then that login is added automatically by SQL server. A default login ID on SQL server only allows a user to log into the server. To allow a user access to a database (without adding a username), a guest user must be added to the database. A visitor login ID is a general purpose login ID. The visitor and guest do not allow for unique identification and authentication, and therefore, do not provide accountability. These accounts should not be used without a business reason.

The public group contains all users. The keyword PUBLIC is used with the GRANT and REVOKE statements to signify that permission is granted to or taken away from all users.


3.7 Ensure that a user database has been selected for each login ID on the server. Review the column titled dbname of the Syslogins Table generated in the following query:


This is each users’ default database when connection is established. The security administer must specify a default database when server login Ids are created, or the master Database is selected.

Note: A default database is the database a user is connected to immediately after logging in to SQL server. However before a user can access objects in the default database, the user must be granted permissions for the database. Master should be the default database for the SA, however you should assign

of 27


default databases other than master to other users to discourage them from creating database objects in the master database.


3.8 Determine whether the SYSALTERNATES TABLE (for all databases being reviewed) is being used. Review the results of the following query and obtain a technical explanation of the business reason for all entries in the table:

Select “SERVER NAME=[place server name here]”Select ”DATABASE NAME”,db_name(),getdate() select a.suid,a.altsuid from sysalternates a

Sysalternates contains rows for users aliased to another ID, such as dbo.

The SYSALTERNATES TABLE contains one row for each SQL Server user mapped to a user (or with an alias) of the current database. When the user tries to access a database, SQL Server looks for a valid uid entry in SYSUSERS. If none is found there, it looks for a uid in the SYSALTERNATES Table. If the user’s suid is found there, he or she is treated as a user whose suid is listed in SYSALTERNATES.

The structure of the SYSALTERNATES TABLE is set forth below:


Suid Smallinit Server user ID of the user being mapped.

Altsuid Smallinit Server user ID of the user to whom another user is mapped.


3.9 Ensure that no user Ids are mapped to the user of another server user ID by reviewing the SYSALTERNATES TABLE generated in the following query:


A user should not need to switch to the user ID of another user, but should instead have his own ID with appropriately assigned user Ids.


3.10 Ensure that Aliases have not been set up for users of the SQL Server. To determine if Aliases are used, review the Altsuid column of the SYSALTERNATES TABLE by generating the following query:

of 27



You can also find all users aliased to a user name in a database by using the sp_ helpuser system procedure. The user name must be specified, or sp helpuser returns all the user names in the current database.

Note: An Alias allows a login ID to assume the identity of a user within the database. In this way, more than one user can be mapped to the same user name. The purpose of an Alias is to allow an individual to assume the identity of some database user without the DBO having to add him or her as a user in the database. It is typically used in temporary situations. A login ID cannot be aliased to a user if the login ID already exists as a user in the database. An individual can be aliased to more than one user at a time.


3.11 Determine that the System Administrator and Database Owner (i.e., the SA account and DBO accounts) have strong passwords established and are not set to blank, SA, DBO or admin.


3.12 Ensure the “probe” account has been assigned a strong password. By default this account is designed to run without any password and has limited access to server system libraries so it can obtain performance data. Note, in SQL 7.0, the probe account has been eliminated.


3.13 Ensure that SQL user accounts do not have weak passwords.

Check to see if user accounts have the password of “password” or if the password is the same as the user account name.


4. Implementing Access Controls: Ensure that access controls have been implemented that provided for the identification, authentication, authorization and monitoring of users accessing servers.

4.1 Determine if changes to SQL security settings are reviewed when initially set and then periodically thereafter.

4.1.1 Ensure all changes are reviewed by an individual other than the person who made the change.

4.1.2 Ensure all issues/concerns are reported to appropriate management.

of 27


Source Identifier: ISM Policy 5.30, ISM 5.30.10

4.2 Ensure that the most recent SQL service pack has been tested and applied.


5. Monitoring Access: Ensure that access to information is monitored to identify unauthorized or unusual access attempts.

5.1 Determine if audit trails are used to monitor unauthorized access attempts or security changes to the SQL Databases


6. Controlling Access to Work Area and Equipment: Ensure that the SQL server infrastructure is physically restricted to appropriate personnel.

6.1 Determine that access to the database console is physically protected from unauthorized access. This might include a review of card key access and camera controls for supported servers; if not performed during other audits.

Source Identifier: ISM 7.10.40, DP 4.50

6.2 Determine whether physical security can be bypassed by remote access to the SQL Server through Telnet or workstation located outside of the Network Communications Center server room.

Source Identifier: DP 6.50

6.3 Determine the process for safeguarding the production version of software. Locate the SQL Server and client Installation diskettes.

Source Identifier: DP 5.10

7. Continuity of Operations for Facilities and Equipment: Ensure continuity of operations by protecting equipment, providing for backup capabilities and facilitating replacement.

7.1 Determine whether management has evaluated the need for a contingency plan for the SQL Server. If the need exists, based on criticality of applications and services, determine whether a plan has been documented and that procedures have been tested.


of 27


7.2 Ensure that SQL Server software and Databases are backed up according to the business availability requirements documented in the Business continuity plan. At least one backup copy should be located off-site.


7.3 Ensure that restart and recovery procedures meet the business availability requirements documented in the business continuity plan.


8. Capacity Planning and Performance Planning: Determine if the SQL Database Management system is making adequate use of available system monitoring tools and whether resources are being managed efficiently.

8.1 Determine whether operating standards have been established for measuring economy and efficiency specific to SQL Servers and established operating standards are understood and are being met, and deviations from operating standards are identified, analyzed and communicated to those responsible for corrective action and whether corrective action has been taken.


8.2 Determine whether a process has been established for ongoing monitoring of capacity and performance.

The SQLPERF statement provides information about performance statistics. The options for this statement are IOSTATS, LRUSTATS, and NETSTATS. IOSTATS generates the I/O statistics since the server was last started or since the statistics were last cleared. LRUSTATS generates statistics about cache since the server was last started or since the statistics were last cleared. (LRU stands for "least recently used" and is the algorithm used by the SQL Server cache manager. NETSTATS provides statistics about network use. Use of the SQLPERF statement should be limited due to its heavy use of resources.

Note: SQL Server NT is integrated with the Windows NT Performance Monitor, thus providing another option for monitoring performance (besides sp_monitor and the DBCC SQLPERF options). The Performance monitor is a graphical tool for measuring the performance of a Windows NT-based computer or computers within a network. Statistics can be viewed such as processors, memory, devices, processes, threads, and so on.

If SQL Server is started as a service under Window NT operating system, events are logged to the SQL Server Error Log, the Windows NT Error Log or both.

of 27


If SQL Server is started from the command line under either operating system, events are logged to the SQL Server error log and to a standard output (typically the monitor, unless output has been directed elsewhere).


8.3 Review the problem logs to determine whether SQL Client/Server problems are receiving adequate attention.


of 27


APPENDIX A - EXPLANATION OF SYSTEM TABLES

System tables define the structure of the database. All system tables are found in the Master Database.

The following tables exist in the Master Database only:

System Table Description Syscharsets Has one row for each character set or sort

order.

Sysconfigures Has one row for each user-settable configuration option.

Syscurconfigs Contains configuration information about configuration options currently being used by SQL Server.

Sysdatabases Has one row for each database on the SQL Server.

Sysdevices Physical storage resources available to SQL servers (both active database devices and backup devices). Has one row for each device.

Syslanguages Has one row for each language.

Syslocks Contains information about active locks.

Syslogins Has one row for each valid SQL Server user account. This table includes the account, password and configuration information.

Sysmessages Has one row for each available system error or warning.

Sysprocesses Contains information about server processes.

Sysremotelogins Has one row for each remote user.

Sysservers Has one row for each remote SQL Server.

Sysusages Has one row for each disk piece allocated to a database.

of 27


IN ALL DATABASES

The following system tables exist in all databases: Syste m Table Description Sysalternates Maps SQL logon Ids to existing database user Ids,

providing the mapped logon Id all privileges currently granted the database user. Commonly used so that multiple users can access a database as dbo while maintaining their unique logon id.

Syscolumns Has one row for each column in a table, or view, and for each parameter in a stored procedure.

Syscomments Has one or more rows for each view, rule, default, trigger, and stored procedure with a SQL statement definition.

Sysdepends Has one row for each procedure, view, or table that is referenced by a procedure, view, or trigger.

Sysindexes Has one row for each clustered index, non-clustered index, and table with no indexes, plus an extra for each table with text or an image.

Syskeys Has one row for each foreign, primary, or common key.

Syslogs Contains the transaction log.

Sysobjects Has one row for each table, view, stored procedure, rule, trigger, default, log and (in temp only) temporary object.

Sysprocedures Has one row for each view, rule, default trigger, and stored procedure.

Sysprotects Contains user permission information for database objects.

Sysegments Has one row for each segment.

Systypes Has one row for each system-supplied and user-defined data type.

Sysysers A table of logon ids (master/syslogins) mapped to database user ids, the group ids associated with the user and the groups defined for the database. Has one row for each user allowed in the database.

of 27


SYSLOGINS TABLE (master database only)

With standard security, SQL Server manages its own validation process for all connections. When a user logs in, the SQL Server looks in the SYSLOGINS Table for the user’s log in ID and password. If the log in ID and password are valid, the user is connected to the SQL Server.

The SYSLOGINS TABLE is one of 13 system tables found in the Master Database1. This table contains one entry for each valid SQL Server user account. When SQL Server is installed, SYSLOGINS contains one entry, in which the name is SA, the SUID is 1, and the password is NULL. It also contains an entry named PROBE with a NULL password.

For each column, the system administrator can indicate whether null values are allowed. A null value is not the same as zero or blank. NULL means no entry has been made and usually implies that the value is unknown or inapplicable. It indicates that the user did not make an entry. (For example, a null value in the password column means that the password has not been entered.) If the system administrator or user fails to make an entry in a column defined with the keyword NULL, SQL Server supplies the value NULL. A column defined with the keyword NULL also excepts the explicit entry of NULL from the user, no matter what data type it is.

THE ABILITY TO LOGON TO THE SQL SERVER IS VERIFIED IN THE SYSLOGINS TABLE, HOWEVER, ACCESS TO DATABASES, OBJECTS, ETC., IS VERIFIED IN OTHER TABLES ONCE THE USER IS LOGGED ON TO THE SQL SERVER. THESE TABLES AND THEIR VALIDATION MECHANISM WILL BE REVIEWED IN OTHER STEPS OF THIS AUDIT PROGRAM.

The layout of the SYSLOGINS Table is set forth below.

COLUMN DATA TYPE DESCRIPTION

1. suid smallinit Server User ID

2. status smallinit Reserved

3. accdate datetime Reserved

4. totcpu init Reserved

5. totio init Reserved

6. spacelimit init Reserved

7. timelimit init Reserved

8. resultlimit init Reserved

1System tables define the structure of the database. All system tables are found in the master database. Some system tables are found in all databases: they are automatically created when the CREATE DATABASE statement is executed.

of 27


9. dbname sysname NULL

Name of the user’s default database when connection is established

10. name sysname Login ID of the user

11. password sysname NULL

Password of user (may be null)

12. language varchart (30) NULL

User’s default language (NULL for us English)

Technical Hint:The SYSLOGINS Table is referenced by the following System Procedures;

1. sp addalias2. sp addlogin3. sp addremotelogin4. sp adduser5. sp changdbowner6. sp defaultlanguage7. sp defaultdb8. sp droplogin9. sp helpdb10. sp helpuser11. sp password

SYSPROTECTS TABLE

Standard Security - perform this step.Mixed Security - perform this step.Integrated Security - perform this step.

The SYSPROTECTS Table exists in all databases and contains user permissions information - entries for GRANT and REVOKE statements that have been executed.

The format of this table is set forth on the following page.

of 27

Internal FR

COLUMN DATA TYPE DESCRIPTIONS

#1 id Init ID of object to which permission applies

#2 uid Smallinit ID of user or group to which this permission applies

#3 action Tinyint One of the following permissions.

193 SELECT

195 INSERT

196 DELETE

197 UPDATE

224 EXECUTE

203 CREATE DATABASE

233 CREATE DEFAULT

222 CREATE PROCEDURE

236 CREATE RULE

198 CREATE TABLE

207 CREATE VIEW

228 DUMP DATABASE

235 DUMP TRANSACTION

Protectype Tinyint Either 205 (GRANT) or 206 (REVOKE)

Columns varbinary (32) NULL

Bitmap of columns to which SELECT or UPDATE permissions applies. Bit 0 indicates all columns; bit 1 means permissions applies to that column; NULL means no information

of 27

Internal FR

The SYSPROTECTS Table is referenced by the following System procedures:

1. sp_dropgroup2. sp_dropuser3. sp_column_privileges4. sp_helprotect5. sp_stored_procedures6. sp_table_privileges7. sp_tables

SYSOBJECTS TABLE (all databases)

The SYSOBJECTS Table exists in all databases. This table contains one row for each table, view, stored procedure, rule, trigger default, log, and (in tempdb only) temporary objects. The format of the SYSLOGINS Table is set forth below.


name sysname Object name.

id int Object ID.

uid smallinit User ID of owner object.

type char One of the following object types.

S System Table

U User Table

V View

L Log

P Stored Procedure

R Rule

C CHECK Constraint

F FOREIGN KEY Constraint

TR Trigger

X Extended stored procedure

RF Stored procedure for replication

K PRIMARY KEY or UNIQUE constraint

of 27

Internal FR

D Default

TR Trigger

userstat smallint Application-dependent type information.

sysstat smallinit Internal-status information.

indexdel smallinit Index Count (incremented if an index is deleted).

schema smallint Count of changes in schema of a given rule (incremented if a rule or default is deleted).

refdate datetime Reserved.

crdate datetime Indicates the date that the object was created.

expdate datetime Reserved.

deltrig init Stored-procedure ID of a delete trigger.

instrig init Stored-procedure ID of an insert trigger.

updtrig init Stored-procedure ID of an update trigger.

seltrig init Reserved.

category init Used for publication, constraints and identity

cache smallint Reserved.

of 27

MS_SQL_Server.doc.doc.doc.doc.doc

Documents

Transcript of MS_SQL_Server.doc.doc.doc.doc.doc