Microsoft SQL Server 2012 Database Instance Security Technical Implementation Guide

Organizations are required to employ integrity verification applications on information systems to look for evidence of information tampering, errors, and omissions. The organization is also required to employ good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, and cryptographic hashes), and to use tools to automatically monitor the integrity of the information system and the applications it hosts. SQL Server opens data files and reads configuration files at system startup, system shutdown, and during abort recovery efforts.

Predictable failure prevention requires organizational planning to address system failure issues. If components key to maintaining system security fail to function, then SQL Server could continue operating in an unsecure state. The organization must be prepared, and the system must be configured, to send an alarm for such conditions and/or automatically shut SQL Server down. If appropriate actions are not taken when component failures occur, a denial of service condition may occur. Appropriate actions can include conducting a graceful application shutdown to avoid losing information. For the purposes of this requirement, "component" may be interpreted as meaning any of the Windows services that comprise a SQL Server instance. "The system" encompasses SQL Server itself, the Windows operating system, and any monitoring/management tools used to control the server.true

The structure and content of SQL Server error messages need to be carefully considered by the organization and development team. The extent to which the application is able to identify and handle error conditions is guided by organizational policy and operational requirements. Database logs can be monitored for specific security-related errors. Any error that can have a negative effect on database security should be quickly identified and forwarded to the appropriate personnel. If security-relevant error conditions are not identified by SQL Server they may be overlooked by the personnel responsible for addressing them.

SQL Server has a feature called 'Availability Group' which provides automatic failover from a primary SQL Server to a secondary server. This concept is not new, but because SQL Server does warn that if the secondary SQL Server is not dedicated 100% to being a backup server, that "resource exhaustion" may be an issue if there is some load balancing going on. If the primary SQL Server has a backup/secondary server that is dedicated 100% to the primary server's process, this is not a finding. If, however, the processing of the primary SQL Server is loaded to a secondary server that is already partly resourced to process something other than that of the primary SQL Server responsibility, then there can be load balancing issues. Load balancing for the purpose of sharing a secondary/backup SQL Server is often done to share and save on resources.

Security functions are defined as "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". Developers 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. Database Management Systems typically separate security functionality from nonsecurity 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 nonsecurity functionality is commingled, users who have access to nonsecurity functionality may be able to access security functionality.true

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. User-generated data, as well as, application-specific configuration data, needs to be protected. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention systems, filtering routers, and authenticator content are examples of system information likely requiring protection. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate. If the confidentiality and integrity of SQL Server data is not protected, the data will be open to compromise and unauthorized modification. Protective measures include encryption, physical security of the facility where the storage devices reside, operating system file permissions, and organizational controls. Each of these should be applied as necessary and appropriate.

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications, with such protection likely being implemented as part of other security controls. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it. The user account associated with public access must not have access to the OS or SQL Server configuration information, include read access to schema information. This requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications, with such protection likely being implemented as part of other security controls. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it. The user account associated with public access must not have access to the OS or SQL Server configuration information, include read access to schema information. This access includes, but is not limited to, SQL Server 'User Mapping' assignments. SQL Server access to any of the three system databases (master, model, or msdb) is restricted from the publicly available user account, because this would grant more than read-only access to public information. Of the existing user-defined databases, privileges must be checked to allow only read access to publically available data. This requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications, with such protection likely being implemented as part of other security controls. If SQL Server contains publicly available information, though not concerned with confidentiality, SQL Server OS must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it. The user account associated with public access must not have access to the OS configuration information. Determine what publicly available user account is being used to access SQL Server and validate that the publicly available user account only has read access to the public data and nothing else. The OS level 'Guests' role grants connection access to the server without granting any other privileges. SQL Server configuration settings are used to grant access to the publicly available information, but this control ensures that the OS only is granted connection access to the server. This requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.

The purpose of this control is to ensure organizations explicitly address the protection needs for public information and applications, with such protection likely being implemented as part of other security controls. SQL Server must be configured to contain publicly available information. Though not concerned with confidentiality, SQL Server must maintain the integrity of the data. If data available to the public is not protected from unauthorized modification or deletion, then the data cannot be trusted by those accessing it. A publicly available user account must not have access to the OS or SQL Server configuration information, including read access to schema information. Determine what publicly available user account is being used to access SQL Server and validate that the publicly available user account only has read access to the public data and nothing else. This read-only access does not include SQL Server 'Securables' assignments. SQL Server 'Securables' assignments grant the assignee privileges that are beyond read access to data. No public user account must have SQL Server 'Securables' privileges. Any assigned 'Securables' privileges to the public user account must be removed. Likely the only 'Server roles' assignment for the publicly available user account would be 'public'. The only other 'Server roles' that could be authorized as read-only is a user-defined 'Server role'. It is more likely that read-only access is set up at the user database instance in role(s) specifically set up for this purpose. Assignment to the user database instances are made in the 'User Mapping' highlight within a user's properties. This requirement is not intended to prevent the establishment of public-facing systems for the purpose of collecting data from the public.

Cryptography is only as strong as the encryption modules/algorithms employed to encrypt the data. Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. NSA has developed Type 1 algorithms for protecting classified information. The Committee on National Security Systems (CNSS) National Information Assurance Glossary (CNSS Instruction No. 4009) defines Type 1 products as: “Cryptographic equipment, assembly or component classified or certified by NSA for encrypting and decrypting classified and sensitive national security information when appropriately keyed. Developed using established NSA business processes and containing NSA approved algorithms are used to protect systems requiring the most stringent protection mechanisms.” NSA-approved cryptography is required to be used for classified information system processing.

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). Non-organizational users shall 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. This may be accomplished by a code embedded within the userid, or via a flag or code columns in a table of users, or by some other means. In any case, the user must be individually identified to, and within, SQL Server via a mapping to an individual account and not mapping to a shared account. Accordingly, a risk assessment is used in determining the authentication needs of the organization. Scalability, 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, and other organizations.

Passwords need to be protected at all times and encryption is the standard method for protecting passwords during transmission. DBMS 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.

SQL Server must enforce password encryption when storing passwords. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Passwords stored in clear text are vulnerable to unauthorized disclosure. Database passwords should always be encoded or encrypted when stored internally or externally to SQL Server.

To ensure individual accountability and prevent unauthorized access, application users (and any processes acting on behalf of users) must be individually identified and authenticated. A shared authenticator is a generic account used by multiple individuals. Use of a shared authenticator alone does not uniquely identify individual users. An example of a shared authenticator is the UNIX OS 'root' user account, a Windows 'administrator' account, an 'sa' account, or a 'helpdesk' account. Legitimate use of shared accounts includes, for example, connection pooling. Since this is insufficient to ensure non-repudiation, such shared accounts should be kept "under the covers," be inaccessible directly to end users, be invoked only after successful individual authentication, be communicated to the DBMS by the application, and be recorded in all relevant audit contexts. (Shared accounts should not be confused with Windows groups, which are used in role-based access control.)

To ensure accountability and prevent unauthorized SQL Server access, organizational users shall be identified and authenticated. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users (and any processes acting on behalf of users) are uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on SQL Server without identification or authentication.

SQL Server backups are a critical step in maintaining data assurance and availability. System-level information includes system-state information, operating system and application software, and licenses. Backups shall be consistent with organization-defined recovery time and recovery point objectives. SQL Server depends upon the availability and integrity of its software libraries. Without backups, compromise or loss of the software libraries can prevent a successful recovery of SQL Server operations. A mixture of full and incremental server-level backups by a third-party tool that backs up those software library directories would satisfy this requirement.

SQL Server backups are a critical step in maintaining data assurance and availability. System-level information includes: system-state information, operating system and application software, and licenses. Backups shall be consistent with organizationally defined recovery time and recovery point objectives. SQL Server depends upon the availability and integrity of its system-level information. Without backups, compromise or loss of system-level information can prevent a successful recovery of SQL Server operations. If SQL Server system-level information is not backed up regularly this risks the loss of SQL Server data in the event of a system failure. A mixture of full and incrementally server level backups that backup the system-level information would satisfy this requirement.

SQL Server backups are a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user generated data is backed up at a defined frequency. This includes data stored on file systems, within databases or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Lost or compromised SQL Server backup or restoration files may lead to not only the loss of data, but also the unauthorized access to sensitive data. SQL Server can maintain local copies of critical control files to provide transparent or easy recovery from hard disk loss or other interruptions to database operation. Backup files, both local to the SQL Server machine and not local to the machine, need the same protections against unauthorized access when stored on backup media as when online and actively in use by the database system. In addition, the backup media needs to be protected against physical loss.

SQL Server backups are a critical step in maintaining data assurance and availability. User-level information is data generated by the information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within SQL Server or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD-defined frequency. Problems with backup procedures or backup media may not be discovered until after a recovery is needed. Testing and verification of procedures provides the opportunity to discover oversights, conflicts, or other issues in the backup procedures or use of media designed to be used. Part of an overall backup and recovery methodology includes regular recovery testing. This is very important and helps to expose any issue in the recovery process (e.g., hardware, procedures, etc.).

SQL Server backup is a critical step in maintaining data assurance and availability. User-level information is data generated by the information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user-generated data is backed up at a defined frequency. This includes data stored on file systems, within SQL Server or within any other storage media. Applications performing backups must be configured to back up user-level information per the DoD-defined frequency. SQL Server Database backups provide the required means to restore databases after compromise or loss. Backups help reduce the vulnerability to unauthorized access or hardware loss.

SQL Server backups are a critical step in maintaining data assurance and availability. User-level information is data generated by information system and/or application users. In order to assure availability of this data in the event of a system failure, DoD organizations are required to ensure user generated data is backed up at a defined frequency. This includes data stored on file systems, within SQL Server or within any other storage media. Applications performing backups must be capable of backing up user-level information per the DoD defined frequency. Databases that do not backup information regularly risk the loss of that information in the event of a system failure.

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). Additionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services) but doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. Database Management Systems using ports, protocols, and services deemed unsafe are open to attack through those ports, protocols, and services. This can allow unauthorized access to the database and, through the database, to other components of the information system.

SQL Server is 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). Additionally, it is sometimes convenient to provide multiple services from a single component of an information system (e.g., email and web services), but doing so increases risk over limiting the services provided by any one component.

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. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements; or providing a wide array of functionality not required for every mission, but which cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. DBMSs may spawn additional external processes to execute procedures that are defined in the DBMS, 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 the DBMS and provide unauthorized access to the host system. The 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.

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. This '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. Some 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.true

SQL Server is 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. Examples include, but are not limited to, installing advertising software demonstrations, or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused and unnecessary SQL Server components increase the number of available attack vectors to 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.

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. Examples include, but are not limited to, installing advertising software demonstrations or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, yet cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused and unnecessary SQL Server components increase the number of available attack vectors to 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. SQL Server must have the SQL Server Analysis Service (SSAS) software component removed from SQL Server if SSAS is unused.

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. Examples include, but are not limited to, installing advertising software demonstrations or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, yet cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused and unnecessary SQL Server components increase the number of available attack vectors to 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. SQL Server must have the SQL Server Integrated Services (SSIS) software component removed from SQL Server if SSIS is unused.

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. Examples include, but are not limited to, installing advertising software demonstrations or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, yet cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Unused and unnecessary SQL Server components increase the number of available attack vectors to 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. SQL Server must have the SQL Server Reporting Service (SSRS) software component removed from SQL Server if SSRS is unused.

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. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements and providing a wide array of functionality not required for every mission, but which cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Even though the very popular "AdventureWorks" database is no longer available by default, it introduces a vulnerability to SQL Server and must be removed. Demonstration 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 the SQL Server and the OS.

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. Examples include, but are not limited to, installing advertising software, demonstrations, or browser plug-ins not related to requirements and providing a wide array of functionality not required for every mission, but which cannot be disabled. Applications must adhere to the principles of least functionality by providing only essential capabilities. Even though the very popular "NorthWind" database is no longer available by default, it introduces a vulnerability to SQL Server and must be removed. Demonstration 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 the SQL Server and the OS.

When dealing with change control issues, it should be noted, 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. If any user were allowed 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. The DBMS software libraries contain the executables used by the DBMS to operate. Unauthorized access to the libraries can result in compromised installations. This may in turn jeopardize data stored in the DBMS and/or operation of the host system. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Of particular note in this context is that any software installed for auditing and/or audit file management must be protected and monitored.true

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. If the application 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. This requirement is contingent upon the language in which the application is programmed, as many application architectures in use today incorporate their software libraries into, and make them inseparable from, their compiled distributions, rendering them static and version dependant. However, this requirement does apply to applications with software libraries accessible and configurable, as in the case of interpreted languages. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. DBA and other privileged administrative or application owner accounts are granted privileges that allow actions that can have a greater impact on SQL Server security and operation. It is especially important to grant access to privileged accounts to only those persons who are qualified and authorized to use them.

When dealing with change control issues, it should be noted, any changes to security-relevant configuration settings of SQL Server can potentially have significant effects on the overall security of the system. If SQL Server were to allow any user to make changes to configuration settings, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement is contingent upon the configuration of SQL Server's hosted application and the security-relevant configuration settings of SQL Server. Accordingly, only qualified and authorized individuals shall be allowed to obtain access to these security-relevant configuration settings for purposes of initiating changes, including upgrades and modifications. Unmanaged changes that occur to SQL Server software libraries or configuration can lead to unauthorized or compromised installations.

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. Accordingly, only qualified and authorized individuals are allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Access restrictions for change also include software libraries. Examples of access restrictions include: physical access controls (such as locks and access cards), logical access controls (such as ACLs), automated auditing (logging) of logical access, workflow automation, media libraries, abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (e.g., changes occur only during specified times, making unauthorized changes outside the window easy to discover). This requirement focuses on the auditing aspect of the protections.true

When dealing with access restrictions pertaining to change control, 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. Only qualified and authorized individuals are allowed to obtain access to information system components for the purposes of initiating changes, upgrades, and modifications. Access restrictions for change also include application software libraries. Examples of access restrictions include: physical and logical access controls, workflow automation, media libraries, abstract layers (i.e., changes are implemented into a third-party interface rather than directly into the information system component), and change windows (i.e., changes occur only during specified times, making unauthorized changes outside the window easy to discover). Multiple applications can provide a cumulative negative effect. A vulnerability and subsequent exploit of one application can lead to an exploit of other applications sharing the same security context. For example, an exploit of 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 other applications’ database objects or directories. Any method that provides any level of separation of security context assists in the protection between applications.

If audit data were to become compromised, competent forensic analysis and discovery of the true source of potentially malicious system activity would be difficult, if not impossible, to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage. To 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. SQL Server and third-party tools are examples of applications that are easily able to view and manipulate audit file data. Additionally, applications with user interfaces to audit records should not allow unfettered manipulation of, or access to, those records via any application. If an application provides access to the audit data, the application becomes accountable for ensuring that audit information is protected from unauthorized access. This 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. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.true

Protection of audit records and audit data is of critical importance. Care must be taken to ensure privileged users cannot circumvent audit protections put in place. Auditing might not be reliable when performed by an information system that the user being audited has privileged access to. The privileged user could inhibit auditing or directly modify audit records. To prevent this from occurring, privileged access shall be further defined between audit-related privileges and other privileges, thus limiting the users with audit-related privileges. Reducing the risk of audit compromises by privileged users can also be achieved, for example, by performing audit activity on a separate information system where the user in question has limited access, or by using storage media that cannot be modified (e.g., write-once recording devices). If an attacker were to gain access to audit tools, they 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.true

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Detection of suspicious activity, including access attempts and successful access from unexpected places, during unexpected times, or other unusual indicators, can support decisions to apply countermeasures to deter an attack. Without detection, malicious activity may proceed without hindrance. In SQL Server's case, this is a combination of the standard audit trace, as well as the operating system logs. Only the SQL Server logs are validated for this check, as the other part is dependent upon the operating system.

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. If the system were to continue processing without auditing enabled, actions could be taken on the system that could not be tracked and recorded for later forensic analysis. In many system configurations, the disk space allocated to the auditing system is separate from the disks allocated for the operating system; therefore, this may not result in a system outage. This places the onus on the DBMS to detect and take actions. A failure of SQL Server auditing will result in either the database continuing to function without auditing, or the halting of SQL Server operations. In this case, the database must cease processing immediately in order to not allow unlogged transaction to occur. Note that trace file rollover does not count as an audit failure, provided that the system is also configured to shut down when it runs out of space. Trace file rollover can be a useful technique for breaking the log into manageable pieces, for archiving, or for transfer to a log management system.true

Configure SQL Server during the installation and/or configuration process to determine if adequate storage capacity has been allocated for audit logs. If SQL Server audit logs that are being generated exceed the amount of space reserved for those logs, the system may shutdown or take other measures to stop processing in order to protect transactions from continuing unlogged. After the initial setup of SQL Server audit log configuration, it is best to check the available space frequently until the maximum number of files has been reached. Checking the available space can help determine the balance of online audit data with space required.

Configure SQL Server during the installation and/or configuration process to determine if adequate storage capacity has been allocated for audit logs. If SQL Server audit logs that are being generated exceed the amount of space reserved for those logs, the system may shutdown or take other measures to stop processing in order to protect transactions from continuing unlogged. After the initial setup of SQL Server audit log configuration, it is best to check the available space until the maximum number of files has been reached. SQL will overwrite the oldest files when the max_files parameter has been exceeded. Care must be taken to ensure that this does not happen, or data will be lost. Therefore, the combination of max_size and max_files must be monitored to ensure that overwriting does not occur. This must also coincide with the backup process of off-loading the files.

SQL Server does not have the ability to be cognizant of potential audit log storage capacity issues. During the installation and/or configuration process, SQL Server should detect and determine if adequate storage capacity has been allocated for audit logs. During the installation process, a notification may be provided to the installer indicating, based on the auditing configuration chosen and the amount of storage space allocated for audit logs, the amount of storage capacity available is not sufficient to meet storage requirements. SQL Server is not able to send out notice based on adequate storage capacity allocated for the audit logs.

SQL Server auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server does have a means available to add organizationally defined additional, more detailed information in the audit event records. These events may be identified by type, location, or subject. An example of more detailed information the organization may require in audit records could be the name of the application where the request is coming from. Some organizations may determine that more detailed information is required for specific database event types. If this information is not available, it could negatively impact forensic investigations into user actions or other malicious events.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. Database software is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly who performed a given action. If user identification information is not recorded and stored with the audit record, the record itself is of very limited use.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know the outcome of attempted actions. This requires specific information regarding the outcome of the action or event that the audit record is referring to. If outcome status information is not recorded and stored with the audit record, the record itself is of very limited use. Success and failure indicators ascertain the outcome of a particular event. As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Without knowing the outcome of audit events, it is very difficult to accurately recreate the series of events during forensic analysis. If auditing is enabled, SQL Server does capture the outcome status-specific information in all audit records.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly who performed what actions. This requires specific information regarding the source of the event an audit record is referring to. If the source of the event information is not recorded and stored with the audit record, the record itself is of very limited use. The source of the event can be a user account and sometimes a system account when timed jobs are run. Without information establishing the source of activity, the value of audit records from a forensics perspective is questionable. If auditing is enabled, SQL Server does capture the source of the event-specific information in all audit records.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly where actions were performed. This requires specific information regarding the event location an audit record is referring to. If event location information is not recorded and stored with the audit record, the record itself is of very limited use. An event location can be a database instance, table, column, row, etc. Without sufficient information establishing where the audit events occurred, investigation into the cause of events is severely hindered. If auditing is enabled, SQL Server does capture the event location-specific information in all audit records.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly when actions were performed. This requires specific information regarding the date and time an audit record is referring to. If date and time information is not recorded and stored with the audit record, the record itself is of very limited use. If auditing is enabled, SQL Server does capture the date and time-specific information in all audit records.

Information system auditing capability is critical for accurate forensic analysis. Audit record content which may be necessary to satisfy the requirement of this control includes, but is not limited to: time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked. SQL Server is capable of a range of actions on data stored within the database. It is important, for accurate forensic analysis, to know exactly what actions were performed. This requires specific information regarding the event type an audit record is referring to. If event type information is not recorded and stored with the audit record, the record itself is of very limited use. If auditing is enabled, SQL Server does capture the event type-specific information in all audit records.

Audit records can be generated from various components within the information system, such as network interfaces, hard disks, modems, etc. From an application perspective, 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 (i.e., auditable events, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, file names involved, and access control or flow control rules invoked). Organizations may define the organizational personnel accountable for determining which application components shall provide auditable events. Auditing provides accountability for changes made to the SQL Server configuration or its objects and data. It provides a means to discover suspicious activity and unauthorized changes. Without auditing, a compromise may go undetected and without a means to determine accountability.

SQL Server Authentication does not provide for many of the authentication requirements of the DoD. In some cases workarounds are present, but the authentication is not as robust and does not provide needed functionality. Without that functionality, SQL Server is vulnerable to authentication attacks. Consideration must be given to the placement of SQL server inside a forest to ensure evaluation of risk within the environment is considered. Risk includes introduction of risk to SQL Server from other applications or workstations as well as risk from introduction of SQL server itself into an established environment.true

This requirement is intended to limit exposure due to operating from within a privileged account. SQL Server does support the organizational requirement that users of information system accounts with access to an organization-defined list of security functions or security-relevant information use non-privileged accounts and roles, when accessing other (non-security) system functions. Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts if used for non-administration application development or application maintenance can lead to miss-assignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in, and provided by, applications. The SQL Server installation account requires privileges not required for SQL Server administration or other functions. Use of accounts configured with excess privileges may result in the loss or compromise of data or system settings due to elevated privileges that bypass controls designed to protect them.

SQL Server DBAs, if assigned excessive OS privileges, could perform actions that could endanger the information system or hide evidence of malicious activity. This requirement is intended to limit exposure due to operating from within a privileged account or role. The check and fix are based on the assumption that Role-Based Access Control (RBAC) is in effect, as mandated by other STIG requirements. They further assume that, as mandated elsewhere, the privileged accounts discussed here are distinct from the accounts used by the same people when not performing privileged functions.true

This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role-Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure when operating from within a privileged account or role, the application must support organizational requirements that users of information system accounts, or roles, with access to an organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. Use of privileged accounts for non-administrative purposes puts data at risk of unintended or unauthorized loss, modification, or exposure. In particular, DBA accounts, if used for non-administration application development or application maintenance, can lead to misassignment of privileges where privileges are inherited by object owners. It may also lead to loss or compromise of application data where the elevated privileges bypass controls designed in, and provided by, applications. External applications called by SQL Server may be executed under OS or domain accounts with unnecessary privileges. This can lead to unauthorized access to OS resources and compromise of the OS, SQL Server, or any other services provided by the host platform.

This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role-Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. Audit of privileged activity may require physical separation, employing information systems on which the user does not have privileged access. To limit exposure and provide forensic history of activity when operating from within a privileged account or role, SQL Server does support organizational requirements that users of information system accounts, or roles, with access to an organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. SQL Server provides access logging that ensures users who are granted a privileged role (or roles) have their privileged activity logged. DBAs, if assigned excessive privileges, could perform actions that endanger the information system or hide evidence of malicious activity.

This is intended to limit exposure, by making it possible to trace any unauthorized access to other data or functionality by a privileged user account or role that has permissions on security functions or security-relevant information.

This requirement is intended to limit exposure due to operating from within a privileged account or role. The inclusion of role is intended to address those situations where an access control policy, such as Role-Based Access Control (RBAC), is being implemented and where a change of role provides the same degree of assurance in the change of access authorizations for both the user and all processes acting on behalf of the user as would be provided by a change between a privileged and non-privileged account. To limit exposure when operating from within a privileged account or role, SQL Server does support organizational requirements that users of information system accounts, or roles, with access to an organization-defined list of security functions or security-relevant information, use non-privileged accounts, or roles, when accessing other (non-security) system functions. When privileged activities are not separated from non-privileged activities, SQL Server could be subject to unauthorized changes of settings or data, which a standard user would not normally have access to outside of an authorized maintenance session. Often, administrator accounts have a unique prefix to help with identification. These accounts are located within SQL Server and may only provide access to one database instance or a limited number of database objects.

The principle of Least Privilege must be applied to the ability of users to access system tables, system management information, other configuration information, and metadata. Unauthorized access to this data could result in unauthorized changes to database objects, access controls, or SQL Server configuration. Only database administrators and other authorized users must be allowed such access. To aid in tracking and administering such permissions, individual logins must not be directly granted permissions or built-in server roles. Instead, user-defined server roles must be created, with the permissions and built-in server roles granted to them; the individual logins must be assigned to the appropriate user-defined server roles. The built-in server role "sysadmin" is a partial exception. This cannot be granted to a user-defined role, only to a login account. Most (not necessarily all) database administrators will need to be members of sysadmin. Without this, most DBCC commands and the system stored procedures/functions listed below are unavailable. The users who require such access must be documented and approved. In addition, if the site uses backup-restore software that connects to SQL Server via the Virtual Device Interface (VDI), the account used by that software must have the sysadmin role. (See Microsoft Knowledge Base article 2926557, http://support.microsoft.com/kb/2926557). If this applies, it must be documented and approved. Stored procedures/functions available only to the sysadmin role: fn_yukonsecuritymodelrequired sp_add_agent_parameter sp_add_agent_profile sp_adddatatype sp_adddistributiondb sp_adddistributor sp_addqreader_agent sp_addsubscriber sp_addsubscriber_schedule sp_addtabletocontents sp_attachsubscription sp_cdc_cleanup_change_table sp_cdc_disable_db sp_cdc_disable_table sp_cdc_drop_job sp_cdc_enable_db sp_cdc_enable_table sp_cdc_restoredb sp_cdc_vupgrade sp_certify_removable sp_change_agent_parameter sp_change_agent_profile sp_change_subscription_properties sp_change_users_login sp_changedistpublisher sp_changedistributiondb sp_changedistributor_password sp_changedistributor_property sp_changemergesubscription sp_changeqreader_agent sp_changereplicationserverpasswords sp_changesubscriptiondtsinfo sp_checkinvalidivarticle sp_copysubscription sp_create_removable sp_cycle_errorlog sp_dbcmptlevel sp_dbmmonitoraddmonitoring sp_dbmmonitorchangealert sp_dbmmonitordropalert sp_dbmmonitordropmonitoring sp_dbmmonitorhelpalert sp_dbmmonitorhelpmonitoring sp_dbmmonitorresults sp_dbmmonitorupdate sp_dbremove sp_drop_agent_parameter sp_drop_agent_profile sp_dropdatatypemapping sp_dropdistpublisher sp_dropdistributiondb sp_dropdistributor sp_dropmergepullsubscription sp_droppullsubscription sp_dropsubscriber sp_dsninfo sp_enumdsn sp_flush_commit_table_on_demand sp_generate_agent_parameter sp_get_distributor sp_get_Oracle_publisher_metadata sp_getagentparameterlist sp_getdefaultdatatypemapping sp_grant_publication_access sp_help_agent_default sp_help_agent_parameter sp_help_agent_profile sp_helpdistpublisher sp_helpdistributor sp_helpmergesubscription sp_helpqreader_agent sp_helpreplicationdboption sp_identitycolumnforreplication sp_IHValidateRowFilter sp_IHXactSetJob sp_link_publication sp_monitor sp_MSadd_distribution_agent sp_MSadd_logreader_agent sp_MSadd_merge_agent sp_MSadd_snapshot_agent sp_MSadd_subscriber_schedule sp_MSadd_tracer_history sp_MSadd_tracer_token sp_MScdc_cleanup_job sp_MScdc_db_ddl_event sp_MScdc_ddl_event sp_MSchange_distribution_agent_properties sp_MSchange_logreader_agent_properties sp_MSchange_merge_agent_properties sp_MSchange_snapshot_agent_properties sp_MSchangedynamicsnapshotjobatdistributor sp_MSchangedynsnaplocationatdistributor sp_MScheck_pull_access sp_MScleanupmergepublisher_internal sp_MSclear_dynamic_snapshot_location sp_MScreate_dist_tables sp_MSdbuserpriv sp_MSdeletefoldercontents sp_MSdrop_6x_replication_agent sp_MSdrop_merge_agent sp_MSdrop_snapshot_dirs sp_MSdropmergedynamicsnapshotjob sp_MSdynamicsnapshotjobexistsatdistributor sp_MSenumallpublications sp_MSfetchAdjustidentityrange sp_MSfix_6x_tasks sp_MSforce_drop_distribution_jobs sp_MSget_agent_names sp_MSget_jobstate sp_MSget_oledbinfo sp_MSget_publication_from_taskname sp_MSgetdbversion sp_MSgetmaxsnapshottimestamp sp_MShelp_repl_agent sp_MShelp_replication_status sp_MShelp_snapshot_agent sp_MShelpconflictpublications sp_MShelpdynamicsnapshotjobatdistributor sp_MShelplogreader_agent sp_MShelpsnapshot_agent sp_MShelptranconflictcounts sp_MSinit_publication_access sp_MSreinit_failed_subscriptions sp_MSremoveoffloadparameter sp_MSrepl_backup_complete sp_MSrepl_backup_start sp_MSrepl_createdatatypemappings sp_MSrepl_dropdatatypemappings sp_MSrepl_enumarticlecolumninfo sp_MSrepl_enumpublications sp_MSrepl_enumpublishertables sp_MSrepl_enumsubscriptions sp_MSrepl_enumtablecolumninfo sp_MSrepl_getdistributorinfo sp_MSrepl_startup_internal sp_MSreplagentjobexists sp_MSreplcheck_permission sp_MSreplcheck_pull sp_MSreplcheck_subscribe sp_MSreplcheck_subscribe_withddladmin sp_MSreplcopyscriptfile sp_MSreplremoveuncdir sp_MSsetalertinfo sp_MSSetServerProperties sp_MSsetupnosyncsubwithlsnatdist sp_MSsetupnosyncsubwithlsnatdist_cleanup sp_MSsetupnosyncsubwithlsnatdist_helper sp_MSstartdistribution_agent sp_MSstartmerge_agent sp_MSstartsnapshot_agent sp_MSstopdistribution_agent sp_MSstopmerge_agent sp_MSstopsnapshot_agent sp_MSupdate_agenttype_default sp_oledbinfo sp_procoption sp_removedbreplication sp_removesrvreplication sp_replication_agent_checkup sp_replicationdboption sp_resetstatus sp_restoredbreplication sp_SetAutoSAPasswordAndDisable sp_setdefaultdatatypemapping sp_updatestats sp_validatelogins sp_vupgrade_mergeobjects sp_vupgrade_replication sp_vupgrade_replsecurity_metadata xp_repl_convert_encrypt_sysadmin_wrapper true

Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Many sites distribute a single SQL Server connection configuration file to all site database users that contains network access information for all databases on the site. Such a file provides information to access SQL Server databases not required by all users that may assist in unauthorized access attempts.

Applications employ the concept of least privilege for specific duties and information systems (including specific functions, ports, protocols, and services). The concept of least privilege is also applied to information system processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and information system accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of information systems. Unauthorized access to sensitive data may compromise the confidentiality of personnel privacy, threaten national security or compromise a variety of other sensitive operations. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user.

Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. The concept of separation of duties extends to processes. The DBMS must run under a custom, dedicated OS or domain account. When the DBMS is running under a shared account, users with access to that account could inadvertently or maliciously make changes to the DBMS’s settings, files, or permissions. Similarly, related services must run under dedicated accounts where this is possible. The SQL Server Browser and Writer services are exceptions: see http://msdn.microsoft.com/en-us/library/hh510203(v=sql.110).aspx and http://msdn.microsoft.com/en-us/library/ms175536(v=sql.110).aspx.true

Separation of duties is a prevalent Information Technology control that is implemented at different layers of the information system, including the operating system and in applications. It serves to eliminate or reduce the possibility that a single user may carry out a prohibited action. Separation of duties requires that the person accountable for approving an action is not the same person who is tasked with implementing or carrying out that action. Additionally, the person or entity accountable for monitoring the activity must be separate as well. To meet this requirement, applications, when applicable, shall be divided where functionality is based on roles and duties. Examples of separation of duties include: (i) mission functions and distinct information system support functions are divided among different individuals/roles; (ii) different individuals perform information system support functions (e.g., system management, systems programming, configuration management, quality assurance and testing, network security); (iii) security personnel who administer access control functions do not administer audit functions; and (iv) different administrator accounts for different roles. Privileges granted outside the role of the application user job function are more likely to go unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment.

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 file permissions. Including or excluding access to the granularity of a single user means providing the capability to either allow or deny access to objects (e.g., files, folders) on a per single-user basis. Databases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.

Discretionary Access Control (DAC) is based on the premise 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). These DAC concepts extend to the server level. Server instances have the potential for the access controls to propagate without limit, resulting in unauthorized access. The DBMS must ensure the recipient of server permissions possesses only the access intended. The DBMS must enforce the ability to limit unauthorized rights propagation. If propagation is not prevented, users can continue to grant rights to other users without limit.true

Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by organizations to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, domains). DAC is a type of access control methodology serving as a means of restricting access to objects and data based on the identity of subjects and/or groups to which they belong. It is discretionary in the sense that application users with the appropriate permissions to access an application resource or data have the discretion to pass that permission on to another user either directly or indirectly. Data protection requirements may result in a DAC policy being specified as part of the application design. Discretionary access controls would be employed at the application level to restrict and control access to application objects and data, thereby providing increased information security for the organization. When DAC controls are employed, those controls must limit sharing to named application users, groups of users, or both. The application DAC controls must also limit the propagation of access rights and have the ability to exclude access to data down to the granularity of a single user. Databases using DAC must have the ability for the owner of an object or information to assign or revoke rights to view or modify the object or information. If the owner of an object or information does not have rights to exclude access to an object or information at a user level, users may gain access to objects and information they are not authorized to view/modify.

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Unsafe assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Unsafe assembly' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any credential' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any connection' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative roles, this access must be removed. (The SQL Server installer gives this privilege to the system account "NT AUTHORITY\SYSTEM", so this account is excluded from the Check. See article KB2847723 in the Microsoft knowledge base.) Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Connect SQL' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Connect SQL' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'View any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any server audit' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Shutdown' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. , If the 'Shutdown' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'External access assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'External access assembly' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create trace event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create trace event notification' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. , If the 'Create server role' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create endpoint' permissions are granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create DDL event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create DDL event notification' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create availability group' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any server audit' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any server audit' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'View any definition' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View any definition' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Authenticate Server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Administer bulk operations' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create DDL event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes. true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Control server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Administer bulk operations' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Administer bulk operations' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter resources' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter resources' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any linked server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any event session' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter trace' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter Settings' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create trace event notification' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter resources' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'External access assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any login' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any availability group' permission is a high server-level privilege that must only be granted to individual administration accounts through roles and users. If the 'Alter any availability group' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any login' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any login' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any linked server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any linked server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Shutdown' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts. If administrative user accounts have direct access to administrative roles, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'View server state' permission is a high server-level privilege that must only granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'View server state' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter trace' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter trace' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Unsafe assembly' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Control server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Control server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Create server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any server role' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter Settings' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter Settings' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Authenticate server' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Authenticate server' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Create any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Create any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'View server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'Alter any server role' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. Privileges granted outside of SQL Server's role-based account assignments are more likely to go unmanaged and without oversight of granted access. Maintenance of privileges using roles defined for discrete job functions offers improved oversight of application user privilege assignments and helps to protect against unauthorized privilege assignment. SQL Server's 'View any definition' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. This administrative privilege must not be assigned directly to administrative user accounts (or any other user accounts). If any user accounts have direct access to administrative privileges, this access must be removed. Note that this does not apply to logins with names of the form '##MS...##'. These accounts are internal-use system principals provisioned by the DBMS, and required by it for specific purposes.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any connection' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any connection' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any credential' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any credential' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any database' permission is a high server-level privilege that must only be granted to individual administration accounts through roles If the 'Alter any database' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any endpoint' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any endpoint' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations, or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter any event session' permission is a high server-level privilege that must only be granted to individual administration accounts through roles. If the 'Alter any event session' permission is granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

The concept of least privilege must be applied to SQL Server processes, ensuring that the processes operate at privilege levels no higher than necessary to accomplish required organizational missions and/or functions. Organizations consider the creation of additional processes, roles, and SQL Server accounts as necessary to achieve least privilege. Organizations also apply least privilege concepts to the design, development, implementation, and operations of SQL Server and the OS. Unauthorized access to sensitive data or SQL Server control may compromise the confidentiality of personnel privacy, threaten national security, compromise a variety of other sensitive operations or lead to a loss of system control. Access controls are best managed by defining requirements based on distinct job functions and assigning access based on the job function assigned to the individual user. SQL Server's 'Alter server state' permission is a high server-level privilege that must only be granted to individual administration accounts through roles, and users who have access must require this privilege to accomplish the organizational missions and/or functions. If the 'Alter server state' permissions are granted to roles that are unauthorized to have this privilege, then this access must be removed. Additionally, the permission must not be denied to a role, because that could disable a user's legitimate access via another role. The fix for this vulnerability specifies the use of REVOKE. Be aware that revoking a permission that is currently denied to a role or user does not necessarily disable the permission. If the user or role can inherent the permission from another role, revoking the denied permission from the user or the first role can effectively enable the inherited permission.true

Non-DAC controls are determined by policy makers and are managed centrally or by a central authority. These controls must not be changed at the discretion of ordinary application users. Data protection requirements may result in a non-DAC policy being specified as part of the application design. Non-DACs are employed at the application level to restrict and control access to application data, thereby providing increased information security for the organization. SQL Server Non-DAC is maintained through the use of Roles. Roles are set up within SQL Server to grant user accounts read and/or write permissions to system objects: databases, tables, columns, etc. After a role is created, user accounts can be assigned to a role granting them permissions of that role. If users have permissions to database objects that they are not authorized to have, the user account that has access to the unauthorized database object must be removed from the role that grants that access. Policy rule sets would be developed to establish that each user receives only the information to which the user is authorized. Frequently, roles grant access to multiple privileges; if a user is authorized and determined to need access to authorized privilege granted by a role, and unauthorized for other privileges of that same role, it may be necessary to split the privileges of one role into two roles.

Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account for later use. Notification of account creation is one method and best practice for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies administrators and/or application owners exist. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Once an attacker establishes initial access to a system, they often attempt to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply modify an existing account. Auditing of account modification is one method and best practice for mitigating this risk. A comprehensive application account management process ensures an audit trail automatically documents the modification of application user accounts and, as required, notifies administrators, application owners, and/or appropriate individuals. Applications must provide this capability directly, leverage complimentary technology providing this capability, or a combination thereof. Automated account-auditing processes greatly reduce the risk that accounts will be surreptitiously modified, and provides logging that can be used for forensic purposes. To address the multitude of policy based access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network and system access is accomplished by leveraging common communication protocols to establish a remote connection. These connections will typically originate over either the public Internet or the Public Switched Telephone Network (PSTN). Neither of these internetworking mechanisms is private or secure, and they do not by default restrict access to networked resources once connectivity is established. Numerous best practices are employed to protect remote connections, such as utilizing encryption to protect data sessions and firewalls to restrict and control network connectivity. In addition to these protections, auditing must also be utilized in order to track system activity, assist in diagnosing system issues, and provide evidence needed for forensic investigations post security incident.

Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). The session data traversing the remote connection could be intercepted and compromised. Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. If cryptography is not used, then the session data traversing the remote connection could be intercepted and potentially modified. Cryptography provides a means to secure the remote connection to prevent unauthorized changes to the data traversing the remote access connection, thereby providing a degree of integrity. The encryption strength of the mechanism is selected based on the security categorization of the information that is traversing the remote connection. Databases that accept remote connections must use approved cryptography to protect data being passed via an unsecure network. If approved cryptography is not used, data can be intercepted and potentially modified. ("Remote access," in this context, does not necessarily relate to the (deprecated) "Allow remote connections to this server" configuration setting.)

Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). The session data traversing the remote connection could be intercepted and compromised. Cryptography provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection, thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information traversing the remote connection. Databases that accept remote connections must use approved cryptography to prevent disclosure of data being passed via an unsecure network. If approved cryptography is not used, data can be intercepted or compromised. ("Remote access," in this context, does not necessarily relate to the (deprecated) "Allow remote connections to this server" configuration setting.)

Remote access is any access to an organizational information system by a user (or an information system) communicating through an external, non-organization-controlled network (e.g., the Internet). Examples of remote access methods include dial-up, broadband, and wireless. Remote network access is accomplished by leveraging common communication protocols and establishing a remote connection. These connections will typically occur over either the Internet or the Public Switched Telephone Network (PSTN). Since neither of these internetworking mechanisms is private or secure, if cryptography is not used, then the session data traversing the remote connection could be intercepted and compromised. Cryptography provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection, thereby providing a degree of confidentiality. The encryption strength of the mechanism is selected based on the security categorization of the information traversing the remote connection. Login/account information can be compromised if authentication data being passed over a public network is not secured via approved cryptography. This can result in unauthorized access to the database. ("Remote access," in this context, does not necessarily relate to the (deprecated) "Allow remote connections to this server" configuration setting.)