Detections
Analytics

SQLD-22-001900 - SQL Server must isolate security functions from nonsecurity functions.

Information

An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions.

Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.

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 are commingled, users who have access to nonsecurity functionality may be able to access security functionality.

NOTE: Nessus has not performed this check. Please review the benchmark to ensure target compliance.

Solution

Check documentation and locate security-related database objects and code in a separate database, schema, table, or other separate security domain from database objects and code implementing application logic.

Schemas are analogous to separate namespaces or containers used to store database objects. Security permissions apply to schemas, making them an important tool for separating and protecting database objects based on access rights. Schemas reduce the work required, and improve the flexibility, for security-related administration of a database.

User-schema separation allows for more flexibility in managing database object permissions. A schema is a named container for database objects, which allows the user group objects into separate namespaces.

Where possible, locate security-related database objects and code in a separate database, schema, or other separate security domain from database objects and code implementing application logic. In all cases, use GRANT, REVOKE, DENY, ALTER ROLE ... ADD MEMBER ... and/or ALTER ROLE .... DROP MEMBER statements to add and remove permissions on server-level and database-level security-related objects to provide effective isolation.

Consider submitting a request to the vendor for changes to a COTS database when database structure does not isolate security functions and cannot be altered directly by the database administrators without loss of official support.

See Also

https://dl.dod.cyber.mil/wp-content/uploads/U_MS_SQL_Server_2022_Y25M06_STIG.zip

Item Details

Category: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-3, CAT|II, CCI|CCI-001084, Rule-ID|SV-271172r1109195_rule, STIG-ID|SQLD-22-001900, Vuln-ID|V-271172

Plugin: MS_SQLDB

Control ID: 6e44bff7b072b40a07a09a18c6241d7d4986829d156158ca171ef1013bddaa63