Microsoft SQL Server 2005 Database Security Technical Implementation Guide

U_SQL_Server_2005_Database_V8R1-8_Manual-xccdf.xml

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: [email protected]
Details

Version / Release: V8R1

Published: 2015-04-03

Updated At: 2018-09-23 12:43:46

Actions

Download

Filter

Vuln Rule Version CCI Severity Title Description
SV-23779r1_rule DM1709-SQLServer9 MEDIUM The guest user account should be disabled. 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
SV-23785r1_rule DM1715-SQLServer9 MEDIUM Object permission assignments should be authorized. 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
SV-23790r1_rule DM1749-SQLServer9 MEDIUM Permissions on system tables should be restricted to authorized accounts. 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
SV-23804r1_rule DM1760-SQLServer9 MEDIUM DDL permissions should be granted only to authorized accounts. 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
SV-23833r1_rule DM5144-SQLServer9 MEDIUM Permissions using the WITH GRANT OPTION should be granted only to DBA or application administrator accounts. 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
SV-24072r1_rule DG0015-SQLServer9 LOW Database applications should be restricted from using static DDL statements to modify the application schema. 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
SV-25285r1_rule DG0073-SQLServer9 MEDIUM Database accounts should not specify account lock times less than the site-approved minimum. 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
SV-24094r1_rule DG0091-SQLServer9 LOW Custom and GOTS application source code stored in the database should be protected with encryption or encoding. 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
SV-24066r1_rule DG0004-SQLServer9 MEDIUM Application object owner accounts should be disabled when not performing installation or maintenance actions. 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
SV-24098r1_rule DG0105-SQLServer9 MEDIUM DBMS application user roles should not be assigned unauthorized privileges. Unauthorized access to the data can lead to loss of confidentiality and integrity of the data.trueDatabase AdministratorDCFA-1
SV-19465r1_rule DG0166-SQLServer9 MEDIUM 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. 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
SV-23769r1_rule DM0531-SQLServer9 MEDIUM Fixed Database roles should have only authorized users or groups as members. 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
SV-23860r1_rule DM6175-SQLServer9 MEDIUM The Database Master key encryption password should meet DoD password complexity requirements. 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
SV-23861r1_rule DM6179-SQLServer9 MEDIUM The Database Master Key should be encrypted by the Service Master Key where required. 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
SV-25497r1_rule DM6180-SQLServer9 MEDIUM Database Master Key passwords shoud not be stored in credentials within the database. 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
SV-23863r1_rule DM6184-SQLServer9 MEDIUM Asymmetric keys should be derived from DoD PKI certificates. 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
SV-23862r1_rule DM6183-SQLServer9 MEDIUM Symmetric keys should use a master key, certificate, or asymmetric key to encrypt the key. 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
SV-23871r1_rule DM6196-SQLServer9 MEDIUM Object permissions should not be assigned to PUBLIC or GUEST. 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
SV-25498r1_rule DM6188-SQLServer9 MEDIUM The Service Master Key should be backed up, stored offline and off site. 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
SV-23864r1_rule DM6185-SQLServer9 MEDIUM Asymmetric private key encryption should use an authorized encryption type. 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
SV-24068r1_rule DG0008-SQLServer9 MEDIUM Application objects should be owned by accounts authorized for ownership. 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
SV-24106r1_rule DG0121-SQLServer9 MEDIUM Application users privileges should be restricted to assignment using application user roles. 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
SV-24307r1_rule DG0122-SQLServer9 MEDIUM Access to sensitive data should be restricted to authorized users identified by the Information Owner. 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
SV-25369r1_rule DG0138-SQLServer9 MEDIUM Access grants to sensitive data should be restricted to authorized user roles. 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
SV-21488r1_rule DG0165-SQLServer9 MEDIUM DBMS symmetric keys should be protected in accordance with NSA or NIST-approved key management technology or processes. 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
SV-21490r1_rule DG0172-SQLServer9 MEDIUM Changes to DBMS security labels should be audited. 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