What changed in MS SQL Server 2016 Instance STIG V3R6V3R6 changes

MS SQL Server 2016 Instance STIG V3R6 (2026-01-05) replaced V3R5 (2025-07-02): 17 checks removed, 7 updated. It has 84 checks, against 101 in V3R5.

  • 0 added
  • 17 removed
  • 7 updated

Updated fields: Discussion 7Check text 6Title 4Fix text 2

Removed since V3R5 (17)

  • V-213962CAT IISQL Server must be configured to prohibit or restrict the use of organization-defined ports, as defined in the PPSM CAL and vulnerability assessments.
  • V-213963CAT IISQL Server must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
  • V-213971CAT IISQL Server must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.
  • V-213990CAT IISQL Server must disable network functions, ports, protocols, and services deemed by the organization to be nonsecure, in accord with the Ports, Protocols, and Services Management (PPSM) guidance.
  • V-213995CAT IISQL Server must be able to generate audit records when successful and unsuccessful attempts to access security objects occur.
  • V-213998CAT IISQL Server must generate audit records when successful and unsuccessful attempts to access categorized information (e.g., classification levels/security levels) occur.
  • V-214006CAT IISQL Server must generate audit records when successful and unsuccessful attempts to modify categorized information (e.g., classification levels/security levels) occur.
  • V-214010CAT IISQL Server must generate audit records when successful and unsuccessful attempts to delete security objects occur.
  • V-214012CAT IISQL Server must generate audit records when successful and unsuccessful attempts to delete categorized information (e.g., classification levels/security levels) occur.
  • V-214015CAT IISQL Server must generate audit records for all privileged activities or other system-level access.
  • V-214016CAT IISQL Server must generate audit records when unsuccessful attempts to execute privileged activities or other system-level access occur.
  • V-214017CAT IISQL Server must generate audit records showing starting and ending time for user access to the database(s).
  • V-214018CAT IISQL Server must generate audit records when concurrent logons/connections by the same user from different workstations occur.
  • V-214020CAT IISQL Server must generate audit records when successful and unsuccessful accesses to objects occur.
  • V-214022CAT ISQL Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to provision digital signatures.
  • V-214023CAT ISQL Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to generate and validate cryptographic hashes.
  • V-214024CAT IISQL Server must implement NIST FIPS 140-2 or 140-3 validated cryptographic modules to protect unclassified information requiring confidentiality and cryptographic protection, in accordance with the data owners requirements.

Updated in V3R6 (7)

V-213933CAT IISQL Server must protect against a user falsely repudiating by ensuring all accounts are individual, unique, and not shared.Check text, Discussion

Check text

Obtain the list of authorized SQL Server accounts in the system documentation. Determine if any accounts are shared. A shared account is defined as a username and password that are used by multiple individuals to log into SQL Server. An example of a shared account is the SQL Server installation account. Windows Groups are not shared accounts as the group itself does not have a password. If accounts are determined to be shared, determine if individuals are first individually authenticated. If individuals are not individually authenticated before using the shared account (e.g., by the operating system or possibly by an application making calls to the database), this is a finding. The key is individual accountability. If this can be traced, this is not a finding. If accounts are determined to be shared, determine if they are directly accessible to end users. If so, this is a finding. Review contents of audit logs, traces and data tables to confirm that the identity of the individual user performing the action is captured. If shared identifiers are found, and not accompanied by individual identifiers, this is a finding. Note: Privileged installation accounts may be required to be accessed by the DBA or other administrators for system maintenance. In these cases, each use of the account must be logged in some manner to assign accountability for any actions taken during the use of the account.

Discussion

Non-repudiationNonrepudiation of actions taken is required in order to maintain data integrity. Examples of particular actions taken by individuals include creating information, sending a message, approving information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiationNonrepudiation protects against later claims by a user of not having created, modified, or deleted a particular data item or collection of data in the database. In designing a database, the organization must define the types of data and the user actions that must be protected from repudiation. The implementation must then include building audit features into the application data tables and configuring SQL Server's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to SQL Server, even where the application connects to SQL Server with a standard, shared account. Satisfies: SRG-APP-000080-DB-000063, SRG-APP-000815-DB-000160

V-213939CAT IISQL Server must generate audit records when attempts to access privileges, categorized information, and security objects occur.Title, Check text, Discussion

Title

SQL Server must generate audit records when successful/unsuccessful attempts to raccetrievess privileges/p, categorized information, and ssecurity onbjects occur.

Check text

Review the system documentation to determine if SQL Server is required to audit when the retrievalfollowing ofevents occur: - Attempts to retrieve privilege/permission/role membership information. - Security objects are accessed, modified, or deleted. - Data classifications (e.g., classification levels/security levels) are accessed, modified, or deleted. - Any other specified objects are accessed, modified, or deleted as required by the site. If SQL Server is not required to audit theany retrieval of privilege/permission/rolethe membership informationabove, this is not a finding. If the documentation does not exist, this is a finding. Determine if an audit is configured and started by executing the following query. If no records are returned, this is a finding. SELECT name AS 'Audit Name', status_desc AS 'Audit Status', audit_file_path AS 'Current Audit File' FROM sys.dm_server_audit_status If the auditing the retrieval of privilege/permission/rolethe membershipabove information or objects is required, execute the following query to verify the SCHEMA_OBJECT_ACCESS_GROUP is included in the server audit specification.: SELECT a.name AS 'AuditName', s.name AS 'SpecName', d.audit_action_name AS 'ActionName', d.audited_result AS 'Result' FROM sys.server_audit_specifications s JOIN sys.server_audits a ON s.audit_guid = a.audit_guid JOIN sys.server_audit_specification_details d ON s.server_specification_id = d.server_specification_id WHERE a.is_state_enabled = 1 AND d.audit_action_name = 'SCHEMA_OBJECT_ACCESS_GROUP' If the SCHEMA_OBJECT_ACCESS_GROUP is not returned in an active audit, this is a finding.

Discussion

Under some circumstances, it may be useful to monitor who/what is reading privilege/permission/role information. Therefore, monitoring must be possible. DBMSs typically make such information available through views or functions. This requirement addresses explicit requests for privilege/permission/role membership information. It does not refer to the implicit retrieval of privileges/permissions/role memberships that SQL Server continually performs to determine if any and every action on the database is permitted. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. Satisfies: SRG-APP-000091-DB-000325, SRG-APP-000091-DB-000066, SRG-APP-000492-DB-000332, SRG-APP-000492-DB-000333, SRG-APP-000494-DB-000344, SRG-APP-000494-DB-000345, SRG-APP-000498-DB-000346, SRG-APP-000498-DB-000347, SRG-APP-000502-DB-000348, SRG-APP-000502-DB-000349, SRG-APP-000507-DB-000356, SRG-APP-000507-DB-000357

V-213961CAT IISQL Server must be configured to prohibit or restrict the use of organization-defined protocols as defined in the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and vulnerability assessments.Title, Check text, Fix text, Discussion

Title

SQL Server must be configured to prohibit or restrict the use of organization-defined protocols as defined in the Ports, Protocols, and Services Management (PPSM) Category Assurance List (CAL) and vulnerability assessments.

Check text

To determine the protocol(s) enabled for SQL Server, open SQL Server Configuration Manager. In the left-hand pane, expand SQL Server Network Configuration. Click on the entry for the SQL Server instance under review: "Protocols for ". The right-hand pane displays the protocols enabled for the instance. If Named Pipes is enabled and not specifically required and authorized, this is a finding. If any listed protocol is enabled but not authorized, this is a finding.

Fix text

In SQL Server Configuration Manager >> SQL Server Network Configuration >> Protocols, right-click on each listed protocol that is enabled but not authorized and Select "Disable".

Discussion

InTo order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary protocols on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of protocols to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. SQL Server using protocols deemed unsafe is open to attack through those protocols. This can allow unauthorized access to the database and through the database to other components of the information system. Satisfies: SRG-APP-000142-DB-000094, SRG-APP-000383-DB-000364

V-213969CAT ISQL Server must use NIST FIPS 140-2/140-3-validated cryptographic operations for encryption, hashing, and signing.Title, Check text, Fix text, Discussion

Title

SQL Server must use NIST FIPS 140-2 or /140-3 -validated cryptographic modulperations for encryptiogrn, hapshicng, operationd signing.

Check text

In Windows, open Administrative Tools >> Local Security Policy. Expand Local Policies >> Security Options. In the right-side pane, find "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing". If, in the "Security Setting" column, the value is "Disabled," this is a finding. https://support.microsoft.com/en-us/kb/955720

Fix text

In Windows, open Administrative Tools >> Local Security Policy. Expand Local Policies >> Security Options. In the right-side pane, double-click on "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing". In the dialog box that appears, if the radio buttons are active, click "Enabled", and then click "Apply". If the radio buttons are grayed out, use Group Policy Management (on the appropriate server for this domain) to enforce the Enabled policy, and deploy it to the server(s) running SQL Server.

Discussion

Use of weak or not validated cryptographic algorithms undermines the purposes of utilizing encryption and digital signatures to protect data. Weak algorithms can be easily broken, and not validated cryptographic modules may not implement algorithms correctly. Unapproved cryptographic modules or algorithms should not be relied on for authentication, confidentiality, or integrity. Weak cryptography could allow an attacker to gain access to, and modify data stored in, the database as well as the administration settings of SQL Server. Applications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 or /140-3 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. NSA Type- (where =1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules. The standard for validating cryptographic modules will transition to the NIST FIPS 140-3 publication. FIPS 140-2 modules can remain active for up to five years after validation or until September 21, 2026, when the FIPS 140-2 validations will be moved to the historical list. Even on the historical list, CMVP supports the purchase and use of these modules for existing systems. While Federalfederal Agenciesagencies decide when they move to FIPS 140-3 only modules, purchasers are reminded that for several years there may be a limited selection of FIPS 140-3 modules from which to choose. CMVP recommends purchasers consider all modules that appear on the Validated Modules Search Page: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules More information on the FIPS 140-3 transition can be found here: https://csrc.nist.gov/Projects/fips-140-3-transition-effort/ Satisfies: SRG-APP-000179-DB-000114, SRG-APP-000176-DB-000068, SRG-APP-000224-DB-000384, SRG-APP-000514-DB-000381, SRG-APP-000514-DB-000382, SRG-APP-000514-DB-000383

V-213989CAT IISQL Server must produce audit records when attempts to modify SQL Server configuration and privileges occur within the database(s).Title, Check text, Discussion

Title

SQL Server must produce audit records of its whenforcement of accttemptss restrictions assmociated withfy changesSQL to thServer configuration ofand SQL Seprivilerges occur within the database(s).

Check text

Determine if an audit is configured to capture denied actions and started by executing the following query: SELECT name AS 'Audit Name', status_desc AS 'Audit Status', audit_file_path AS 'Current Audit File' FROM sys.dm_server_audit_status If no records are returned, this is a finding. Execute the following query to verify the following events are included in the server audit specification: APPLICATION_ROLE_CHANGE_PASSWORD_GROUP, AUDIT_CHANGE_GROUP, BACKUP_RESTORE_GROUP, DATABASE_CHANGE_GROUP, DATABASE_OBJECT_ACCESS_GROUP, DATABASE_OBJECT_CHANGE_GROUP, DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP, DATABASE_OBJECT_PERMISSION_CHANGE_GROUP, DATABASE_OWNERSHIP_CHANGE_GROUP, DATABASE_OPERATION_GROUP, DATABASE_PERMISSION_CHANGE_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP, DATABASE_PRINCIPAL_IMPERSONATION_GROUP, DATABASE_ROLE_MEMBER_CHANGE_GROUP, DBCC_GROUP, LOGIN_CHANGE_PASSWORD_GROUP, SCHEMA_OBJECT_CHANGE_GROUP, SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP, SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP, SERVER_OBJECT_CHANGE_GROUP, SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP, SERVER_OBJECT_PERMISSION_CHANGE_GROUP, SERVER_OPERATION_GROUP, SERVER_PERMISSION_CHANGE_GROUP, SERVER_PRINCIPAL_IMPERSONATION_GROUP, SERVER_ROLE_MEMBER_CHANGE_GROUP, SERVER_STATE_CHANGE_GROUP, TRACE_CHANGE_GROUP SELECT a.name AS 'AuditName', s.name AS 'SpecName', d.audit_action_name AS 'ActionName', d.audited_result AS 'Result' FROM sys.server_audit_specifications s JOIN sys.server_audits a ON s.audit_guid = a.audit_guid JOIN sys.server_audit_specification_details d ON s.server_specification_id = d.server_specification_id WHERE a.is_state_enabled = 1 AND d.audit_action_name IN ( 'APPLICATION_ROLE_CHANGE_PASSWORD_GROUP', 'AUDIT_CHANGE_GROUP', 'BACKUP_RESTORE_GROUP', 'DATABASE_CHANGE_GROUP', 'DATABASE_OBJECT_ACCESS_GROUP', 'DATABASE_OBJECT_CHANGE_GROUP', 'DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP', 'DATABASE_OBJECT_PERMISSION_CHANGE_GROUP', 'DATABASE_OWNERSHIP_CHANGE_GROUP', 'DATABASE_OPERATION_GROUP', 'DATABASE_PERMISSION_CHANGE_GROUP', 'DATABASE_PRINCIPAL_CHANGE_GROUP', 'DATABASE_PRINCIPAL_IMPERSONATION_GROUP', 'DATABASE_ROLE_MEMBER_CHANGE_GROUP', 'DBCC_GROUP', 'LOGIN_CHANGE_PASSWORD_GROUP', 'SCHEMA_OBJECT_CHANGE_GROUP', 'SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP', 'SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP', 'SERVER_OBJECT_CHANGE_GROUP', 'SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP', 'SERVER_OBJECT_PERMISSION_CHANGE_GROUP', 'SERVER_OPERATION_GROUP', 'SERVER_PERMISSION_CHANGE_GROUP', 'SERVER_PRINCIPAL_IMPERSONATION_GROUP', 'SERVER_ROLE_MEMBER_CHANGE_GROUP', 'SERVER_STATE_CHANGE_GROUP', 'TRACE_CHANGE_GROUP' ) Order by d.audit_action_name If the identified groups are not returned, this is a finding.

Discussion

Without auditing the enforcement of access restrictions against changes to configuration, it would be difficult to identify attempted attacks, and an audit trail would not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact. Changes in the permissions, privileges, and roles granted to users and roles, as well as privileged activity, must be tracked. Without an audit trail, unauthorized elevation or restriction of privileges could go undetected. Elevated privileges give users access to information and functionality that they should not have; restricted privileges wrongly deny access to authorized users. A privileged function in this context is any operation that modifies the structure of the database, its built-in logic, or its security settings. This would include all Data Definition Language (DDL) statements and all security-related statements. In a SQL environment, it encompasses, but is not necessarily limited to, CREATE, ALTER, DROP, GRANT, REVOKE, and DENY. There may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples in SQL include TRUNCATE TABLE, SELECT, INSERT, UPDATE, or DELETE (to a security table executed by a user other than a security principal). Depending on the capabilities of SQL Server and the design of the database and associated applications, audit logging may be achieved by means of DBMS auditing features, database triggers, other mechanisms, or a combination of these. Note that it is particularly important to audit, and tightly control, any action that weakens the implementation of this requirement, since the objective is to have a complete audit trail of all administrative activity. To aid in diagnosis, it is necessary to track failed attempts in addition to the successful ones. Satisfies: SRG-APP-000381-DB-000361, SRG-APP-000495-DB-000326, SRG-APP-000495-DB-000327, SRG-APP-000495-DB-000328, SRG-APP-000495-DB-000329, SRG-APP-000499-DB-000330, SRG-APP-000499-DB-000331, SRG-APP-000504-DB-000354, SRG-APP-000504-DB-000355

V-214004CAT IISQL Server must generate audit records when successful and unsuccessful attempts to modify security objects occur.Discussion

Discussion

Changes in the database objects (tables, views, procedures, functions) that record and control permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized changes to the security subsystem could go undetected. The database could be severely compromised or rendered inoperative. To aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. Satisfies: SRG-APP-000496-DB-000334, SRG-APP-000496-DB-000335, SRG-APP-000501-DB-000336, SRG-APP-000501-DB-000337

V-214014CAT IISQL Server must generate audit records when successful and unsuccessful logons or connection attempts occur.Check text, Discussion

Check text

Determine if an audit is configured and started by executing the following query: SELECT name AS 'Audit Name', status_desc AS 'Audit Status', audit_file_path AS 'Current Audit File' FROM sys.dm_server_audit_status Execute the following query to verify the SUCCESSFUL_LOGIN_GROUP and FAILED_LOGIN_GROUP are included in the server audit specification. SELECT a.name AS 'AuditName', s.name AS 'SpecName', d.audit_action_name AS 'ActionName', d.audited_result AS 'Result' FROM sys.server_audit_specifications s JOIN sys.server_audits a ON s.audit_guid = a.audit_guid JOIN sys.server_audit_specification_details d ON s.server_specification_id = d.server_specification_id WHERE a.is_state_enabled = 1 AND d.audit_action_name IN ('SUCCESSFUL_LOGIN_GROUP', 'FAILED_LOGIN_GROUP') If both "SUCCESSFUL_LOGIN_GROUP" and "FAILED_LOGIN_GROUP" are returned in an active audit, this is not a finding. If both "SUCCESSFUL_LOGIN_GROUP" and "FAILED_LOGIN_GROUP" are not in the active audit, determine whether "Both failed and successful logins" is enabled. In SQL Management Studio: Right-click on the instance. >>- Select "Properties". >>- Select "Security" on the left hand side. >>- Check the setting for "Login auditing". If "Both failed and successful logins" is not selected, this is a finding.

Discussion

For completeness of forensic analysis, it is necessary to track who/what (a user or other principal) logs on to SQL Server. It is also necessary to track failed attempts to log on to SQL Server. While positive identification may not be possible in a case of failed authentication, as much information as possible about the incident must be captured. Satisfies: SRG-APP-000503-DB-000350, SRG-APP-000503-DB-000351, SRG-APP-000506-DB-000353

How these changes are found

Checks are matched across the two releases by V-number. A check counts as updated when DISA gave it a new rule revision (the r number in its SV-…_rule id) and its title, severity, check text, fix text, discussion, CCIs or other fields changed — the same comparison STIG Compare makes. Added checks are new V-numbers; removed checks are V-numbers V3R6 no longer has.

Comparing other releases, or this one against an older release? Pick any two in STIG Compare.