Applications STIGs
CAT I 34
Any vulnerability, the exploitation of which will directly and immediately result in loss of confidentiality, availability or integrity.
-
Messages protected with WS_Security must use time stamps with creation and expiration times.
Maps to AC-17(2) via CCI-000068Check
Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. If the application does not utilize WS-Security tokens, this check is not applicable. Examine the contents of a SOAP message using WS Security; all messages should contain time stamps, sequence numbers, and expiration. If messages using WS Security do not contain time stamps, sequence numbers, and expiration, this is a finding.
Fix
Design and configure applications using WS-Security messages to use time stamps with creation and expiration times and sequence numbers.
-
Validity periods must be verified on all application messages using WS-Security or SAML assertions.
Maps to AC-17(2) via CCI-000068Check
Ask the application representative for the design document. Review the design document for web services. If the application does not utilize WSS or SAML assertions, this requirement is not applicable. Review the design document and verify validity periods are checked on all messages using WS-Security or SAML assertions. If the design document does not exist, or does not indicate validity periods are checked on messages using WS-Security or SAML assertions, this is a finding.
Fix
Design and configure the application to use validity periods, ensure validity periods are verified on all WS-Security token profiles and SAML Assertions.
-
The application must use the NotOnOrAfter condition when using the SubjectConfirmation element in a SAML assertion.
Maps to AC-17(2) via CCI-000068Check
Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the element. All messages should contain the element. This can be accomplished if the application allows the ability to view XML messages or via a protocol analyzer like Wireshark. If SOAP messages do not contain elements, this is a finding.
Fix
Design and configure the application to use the condition when using the element in a SAML assertion.
-
The application must use both the NotBefore and NotOnOrAfter elements or OneTimeUse element when using the Conditions element in a SAML assertion.
Maps to AC-17(2) via CCI-000068Check
Ask the application representative for the design document. Review the design document for web services using SAML assertions. If the application does not utilize SAML assertions, this check is not applicable. Examine the contents of a SOAP message using the element; all messages should contain the and or element when in a SAML Assertion. This can be accomplished using a protocol analyzer such as Wireshark. If SOAP using the element does not contain and or elements, this is a finding.
Fix
Design and configure the application to implement the use of the and or when using the element in a SAML assertion.
-
The application must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.
Maps to AC-3 via CCI-000213Check
Review the application documentation and interview the application administrator. Review application data protection requirements. Identify application resources that require protection and authentication over and above the authentication required to access the application itself. This can be access to a URL, a folder, a file, a process or a database record that should only be available to certain individuals. Identify the access control methods utilized by the application in order to control access to the resource. Examples include Role-Based Access Control policies (RBAC). Using RBAC as an example, utilize a test account placed into a test role. Set a protection control on a resource and explicitly deny access to the role assigned to the test user account. Try to access an application resource that is not configured to allow access. Access should be denied. If the enforcement of configured access restrictions is not performed, this is a finding.
Fix
Design or configure the application to enforce access to application resources.
-
The application must execute without excessive account permissions.
Maps to AC-6(8) via CCI-002233Check
Review the system documentation or interview the application representative and identify if the application utilizes an account in order to operate. Determine the OS user groups in which each application account is a member. List the user rights assigned to these users and groups using relevant OS commands and evaluate whether any of them provide admin rights or if they are unnecessary or excessive. If the application connects to a database, open an admin console to the database and view the database users, their roles and group rights. Locate the application user account used to access the database and examine the accounts privileges. This includes group privileges. If the application user account has excessive OS privileges such as being in the admin group, database privileges such as being in the DBA role, has the ability to create, drop, alter the database (not application database tables), or if the application user account has other excessive or undefined system privileges, this is a finding.
Fix
Configure the application accounts with minimalist privileges. Do not allow the application to operate with admin credentials.
-
The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period.
Maps to AC-7 via CCI-000044Check
All testing must be performed within a 15-minute window. Log on to the application with a test user account. Intentionally enter an incorrect user password or pin. Repeat 2 times within 15 minutes for a total of three failed attempts. Notification of a locked account may or may not be provided. Using the correct user password or pin, attempt to logon a 4th time. If the logon is successful upon the 4th attempt the account was not locked after the third failed attempt and this is a finding.
Fix
Configure the application to enforce an account lock after 3 failed logon attempts occurring within a 15-minute window.
-
The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
Maps to IA-2 via CCI-000764Check
Review the application documentation and interview the application administrator to determine how organizational users access the application. If the application is publicly available, providing access to publicly releasable data and the users are non-organizational users such as individuals who no longer have a CAC (e.g., retirees) or members of the public with no requirement for DoW credentials, this requirement is not applicable. The requirement still applies to DoW organizational users and admins when accessing the non-public data areas or system resources of the system. Attempt to access the application and confirm that a unique user account and password or CAC token and pin are required in order to access the application. If the application does not uniquely identify and authenticate users, this is a finding.
Fix
Configure the application to uniquely identify and authenticate users and user processes.
-
The application must enforce a minimum 15-character password length.
Maps to IA-5(1) via CCI-004066, CCI-000205Check
Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, this requirement is Not Applicable. Access the application management interface and create a test user account or log on to the system with a test account and access the functionality that provides password change capabilities. When prompted to provide the password, attempt to create a password shorter than 15 characters in length. If a password shorter than 15 characters can be created, this is a finding.
Fix
Configure the application to require 15 characters in the password.
-
The application must only store cryptographic representations of passwords.
Maps to IA-5(1) via CCI-004062, CCI-000196Check
Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, this requirement is Not Applicable. Have the application administrator identify the application's password storage locations. Potential locations include the local file system where the application is stored or in an application-related database table that should not be accessible to application users. Review application files and folders using a text editor or by using a database tool that allows you to view data stored in database tables. Look for indications of stored user information and review that information. Determine if password strings are readable/discernable. Determine if the application uses the MD5 hashing algorithm to create password hashes. If the passwords are readable or there is no indication the application utilizes cryptographic hashing to protect passwords, or if the MD5 hash algorithm is used to create password hashes, this is a finding.
Fix
Use strong cryptographic hash functions when creating password hash values. Utilize random salt values when creating the password hash. Ensure strong access control permissions on data files containing authentication data.
-
The application must transmit only cryptographically-protected passwords.
Maps to IA-5(1) via CCI-000197Check
Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, the requirement is not applicable. Identify when the application transmits passwords. This will most likely be when the user authenticates to the application or when the application authenticates to another resource. Access the application management interface with a test account and access the functionality that requires a password be provided. If the interface is via a web browser, verify the web browser has gone secure prior to entering any password or authentication information. This can be done by viewing the browser and observing a “lock” icon displayed somewhere in the browser as well as an https:// to indicate an SSL connection. Most browsers display this in the upper left hand corner. If the application is transmitting the password rather than the user, obtain design documentation from the application admin that provides the details on how they are protecting the password during transmission. This will usually be via a TLS/SSL tunneled connection or VPN. If the passwords are not encrypted when being transmitted, this is a finding.
Fix
Configure the application to encrypt passwords when they are being transmitted.
-
The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
Maps to IA-5(2) via CCI-000185Check
Review the application documentation, the application architecture and interview the application administrator to identify the method employed by the application for validating certificates. Review the method to determine if a certification path that includes status information is constructed when certificate validation occurs. Some applications may utilize underlying OS certificate validation and certificate path building capabilities while others may build the capability into the application itself. The certification path will include the intermediary certificate CAs along with a status of the CA server's signing certificate and will end at the trusted root anchor. If the application does not construct a certificate path to an accepted trust anchor, this is a finding.
Fix
Design the application to construct a certification path to an accepted trust anchor when using PKI-based authentication.
-
The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key.
Maps to IA-5(2) via CCI-000186Check
Review the application documentation and interview the application administrator to identify where the application's private key is stored. If the application does not perform code signing or other cryptographic tasks requiring a private key, this requirement is not applicable. Ask the administrator to demonstrate where the application private key(s) are stored. Examine access restrictions and ensure access controls are in place to restrict access to the private key(s). If the key(s) are stored on the file system, ensure adequate file permissions are set so as to only allow authorized users and processes. If the key(s) are maintained or available via an application interface, ensure the application provides access controls that limit access via the application interface to only authorized users and processes. Review access controls and attempt to use a relevant user account, group or application role that is not allowed access to the private key. Verify access to the keys is denied. If unauthorized access is granted to the private key(s), this is a finding.
Fix
Configure the application or relevant access control mechanism to enforce authorized access to the application private key(s).
-
The application must not display passwords/PINs as clear text.
Maps to IA-6 via CCI-000206Check
Ask the application admin to log on to the application. Observe the authentication process and verify any display feedback provided when the admin enters her/his password is obfuscated and not clear text. For applications that display authentication feedback for a very limited time, ensure the feedback time the character is displayed is only momentary i.e., fractions of a second. Using a text editor, copy the obfuscated password and paste to a text file. Do not save the file. If the application displays clear text when the password/PIN is entered, or if the time period for displayed feedback exceeds fractions of a second, or if the clear text password/PIN is displayed when pasted, this is a finding.
Fix
Configure the application to obfuscate passwords and PINs when they are being entered so they cannot be read. Design the application so obfuscated passwords cannot be copied and then pasted as clear text.
-
The application must use mechanisms meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module.
Maps to IA-7 via CCI-000803Check
Review the application documentation and interview the application administrator. Identify if the application provides access to cryptographic modules and if access is required in order to manage cryptographic modules contained within the application. If the application does not provide authenticated access to a cryptographic module, the requirement is not applicable. Review and identify the cryptographic module. Refer to the NIST website listing all FIPS-approved cryptographic modules. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm If the cryptographic module that requires authentication is not on the FIPS-approved module list, this is a finding.
Fix
Use FIPS-approved cryptographic modules.
-
The application must not expose session IDs.
Maps to SC-23 via CCI-001184Check
Review the application documentation and configuration. Interview the application administrator and obtain implementation documentation identifying system architecture. Identify the application communication paths. This includes system to system communication and client to server communication that transmit session identifiers over the network. Have the application administrator identify the methods and mechanisms used to protect the application session ID traffic. Acceptable methods include SSL/TLS both one-way and two-way and VPN tunnel. The protections must be implemented on a point-to-point basis based upon the architecture of the application. For example; a web application hosting static data will provide SSL/TLS encryption from web client to the web server. More complex designs may encrypt from application server to application server (if applicable) and application server to database as well. If the session IDs are unencrypted across network segments, this is a finding.
Fix
Configure the application to protect session IDs from interception or from manipulation.
-
The application must destroy the session ID value and/or cookie on logoff or browser close.
Maps to SC-23(1) via CCI-001185Check
Review the application documentation and interview the application administrator. Identify how the application destroys session IDs. If using a web development framework, ask the application administrator to provide details on the framework's session configuration. Review framework configuration setting to determine how the session identifiers are destroyed. Review the client system and using a browser or other tool capable of viewing client cookies, identify cookies set by the application and verify that application session ID cookies are destroyed once the user has logged off or the browser has closed. If the session IDs and associated cookies are not destroyed on logoff or browser close, this is a finding.
Fix
Configure the application to destroy session ID cookies once the application session has terminated.
-
The application must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.
Maps to SC-24 via CCI-001190Check
Review application design documentation, vulnerability scanner reports and interview application administrator to identify application components. The design of the application should account for the following: - Connections to databases are left open - Access control mechanisms are disabled - Data left in temporary locations Testing application failure will require taking down parts of the application. Review the vulnerability assessment configuration settings included in vulnerability report. Examine the application test plans and procedures to determine if this type of failure was previously tested. If test plans exist, validate the tests by performing a subset of the checks. If test plans do not exist, an application failure must be simulated. Simulate a failure. This can be accomplished by stopping the web server service and/or the database service. Also, for applications using web services stop the web service and/or the database. Check to ensure that application data is still protected. Some examples of tests follow: - Try to submit SQL queries to the database. Verify that the database requires authentication before returning data. - Try to read the application source files; access should not be granted to these files because the application is not operating. - Try to open database files; data should not be available because the application is not operational. If the application fails in such a way that the application security controls are rendered inoperable, this is a finding.
Fix
Fix any vulnerability found when the application is an insecure state (initialization, shutdown and aborts).
-
The application must implement approved cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest on organization-defined information system components.
Maps to SC-28(1) via CCI-002475Check
Review the documentation and interview the application administrator. Identify the data processed by the application and the accompanying data protection requirements. Determine if the data owner has specified data protection encryption requirements regarding modification of data. Determine if the application is processing publicly releasable, CUI, or classified data. Determine if the application configuration information contains sensitive information. If the data is strictly publicly releasable information and system documentation specifies no data encryption is required for any hosted application data, this is not applicable. Access the data repository and have the application administrator identify the encryption protections that are utilized. If the application processes classified data or if the data owner has specified encryption requirements and the application administrator is unable to demonstrate how the data is encrypted, this is a finding.
Fix
Identify data elements that require protection. Document the data types and specify encryption requirements. Encrypt data according to DoW policy or data owner requirements.
-
The application must use appropriate cryptography in order to protect stored DoW information when required by the information owner or DoW policy.
Maps to SC-28(1) via CCI-002476Check
Review the application documentation and interview the application administrator. Identify the data processed by the application and the accompanying data protection requirements. Determine if the application is processing publicly releasable, SBU, CUI, or classified data. If the data is strictly publicly releasable information with no SBU, CUI, or classified and system documentation specifies no data encryption is required for any hosted application data, this requirement is not applicable. Have the application administrator identify the encryption protections that are utilized. Validate the application is using encryption protections that are commensurate with the data being protected. If the application is processing classified data, type 1, suite B cryptography, or hardware-based encryption solutions; meeting NSA encryption requirements for classified data processing and storage is required. If the application processes classified data or if the data owner has specified encryption requirements and the application administrator is unable to demonstrate the type of encryption used or if the application processes classified and does not use type 1, suite B, or NSA-approved hardware-based encryption, this is a finding.
Fix
Identify data elements that require protection. Document the data types and specify encryption requirements. Encrypt classified data using Type 1, Suite B, or other NSA-approved encryption solutions.
-
The application must protect the confidentiality and integrity of transmitted information.
Maps to SC-8 via CCI-002418Check
Review the application documentation and interview the application administrator. Identify application clients, servers and associated network connections including application networking ports. Identify the types of data processed by the application and review any documented data protection requirements. Identify the application communication protocols. Review application documents for instructions or guidance on configuring application encryption settings. Verify the application is configured to enable encryption protections for data in accordance with the data protection requirements. If no data protection requirements exist, ensure all application data is encrypted. If the application does not utilize TLS, IPsec or other approved encryption mechanism to protect the confidentiality and integrity of transmitted information, this is a finding.
Fix
Configure all of the application systems to require TLS encryption in accordance with data protection requirements.
-
The application must not store sensitive information in hidden fields.
Maps to SC-8(2) via CCI-002420Check
Interview application administrator and review application documentation to identify and familiarize with the application features and functions. Request most recent code review and vulnerability scan results. Review test configuration to ensure testing for hidden fields was conducted. Review test results for incidents of hidden data fields. Examine identified hidden fields and determine what type of data is stored in the hidden fields. If the data stored in the hidden fields are determined to be authentication or session related data, or if the code review or vulnerability scan results are not available and configured to test for hidden fields, this is a finding.
Fix
Design and configure the application to not store sensitive information in hidden fields. Encrypt sensitive information stored in hidden fields using DoW-approved encryption and use server side session management techniques for user session management.
-
The application must protect from Cross-Site Scripting (XSS) vulnerabilities.
Maps to SI-10 via CCI-001310Check
Review the application documentation and the vulnerability assessment scan results from automated vulnerability assessment tools. Verify scan configuration settings include web-based applications settings which include XSS tests. Review scan results for XSS vulnerabilities. If the scan results indicate aspects of the application are vulnerable to XSS, request subsequent scan data that shows the XSS vulnerabilities previously detected have been fixed. If results that show compliance are not available, request proof of any steps that have been taken to mitigate the risk. This can include using network-based IPS to detect and prevent XSS attacks from occurring. If scan results are not available, perform manual testing in various data entry fields to determine if XSS exist. Navigate through the web application as a regular user and identify any data entry fields where data can be input. Input the following strings: alert('hello') <img src=x onerror="alert(document.cookie);" If the script pop up box is displayed, or if scan reports show unremediated XSS results and no mitigating steps have been taken, this is a finding.
Fix
Verify user input is validated and encode or escape user input to prevent embedded script code from executing. Develop your application using a web template system or a web application development framework that provides auto escaping features rather than building your own escape logic.
-
The application must protect from command injection.
Maps to SI-10 via CCI-001310Check
Review the application documentation and the system configuration settings. Interview the application administrator for details regarding security assessment including automated code review and vulnerability scans conducted to test for command injection. Review the scan results from the entire application. Verify scan configuration is set to check for command injection vulnerabilities. If results indicate vulnerability, verify a subsequent scan has been run to ensure the issue has been remediated. Manual test procedures are available on the OWASP website. Procedures may need to be modified to suit application architecture. https://www.owasp.org/index.php/Testing_for_Command_Injection_%28OTG-INPVAL-013%29 If testing results are not provided demonstrating the vulnerability does not exist, or if the application representative cannot demonstrate how actions are taken to identify and protect from command injection vulnerabilities, this is a finding.
Fix
Modify the application so as to escape/sanitize special character input or configure the system to protect against command injection attacks based on application architecture.
-
The application must not be vulnerable to SQL Injection.
Maps to SI-10 via CCI-001310Check
Review the application documentation and interview the application administrator. Request the latest vulnerability scan test results. Verify the scan configuration is configured to test for SQL injection flaws. Review the scan results to determine if any SQL injection flaws were detected during application testing. If SQL injection flaws were discovered, request a subsequent scan that will show that the issues have been remediated. If the scan results are not available, identify the database product in use and refer to the OWASP web application testing guide for detailed instructions on performing a manual SQL injection test. The instructions are located here and many tests are organized by database product: https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL-005%29 If the application is vulnerable to SQL injection attack, contains SQL injection flaws, or if scan results do not exist, this is a finding.
Fix
Modify the application and remove SQL injection vulnerabilities.
-
The application must not be vulnerable to XML-oriented attacks.
Maps to SI-10 via CCI-001310Check
Review the application documentation, the application architecture and interview the application administrator. Identify any XML-based web services or XML functionality performed by the application. Determine if an XML firewall is deployed to protect application from XML-related attacks. If the application does not process XML, the requirement is not applicable. Review the latest application vulnerability assessment and verify the scan was configured to test for XML-related vulnerabilities and security issues. Examples include but are not limited to: XML Injection XML related Denial of Service XPATH injection XML Signature attacks XML Spoofing If an XML firewall is deployed, request configuration information regarding the application and validate the firewall is configured to protect the application. If the vulnerability scan is not configured to scan for XML-oriented vulnerabilities, if no scan results exist, or if the XML firewall is not configured to protect the application, this is a finding.
Fix
Design the application to utilize components that are not vulnerable to XML attacks. Patch the application components when vulnerabilities are discovered.
-
The application must not be subject to input handling vulnerabilities.
Maps to SI-10(3) via CCI-002754Check
Review the application documentation and interview the application administrator. If working with the developer, request documentation on their development processes and what their standard operating procedure is for sanitizing all application input. Identify the latest vulnerability scan results. Review the scan results and scan configuration settings. Verify the scan was configured to identify input validation vulnerabilities. If the scan results detected high risk vulnerabilities, verify a more recent scan shows remediation of the vulnerabilities is available for examination. Review any risk acceptance documentation that indicates the ISSO has reviewed and accepted the risk. If the vulnerability scan is not configured to test for input validation vulnerabilities if the most recent scan results show that high risk input validation vulnerabilities exist and a documented risk acceptance from the ISSO is not available, or if the scan results do not exist, this is a finding.
Fix
Follow best practice when accepting user input and verify that all input is validated before the application processes the input. Remediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.
-
The application must not be vulnerable to overflow attacks.
Maps to SI-16 via CCI-002824Check
Review the application documentation and architecture. Interview the application admin and identify the most recent code testing and analysis that has been conducted. Review the test results; verify configuration of analysis tools are set to check for the existence of overflows. This includes but is not limited to buffer overflows, stack overflows, heap overflows, integer overflows and format string overflows. If overflows are identified in the test results, verify the latest test results are being used, if not, ensure remediation has been completed. If the test results show overflows exist and no remediation evidence is presented, or if test results are not available, this is a finding.
Fix
Design the application to use a language or compiler that performs automatic bounds checking. Use an abstraction library to abstract away risky APIs. Use compiler-based canary mechanisms such as StackGuard, ProPolice, and the Microsoft Visual Studio/GS flag. Use OS-level preventative functionality and control user input validation. Patch applications when overflows are identified in vendor products.
-
Application web servers must be on a separate network segment from the application and database servers if it is a tiered application operating in the DoW DMZ.
Maps to AC-6(4) via CCI-002225Check
Review the application documentation. Review the application data protection requirements and identify if all data types hosted on server are identical. Review the network diagram and identify web servers/web services, web application servers, and database servers. If the application is not hosted in the DoW DMZ, this requirement is not applicable. Verify the application web servers are separated from the application and database servers if the application is a tiered design as per DoW DMZ STIG requirements. If the application is tiered and the network infrastructure hosting the application is not configured to provide separation and security access controls between the tiered layers in accordance with DoW DMZ requirements, this is a finding.
Fix
Separate web server from other application tiers and place it on a separate network segment apart from the application and database servers in accordance with DoW DMZ data access controls requirements.
-
The application must not contain embedded authentication data.
Maps to IA-5(7) via CCI-002367Check
Review the application documentation and any available source code; this includes configuration files such as global.asa, if present, scripts, HTML files, and any ASCII files. Identify any instances of passwords, certificates, or sensitive data included in code. If credentials were found, check the file permissions and ownership of the offending file. If access to the folder hosting the file is not restricted to the related application process and administrative users, this is a finding. The finding details should note specifically where the offending credentials or data were located and what resources they enabled.
Fix
Remove embedded authentication data stored in code, configuration files, scripts, HTML file, or any ASCII files.
-
The application must have the capability to mark sensitive/classified output when required.
Maps to MP-3 via CCI-001010Check
Review the application documentation and interview the application administrator. Ask the application representative for the application’s classification guide. This guide should document the data elements and their classification. Determine which application functions to examine, giving preference to report generation capabilities and the most common user transactions that involve sensitive data (CUI, secret, or above). Log on to the application and perform these steps in sequence, printing output when applicable. The application representative’s assistance may be required to perform these steps. For each function, note whether the appropriate markings appear on the displayed and printed output. If a classification document does not exist, data must be marked at the highest classification of the system. Appropriate markings for an application are as follows: For classified and CUI data, markings are required at a minimum at the top and the bottom of screens and reports. In some cases, technology may prohibit the appropriate markings on printed documents. For example, in some cases, it is not possible to mark all pages top and bottom when a user prints from a browser. If this is the case, ask the application representative if user procedures exist for manually marking printed documents. If procedures do exist, examine the procedures to verify the data would be marked correctly if the users follow the procedures. Ask how these procedures are distributed to the users. For systems that do not process sensitive/classified/CUI information, and do not require classification markings, this is not applicable. If appropriate markings are not present within the application and it is technically possible to have the markings present, this is a finding. If it is not technically feasible to meet the minimum marking requirement and no user procedures exist, or if followed the procedures will result in incorrect markings, or the procedures are not readily available to users, this is a finding. In any case of a finding, the finding details must specify which functions failed to produce the desired results. After completing the test, destroy all printed output using the site’s preferred method for disposal. Examples are using a shredder or disposing in burn bags.
Fix
Enable the application to adequately mark sensitive/classified output.
-
All products must be supported by the vendor or the development team.
Maps to SA-22 via CCI-003376Check
Review the application documentation and interview the application administrator. Identify all software components. Review the version information and identify the vendor if COTS software. Access the vendor website to verify the version is still supported. Ask the application representative for proof that the application and all of its components are supported. Examples of proof may include: design documentation that includes support information, support specific contract documentation, successful creation of vendor support tickets, website toll free support phone numbers etcetera. If any of the software components are not supported by a COTS vendor or a GOTS organization, this is a finding.
Fix
Remove or decommission all unsupported software products in the application.
-
The application must be decommissioned when maintenance or support is no longer available.
Maps to SA-22 via CCI-003376Check
Interview the application representative and determine if all the application components are under maintenance contract. The entire application may be covered by a single maintenance agreement. The application should be decommissioned if maintenance or security support is no longer being provided by the vendor or by the development staff of a custom developed application. If the application or any of the application components are not being maintained, this is a finding.
Fix
Ensure there is maintenance for the application.
-
Default passwords must be changed.
Maps to SA-4(5) via CCI-003109Check
Identify the application name and version and do an Internet search for the product name and the string "default password". If default passwords are found, attempt to authenticate with the published default passwords. If authentication is successful, this is a finding.
Fix
Configure the application to use strong authenticators instead of passwords when possible. Otherwise, change default passwords to a DoW-approved strength password and follow all guidance for passwords.