UCF STIG Viewer Logo

SQL Server must employ NSA-approved cryptography to protect classified information.


Overview

Finding ID Version Rule ID IA Controls Severity
V-40918 SQL2-00-019800 SV-53272r3_rule Medium
Description
Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. NSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as: “Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA approved algorithms are used to protect systems requiring the most stringent protection mechanisms.” NSA-approved cryptography is required to be used for classified information system processing.
STIG Date
Microsoft SQL Server 2012 Database Instance Security Technical Implementation Guide 2015-06-23

Details

Check Text ( C-47573r4_chk )
Review system documentation to determine whether cryptography for classified or sensitive information is required by the information owner.

If the system documentation does not specify the type of information hosted on SQL Server: classified, sensitive and/or unclassified, this is a finding.

If neither classified nor sensitive information exists within SQL Server databases or configuration, this requirement is NA.
Note: If the SQL Server is compliant, nothing is displayed.

If cryptography is being used by SQL Server, examine evidence that an audit record is created whenever the asymmetric key is accessed by other than authorized users. In particular, view evidence that access by a SYSADMIN or other system privileged account results in the generation of an audit record. This is required because system privileges allow access to encryption keys and can use them to access sensitive data where they do not have a need-to-know.


Note: The list of acceptable algorithms: "AES 128", "AES 192", "AES 256" and "Triple DES".

If cryptography is being used by SQL Server, verify that the cryptography is NIST FIPS 140-2 certified by running the following SQL query:
EXEC sp_MSforeachdb
'
DECLARE @nCount integer;

SELECT @nCount = Count(*)
FROM [?].sys.symmetric_keys
WHERE key_algorithm NOT IN (''D3'',''A1'',''A2'',''A3'');

IF @nCount > 0
SELECT ''?'' AS ''database ?''
, name
, algorithm_desc
FROM [?].sys.symmetric_keys
WHERE key_algorithm NOT IN (''D3'',''A1'',''A2'',''A3'')
ORDER BY name, algorithm_desc;
'
;


If any items list showing an uncertified NIST FIPS 140-2 algorithm type, this is a finding.
If an audit record is not generated for unauthorized access to the asymmetric key, this is a finding.

Detailed information on the NIST Cryptographic Module Validation Program (CMVP) is available at the following website: http://csrc.nist.gov/groups/STM/cmvp/index.html.
Fix Text (F-46200r5_fix)
Document within the system documentation the type of information hosted on SQL Server: classified, sensitive, and/or unclassified.

Obtain and utilize native or third-party NIST-validated FIPS 140-2 compliant cryptography solution on SQL Server.
Configure cryptographic functions to use FIPS 140-2 compliant algorithms functions.

Use DoD code-signing certificates to create asymmetric keys stored in the database and used to encrypt sensitive data stored in the database.

Run the following SQL script to create a certificate:
USE
CREATE CERTIFICATE
ENCRYPTION BY PASSWORD = <'password'>
FROM FILE = <'path/file_name'>
WITH SUBJECT = 'name of person creating key',
EXPIRY_DATE = '<'expiration date: yyyymmdd'>'

Run the following SQL script to create a symmetric key and assign an existing certificate:
USE
CREATE SYMMETRIC KEY <'key name'>
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE

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.

For whole-database encryption (Transparent Data Encryption - TDE):
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '';
CREATE CERTIFICATE . . .;
USE ;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE ;
ALTER DATABASE
SET ENCRYPTION ON;