Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

Microsoft SQL Server 2005 Database Security Technical Implementation Guide

V8R1.8 · · · Released 24 Jan 2014 · 26 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

The Microsoft SQL Server 2005 Database Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.
Sort by
b
The guest user account should be disabled.
Medium - V-2451 - SV-23779r1_rule
RMF Control
Severity
M
CCI
Version
DM1709-SQLServer9
Vuln IDs
  • V-2451
Rule IDs
  • SV-23779r1_rule
The guest user ID in a database allows access by all Windows login IDs without requiring an individual database account. This allows unauthorized access to the database.trueDatabase AdministratorIAAC-1
Checks:

Fix: F-19706r1_fix

Revoke connect permission from all databases except master and tempdb. From the query prompt: SELECT name FROM [master].sys.databases WHERE name NOT IN ('master', 'tempdb') AND state = 0 Repeat for each database: From the query prompt: USE [database name] REVOKE CONNECT FROM 'guest'

b
Object permission assignments should be authorized.
Medium - V-2457 - SV-23785r1_rule
RMF Control
Severity
M
CCI
Version
DM1715-SQLServer9
Vuln IDs
  • V-2457
Rule IDs
  • SV-23785r1_rule
Securely designed applications require only that database application user accounts have permissions to access and manipulate only the application data assigned to them in accordance with the their job function. Restrictions may be further restricted by granting data access to users only through execution of database procedures. Excess privileges can lead to unauthorized data access and can compromise data integrity.trueDatabase AdministratorECLP-1
Checks:

Fix: F-20259r1_fix

Revoke unauthorized permissions assigned to application user roles where supported by the DBMS vendor. From the query prompt: USE [database name] REVOKE [permission] ON [object] FROM [group name] Document assigned role permissions in the System Security Plan and authorize with the IAO.

b
Permissions on system tables should be restricted to authorized accounts.
Medium - V-2458 - SV-23790r1_rule
RMF Control
Severity
M
CCI
Version
DM1749-SQLServer9
Vuln IDs
  • V-2458
Rule IDs
  • SV-23790r1_rule
Microsoft SQL Server defaults to allow all users to view the majority of the system tables. The system tables contain information such as login IDs, permissions, objects and even the text of all stored procedures. In a secure environment, any direct access granted to these tables by users bypasses security controls defined within the associated system procedures and views. The bypass of these controls can lead to unauthorized viewing of sensitive data.trueDatabase AdministratorECLP-1
Checks:

Fix: F-24604r1_fix

Revoke permissions granted to system tables where supported by the DBMS vendor. From the query prompt: USE [database name] REVOKE [permission] ON [object name] FROM [user name] Document permission grants in the System Security Plan and authorize with the IAO.

b
DDL permissions should be granted only to authorized accounts.
Medium - V-2463 - SV-23804r1_rule
RMF Control
Severity
M
CCI
Version
DM1760-SQLServer9
Vuln IDs
  • V-2463
Rule IDs
  • SV-23804r1_rule
Data Definition Language (DDL) commands include CREATE, ALTER, and DROP object actions. These actions cause changes to the structure, definition and configuration of the DBMS as well as to the objects themselves that can affect any or all operations of the database. Such privileged actions, when not restricted to authorized persons and activities, can lead to a compromise of data and DBMS availability.trueDatabase AdministratorECLP-1
Checks:

Fix: F-14854r1_fix

Revoke DDL permissions from unauthorized accounts with the REVOKE command: From the query prompt: USE [database name] REVOKE [permission] FROM [user name] Document required DDL permission grants in the System Security Plan and authorize with the IAO.

b
Permissions using the WITH GRANT OPTION should be granted only to DBA or application administrator accounts.
Medium - V-2498 - SV-23833r1_rule
RMF Control
Severity
M
CCI
Version
DM5144-SQLServer9
Vuln IDs
  • V-2498
Rule IDs
  • SV-23833r1_rule
The WITH GRANT option assigned with privileges, allows the grantee of the privilege to re-grant the privilege to other accounts. Unauthorized or unmanaged assignment of privileges may result in a compromise of data confidentiality and database operation. Privilege assignment should be restricted to DBA, application object owner accounts and application administration accounts.trueDatabase AdministratorECLP-1
Checks:

Fix: F-2479r1_fix

Revoke unauthorized permissions granted with the WITH GRANT option. From the query prompt: USE [Database Name] REVOKE GRANT OPTION FOR [object] FROM [Principal] You may re-grant the object permissions to the Principal as shown below. From the query prompt: USE [Database Name] GRANT [permission] ON [object] TO [Principal] Document required object permission grants with Grant Option in the System Security Plan and authorize with the IAO.

a
Database applications should be restricted from using static DDL statements to modify the application schema.
Low - V-3727 - SV-24072r1_rule
RMF Control
Severity
L
CCI
Version
DG0015-SQLServer9
Vuln IDs
  • V-3727
Rule IDs
  • SV-24072r1_rule
Application users by definition and job function require only the permissions to manipulate data within database objects and execute procedures within the database. The statements used to define objects in the database are referred to as Data Definition Language (DDL) statements and include the CREATE, DROP, and ALTER object statements (DDL statements do not include CREATE USER, DROP USER, or ALTER USER actions). This requirement is included here as a production system would by definition not support changes to the data definitions. Where object creation is an indirect result of DBMS operation or dynamic object structures are required by the application function as is found in some object-oriented DBMS applications, this restriction does not apply. Re-use of static data structures to recreate temporary data objects are not exempted.trueInformation Assurance OfficerECSD-1, ECSD-2
Checks:

Fix: F-22643r1_fix

Coordinate with the application designer to modify the application to use static objects with temporary data rather than creating and using temporary objects. Document in the System Security Plan all known object creation that supports dynamic object usage.

b
Database accounts should not specify account lock times less than the site-approved minimum.
Medium - V-3817 - SV-25285r1_rule
RMF Control
Severity
M
CCI
Version
DG0073-SQLServer9
Vuln IDs
  • V-3817
Rule IDs
  • SV-25285r1_rule
Unauthorized access to database accounts may be thwarted by instituting a lock on the target account after the specified number of unsuccessful logins. If allowed to continue an attack unimpeded, the attempt could eventually become successful and compromise the database and data integrity.Database AdministratorECLO-1, ECLO-2
Checks: C-13830r1_chk

If no DBMS accounts authenticate using passwords, this check is Not a Finding. If DBMS uses Host Authentication only, this check is Not a Finding. If the DBMS does not natively support this functionality, this check is Not a Finding. If the DBMS is not configured to lock database accounts after three or an IAO-specified number of consecutive unsuccessful connection attempts within a 60 minute period, this is a Finding. Note: The counter may be reset to 0 if a third failed logon attempt does not occur before reset. Ensure password policy enforcement is enabled for SQL Server accounts per Check DG0079.

Fix: F-20069r1_fix

Set the failed login attempt count to 3 to trigger an account lockout or to the number specified in the System Security Plan where supported by the DBMS. Where this requirement is not compatible with the operation of a front-end application, the unsuccessful logon count and time will be specified and the operational need documented in the System Security Plan.

a
Custom and GOTS application source code stored in the database should be protected with encryption or encoding.
Low - V-3823 - SV-24094r1_rule
RMF Control
Severity
L
CCI
Version
DG0091-SQLServer9
Vuln IDs
  • V-3823
Rule IDs
  • SV-24094r1_rule
Source code may include information on data relationships, locations of sensitive data that are otherwise obscured, or other processing information that could aid a malicious user. Encoding or encryption of the custom source code objects within the database helps protect against this type of disclosure.trueDatabase AdministratorDCSL-1
Checks:

Fix: F-19555r1_fix

Recreate stored procedures and specify encryption using the ALTER PROCEDURE command. Example: ALTER PROCEDURE [MyProc] WITH ENCRYPTION AS SELECT [mycol1], [mycol2] FROM [mytable]... Replace objects specified between the "[]" characters with custom/GOTS procedure references. Document all exceptions to this requirement in the System Security Plan and authorize with the IAO.

b
Application object owner accounts should be disabled when not performing installation or maintenance actions.
Medium - V-5683 - SV-24066r1_rule
RMF Control
Severity
M
CCI
Version
DG0004-SQLServer9
Vuln IDs
  • V-5683
Rule IDs
  • SV-24066r1_rule
Object ownership provides all database object permissions to the owned object. Access to the application object owner accounts requires special protection to prevent unauthorized access and use of the object ownership privileges. In addition to the high privileges to application objects assigned to this account, it is also an account that, by definition, is not accessed interactively except for application installation and maintenance. This reduced access to the account means that unauthorized access to the account could go undetected. To help protect the account, it should be enabled only when access is required.trueDatabase AdministratorECLP-1
Checks:

Fix: F-20174r1_fix

Disable logins for all application object owner accounts or members of database roles that own objects: ALTER LOGIN [name] DISABLE Document application object owner accounts that are not disabled in the System Security Plan and authorize with the IAO.

b
DBMS application user roles should not be assigned unauthorized privileges.
Medium - V-15128 - SV-24098r1_rule
RMF Control
Severity
M
CCI
Version
DG0105-SQLServer9
Vuln IDs
  • V-15128
Rule IDs
  • SV-24098r1_rule
Unauthorized access to the data can lead to loss of confidentiality and integrity of the data.trueDatabase AdministratorDCFA-1
Checks:

Fix: F-23528r1_fix

Use the grant and revoke commands to assign the authorized privileges as listed in the System Security Plan to custom database application or application user roles.

b
Asymmetric keys used by the DBMS for encryption of sensitive data should use DoD PKI Certificates. Private keys used by the DBMS should be protected in accordance with NIST (unclassified data) or NSA (classified data) approved key management and processes.
Medium - V-15142 - SV-19465r1_rule
RMF Control
Severity
M
CCI
Version
DG0166-SQLServer9
Vuln IDs
  • V-15142
Rule IDs
  • SV-19465r1_rule
Encryption is only effective if the encryption method is robust and the keys used to provide the encryption are not easily discovered. Without effective encryption, sensitive data is vulnerable to unauthorized access.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-18431r1_fix

Use DOD code-signing certificates to create asymmetric keys stored in the database and used to encrypt sensitive data stored in the database. Assign the application object owner account as the owner of the asymmetric key. Create audit events for access to the key by other than the application owner account or approved application objects. Revoke any privileges assigned to the asymmetric key to other than the application object owner account and authorized users. Protect the private key by encrypting it with the database or service master key.

b
Fixed Database roles should have only authorized users or groups as members.
Medium - V-15151 - SV-23769r1_rule
RMF Control
Severity
M
CCI
Version
DM0531-SQLServer9
Vuln IDs
  • V-15151
Rule IDs
  • SV-23769r1_rule
Fixed database roles provide a mechanism to grant groups of privileges to users. These privilege groupings are defined by the installation or upgrade of the SQL Server software at the discretion of Microsoft. Memberships in these roles granted to users should be strictly controlled and monitored. Privileges assigned to these roles should be reviewed for change after software upgrade or maintenance to ensure that the privileges continue to be appropriate to the assigned members.trueDatabase AdministratorECLP-1
Checks:

Fix: F-19750r1_fix

Grant fixed database roles only to authorized accounts. Revoke unauthorized accounts from fixed database roles. From the SQL Server Management Studio GUI: To deassign roles: 1. Expand [instance name] 2. Expand Databases 3. Expand [database type] 4. Expand [database name] 5. Expand Security 6. Expand Roles 7. Expand Database Roles 8. Double-click the role to be removed from the assigned user 9. Select the user's account under Role Members 10. Click on the Remove button Document fixed database role grants in the System Security Plan and authorize with the IAO.

b
The Database Master key encryption password should meet DoD password complexity requirements.
Medium - V-15159 - SV-23860r1_rule
RMF Control
Severity
M
CCI
Version
DM6175-SQLServer9
Vuln IDs
  • V-15159
Rule IDs
  • SV-23860r1_rule
Weak passwords may be easily guessed. When passwords used to encrypt keys used for encryption of sensitive data, then the confidentiality of all data encrypted using that key is at risk.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-14843r1_fix

Assign an encryption password to the Database Master Key that is a minimum of 15 characters, contains at least 2 uppercase characters, 2 lowercase characters, 2 special characters, 2 numeric characters and has no repeating characters. To change the Database Master Key encryption password: USE [database name] ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = '[new password]' Note: The database master key encryption method should not be changed until the effects are thoroughly reviewed. Changing the master key encryption causes all encryption using the database master key to be decrypted and re-encrypted. This action should not be taken during a high-demand time. Please see the MS SQL Server documentation prior to re-encrypting the database master key for detailed information.

b
The Database Master Key should be encrypted by the Service Master Key where required.
Medium - V-15161 - SV-23861r1_rule
RMF Control
Severity
M
CCI
Version
DM6179-SQLServer9
Vuln IDs
  • V-15161
Rule IDs
  • SV-23861r1_rule
Protection of the Database Master Key is necessary to protect the confidentiality of sensitive data. When encrypted by the Service Master Key, SYSADMINs may access and use the key to view sensitive data that they are not authorized to view. Where alternate encryption means are not feasible, encryption by the Service Master Key may be necessary. To help protect sensitive data from unauthorized access by DBA's, mitigations may be in order. Mitigations may include automatic alerts or other audit events when the database master key is accessed outside of the application or by a DBA account.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-14856r1_fix

Where possible, encrypt the Database Master Key with a password known only to the application administrator. Where not possible, configure additional audit events or alerts to detect unauthorized access to the database master key by users not authorized to view sensitive data.

b
Database Master Key passwords shoud not be stored in credentials within the database.
Medium - V-15162 - SV-25497r1_rule
RMF Control
Severity
M
CCI
Version
DM6180-SQLServer9
Vuln IDs
  • V-15162
Rule IDs
  • SV-25497r1_rule
Storage of the database master key password in a database credential allows decryption of sensitive data by privileged users who may not have a need-to-know requirement to access the data.Database AdministratorIAKM-1, IAKM-2, IAKM-3
Checks: C-22863r1_chk

From the query prompt: SELECT COUNT(credential_id) FROM [master].sys.master_key_passwords If count is not 0, this is a Finding.

Fix: F-14844r1_fix

Use the stored procedure sp_control_dbmasterkey_password to remove any credentials that store database master key passwords. From the query prompt: EXEC SP_CONTROL_DBMASTERKEY_PASSWORD @db_name = '[database name]', @action = N'drop'

b
Asymmetric keys should be derived from DoD PKI certificates.
Medium - V-15164 - SV-23863r1_rule
RMF Control
Severity
M
CCI
Version
DM6184-SQLServer9
Vuln IDs
  • V-15164
Rule IDs
  • SV-23863r1_rule
Asymmetric keys derived from self-signed certificates or self-generated by other means do not meet the security requirements of DOD that require validation by DOD trusted certificate authorities.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-14859r1_fix

Where asymmetric key use is required, the asymmetric should be generated using a code-signing certificate or using the database master key to encrypt the private key. Use of the asymmetric key is expected in DOD installations to be used to support symmetric keys that are in turn used to encrypt sensitive data. In a DOD environment, asymmetric keys generated and stored within the SQL Server database are not expected to be used for storage of DOD PKI certificates associated with DOD personnel and used to authenticate them for any database access. CREATE ASYMMETRIC KEY [key name] OR CREATE ASYMMETRIC KEY [key name] FROM [asymmetric key source] [asymmetric key source] may be FILE = [strong file name] or EXECUTABLE FILE = 'executable file' or ASSEMBLY [assembly name] Each of the asymmetric key sources is expected in a DOD environment to files signed with code-signing certificates issued by the DOD PKMO. Use of the database master key to encrypt is acceptable, especially where the key is generated using the service master key which in turn is generated from the server certificate. In cases where the DBAs are not trusted, use of external key sources is required.

b
Symmetric keys should use a master key, certificate, or asymmetric key to encrypt the key.
Medium - V-15168 - SV-23862r1_rule
RMF Control
Severity
M
CCI
Version
DM6183-SQLServer9
Vuln IDs
  • V-15168
Rule IDs
  • SV-23862r1_rule
Symmetric keys are vulnerable if the symmetric key encryption is not protected from disclosure. Symmetric keys are well protected by use of either the database or the service master key. Where access by DBA's is not acceptable, use of the application code-signing certificate can be used to provide protection.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-14858r1_fix

Configure or alter symmetric keys to encrypt keys with certificates or authorized asymmetric keys: From the query prompt: ALTER SYMMETRIC KEY [key name] ADD ENCRYPTION BY CERTIFICATE [certificate name] ALTER SYMMETRIC KEY [key name] DROP ENCRYPTION BY [password, symmetric key or asymmetric key] The symmetric key must specify a certificate or asymmetric key for encryption. The certificate may be the code-signing certificate used by the application.

b
Object permissions should not be assigned to PUBLIC or GUEST.
Medium - V-15172 - SV-23871r1_rule
RMF Control
Severity
M
CCI
Version
DM6196-SQLServer9
Vuln IDs
  • V-15172
Rule IDs
  • SV-23871r1_rule
The guest account is available to users that do not have authorized accounts on the database. The PUBLIC role is granted to all users of the database regardless of assigned job function. Assignment of object privileges to unauthorized users can compromise data integrity and/or confidentiality.trueDatabase AdministratorECLP-1
Checks:

Fix: F-19722r1_fix

Revoke any unauthorized object privileges assigned to PUBLIC or GUEST where supported by the DBMS vendor. Document all remaining object privileges assigned to PUBLIC in the System Security Plan and authorize with the IAO. From the query prompt: SELECT name FROM [master].sys.databases WHERE state = 0 Repeat for each database: From the query prompt: USE [database name] REVOKE [privilege] ON [object name] FROM '[public or guest]' Repeat for each object privilege assigned to public or guest: From the query prompt: USE [database name] REVOKE [permission] ON [schema name].[object name] TO PUBLIC To determine correct schema name for the object, use: SELECT SCHEMA_NAME(schema_id) FROM [master].sys.all_objects WHERE name = '[object name]'

b
The Service Master Key should be backed up, stored offline and off site.
Medium - V-15177 - SV-25498r1_rule
RMF Control
Severity
M
CCI
Version
DM6188-SQLServer9
Vuln IDs
  • V-15177
Rule IDs
  • SV-25498r1_rule
Backup and recovery of the Service Master Key may be critical to the complete recovery of the database.Database AdministratorIAKM-1, IAKM-2, IAKM-3
Checks: C-13824r1_chk

Review procedures for and evidence of backup of the SQL Server Service Master Key in the System Security Plan. If the procedures or evidence does not exist, this is a Finding. If the procedures do not indicate offline and off-site storage of the Service Master Key, this is a Finding. If procedures do not indicate access restrictions to the Service Master Key backup, this is a Finding.

Fix: F-14845r1_fix

Document and implement procedures to safely backup and store the service master key. Include in the procedures methods to establish evidence of backup and storage and careful, restricted access and restoration of the service master key. Also, include provisions to store the key offsite. BACKUP SERVICE MASTER KEY TO FILE = 'path_to_file' ENCRYPTION BY PASSWORD = 'password'

b
Asymmetric private key encryption should use an authorized encryption type.
Medium - V-15185 - SV-23864r1_rule
RMF Control
Severity
M
CCI
Version
DM6185-SQLServer9
Vuln IDs
  • V-15185
Rule IDs
  • SV-23864r1_rule
Asymmetric keys stored in the database that also include storage of the private key require protection from any unauthorized user. To protect unauthorized access and use of any asymmetric key by DBA's or users with SYSADMIN privileges, a password must be used to encrypt the private key. Use of the Database Master Key or Service Master Key allows access by the DBA. Consider the protection requirements for asymmetric key usage and document this in the System Security Plan. Avoid storage of static asymmetric private keys that is keys not generated and maintained for temporary session or other temporary usage, in the database.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-14860r1_fix

If stored with a private key, the private key is always encrypted either by a specified password, or by the database or service master key. Create or alter the asymmetric key with the approved encryption type specified in the System Security Plan. Document the approved encryption method after considering whether the DBA should be trusted to access the asymmetric key.

b
Application objects should be owned by accounts authorized for ownership.
Medium - V-15607 - SV-24068r1_rule
RMF Control
Severity
M
CCI
Version
DG0008-SQLServer9
Vuln IDs
  • V-15607
Rule IDs
  • SV-24068r1_rule
Database object ownership implies full privileges to the owned object including the privilege to assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of objects can lead to unauthorized object grants and alterations.trueDatabase AdministratorECLP-1
Checks:

Fix: F-17828r1_fix

Create database accounts dedicated for application object ownership. To simplify access authorizations, use a single account for each application to avoid cross chaining of ownership, which makes security configuration more complex and degrades system performance. Document all application object ownership in the System Security Plan and authorize with the IAO.

b
Application users privileges should be restricted to assignment using application user roles.
Medium - V-15629 - SV-24106r1_rule
RMF Control
Severity
M
CCI
Version
DG0121-SQLServer9
Vuln IDs
  • V-15629
Rule IDs
  • SV-24106r1_rule
Privileges granted outside the role of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.trueDatabase AdministratorECLP-1
Checks:

Fix: F-23530r1_fix

Revoke permissions assigned directly to user accounts and grant them instead to the appropriate group account. From the query prompt: REVOKE [permission] ON [object] FROM [user name] GRANT [permission] ON [object] TO [group name] Document any exceptions to privileges that cannot be assigned via database roles in the System Security Plan.

b
Access to sensitive data should be restricted to authorized users identified by the Information Owner.
Medium - V-15630 - SV-24307r1_rule
RMF Control
Severity
M
CCI
Version
DG0122-SQLServer9
Vuln IDs
  • V-15630
Rule IDs
  • SV-24307r1_rule
Unauthorized access to sensitive data can lead to unauthorized disclosure, modification or accountability. Access to sensitive data that is granted that is not restricted at all levels based on job function may be exploited regardless of attempts to control. An example of this is a web application that serves general users, but that access sensitive data in a backend database using an account with elevated privileges. This provides a means for the web application user to exploit the application to gain unauthorized access to data in the database. Where the user never has access to a path with excess privileges, unauthorized access is more difficult to gain.Database AdministratorECAN-1
Checks: C-13833r1_chk

If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. Review privilege assignments to sensitive data stored in the database. Compare assigned privileges to those that are authorized in the System Security Plan. If unauthorized access is granted or sensitive data access requirements are not documented, this is a Finding.

Fix: F-23498r1_fix

Have the Information Owner identify all sensitive data stored in the database specified in the System Security Plan. Define job functions and sensitive data access requirements for the job functions and included them in the System Security Plan. Assign only authorized users for job functions.

b
Access grants to sensitive data should be restricted to authorized user roles.
Medium - V-15642 - SV-25369r1_rule
RMF Control
Severity
M
CCI
Version
DG0138-SQLServer9
Vuln IDs
  • V-15642
Rule IDs
  • SV-25369r1_rule
Unauthorized access to sensitive data may compromise the confidentiality of personnel privacy, threaten national security or compromise a variety of other sensitive operations. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user.Database AdministratorECAN-1
Checks: C-13841r1_chk

If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. Review data access requirements for sensitive data as identified and assigned by the Information Owner in the System Security Plan. Review the access controls for sensitive data configured in the database. If the configured access controls do not match those defined in the System Security Plan, this is a Finding.

Fix: F-23502r1_fix

Define, document and implement all sensitive data access controls based on job function in the System Security Plan.

b
DBMS symmetric keys should be protected in accordance with NSA or NIST-approved key management technology or processes.
Medium - V-15654 - SV-21488r1_rule
RMF Control
Severity
M
CCI
Version
DG0165-SQLServer9
Vuln IDs
  • V-15654
Rule IDs
  • SV-21488r1_rule
Symmetric keys used for encryption protect data from unauthorized access. However, if not protected in accordance with acceptable standards, the keys themselves may be compromised and used for unauthorized data access.trueDatabase AdministratorIAKM-1, IAKM-2, IAKM-3
Checks:

Fix: F-20181r1_fix

Document all users authorized to access the database master key in the System Security Plan. Restrict authorized users to the application, database owner and SYSADMINs. For each unauthorized user: From the query prompt: REVOKE CONTROL FROM [user name]

b
Changes to DBMS security labels should be audited.
Medium - V-15657 - SV-21490r1_rule
RMF Control
Severity
M
CCI
Version
DG0172-SQLServer9
Vuln IDs
  • V-15657
Rule IDs
  • SV-21490r1_rule
Some DBMS systems provide the feature to assign security labels to data elements. The confidentiality and integrity of the data depends upon the security label assignment where this feature is in use. Changes to security label assignment may indicate suspicious activity.Database AdministratorECLC-1
Checks: C-23697r1_chk

If no data is identified as being sensitive or classified by the Information Owner, in the System Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding. If no identified sensitive or classified data requires encryption by the Information Owner in the System Security Plan and/or AIS Functional Architecture documentation, this check is Not a Finding. If the DBMS does not provide the capability to display sensitivity marking of data, this check is Not a Finding. For SQL Server 2005: Review the DBMS configuration for marking and labeling of sensitive data. http://www.microsoft.com/technet/prodtechnol/sql/2005/multisec.mspx If security label assignment is not audited for changes, this is a Finding.

Fix: F-20183r1_fix

Define the policy for auditing changes to security labels defined for the data. Document the audit requirements in the System Security Plan and configure database auditing in accordance with the policy.