kriterion 0.0.1

data/standards/stig_ms_sql_server_2016_database.json

@@ -0,0 +1,185 @@
+{
+  "name": "stig_ms_sql_server_2016_database",
+  "date": "2018-03-09",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
+  "title": "MS SQL Server 2016 Database Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-79061",
+      "title": "SQL Server databases must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.",
+      "description": "Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization.\n\nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. \n\nExamples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage.\n\nSQL Server must be configured to automatically utilize organization-level account management functions, and these functions must immediately enforce the organization's current account policy. \n\nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79063",
+      "title": "SQL Server must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.",
+      "description": "Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization.\n\nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed. \n\nExamples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage.\n\nSQL Server must be configured to automatically utilize organization-level account management functions, and these functions must immediately enforce the organization's current account policy. \n\nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79065",
+      "title": "SQL Server must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.",
+      "description": "Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access SQL Server.  To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies. \n\nSuccessful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. \n\nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. \n\nThis requirement is applicable to access control enforcement applications, a category that includes database management systems.  If SQL Server does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79067",
+      "title": "SQL Server must protect against a user falsely repudiating by ensuring only clearly unique Active Directory user accounts can connect to the database.",
+      "description": "Non-repudiation 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. \n\nNon-repudiation 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.\n\nIn 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 the DBMS's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to the DBMS, even where the application connects to the DBMS with a standard, shared account.\n\nIf the computer account of a remote computer is granted access to a SQL Server database, any service or scheduled task running as NT AUTHORITY\\SYSTEM or NT AUTHORITY\\NETWORK SERVICE can log into the instance and perform actions. These actions cannot be traced back to a specific user or process.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79069",
+      "title": "SQL Server must protect against a user falsely repudiating by use of system-versioned tables (Temporal Tables).",
+      "description": "Non-repudiation 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.\n\nNon-repudiation 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. \n\nIn 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. \n\nApplications should use temporal tables to track the changes and history of sensitive data.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79071",
+      "title": "SQL Server must protect against a user falsely repudiating by ensuring databases are not in a trust relationship.",
+      "description": "Non-repudiation 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. \n\nNon-repudiation 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.\n\nSQL Server provides the ability for high privileged accounts to impersonate users in a database using the TRUSTWORTHY feature. This will allow members of the fixed database role to impersonate any user within the database. ",
+      "severity": "high"
+    },
+    {
+      "id": "V-79073",
+      "title": "SQL Server must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.",
+      "description": "Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events.\n\nSuppression of auditing could permit an adversary to evade detection.\n\nMisconfigured audits can degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79075",
+      "title": "SQL Server must limit privileges to change software modules, to include stored procedures, functions, and triggers.",
+      "description": "If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79077",
+      "title": "SQL Server must limit privileges to change software modules, to include stored procedures, functions, and triggers, and links to software external to SQL Server.",
+      "description": "If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79079",
+      "title": "Database objects (including but not limited to tables, indexes, storage, stored procedures, functions, triggers, links to software external to SQL Server, etc.) must be owned by database/DBMS principals authorized for ownership.",
+      "description": "Within the database, object ownership implies full privileges to the owned object, including the privilege to assign access to the owned objects to other subjects. Database functions and procedures can be coded using definer's rights. This allows anyone who utilizes the object to perform the actions if they were the owner. If not properly managed, this can lead to privileged actions being taken by unauthorized individuals.\n\nConversely, if critical tables or other objects in SQL Server rely on unauthorized owner accounts, these objects may be lost when an account is removed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79081",
+      "title": "The role(s)/group(s) used to modify database structure (including but not necessarily limited to tables, indexes, storage, etc.) and logic modules (stored procedures, functions, triggers, links to software external to SQL Server, etc.) must be restricted to authorized users.",
+      "description": "If SQL Server were to allow any user to make changes to database structure or logic, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.\n\nAccordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.\n\nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79083",
+      "title": "In the event of a system failure, hardware loss or disk failure, SQL Server must be able to restore necessary databases with least disruption to mission processes.",
+      "description": "Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. In the event of a system failure, SQL Server must be able to bring the database back to a consistent state.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79085",
+      "title": "The Database Master Key encryption password must meet DOD password complexity requirements.",
+      "description": "Weak passwords may be easily guessed. When passwords are used to encrypt keys used for encryption of sensitive data, then the confidentiality of all data encrypted using that key is at risk.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79087",
+      "title": "The Database Master Key must be encrypted by the Service Master Key, where a Database Master Key is required and another encryption method has not been specified.",
+      "description": "When not encrypted by the Service Master Key, system administrators or application administrators may access and use the Database Master 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 DBAs, 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79089",
+      "title": "The Certificate used for encryption must be backed up, stored offline and off-site.",
+      "description": "Backup and recovery of the Certificate used for encryption is critical to the complete recovery of the database. Not having this key can lead to loss of data during recovery.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79091",
+      "title": "SQL Server must isolate security functions from non-security functions.",
+      "description": "An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions. \n\nSecurity functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.\n\nDevelopers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. \n\nDatabase Management Systems typically separate security functionality from non-security functionality via separate databases or schemas. Database objects or code implementing security functionality should not be commingled with objects or code implementing application logic. When security and non-security functionality are commingled, users who have access to non-security functionality may be able to access security functionality.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79093",
+      "title": "Database contents must be protected from unauthorized and unintended information transfer by enforcement of a data-transfer policy.",
+      "description": "Applications, including DBMSs, must prevent unauthorized and unintended information transfer via shared system resources. \n\nData used for the development and testing of applications often involves copying data from production. It is important that specific procedures exist for this process, to include the conditions under which such transfer may take place, where the copies may reside, and the rules for ensuring sensitive data are not exposed.\n\nCopies of sensitive data must not be misplaced or left in a temporary location without the proper controls.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79095",
+      "title": "SQL Server must check the validity of all data inputs except those specifically identified by the organization.",
+      "description": "Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid user input is one of the primary methods employed when attempting to compromise an application.\n\nWith respect to database management systems, one class of threat is known as SQL Injection, or more generally, code injection. It takes advantage of the dynamic execution capabilities of various programming languages, including dialects of SQL. Potentially, the attacker can gain unauthorized access to data, including security settings, and severely corrupt or destroy the database.\n\nEven when no such hijacking takes place, invalid input that gets recorded in the database, whether accidental or malicious, reduces the reliability and usability of the system. Available protections include data types, referential constraints, uniqueness constraints, range checking, and application-specific logic. Application-specific logic can be implemented within the database in stored procedures and triggers, where appropriate.\n\nThis calls for inspection of application source code, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79097",
+      "title": "SQL Server must provide non-privileged users with error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.",
+      "description": "Any DBMS or associated application providing too much information in error messages on the screen or printout risks compromising the data and security of the system. The structure and content of error messages need to be carefully considered by the organization and development team.\n\nDatabases can inadvertently provide a wealth of information to an attacker through improperly handled error messages. In addition to sensitive business or personal information, database errors can provide host names, IP addresses, user names, and other system information not required for troubleshooting but very useful to someone targeting the system.\n\nCarefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79099",
+      "title": "SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in storage.",
+      "description": "Without the association of security labels to information, there is no basis for SQL Server to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy.\n\nOne example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.\n\nThe mechanism used to support security labeling may be a feature of SQL Server, a third-party product, or custom application code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79101",
+      "title": "SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in process.",
+      "description": "Without the association of security labels to information, there is no basis for SQL Server to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.\n\nThese labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy.\n\nOne example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.\n\nThe mechanism used to support security labeling may be a feature of SQL Server, a third-party product, or custom application code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79103",
+      "title": "SQL Server must associate organization-defined types of security labels having organization-defined security label values with information in transmission.",
+      "description": "Without the association of security labels to information, there is no basis for SQL Server to make security-related access-control decisions.\n\nSecurity labels are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These labels are typically associated with internal data structures (e.g., tables, rows) within the database and are used to enable the implementation of access control and flow control policies; reflect special dissemination, handling, or distribution instructions; or support other aspects of the information security policy. One example includes marking data as classified or FOUO. These security labels may be assigned manually or during data processing, but, either way, it is imperative these assignments are maintained while the data is in storage. If the security labels are lost when the data is stored, there is the risk of a data compromise.\n\nThe mechanism used to support security labeling may be a feature of SQL Server, a third-party product, or custom application code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79105",
+      "title": "SQL Server must enforce discretionary access control policies, as defined by the data owner, over defined subjects and objects.",
+      "description": "Discretionary Access Control (DAC) is based on the notion that individual users are \"owners\" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled table permissions.\n\nWhen discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. \n\nA subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. \n\nThe policy is bounded by the information system boundary. Once the information is passed outside of the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79107",
+      "title": "Execution of stored procedures and functions that utilize execute as must be restricted to necessary cases only.",
+      "description": "In certain situations, to provide required functionality, a DBMS needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations.\n\nPrivilege elevation must be utilized only where necessary and protected from misuse.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79109",
+      "title": "SQL Server must prohibit user installation of logic modules (stored procedures, functions, triggers, views, etc.) without explicit privileged status.",
+      "description": "Allowing regular users to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceed the rights of a regular user.\n\nDBMS functionality and the nature and requirements of databases will vary; so while users are not permitted to install unapproved software, there may be instances where the organization allows the user to install approved software packages such as from an approved software repository. The requirements for production servers will be more restrictive than those used for development and research.\n\nSQL Server must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization). \n\nIn the case of a database management system, this requirement covers stored procedures, functions, triggers, views, etc.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79111",
+      "title": "SQL Server must enforce access restrictions associated with changes to the configuration of the database(s).",
+      "description": "Failure to provide logical access restrictions associated with changes to configuration may have significant effects on the overall security of the system. \n\nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system. \n\nAccordingly, only qualified and authorized individuals should be allowed to obtain access to system components for the purposes of initiating changes, including upgrades and modifications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79113",
+      "title": "SQL Server must use NSA-approved cryptography to protect classified information in accordance with the data owners requirements.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.\n\nIt is the responsibility of the data owner to assess the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards.\n\nNSA-approved cryptography for classified networks is hardware based. This requirement addresses the compatibility of a DBMS with the encryption devices.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79115",
+      "title": "SQL Server must implement cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest (to include, at a minimum, PII and classified information) on organization-defined information system components.",
+      "description": "DBMSs handling data requiring \"data at rest\" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to SQL Server or implemented via additional software or operating system/file system settings, as appropriate to the situation.\n\nSelection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). \n\nThe decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79117",
+      "title": "SQL Server must implement cryptographic mechanisms preventing the unauthorized disclosure of organization-defined information at rest on organization-defined information system components.",
+      "description": "SQL Server’s handling data requiring \"data at rest\" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. These cryptographic mechanisms may be native to SQL Server or implemented via additional software or operating system/file system settings, as appropriate to the situation.\n\nSelection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). \n\nThe decision whether and what to encrypt rests with the data owner and is also influenced by the physical measures taken to secure the equipment and media on which the information resides.",
+      "severity": "medium"
+    }
+  ]
+}

data/standards/stig_ms_sql_server_2016_instance.json

@@ -0,0 +1,731 @@
+{
+  "name": "stig_ms_sql_server_2016_instance",
+  "date": "2018-03-09",
+  "description": "This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.",
+  "title": "MS SQL Server 2016 Instance Security Technical Implementation Guide",
+  "version": "1",
+  "item_syntax": "^\\w-\\d+$",
+  "section_separator": null,
+  "items": [
+    {
+      "id": "V-79119",
+      "title": "SQL Server must limit the number of concurrent sessions to an organization-defined number per user for all accounts and/or account types.",
+      "description": "Database management includes the ability to control the number of users and user sessions utilizing SQL Server. Unlimited concurrent connections to SQL Server could allow a successful Denial of Service (DoS) attack by exhausting connection resources; and a system can also fail or be degraded by an overload of legitimate users. Limiting the number of concurrent sessions per user is helpful in reducing these risks. \n  \nThis requirement addresses concurrent session control for a single account. It does not address concurrent sessions by a single user via multiple system accounts; and it does not deal with the total number of sessions across all accounts. \n  \nThe capability to limit the number of concurrent sessions per user must be configured in or added to SQL Server (for example, by use of a logon trigger), when this is technically feasible. Note that it is not sufficient to limit sessions via a web server or application server alone, because legitimate users and adversaries can potentially connect to SQL Server by other means. \n  \nThe organization will need to define the maximum number of concurrent sessions by account type, by account, or a combination thereof. In deciding on the appropriate number, it is important to consider the work requirements of the various types of users. For example, 2 might be an acceptable limit for general users accessing the database via an application; but 10 might be too few for a database administrator using a database management GUI tool, where each query tab and navigation pane may count as a separate session. \n  \n(Sessions may also be referred to as connections or logons, which for the purposes of this requirement are synonyms.)",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79121",
+      "title": "SQL Server must integrate with an organization-level authentication/access mechanism providing account management and automation for all users, groups, roles, and any other principals.",
+      "description": "Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization. \n \nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed.  \n \nExamples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage. \n \nSQL Server must be configured to automatically utilize organization-level account management functions, and these functions must immediately enforce the organization's current account policy.  \n \nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79123",
+      "title": "SQL Server must be configured to utilize the most-secure authentication method available.",
+      "description": "Enterprise environments make account management for applications and databases challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error. Managing accounts for the same person in multiple places is inefficient and prone to problems with consistency and synchronization. \n \nA comprehensive application account management process that includes automation helps to ensure that accounts designated as requiring attention are consistently and promptly addressed.  \n \nExamples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated, or by disabling accounts located in non-centralized account stores, such as multiple servers. Account management functions can also include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephone notification to report atypical system account usage. \n \nSQL Server must be configured to automatically utilize organization-level account management functions, and these functions must immediately enforce the organization's current account policy.  \n \nAutomation may be comprised of differing technologies that when placed together contain an overall mechanism supporting an organization's automated account management requirements. \n \nSQL Server supports several authentication methods to allow operation in various environments, Kerberos, NTLM, and SQL Server. An instance of SQL Server must be configured to utilize the most-secure method available. Service accounts utilized by SQL Server should be unique to a given instance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79125",
+      "title": "SQL Server must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.",
+      "description": "Authentication with a DoD-approved PKI certificate does not necessarily imply authorization to access SQL Server.  To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems, including databases, must be properly configured to implement access control policies.  \n \nSuccessful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.  \n \nAccess control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.  \n \nThis requirement is applicable to access control enforcement applications, a category that includes database management systems.  If SQL Server does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79127",
+      "title": "SQL Server must protect against a user falsely repudiating by ensuring all accounts are individual, unique, and not shared.",
+      "description": "Non-repudiation 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.  \n \nNon-repudiation 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. \n \nIn 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79129",
+      "title": "SQL Server must protect against a user falsely repudiating by ensuring the NT AUTHORITY SYSTEM account is not used for administration.",
+      "description": "Non-repudiation 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.  \n \nNon-repudiation 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. \n \nIn 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 the DBMS's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to the DBMS, even where the application connects to the DBMS with a standard, shared account. \n \nAny user with enough access to the server can execute a task that will be run as NT AUTHORITY\\SYSTEM either using task scheduler or other tools. At this point, NT AUTHORITY\\SYSTEM essentially becomes a shared account because the operating system and SQL Server are unable to determine who created the process. \n \nPrior to SQL Server 2012, NT AUTHORITY\\SYSTEM was a member of the sysadmin role by default. This allowed jobs/tasks to be executed in SQL Server without the approval or knowledge of the DBA because it looked like operating system activity.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79131",
+      "title": "SQL Server must protect against a user falsely repudiating by ensuring only clearly unique Active Directory user accounts can connect to the instance.",
+      "description": "Non-repudiation 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.  \n \nNon-repudiation 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. \n \nIn 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 the DBMS's audit tools to capture the necessary audit trail. Design and implementation also must ensure that applications pass individual user identification to the DBMS, even where the application connects to the DBMS with a standard, shared account. \n \nIf the computer account of a remote computer is granted access to SQL Server, any service or scheduled task running as NT AUTHORITY\\SYSTEM or NT AUTHORITY\\NETWORK SERVICE can log into the instance and perform actions. These actions cannot be traced back to a specific user or process.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79133",
+      "title": "SQL Server must be configured to generate audit records for DoD-defined auditable events within all DBMS/database components.",
+      "description": "Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.  \n \nAudit records can be generated from various components within SQL Server (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. \n \nDoD has defined the list of events for which SQL Server will provide an audit record generation capability as the following:  \n \n(i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); \n \n(ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and \n \n(iii) All account creation, modification, disabling, and termination actions. \n \nOrganizations may define additional events requiring continuous or ad hoc auditing.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79135",
+      "title": "SQL Server must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.",
+      "description": "Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent or interfere with the auditing of critical events. \n \nSuppression of auditing could permit an adversary to evade detection. \n \nMisconfigured audits can degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79137",
+      "title": "SQL Server must generate audit records when privileges/permissions are retrieved.",
+      "description": "Under some circumstances, it may be useful to monitor who/what is reading privilege/permission/role information. Therefore, it must be possible to configure auditing to do this. DBMSs typically make such information available through views or functions. \n \nThis 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79139",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to retrieve privileges/permissions occur.",
+      "description": "Under some circumstances, it may be useful to monitor who/what is reading privilege/permission/role information. Therefore, it must be possible to configure auditing to do this. DBMSs typically make such information available through views or functions. \n \nThis 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. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79141",
+      "title": "SQL Server must initiate session auditing upon startup.",
+      "description": "Session auditing is for use when a user's activities are under investigation. To be sure of capturing all activity during those periods when session auditing is in use, it needs to be in operation for the whole time SQL Server is running.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79143",
+      "title": "SQL Server must be configured to allow authorized users to capture, record, and log all content related to a user session.",
+      "description": "Without the capability to capture, record, and log all content related to a user session, investigations into suspicious user activity would be hampered. \n \nTypically, this DBMS capability would be used in conjunction with comparable monitoring of a user's online session, involving other software components such as operating systems, web servers and front-end user applications. The current requirement, however, deals specifically with SQL Server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79145",
+      "title": "SQL Server must include additional, more detailed, organization-defined information in the audit records for audit events identified by type, location, or subject.",
+      "description": "Information system auditing capability is critical for accurate forensic analysis. Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. To support analysis, some types of events will need information to be logged that exceeds the basic requirements of event type, time stamps, location, source, outcome, and user identity. If additional information is not available, it could negatively impact forensic investigations into user actions or other malicious events. \n \nThe organization must determine what additional information is required for complete analysis of the audited events. The additional information required is dependent on the type of information (e.g., sensitivity of the data and the environment within which it resides). At a minimum, the organization must employ either full-text recording of privileged commands or the individual identities of users of shared accounts, or both. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.  \n \nExamples of detailed information the organization may require in audit records are full-text recording of privileged commands or the individual identities of shared account users.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79147",
+      "title": "SQL Server must by default shut down upon audit failure, to include the unavailability of space for more audit log records; or must be configurable to shut down upon audit failure.",
+      "description": "It is critical that when SQL Server is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.  \n \nWhen the need for system availability does not outweigh the need for a complete audit trail, SQL Server should shut down immediately, rolling back all in-flight transactions. \n \nSystems where audit trail completeness is paramount will most likely be at a lower MAC level than MAC I; the final determination is the prerogative of the application owner, subject to Authorizing Official concurrence. In any case, sufficient auditing resources must be allocated to avoid a shutdown in all but the most extreme situations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79149",
+      "title": "SQL Server must be configurable to overwrite audit log records, oldest first (First-In-First-Out - FIFO), in the event of unavailability of space for more audit log records.",
+      "description": "It is critical that when SQL Server is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include; software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.  \n \nWhen availability is an overriding concern, approved actions in response to an audit failure are as follows:  \n \n(i) If the failure was caused by the lack of audit record storage capacity, SQL Server must continue generating audit records, if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.  \n \n(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, SQL Server must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.  \n \nSystems where availability is paramount will most likely be MAC I; the final determination is the prerogative of the application owner, subject to Authorizing Official concurrence. In any case, sufficient auditing resources must be allocated to avoid audit data loss in all but the most extreme situations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79151",
+      "title": "The audit information produced by SQL Server must be protected from unauthorized read access.",
+      "description": "If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.  \n \nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, copy, etc.  \n \nThis requirement can be achieved through multiple methods which will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions utilizing file system protections and limiting log data location. \n   \nAdditionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access.  SQL Server is an application that is able to view and manipulate audit file data. \n \nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79153",
+      "title": "The audit information produced by SQL Server must be protected from unauthorized modification.",
+      "description": "If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n\nTo ensure the veracity of audit data the information system and/or the application must protect audit information from unauthorized modification. \n \nThis requirement can be achieved through multiple methods that will depend upon system architecture and design. Some commonly employed methods include ensuring log files enjoy the proper file system permissions and limiting log data locations. \n \nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.  SQL Server is an application that does provide access to audit file data. \n \nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n \nModification of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79155",
+      "title": "The audit information produced by SQL Server must be protected from unauthorized deletion.",
+      "description": "If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. \n \nTo ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods which will depend upon system architecture and design. \n \nSome commonly employed methods include; ensuring log files enjoy the proper file system permissions utilizing file system protections; restricting access; and backing up log data to ensure log data is retained. \n \nApplications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.  SQL Server is an application that does provide access to audit file data. \n \nAudit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. \n \nDeletion of database audit data could mask the theft of, or the unauthorized modification of, sensitive data stored in the database.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79157",
+      "title": "SQL Server must protect its audit features from unauthorized access.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. \n \nDepending upon the log format and application, system and application log tools may provide the only means to manipulate and manage application and system log data. It is, therefore, imperative that access to audit tools be controlled and protected from unauthorized access. \n \nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.  SQL Server is an application that does provide access to audit data. \n \nAudit tools include, but are not limited to, OS-provided audit tools, vendor-provided audit tools, and open source audit tools needed to successfully view and manipulate audit information system activity and records. \n \nIf an attacker were to gain access to audit tools, he could analyze audit logs for system weaknesses or weaknesses in the auditing itself. An attacker could also manipulate logs to hide evidence of malicious activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79159",
+      "title": "SQL Server must protect its audit configuration from unauthorized modification.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. \n \nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.  SQL Server is an application that does provide access to audit data. \n \nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79161",
+      "title": "SQL Server must protect its audit features from unauthorized removal.",
+      "description": "Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data. \n \nApplications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.  SQL Server is an application that does provide access to audit data. \n \nAudit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79163",
+      "title": "SQL Server must limit privileges to change software modules and links to software external to SQL Server.",
+      "description": "If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. \n \nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. \n \nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79165",
+      "title": "SQL Server must limit privileges to change software modules, to include stored procedures, functions and triggers, and links to software external to SQL Server.",
+      "description": "If the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. \n \nAccordingly, only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. \n \nUnmanaged changes that occur to the database software libraries or configuration can lead to unauthorized or compromised installations.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79167",
+      "title": "SQL Server software installation account must be restricted to authorized users.",
+      "description": "When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. \n\nIf the system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. Accordingly, only qualified and authorized individuals must be allowed access to information system components for purposes of initiating changes, including upgrades and modifications. \n\nDBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a great impact on SQL Server security and operation. It is especially important to grant privileged access to only those persons who are qualified and authorized to use them.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79169",
+      "title": "Database software, including DBMS configuration files, must be stored in dedicated directories, separate from the host OS and other applications.",
+      "description": "When dealing with change control issues, it should be noted any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system. \n \nMultiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit to one application can lead to an exploit of other applications sharing the same security context. For example, an exploit to a web server process that leads to unauthorized administrative access to host system directories can most likely lead to a compromise of all applications hosted by the same system. Database software not installed using dedicated directories both threatens and is threatened by other hosted applications. Access controls defined for one application may by default provide access to the other application's database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79171",
+      "title": "Default demonstration and sample databases, database objects, and applications must be removed.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n \nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plugins not related to requirements or providing a wide array of functionality, not required for every mission, that cannot be disabled. \n \nDBMSs must adhere to the principles of least functionality by providing only essential capabilities. \n \nDemonstration and sample database objects and applications present publicly known attack points for malicious users. These demonstration and sample objects are meant to provide simple examples of coding specific functions and are not developed to prevent vulnerabilities from being introduced to SQL Server and host system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79173",
+      "title": "Unused database components, DBMS software, and database objects must be removed.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n \nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives.  \n \nDBMSs must adhere to the principles of least functionality by providing only essential capabilities.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79175",
+      "title": "Unused database components that are integrated in SQL Server and cannot be uninstalled must be disabled.",
+      "description": "Information systems 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 (e.g., key missions, functions).  \n \nIt is detrimental for software products to provide, or install by default, functionality exceeding requirements or mission objectives.  \n \nDBMSs must adhere to the principles of least functionality by providing only essential capabilities. \n \nUnused, unnecessary DBMS components increase the attack vector for SQL Server by introducing additional targets for attack. By minimizing the services and applications installed on the system, the number of potential vulnerabilities is reduced. Components of the system that are unused and cannot be uninstalled must be disabled. The techniques available for disabling components will vary by DBMS product, OS, and the nature of the component and may include DBMS configuration settings, OS service settings, OS file access security, and DBMS user/role permissions.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79177",
+      "title": "Access to xp_cmdshell must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions).  \n \nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives.  \n \nApplications must adhere to the principles of least functionality by providing only essential capabilities. \n \nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system. \n \nThe xp_cmdshell extended stored procedure allows execution of host executables outside the controls of database access permissions. This access may be exploited by malicious users who have compromised the integrity of the SQL Server database process to control the host operating system to perpetrate additional malicious activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79179",
+      "title": "Access to CLR code must be disabled or restricted, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions).  \n \nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives.  \n \nApplications must adhere to the principles of least functionality by providing only essential capabilities. \n \nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system. \n \nThe common language runtime (CLR) component of the .NET Framework for Microsoft Windows in SQL Server allows you to write stored procedures, triggers, user-defined types, user-defined functions, user-defined aggregates, and streaming table-valued functions, using any .NET Framework language, including Microsoft Visual Basic .NET and Microsoft Visual C#.  CLR packing assemblies can access resources protected by .NET Code Access Security when it runs managed code.  Specifying UNSAFE enables the code in the assembly complete freedom to perform operations in the SQL Server process space that can potentially compromise the robustness of SQL Server. UNSAFE assemblies can also potentially subvert the security system of either SQL Server or the common language runtime.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79181",
+      "title": "Access to Non-Standard extended stored procedures must be disabled or restricted, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions).  \n \nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives.  \n \nApplications must adhere to the principles of least functionality by providing only essential capabilities. \n \nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system. \n \nExtended stored procedures are DLLs that an instance of SQL Server can dynamically load and run. Extended stored procedures run directly in the address space of an instance of SQL Server and are programmed by using the SQL Server Extended Stored Procedure API.  Non-Standard extended stored procedures can compromise the integrity of the SQL Server process.  This feature will be removed in a future version of Microsoft SQL Server. Do not use this feature in new development work, and modify applications that currently use this feature as soon as possible.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79183",
+      "title": "Access to linked servers must be disabled or restricted, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. Applications must adhere to the principles of least functionality by providing only essential capabilities. SQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system. A linked server allows for access to distributed, heterogeneous queries against OLE DB data sources. After a linked server is created, distributed queries can be run against this server, and queries can join tables from more than one data source. If the linked server is defined as an instance of SQL Server, remote stored procedures can be executed.  This access may be exploited by malicious users who have compromised the integrity of the SQL Server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79185",
+      "title": "SQL Server must be configured to prohibit or restrict the use of organization-defined protocols as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "In 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. \n \nApplications 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.  \n \nTo 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. \n \nSQL 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79187",
+      "title": "SQL Server must be configured to prohibit or restrict the use of organization-defined ports, as defined in the PPSM CAL and vulnerability assessments.",
+      "description": "In 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 physical and logical ports on information systems. \n \nApplications 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.  \n \nTo support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. \n \nSQL Server using ports deemed unsafe is open to attack through those ports. This can allow unauthorized access to the database and through the database to other components of the information system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79189",
+      "title": "SQL Server must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).",
+      "description": "To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system.  \n \nOrganizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses, except the following: \n \n(i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and  \n(ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals using shared accounts, for detailed accountability of individual activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79191",
+      "title": "If DBMS authentication, using passwords, is employed, SQL Server must enforce the DoD standards for password complexity and lifetime.",
+      "description": "OS/enterprise authentication and identification must be used (SQL2-00-023600).  Native DBMS authentication may be used only when circumstances make it unavoidable; and must be documented and AO-approved. \n \nThe DoD standard for authentication is DoD-approved PKI certificates.  Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. \n \nIn such cases, the DoD standards for password complexity and lifetime must be implemented.  DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so.  For other DBMSs, the rules must be enforced using available configuration parameters or custom code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79193",
+      "title": "Contained databases must use Windows principals.",
+      "description": "OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001).  Native DBMS authentication may be used only when circumstances make it unavoidable; and must be documented and AO-approved. \n \nThe DoD standard for authentication is DoD-approved PKI certificates.  Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. \n \nIn such cases, the DoD standards for password complexity and lifetime must be implemented.  DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so.  For other DBMSs, the rules must be enforced using available configuration parameters or custom code.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79195",
+      "title": "If passwords are used for authentication, SQL Server must transmit only encrypted representations of passwords.",
+      "description": "The DoD standard for authentication is DoD-approved PKI certificates. \n \nAuthentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. \n \nIn such cases, passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. \n \nSQL Server passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79197",
+      "title": "SQL Server must enforce authorized access to all PKI private keys stored/utilized by SQL Server.",
+      "description": "The DoD standard for authentication is DoD-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key. \n \nIf the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder.  In cases where SQL Server-stored private keys are used to authenticate SQL Server to the system’s clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man in the middle attacks against SQL Server system and its clients. \n \nBoth the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2 validated cryptographic modules. \n \nAll access to the private key(s) of SQL Server must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of SQL Server's private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79199",
+      "title": "SQL Server must use NIST FIPS 140-2 validated cryptographic modules for cryptographic operations.",
+      "description": "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. \n \nApplications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.   \n \nThe security functions validated as part of FIPS 140-2 for cryptographic modules are described in FIPS 140-2 Annex A. \n \nNSA Type- (where =1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79201",
+      "title": "SQL Server must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).",
+      "description": "Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). \n \nNon-organizational users must be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server. \n \nAccordingly, a risk assessment is used in determining the authentication needs of the organization. \n \nScalability, practicality, and security are simultaneously considered in balancing the need to ensure ease of use for access to federal information and information systems with the need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals, other organizations, and the Nation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79203",
+      "title": "SQL Server must maintain the authenticity of communications sessions by guarding against man-in-the-middle attacks that guess at Session ID values.",
+      "description": "One class of man-in-the-middle, or session hijacking, attack involves the adversary guessing at valid session identifiers based on patterns in identifiers already known. \n \nThe preferred technique for thwarting guesses at Session IDs is the generation of unique session identifiers using a FIPS 140-2 approved random number generator. \n \nHowever, it is recognized that available DBMS products do not all implement the preferred technique yet may have other protections against session hijacking. Therefore, other techniques are acceptable, provided they are demonstrated to be effective.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79205",
+      "title": "SQL Server must protect the confidentiality and integrity of all information at rest.",
+      "description": "This control is intended to address the confidentiality and integrity of information at rest in non-mobile devices and covers user information and system information. Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational information system. Applications and application users generate information throughout the course of their application use.  \n \nUser data generated, as well as application-specific configuration data, needs to be protected. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate.  \n \nIf the confidentiality and integrity of SQL Server data is not protected, the data will be open to compromise and unauthorized modification.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79207",
+      "title": "The Service Master Key must be backed up, stored offline and off-site.",
+      "description": "Backup and recovery of the Service Master Key may be critical to the complete recovery of the database. Creating this backup should be one of the first administrative actions performed on the server.  Not having this key can lead to loss of data during recovery.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79209",
+      "title": "The Master Key must be backed up, stored offline and off-site.",
+      "description": "Backup and recovery of the Master Key may be critical to the complete recovery of the database.  Not having this key can lead to loss of data during recovery.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79211",
+      "title": "SQL Server must prevent unauthorized and unintended information transfer via shared system resources.",
+      "description": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79213",
+      "title": "SQL Server must prevent unauthorized and unintended information transfer via shared system resources.",
+      "description": "The purpose of this control is to prevent information, including encrypted representations of information, produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role) from being available to any current user/role (or current process) that obtains access to a shared system resource (e.g., registers, main memory, secondary storage) after the resource has been released back to the information system. Control of information in shared resources is also referred to as object reuse.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79215",
+      "title": "Access to database files must be limited to relevant processes and to authorized, administrative users.",
+      "description": "SQL Server must prevent unauthorized and unintended information transfer via shared system resources. Permitting only SQL Server processes and authorized, administrative users to have access to the files where the database resides helps ensure that those files are not shared inappropriately and are not open to backdoor access and manipulation.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79217",
+      "title": "SQL Server must reveal detailed error messages only to the ISSO, ISSM, SA, and DBA.",
+      "description": "If SQL Server provides too much information in error logs and administrative messages to the screen, this could lead to compromise. The structure and content of error messages need to be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. \n \nSome default DBMS error messages can contain information that could aid an attacker in, among others things, identifying the database type, host address, or state of the database. Custom errors may contain sensitive customer information. \n \nIt is important that detailed error messages be visible only to those who are authorized to view them; that general users receive only generalized acknowledgment that errors have occurred; and that these generalized messages appear only when relevant to the user's task. For example, a message along the lines of, \"An error has occurred. Unable to save your changes. If this problem persists, please contact your help desk.\" would be relevant. A message such as \"Warning: your transaction generated a large number of page splits\" would likely not be relevant. \"ABGQ is not a valid widget code.\" would be appropriate; but \"The INSERT statement conflicted with the FOREIGN KEY constraint \"WidgetTransactionFK\". The conflict occurred in database \"DB7\", table \"dbo.WidgetMaster\", column 'WidgetCode'\" would not, as it reveals too much about the database structure.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79219",
+      "title": "SQL Server must prevent non-privileged users from executing privileged functions, to include disabling, circumventing, or altering implemented security safeguards/countermeasures.",
+      "description": "Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.  \n \nSystem documentation should include a definition of the functionality considered privileged. \n \nDepending on circumstances, privileged functions can include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users. \n \nA privileged function in SQL Server/database 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 an SQL environment, it encompasses, but is not necessarily limited to:  \nCREATE \nALTER \nDROP \nGRANT \nREVOKE \nDENY \n \nThere may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples include: \n \nTRUNCATE TABLE; \nDELETE, or \nDELETE affecting more than n rows, for some n, or \nDELETE without a WHERE clause; \n \nUPDATE or \nUPDATE affecting more than n rows, for some n, or \nUPDATE without a WHERE clause; \n \nAny SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal. \n \nDepending on the capabilities of SQL Server and the design of the database and associated applications, the prevention of unauthorized use of privileged functions may be achieved by means of DBMS security features, database triggers, other mechanisms, or a combination of these.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79221",
+      "title": "Use of credentials and proxies must be restricted to necessary cases only.",
+      "description": "In certain situations, to provide required functionality, a DBMS needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations. \n \nPrivilege elevation must be utilized only where necessary and protected from misuse.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79223",
+      "title": "SQL Server must utilize centralized management of the content captured in audit records generated by all components of SQL Server.",
+      "description": "Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack. \n \nThe content captured in audit records must be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records.  \n \nSQL Server may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79225",
+      "title": "SQL Server must provide centralized configuration of the content to be captured in audit records generated by all components of SQL Server.",
+      "description": "If the configuration of SQL Server's auditing is spread across multiple locations in the database management software, or across multiple commands, only loosely related, it is harder to use and takes longer to reconfigure in response to events. \n\nSQL Server must provide a unified tool for audit configuration.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79227",
+      "title": "SQL Server must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.",
+      "description": "In order to ensure sufficient storage capacity for the audit logs, SQL Server must be able to allocate audit record storage capacity. Although another requirement (SRG-APP-000515-DB-000318) mandates that audit data be off-loaded to a centralized log management system, it remains necessary to provide space on the database server to serve as a buffer against outages and capacity limits of the off-loading mechanism. \n \nThe task of allocating audit record storage capacity is usually performed during initial installation of SQL Server and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both. \n \nIn determining the capacity requirements, consider such factors as: total number of users; expected number of concurrent users during busy periods; number and type of events being monitored; types and amounts of data being captured; the frequency/speed with which audit records are off-loaded to the central log management system; and any limitations that exist on SQL Server's ability to reuse the space formerly occupied by off-loaded records.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79229",
+      "title": "SQL Server must provide a warning to appropriate support staff when allocated audit record storage volume reaches 75% of maximum audit record storage capacity.",
+      "description": "Organizations are required to use a central log management system, so, under normal conditions, the audit space allocated to SQL Server on its own server will not be an issue. However, space will still be required on the server for SQL Server audit records in transit, and, under abnormal conditions, this could fill up. Since a requirement exists to halt processing upon audit failure, a service outage would result. \n \nIf support personnel are not notified immediately upon storage volume utilization reaching 75%, they are unable to plan for storage capacity expansion.  \n \nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA. \n \nMonitoring of free space can be accomplished using Microsoft System Center or a third-party monitoring tool.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79231",
+      "title": "SQL Server must provide an immediate real-time alert to appropriate support staff of all audit failure events requiring real-time alerts.",
+      "description": "It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.  \n \nThe appropriate support staff include, at a minimum, the ISSO and the DBA/SA. \n \nAlerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less). Alerts can be generated using tools like the SQL Server Agent Alerts and Database Mail.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79233",
+      "title": "SQL Server must record time stamps in audit records and application data that can be mapped to Coordinated Universal Time (UTC, formerly GMT).",
+      "description": "If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. \n \nTime stamps generated by SQL Server must include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79235",
+      "title": "SQL Server must enforce access restrictions associated with changes to the configuration of the instance.",
+      "description": "Failure to provide logical access restrictions associated with changes to configuration may have significant effects on the overall security of the system.  \n \nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system.  \n \nAccordingly, only qualified and authorized individuals should be allowed to obtain access to system components for the purposes of initiating changes, including upgrades and modifications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79237",
+      "title": "Windows must enforce access restrictions associated with changes to the configuration of the SQL Server instance.",
+      "description": "Failure to provide logical access restrictions associated with changes to configuration may have significant effects on the overall security of the system.  \n \nWhen dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system can potentially have significant effects on the overall security of the system.  \n \nAccordingly, only qualified and authorized individuals should be allowed to obtain access to system components for the purposes of initiating changes, including upgrades and modifications.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79239",
+      "title": "SQL Server must produce audit records of its enforcement of access restrictions associated with changes to the configuration of SQL Server or database(s).",
+      "description": "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.  \n \nEnforcement 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79241",
+      "title": "SQL 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.",
+      "description": "Use of nonsecure network functions, ports, protocols, and services exposes the system to avoidable threats.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79243",
+      "title": "SQL Server must maintain a separate execution domain for each executing process.",
+      "description": "Database management systems can maintain separate execution domains for each executing process by assigning each process a separate address space.  \n \nEach process has a distinct address space so that communication between processes is controlled through the security functions, and one process cannot modify the executing code of another process.  \n \nMaintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79245",
+      "title": "SQL Server services must be configured to run under unique dedicated user accounts.",
+      "description": "Database management systems can maintain separate execution domains for each executing process by assigning each process a separate address space. Each process has a distinct address space so that communication between processes is controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79247",
+      "title": "When updates are applied to SQL Server software, any software components that have been replaced or made unnecessary must be removed.",
+      "description": "Previous versions of DBMS components that are not removed from the information system after updates have been installed may be exploited by adversaries.  \n \nSome DBMSs' installation tools may remove older versions of software automatically from the information system. In other cases, manual review and removal will be required. In planning installations and upgrades, organizations must include steps (automated, manual, or both) to identify and remove the outdated modules. \n \nA transition period may be necessary when both the old and the new software are required. This should be taken into account in the planning.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79249",
+      "title": "Security-relevant software updates to SQL Server must be installed within the time period directed by an authoritative source (e.g. IAVM, CTOs, DTMs, and STIGs).",
+      "description": "Security flaws with software applications, including database management systems, are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously. \n \nOrganization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw). \n \nThis requirement will apply to software patch management solutions that are used to install patches across the enclave and also to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality, will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process. \n \nSQL Server will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g. IAVM, CTOs, DTMs, and STIGs).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79251",
+      "title": "SQL Server must be able to generate audit records when security objects are accessed.",
+      "description": "Changes to the security configuration must be tracked. \n \nThis requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality. \n \nIn an SQL environment, types of access include, but are not necessarily limited to: \nSELECT \nINSERT \nUPDATE \nDELETE \nEXECUTE",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79253",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to access security objects occur.",
+      "description": "Changes to the security configuration must be tracked. \n \nThis requirement applies to situations where security data is retrieved or modified via data manipulation operations, as opposed to via specialized security functionality. \n \nIn an SQL environment, types of access include, but are not necessarily limited to: \nSELECT \nINSERT \nUPDATE \nDELETE \nEXECUTE \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79255",
+      "title": "SQL Server must generate audit records when categorized information (e.g., classification levels/security levels) is accessed.",
+      "description": "Changes in categorized information must be tracked.  Without an audit trail, unauthorized access to protected data could go undetected. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79257",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to access categorized information (e.g., classification levels/security levels) occur.",
+      "description": "Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79259",
+      "title": "SQL Server must generate audit records when privileges/permissions are added.",
+      "description": "Changes in the permissions, privileges, and roles granted to users and roles 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. \n \nIn an SQL environment, adding permissions is typically done via the GRANT command, or, in the negative, the DENY command.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79261",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to add privileges/permissions occur.",
+      "description": "Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected.  \n \nIn an SQL environment, adding permissions is typically done via the GRANT command, or, in the negative, the DENY command.  \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79263",
+      "title": "SQL Server must generate audit records when privileges/permissions are modified.",
+      "description": "Changes in the permissions, privileges, and roles granted to users and roles 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. \n \nIn an SQL environment, modifying permissions is typically done via the GRANT, REVOKE, and DENY commands.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79265",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to modify privileges/permissions occur.",
+      "description": "Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected.  \n \nIn an SQL environment, modifying permissions is typically done via the GRANT, REVOKE, and DENY commands.  \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79267",
+      "title": "SQL Server must generate audit records when security objects are modified.",
+      "description": "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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79269",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to modify security objects occur.",
+      "description": "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. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79271",
+      "title": "SQL Server must generate audit records when categorized information (e.g., classification levels/security levels) is modified.",
+      "description": "Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79273",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to modify categorized information (e.g., classification levels/security levels) occur.",
+      "description": "Changes in categories of information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79275",
+      "title": "SQL Server must generate audit records when privileges/permissions are deleted.",
+      "description": "Changes in the permissions, privileges, and roles granted to users and roles 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. \n \nIn an SQL environment, deleting permissions is typically done via the REVOKE or DENY command.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79277",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to delete privileges/permissions occur.",
+      "description": "Failed attempts to change the permissions, privileges, and roles granted to users and roles must be tracked. Without an audit trail, unauthorized attempts to elevate or restrict privileges could go undetected.  \n \nIn an SQL environment, deleting permissions is typically done via the REVOKE or DENY command.  \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79279",
+      "title": "SQL Server must generate audit records when security objects are deleted.",
+      "description": "The removal of security objects from the database/DBMS would seriously degrade a system's information assurance posture. If such an event occurs, it must be logged.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79281",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to delete security objects occur.",
+      "description": "The removal of security objects from the database/DBMS would seriously degrade a system's information assurance posture. If such an action is attempted, it must be logged. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79283",
+      "title": "SQL Server must generate audit records when categorized information (e.g., classification levels/security levels) is deleted.",
+      "description": "Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79285",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to delete categorized information (e.g., classification levels/security levels) occur.",
+      "description": "Changes in categorized information must be tracked. Without an audit trail, unauthorized access to protected data could go undetected. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones. \n \nFor detailed information on categorizing information, refer to FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79287",
+      "title": "SQL Server must generate audit records when successful logons or connections occur.",
+      "description": "For completeness of forensic analysis, it is necessary to track who/what (a user or other principal) logs on to SQL Server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79289",
+      "title": "SQL Server must generate audit records when unsuccessful logons or connection attempts occur.",
+      "description": "For completeness of forensic analysis, it is 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.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79291",
+      "title": "SQL Server must generate audit records for all privileged activities or other system-level access.",
+      "description": "Without tracking privileged activity, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.  \n \nSystem documentation should include a definition of the functionality considered privileged. \n \nA 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 an SQL environment, it encompasses, but is not necessarily limited to: \nCREATE \nALTER \nDROP \nGRANT \nREVOKE \nDENY \n \nThere may also be Data Manipulation Language (DML) statements that, subject to context, should be regarded as privileged. Possible examples in SQL include: \n \nTRUNCATE TABLE; \nDELETE, or \nDELETE affecting more than n rows, for some n, or \nDELETE without a WHERE clause; \n \nUPDATE or \nUPDATE affecting more than n rows, for some n, or \nUPDATE without a WHERE clause; \n \nany SELECT, INSERT, UPDATE, or DELETE to an application-defined security table executed by other than a security principal. \n \nDepending 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. \n \nNote that it is particularly important to audit, and tightly control, any action that weakens the implementation of this requirement itself, since the objective is to have a complete audit trail of all administrative activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79293",
+      "title": "SQL Server must generate audit records when unsuccessful attempts to execute privileged activities or other system-level access occur.",
+      "description": "Without tracking privileged activity, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.  \n \nSystem documentation should include a definition of the functionality considered privileged. \n \nA 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 an SQL environment, it encompasses, but is not necessarily limited to: \nCREATE \nALTER \nDROP \nGRANT \nREVOKE \nDENY \n \nNote that it is particularly important to audit, and tightly control, any action that weakens the implementation of this requirement itself, since the objective is to have a complete audit trail of all administrative activity. \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79295",
+      "title": "SQL Server must generate audit records showing starting and ending time for user access to the database(s).",
+      "description": "For completeness of forensic analysis, it is necessary to know how long a user's (or other principal's) connection to SQL Server lasts. This can be achieved by recording disconnections, in addition to logons/connections, in the audit logs.  \n \nDisconnection may be initiated by the user or forced by the system (as in a timeout) or result from a system or network failure. To the greatest extent possible, all disconnections must be logged.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79297",
+      "title": "SQL Server must generate audit records when concurrent logons/connections by the same user from different workstations occur.",
+      "description": "For completeness of forensic analysis, it is necessary to track who logs on to SQL Server. \n \nConcurrent connections by the same user from multiple workstations may be valid use of the system; or such connections may be due to improper circumvention of the requirement to use the CAC for authentication; or they may indicate unauthorized account sharing; or they may be because an account has been compromised. \n \n(If the fact of multiple, concurrent logons by a given user can be reliably reconstructed from the log entries for other events (logons/connections; voluntary and involuntary disconnections), then it is not mandatory to create additional log entries specifically for this.)",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79299",
+      "title": "SQL Server must generate audit records when successful accesses to objects occur.",
+      "description": "Without tracking all or selected types of access to all or selected objects (tables, views, procedures, functions, etc.), it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.  \n \nIn an SQL environment, types of access include, but are not necessarily limited to: \nSELECT \nINSERT \nUPDATE \nDELETE \nEXECUTE",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79301",
+      "title": "SQL Server must generate audit records when unsuccessful accesses to objects occur.",
+      "description": "Without tracking all or selected types of access to all or selected objects (tables, views, procedures, functions, etc.), it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.  \n \nIn an SQL environment, types of access include, but are not necessarily limited to: \nSELECT \nINSERT \nUPDATE \nDELETE \nEXECUTE \n \nTo aid in diagnosis, it is necessary to keep track of failed attempts in addition to the successful ones.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79303",
+      "title": "SQL Server must generate audit records for all direct access to the database(s).",
+      "description": "In this context, direct access is any query, command, or call to SQL Server that comes from any source other than the application(s) that it supports. Examples would be the command line or a database management utility program. The intent is to capture all activity from administrative and non-standard sources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79305",
+      "title": "SQL Server must implement NIST FIPS 140-2 validated cryptographic modules to provision digital signatures.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. \n \nFor detailed information, refer to NIST FIPS Publication 140-2, Security Requirements For Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79307",
+      "title": "SQL Server must implement NIST FIPS 140-2 validated cryptographic modules to generate and validate cryptographic hashes.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. \n \nFor detailed information, refer to NIST FIPS Publication 140-2, Security Requirements For Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79309",
+      "title": "SQL Server must implement NIST FIPS 140-2 validated cryptographic modules to protect unclassified information requiring confidentiality and cryptographic protection, in accordance with the data owners requirements.",
+      "description": "Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. \n \nIt is the responsibility of the data owner to assess the cryptography requirements in light of applicable federal laws, Executive Orders, directives, policies, regulations, and standards. \n \nFor detailed information, refer to NIST FIPS Publication 140-2, Security Requirements For Cryptographic Modules. Note that the product's cryptographic modules must be validated and certified by NIST as FIPS-compliant.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79311",
+      "title": "The system SQL Server must off-load audit data to a separate log management facility; this must be continuous and in near real time for systems with a network connection to the storage facility and weekly or more often for stand-alone systems.",
+      "description": "Information stored in one location is vulnerable to accidental or incidental deletion or alteration. \n \nOff-loading is a common process in information systems with limited audit storage capacity. \n \nThe system SQL Server may write audit records to database tables, to files in the file system, to other kinds of local repository, or directly to a centralized log management system. Whatever the method used, it must be compatible with off-loading the records to the centralized system.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79313",
+      "title": "SQL Server must configure Customer Feedback and Error Reporting.",
+      "description": "By default, Microsoft SQL Server enables participation in the customer experience improvement program (CEIP). This program collects information about how its customers are using the product. Specifically, SQL Server collects information about the installation experience, feature usage, and performance. This information helps Microsoft improve the product to better meet customer needs.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79315",
+      "title": "SQL Server must configure SQL Server Usage and Error Reporting Auditing.",
+      "description": "By default, Microsoft SQL Server enables participation in the customer experience improvement program (CEIP). This program collects information about how its customers are using the product. Specifically, SQL Server collects information about the installation experience, feature usage, and performance. This information helps Microsoft improve the product to better meet customer needs. The Local Audit component of SQL Server Usage Feedback collection writes data collected by the service to a designated folder, representing the data (logs) that will be sent to Microsoft. The purpose of the Local Audit is to allow customers to see all data Microsoft collects with this feature, for compliance, regulatory or privacy validation reasons.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79317",
+      "title": "The SQL Server default account [sa] must be disabled.",
+      "description": "SQL Server's [sa] account has special privileges required to administer the database. The [sa] account is a well-known SQL Server account and is likely to be targeted by attackers and thus more prone to providing unauthorized access to the database. \n\nThis [sa] default account is administrative and could lead to catastrophic consequences, including the complete loss of control over SQL Server. If the [sa] default account is not disabled, an attacker might be able to gain access through the account. SQL Server by default, at installation, disables the [sa] account. \n\nSome applications that run on SQL Server require the [sa] account to be enabled in order for the application to function properly. These applications that require the [sa] account to be enabled are usually legacy systems.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79319",
+      "title": "SQL Server default account [sa] must have its name changed.",
+      "description": "SQL Server's [sa] account has special privileges required to administer the database. The [sa] account is a well-known SQL Server account name and is likely to be targeted by attackers, and is thus more prone to providing unauthorized access to the database. \n\nSince the SQL Server [sa] is administrative in nature, the compromise of a default account can have catastrophic consequences, including the complete loss of control over SQL Server. Since SQL Server needs for this account to exist and it should not be removed, one way to mitigate this risk is to change the [sa] account name.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79321",
+      "title": "Execution of startup stored procedures must be restricted to necessary cases only.",
+      "description": "In certain situations, to provide required functionality, a DBMS needs to execute internal logic (stored procedures, functions, triggers, etc.) and/or external code modules with elevated privileges. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking the functionality applications/programs, those users are indirectly provided with greater privileges than assigned by organizations.\n\nWhen 'Scan for startup procs' is enabled, SQL Server scans for and runs all automatically run stored procedures defined on the server.  The execution of start-up stored procedures will be done under a high privileged context, therefore it is a commonly used post-exploitation vector.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79323",
+      "title": "SQL Server Mirroring endpoint must utilize AES encryption.",
+      "description": "Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nUse of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. \n\nSQL Mirroring endpoints support different encryption algorithms, including no-encryption. Using a weak encryption algorithm or plaintext in communication protocols can lead to data loss, data manipulation and/or connection hijacking.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79325",
+      "title": "SQL Server Service Broker endpoint must utilize AES encryption.",
+      "description": "Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information.\n\nUse of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. \n\nSQL Server Service Broker endpoints support different encryption algorithms, including no-encryption. Using a weak encryption algorithm or plaintext in communication protocols can lead to data loss, data manipulation and/or connection hijacking.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79327",
+      "title": "SQL Server execute permissions to access the registry must be revoked, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nThe registry contains sensitive information, including password hashes as well as clear text passwords. Registry extended stored procedures allow Microsoft SQL Server to access the machine's registry. The sensitivity of these procedures are exacerbated if Microsoft SQL Server is run under the Windows account LocalSystem. LocalSystem can read and write nearly all values in the registry, even those not accessible by the Administrator. Unlike the xp_cmdshell extended stored procedure, which runs under a separate context if executed by a login not in the sysadmin role, the registry extended stored procedures always execute under the security context of the MSSQLServer service. Because the sensitive information is stored in the registry, it is essential that access to that information be properly guarded.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79329",
+      "title": "Filestream must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nThe most significant potential for attacking an instance is through the use of features that expose an external interface or ad hoc execution capability. FILESTREAM integrates the SQL Server Database Engine with an NTFS file system by storing varbinary(max) binary large object (BLOB) data as files on the file system. Transact-SQL statements can insert, update, query, search, and back up FILESTREAM data.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79331",
+      "title": "The Filestream setting in registry and in SQL Server configuration must match.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nThere are two settings governing Filestream option, one in the registry (OS level) and one in SQL Server configuration. There is a separation of security concerns between the Windows and database administrators, and the same access level set for the Windows service needs to be set for the SQL Server instance.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79333",
+      "title": "Ole Automation Procedures feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe Ole Automation Procedures option controls whether OLE Automation objects can be instantiated within Transact-SQL batches. These are extended stored procedures that allow SQL Server users to execute functions external to SQL Server in the security context of SQL Server.\n\nThe Ole Automation Procedures extended stored procedure allows execution of host executables outside the controls of database access permissions. This access may be exploited by malicious users who have compromised the integrity of the SQL Server database process to control the host operating system to perpetrate additional malicious activity.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79335",
+      "title": "SQL Server User Options feature must be disabled, unless specifically required and approved.",
+      "description": "SQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe user options option specifies global defaults for all users. A list of default query processing options is established for the duration of a user's work session. The user options option allows you to change the default values of the SET options (if the server's default settings are not appropriate).",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79337",
+      "title": "Remote Access feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe Remote Access option controls the execution of local stored procedures on remote servers or remote stored procedures on local server.  'Remote access' functionality can be abused to launch a Denial-of-Service (DoS) attack on remote servers by off-loading query processing to a target.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79339",
+      "title": "Smo and Dmo Xps feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe SMO and DMO XPs are management object extended stored procedures that provide highly privileged actions that run externally to the DBMS under the security context of the SQL Server service account. If these procedures are available from a database session, an exploit to the SQL Server instance could result in a compromise of the host system and external SQL Server resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79341",
+      "title": "Hadoop Connectivity feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe Hadoop Connectivity feature allows multiple types of external data sources to be created and used across all sessions on the server.  An exploit to the SQL Server instance could result in a compromise of the host system and external SQL Server resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79343",
+      "title": "Allow Polybase Export feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe Allow Polybase Export feature allows an export of data to an external data source such as Hadoop File System or Azure Data Lake. An exploit to the SQL Server instance could result in a compromise of the host system and external SQL Server resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79345",
+      "title": "Remote Data Archive feature must be disabled, unless specifically required and approved.",
+      "description": "Information systems 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 (e.g., key missions, functions). \n\nIt is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. \n\nApplications must adhere to the principles of least functionality by providing only essential capabilities.\n\nSQL Server may spawn additional external processes to execute procedures that are defined in the SQL Server but stored in external host files (external procedures). The spawned process used to execute the external procedure may operate within a different OS security context than SQL Server and provide unauthorized access to the host system.\n\nSQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe Remote Data Archive feature allows an export of local SQL Server data to an Azure SQL Database. An exploit to the SQL Server instance could result in a compromise of the host system and external SQL Server resources.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79347",
+      "title": "SQL Server External Scripts Enabled feature must be disabled, unless specifically required and approved.",
+      "description": "SQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nThe External Scripts Enabled feature allows scripts external to SQL such as files located in an R library to be executed.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79349",
+      "title": "The SQL Server Browser service must be disabled unless specifically required and approved.",
+      "description": "The SQL Server Browser simplifies the administration of SQL Server, particularly when multiple instances of SQL Server coexist on the same computer. It avoids the need to hard-assign port numbers to the instances and to set and maintain those port numbers in client systems. It enables administrators and authorized users to discover database management system instances, and the databases they support, over the network. SQL Server uses the SQL Server Browser service to enumerate instances of the Database Engine installed on the computer. This enables client applications to browse for a server, and helps clients distinguish between multiple instances of the Database Engine on the same computer.\n\nThis convenience also presents the possibility of unauthorized individuals gaining knowledge of the available SQL Server resources. Therefore, it is necessary to consider whether the SQL Server Browser is needed. Typically, if only a single instance is installed, using the default name (MSSQLSERVER) and port assignment (1433), the Browser is not adding any value. The more complex the installation, the more likely SQL Server Browser is to be helpful. \n\nThis requirement is not intended to prohibit use of the Browser service in any circumstances.  It calls for administrators and management to consider whether the benefits of its use outweigh the potential negative consequences of it being used by an attacker to browse the current infrastructure and retrieve a list of running SQL Server instances.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79351",
+      "title": "SQL Server Replication Xps feature must be disabled, unless specifically required and approved.",
+      "description": "SQL Server is capable of providing a wide range of features and services. Some of the features and services, provided by default, may not be necessary, and enabling them could adversely affect the security of the system.\n\nEnabling the replication XPs opens a significant attack surface area that can be used by an attacker to gather information about the system and potentially abuse the privileges of SQL Server.",
+      "severity": "medium"
+    },
+    {
+      "id": "V-79353",
+      "title": "If the SQL Server Browser Service is specifically required and approved, SQL instances must be hidden.",
+      "description": "The SQL Server Browser simplifies the administration of SQL Server, particularly when multiple instances of SQL Server coexist on the same computer. It avoids the need to hard-assign port numbers to the instances and to set and maintain those port numbers in client systems. It enables administrators and authorized users to discover database management system instances, and the databases they support, over the network. SQL Server uses the SQL Server Browser service to enumerate instances of the Database Engine installed on the computer. This enables client applications to browse for a server, and helps clients distinguish between multiple instances of the Database Engine on the same computer.\n\nThis convenience also presents the possibility of unauthorized individuals gaining knowledge of the available SQL Server resources. Therefore, it is necessary to consider whether the SQL Server Browser is needed. Typically, if only a single instance is installed, using the default name (MSSQLSERVER) and port assignment (1433), the Browser is not adding any value. The more complex the installation, the more likely SQL Server Browser is to be helpful. \n\nThis requirement is not intended to prohibit use of the Browser service in any circumstances.  It calls for administrators and management to consider whether the benefits of its use outweigh the potential negative consequences of it being used by an attacker to browse the current infrastructure and retrieve a list of running SQL Server instances.  In order to prevent this, the SQL instance(s) can be hidden.",
+      "severity": "low"
+    },
+    {
+      "id": "V-79355",
+      "title": "When using command-line tools such as SQLCMD in a mixed-mode authentication environment, users must use a logon method that does not expose the password.",
+      "description": "To prevent the compromise of authentication information, such as passwords and PINs, during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\n\nObfuscation of user-provided information when typed into the system is a method used in addressing this risk.\n\nFor example, displaying asterisks when a user types in a password or PIN, is an example of obscuring feedback of authentication information.\n\nThis requirement is applicable when mixed-mode authentication is enabled.  When this is the case, password-authenticated accounts can be created in and authenticated by SQL Server.  Other STIG requirements prohibit the use of mixed-mode authentication except when justified and approved.  This deals with the exceptions.\n\nSQLCMD and other command-line tools are part of any SQL Server installation. These tools can accept a plain-text password, but do offer alternative techniques. Since the typical user of these tools is a database administrator, the consequences of password compromise are particularly serious. Therefore, the use of plain-text passwords must be prohibited, as a matter of practice and procedure.",
+      "severity": "high"
+    },
+    {
+      "id": "V-79357",
+      "title": "Applications must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.",
+      "description": "To prevent the compromise of authentication information, such as passwords and PINs, during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.\n\nObfuscation of user-provided information when typed into the system is a method used in addressing this risk.\n\nFor example, displaying asterisks when a user types in a password or PIN, is an example of obscuring feedback of authentication information.\n\nDatabase applications may allow for entry of the account name and password as a visible parameter of the application execution command. This practice must be prohibited and disabled to prevent shoulder surfing.",
+      "severity": "high"
+    }
+  ]
+}