CUI

USNS MONTFORD POINT - Findings

Back to Ship Export CSV Download POA&M

Showing 5 of 5 findings (filtered) View Documentation Status (90 tracked)

Vuln ID	Severity	Asset	STIG	Title	Status	Doc Status	Assigned To	Actions
V-213914	CAT III	MONT-BE-002	MS SQL Server 2016 Database Security Tec...	SQL Server must isolate security functions from no...		-
Check Text Determine elements of security functionality (lists of permissions, additional authentication information, stored procedures, application specific auditing, etc.) that are being housed inside SQL server. For any elements found, check SQL Server to determine if these objects or code implementing security functionality are located in a separate security domain, such as a separate database, schema, or table created specifically for security functionality. If the database is a SQL Server default database (master, msdb, model, tempdb), this is NA. Run the following query to list all the user-defined databases: SELECT Name FROM sys.databases WHERE database_id > 4 ORDER BY 1; Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding. Fix Text Check the server documentation, 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. Microsoft SQL Server 2005 introduced the concept of database object schemas. 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 to 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. Finding Details Evaluate-STIG 1.2507.5 (Scan-SqlServer2016Database_Checks) was unable to determine a Status but found the below configuration on 10/23/2025: Instance: MONT-BE-002\BKUPEXEC64 Database: BEDB ResultHash: DD3B0DF50BA0D49C44E09088B157BC178BD023F1 ~~~~~ DBA, Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding: Name ---- BEDB Source: _Reviewed/MONT-BE-002/Checklist/MONT-BE-002_SQL2016DB_MONT-BE-002-BKUPEXEC64_BEDB_V3R3_20251023-143959.ckl Scan Date: 2026-01-14T12:57:40.371699 Technology Area: Database Review
V-213914	CAT III	MONT-BE-002	MS SQL Server 2016 Database Security Tec...	SQL Server must isolate security functions from no...		-
Check Text Determine elements of security functionality (lists of permissions, additional authentication information, stored procedures, application specific auditing, etc.) that are being housed inside SQL server. For any elements found, check SQL Server to determine if these objects or code implementing security functionality are located in a separate security domain, such as a separate database, schema, or table created specifically for security functionality. If the database is a SQL Server default database (master, msdb, model, tempdb), this is NA. Run the following query to list all the user-defined databases: SELECT Name FROM sys.databases WHERE database_id > 4 ORDER BY 1; Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding. Fix Text Check the server documentation, 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. Microsoft SQL Server 2005 introduced the concept of database object schemas. 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 to 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. Finding Details Evaluate-STIG 1.2507.5 (Scan-SqlServer2016Database_Checks) found this to be NOT APPLICABLE on 10/23/2025 Instance: MONT-BE-002\BKUPEXEC64 Database: master ResultHash: EF787DBB5C776F2359DFBEEBF14C0D6F928F1B0E ~~~~~ This is the 'master' database so this requirement is NA. Source: _Reviewed/MONT-BE-002/Checklist/MONT-BE-002_SQL2016DB_MONT-BE-002-BKUPEXEC64_master_V3R3_20251023-144120.ckl Scan Date: 2026-01-14T12:57:40.470811 Technology Area: Database Review
V-213914	CAT III	MONT-BE-002	MS SQL Server 2016 Database Security Tec...	SQL Server must isolate security functions from no...		-
Check Text Determine elements of security functionality (lists of permissions, additional authentication information, stored procedures, application specific auditing, etc.) that are being housed inside SQL server. For any elements found, check SQL Server to determine if these objects or code implementing security functionality are located in a separate security domain, such as a separate database, schema, or table created specifically for security functionality. If the database is a SQL Server default database (master, msdb, model, tempdb), this is NA. Run the following query to list all the user-defined databases: SELECT Name FROM sys.databases WHERE database_id > 4 ORDER BY 1; Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding. Fix Text Check the server documentation, 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. Microsoft SQL Server 2005 introduced the concept of database object schemas. 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 to 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. Finding Details Evaluate-STIG 1.2507.5 (Scan-SqlServer2016Database_Checks) found this to be NOT APPLICABLE on 10/23/2025 Instance: MONT-BE-002\BKUPEXEC64 Database: model ResultHash: 0C37E2D31736DC7FA21808E49F68A9407D675C75 ~~~~~ This is the 'model' database so this requirement is NA. Source: _Reviewed/MONT-BE-002/Checklist/MONT-BE-002_SQL2016DB_MONT-BE-002-BKUPEXEC64_model_V3R3_20251023-144128.ckl Scan Date: 2026-01-14T12:57:40.569961 Technology Area: Database Review
V-213914	CAT III	MONT-BE-002	MS SQL Server 2016 Database Security Tec...	SQL Server must isolate security functions from no...		-
Check Text Determine elements of security functionality (lists of permissions, additional authentication information, stored procedures, application specific auditing, etc.) that are being housed inside SQL server. For any elements found, check SQL Server to determine if these objects or code implementing security functionality are located in a separate security domain, such as a separate database, schema, or table created specifically for security functionality. If the database is a SQL Server default database (master, msdb, model, tempdb), this is NA. Run the following query to list all the user-defined databases: SELECT Name FROM sys.databases WHERE database_id > 4 ORDER BY 1; Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding. Fix Text Check the server documentation, 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. Microsoft SQL Server 2005 introduced the concept of database object schemas. 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 to 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. Finding Details Evaluate-STIG 1.2507.5 (Scan-SqlServer2016Database_Checks) found this to be NOT APPLICABLE on 10/23/2025 Instance: MONT-BE-002\BKUPEXEC64 Database: msdb ResultHash: 3406777B844458113130EE297FDBBCA208836E7C ~~~~~ This is the 'msdb' database so this requirement is NA. Source: _Reviewed/MONT-BE-002/Checklist/MONT-BE-002_SQL2016DB_MONT-BE-002-BKUPEXEC64_msdb_V3R3_20251023-144148.ckl Scan Date: 2026-01-14T12:57:40.663257 Technology Area: Database Review
V-213914	CAT III	MONT-BE-002	MS SQL Server 2016 Database Security Tec...	SQL Server must isolate security functions from no...		-
Check Text Determine elements of security functionality (lists of permissions, additional authentication information, stored procedures, application specific auditing, etc.) that are being housed inside SQL server. For any elements found, check SQL Server to determine if these objects or code implementing security functionality are located in a separate security domain, such as a separate database, schema, or table created specifically for security functionality. If the database is a SQL Server default database (master, msdb, model, tempdb), this is NA. Run the following query to list all the user-defined databases: SELECT Name FROM sys.databases WHERE database_id > 4 ORDER BY 1; Review the database structure to determine where security related functionality is stored. If security-related database objects or code are not kept separate, this is a finding. Fix Text Check the server documentation, 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. Microsoft SQL Server 2005 introduced the concept of database object schemas. 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 to 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. Finding Details Evaluate-STIG 1.2507.5 (Scan-SqlServer2016Database_Checks) found this to be NOT APPLICABLE on 10/23/2025 Instance: MONT-BE-002\BKUPEXEC64 Database: tempdb ResultHash: E72A43AA1F56BC880CAFBD122F108E27602D0980 ~~~~~ This is the 'tempdb' database so this requirement is NA. Source: _Reviewed/MONT-BE-002/Checklist/MONT-BE-002_SQL2016DB_MONT-BE-002-BKUPEXEC64_tempdb_V3R3_20251023-144154.ckl Scan Date: 2026-01-14T12:57:40.769694 Technology Area: Database Review

CUI