Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
This check is not applicable where application users are determined to have authorized access to the application and are not eligible to receive a CAC/DoD PKI certificate (e.g., retirees, dependents, etc.), as defined by DoDI 8520.2. 1) Ask the application representative if an application is PK-enabled. If the answer is no, this a finding. If the application is in a production environment, the application representative should be able to login to the application with a CAC. If the application resides on the SIPRNet, or in a test environment, the application representative may only have test certificates and should be able to login to the application with a soft certificate. Note: The certificates for this check do not need to be DoD approved certificates. 2) If the application representative cannot log in to the application with either soft certificates or certificates from a CAC, it is a finding. Ask the application representative where the certificate store is for the application and verify there are the correct test or production certificates for user authentication. Make certain a certificate is required for user authentication. Ask the application representative to temporarily remove the certificate from the certificate store and authenticate to the application. For web application using Internet Explorer from the Tools Menu Select “Internet Options” Select “Content” tab Select “Certificates” Select “Remove” Other applications certificate stores will have similar features. 3) If the application representative can login to the application without either soft certificates or certificates stored on a CAC or another authentication mechanism, this is a CAT I finding for check APP3460. This finding should not be recorded for this check. 4) Ask the application representative to demonstrate encryption is being used for authentication. If the application representative cannot demonstrate encryption is being used, it is a finding.
Modify the application to use certificate based authentication.
Policy: The designer and IAO will ensure PK-enabled applications are designed and implemented to use approved credentials authorized under the DoD PKI program. The IAO will ensure the PK-enabled applications are configured to honor only approved DoD PKI certificates. If the application is not PK-enabled, this check is not applicable. If the application resides on the SIPRNet and PKI infrastructure is unavailable, this check is not applicable. Ask whether the application utilizes PKI certificates other than DoD PKI and External Certification Authority (ECA) certificates. Verify the certificate used in authentication in APP3280. Internet Explorer can be used to view certificate information: Select “Tools” Select “Internet Options” Select “Content” tab Select “Certificates” Select the certificate used for authentication: Click “View” Select “Details” tab Select “Issuer” If the application utilizes PKI certificates other than DoD PKI and ECA certificates, this is a finding.
Configure the application to use approved DoD PKI certificates.
If the application is not PK-enabled, this check is not applicable. If the application resides on the SIPRNet and PKI infrastructure is unavailable, this check is not applicable. This check is not applicable where system users are determined to be information privileged individuals, volunteers, or reservists, as required in the DoDI 8520.2. DoD test certificates can be obtained from the following website: http://jitc.fhu.disa.mil/pki/lab2.html Note: Before executing this check, the following certificate types need to be obtained: • Expired • Revoked • Improperly Signed If the application is PK-enabled and is not using DoD PKI certificates, the application representative will need to provide these certificates. If the application is PK-enabled and is not using DoD PKI certificates, the application representative will need to provide these certificates. If the application is a web-application that utilizes client certificates, validate proper PKI-functionality by using a test system configured to use an expired certificate, a revoked certificate and an improperly signed certificate. The test system should contain three user profiles: One with a revoked certificate, one with an expired certificate, and one with an improperly signed certificate. Log on with each of the user accounts for which there is an associated “bad certificate” profile and perform selected functions in the application that requires the use of a certificate (e.g., authentication). 1) If the expired, revoked, or improperly signed certificate can be used for application functions, it is a finding. Also, review the web server’s configuration to ascertain whether appropriate certificate validity checks are occurring. 2) If the web server does not check for and deny expired, revoked, or improperly signed certificates, it is a finding. If the application is not a web-application, work with an application SA to identify PK-enabled application functions, and then sequentially install the invalid certificates, testing each of the functions against each of the certificates. 3) Any successful use of any of the invalid certificates is a finding. If a finding is found in any of the preceding steps, document the details of the finding to include the following: • Which of the invalid certificates was accepted (potentially more than one). • The specific application functions that accepted the invalid certificate. *Note: Do not use (WS-Security, SAML, and XML) security libraries that do not perform full certificate validation adequately. Checking should include the certificate against the CA’s Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP).
Enable the application to provide certificate validation.
Policy: The designer will ensure the application has the capability to require account passwords having a minimum of 15 alphanumeric characters in length. The designer will ensure the application has the capability to require account passwords contain a mix of upper case letters, lower case letters, numbers, and special characters. The Designer will ensure the application has the capability to require account passwords be changed every 60 days or more frequently. The Designer will ensure passwords do not contain personal information such as names, telephone numbers, account names, birthdates, or dictionary words. The Designer will ensure the application has the capability to limit reuse of account passwords within the last 10 password changes. The Designer will ensure the application has the capability to limit user changes to their account passwords once every 24 hours with the exception of privileged or administrative users. The Designer will ensure the application has the capability to require new account passwords differ from the previous password by at least four characters when a password is changed. The IAO will configure the application to ensure account passwords conform to DoD password policy. If the entire authentication process for the application is performed by the operating system (such is the case for a Desktop Application), this check is Not Applicable. First, inventory all the password based authentication processes present in the application. For example, a web server may effectively act as a client when authenticating with a back-end database server. Peer-to-peer processes also are included because each peer still acts in the role of a client or server for particular transactions. Each process must be evaluated separately. If multiple processes must be used for a single authentication attempt, the combination of the processes should be evaluated to ensure this check is fully met. In addition, the authentication may involve a user account database specific to the application or it may involve leveraging the authentication service of an operating system or directory service. 1) If the authentication process involves the presentation of a user account name only, this is a finding. If the authentication is based on passwords, the passwords must have the following characteristics: • A minimum of 15 characters • Include at least one uppercase alphabetic character • Include at least one lowercase alphabetic character • Include at least one non-alphanumeric (special) character • Expire after 60 days • Be different from the previous 10 passwords used • Be changeable by the administrator at any time • Be changeable by the associated user only once in a 24 hour period (for human user accounts) • Not be changeable by users other than the administrator or the user with which the password is associated • Not contain personal information such as names, telephone numbers, account names, birthdates or dictionary words. 2) If the passwords do not have these characteristics, it is a finding. To verify compliance with these requirements, check the configuration of the software that manages the authentication process (e.g., OS, directory, and database or application software) and determine if each of the criteria listed are met. Also sample individual accounts to determine if any of the policy settings are overridden (e.g., password set to never expire). Focus on non-human user accounts, as these are the most likely to violate the stated requirements. Non-human accounts, sometimes known as services accounts, may not be set to expire after 60 days.
Enable PKI authentication. Enable the application to require account passwords having a minimum of 15 alphanumeric characters in length. Enable the application to require account passwords contain a mix of upper case letters, lower case letters, numbers, and special characters. Enable the application to require account passwords be changed every 60 days or more frequently. Enable the application to ensure passwords do not contain personal information such as names, telephone numbers, account names, birthdays, or dictionary words. Enable the application to limit reuse of account passwords within the last 10 password changes. Enable the application to limit user changes to their account passwords once every 24 hours with the exception of privileged or administrative users. Enable the application to require new account passwords differ from the previous password by at least four characters when a password is changed. Configure the application to ensure account passwords conform to DoD password policy.
If the user accounts used in the application are only operating system or database accounts, this check is Not Applicable. Identify duplicate userids. If these are not available, sort the list by the user name and, if applicable, associated ID number so that duplicates will be contiguous and thus easier to locate. 1) If any duplicates user accounts are discovered, it is a finding. The finding details should specify the duplicates by name, unless they are too numerous to document, in which case a numerical count of the IDs is more appropriate.
Remove duplicate user accounts.
If the user accounts used in the application are only operating system or database accounts this check is Not Applicable. Identify all users that have not authenticated in the past 35 days. 1) If any of these accounts are enabled, it is a finding.
APP6240-DG-AP
If the user accounts used in the application are only operating system or database accounts, this check is Not Applicable. Built-in accounts are those that are added as part of the installation of the application software. These accounts exist for many common commercial off-the-shelf (COTS) or open source components of enterprise applications (e.g., OS, web browser or database software). If SRRs are performed for these components, this is not applicable because the other SRRs will capture the relevant information and findings. If not, read the installation documentation to identify the built-in accounts. Also peruse the account list for obvious examples (e.g., accounts with vendor names such as Oracle or Tivoli). Verify that these accounts have been removed or disabled. If enabled built-in accounts are present, ask the application representative the reason for their existence. 1) If these accounts are not necessary to run the application, it is a finding. 2) If any of these accounts are privileged, it is a finding.
Disable unnecessary built-in userids
Run a password-cracking tool, if available, on a copy of each account database (there may be more than one in the application infrastructure). 1) If the password-cracking tool is able to crack the password of a privileged user, this is a CAT I finding. 2) If the password-cracking tool is able to crack the password of a non-privileged user, this is a CAT II finding. Manually attempt to authenticate with the published default password for that account, if such a default password exists. 3) If any privileged built-in account uses a default password – no matter how complex – this is a CAT I finding. 4) If a non-privileged account has a default password, this is a CAT II finding.
Change default passwords.
The designer will ensure: - NIST-certified cryptography is used to protect stored sensitive information if required by the information owner. - NIST-certified cryptography is used to store classified non-Sources and Methods Intelligence (SAMI) information if required by the information owner. - A classified enclave containing SAMI data is encrypted with NSA-approved cryptography. Review the system security plan or interview the application representative to determine the classification of data in the application. Also, review encryption mechanisms protecting the data. This should include all data stored by REST-Style or SOAP-based web services. NIST-certified cryptography should be used to protect stored sensitive information if required by the information owner. NIST-certified cryptography should be used to protect stored classified non-SAMI data if required by the information owner. NSA-approved cryptography should be used to protect stored classified SAMI information. 1) If data at rest is not protected with the appropriate level of encryption, this is a finding.
Configure system to encrypt stored sensitive information as required by the data owner; ensure encryption is performed using NIST FIPS 140-2 validated encryption. Replace cryptography that is not NIST certified. Encrypt stored, non-SAMI classified information using NIST FIPS 140-2 validated encryption. Implement NSA validated type-1 encryption of all SAMI data stored in the enclave. Remove the SAMI from the enclave. Remove the uncleared users from the enclave.
Policy: The designer will ensure unclassified, sensitive data transmitted through a commercial or wireless network is protected using NIST certified cryptography. The designer will ensure classified data, transmitted through a network that is cleared to a lower level than the data being transmitted, is separately protected using NSA approved cryptography. The designer will ensure data in transit through a network at the same classification level, but which must be separated for need to know reasons, is protected minimally with NIST certified cryptography. The designer will ensure SAMI data in transit through a network at the same classification level is protected with NSA approved cryptography. Interview the application representative to determine if sensitive data is transmitted over a commercial circuit or wireless network (e.g., NIPRNet, ISP, etc.). 1) If any sensitive data is transferred over a commercial or wireless network and is not encrypted using NIST FIPS 140-2 validated encryption, this is a CAT I finding. Interview the application representative to determine if classified data is transmitted over a network cleared to a lower level than the data. (e.g., TS over SIPRNet, Secret over NIPRNet, etc.). 2) If classified data is transmitted over a network cleared to a lower level than the data and NSA approved type-1 encryption is not used to encrypt the data, this is a CAT I finding. Interview the application representative and determine if the data in transit must be separated for need to know reasons. 3) If data in transit across a network at the same classification level is separated for need-to-know reasons and the data is not minimally encrypted using NIST FIPS 140-2 validated encryption, this is a CAT II finding. Interview the application representative and determine if SAMI data is transmitted. 4) If SAMI data in transit across a network at the same classification level is not separately encrypted using NSA type-1 approved encryption, this is a CAT II finding. *Note: These checks apply to all data transmitted by REST-styled or SOAP-based Web Services.
Encrypt data in transit.
If the application does not utilize encryption, key exchange, digital signature, or hash, FIPS 140-2 cryptography is not required and this check is not applicable. Identify all application or supporting infrastructure features that require cryptography such as, file encryption, VPN, SSH, etc. Verify the application is using FIPS-140 validated cryptographic modules. The National Institute of Standards and Technology’s FIPS 140-1 and FIPS 140-2 Vendor List is located at: http://csrc.nist.gov/cryptval/. 1) If the application requiring encryption, key exchange, digital signature or hash is using an unapproved module or no module, it is a finding. 2) If the application utilizes unapproved modules for cryptographic random number generation, it is a finding. Note: If the application uses WS Security tokens, W3C XML Signature can be used to digitally sign messages and provide message integrity.
Utilize FIPS 140-2 cryptography for modules implementing encryption, key exchange, digital signature, and hash.
MAC I or DoD Information Systems processing classified information, require the following events and data for auditing. Types of events are: - Successful and unsuccessful attempts to access security files. - Successful and unsuccessful logons. - Denial of access resulting from excessive number of logon attempts. - Blocking or blacklisting a user ID, terminal or access port. - Activities that might modify, bypass, or negate safeguards controlled by the system. - Possible use of covert channel mechanisms. - Privileged activities and other system-level access. - Starting and ending time for access to the system. - Security relevant actions associated with periods processing or the changing of security labels or categories of information. - Deletion or modification of data. Audit records include: - User ID - Date and time of the event - Type of event - Success or failure of event - origin of request (e.g., originating host’s IP address) for Identification and Authentication events only - name of data object modified or deleted for deletion or modification events only - reason user is blocked or blacklisted for blocking or blacklisting events only - Data required to monitor for the possible use of covert channels events only MAC II DoD Information Systems processing sensitive information require the following events and data for auditing. Types of events are: - Successful and unsuccessful attempts to access security files. - Successful and unsuccessful logons. - Denial of access resulting from excessive number of logon attempts. - Blocking or blacklisting a user ID, terminal or access port. - Activities that might modify, bypass, or negate safeguards controlled by the system. - Deletion or modification of data. Audit records include: - User ID - Date and time of the event - Type of event - Success or failure of event - origin of request (e.g., originating host’s IP address) for Identification and Authentication events only - name of data object modified or deleted for deletion or modification events only - reason user is blocked or blacklisted for blocking or blacklisting events only MAC III or DoD Information Systems processing publicly released information require the following events and data for auditing. Types of events are: - Successful and unsuccessful attempts to access security files. - Deletion or modification of data Audit records include: - User ID - Date and time of the event - Type of event - origin of request (e.g., originating host’s IP address) for Identification and Authentication events only. - name of data object modified or deleted for deletion or modification events only 1) If all the required events and associated details are not included in the log or there is not a logging mechanism, it is a finding. *Note: The mechanism that performs auditing may be a combination of the operating system, web server, database, application, etc. Also web services may be distributed over many geographic locations; however, auditing requirements remain the same in web services as they do in a traditional application.
Implement logging of security-relevant events.
Examine the application documentation and ask the application representative what automated mechanism is in place to ensure the administrator is notified when the application logs are near capacity. 1) If an automated mechanism is not in place to warn the administrator, it is a finding. If the application representative or the documentation indicates a mechanism is in place, examine the configuration of the mechanism to ensure the process is present and executing. 2) If an automated mechanism is not executing, it is a finding. Note: This may be automated by the operating system of the application servers.
Implement a warning mechanism to notify system administrators when the audit records are near full.
Locate the application audit log location. Examine the properties of the log files. For a Windows system, the NTFS file permissions should be System – Full control, Administrators and Application Administrators - Read, and Auditors - Full Control. 1) If the log files have permissions more permissive than what is listed, it is a finding. For UNIX systems, use the ls –la (or equivalent) command to check the permissions of the audit log files. 2) If excessive permissions exist, it is a finding.
Correct permissions on application audit logs.
Policy: The designer will ensure access control mechanisms exist to ensure data is accessed and changed only by authorized personnel. The designer will ensure the access procedures enforce the principles of separation of duties and "least privilege." The IAO will ensure the access procedures enforce the principles of separation of duties and "least privilege." Ask the application representative if particular administrative and user functions can be restricted to certain roles. The objective is to ensure that the application prohibits combination of roles that represent an IA risk. In particular, inquire about separation of duties between the following: • Personnel that review and clear audit logs and personnel that perform non-audit administration. • Personnel that create, modify, and delete access control rules and personnel that perform either data entry or application programming. Some applications may only contain administrator access and no other access. For example, network appliances may have administrator only access. Web applications with no user authentication required are also considered to contain a single role, unless the web application provides administrative access to publish web server content. 1) If the application is designed specifically to only have one role, this check is not applicable. 2) If the application representative states that the application does not enforce separation of duties between the roles listed above, it is a finding. If the representative claims that the required separation exists, identify which software component is enforcing it. Evidence of enforcement can either involve the display of relevant security configuration settings or a demonstration using different user accounts, each assigned to a different role. 3) If the application representative cannot provide evidence of separation of duties, it is a finding. *Note: Web services are required to implement role-based access control.
Implement access control mechanisms.
Ask the application for the design document. Review the design document to ensure the application handles objects so that no residual data exists when reusing objects. No information, including encrypted representations of information, produced by a prior actions is available to any subsequent use of the object. There should be no residual data from the former object. Verify the design document objects which are reused within the application do not contain any residual information. 1) If the design document does not exist or does not address object reuse, it is a finding.
Revoke access authorizations to data revoked prior to initial assignment, allocation, or reallocation, to an unused state.
Identify the application user account(s) that the application uses to run. These accounts include the application processes (defined by Control Panel Services (Windows) or ps –ef (UNIX)) or for an n-tier application, the account that connects from one service (such as a web server) to another (such as a database server). Determine the user groups in which each account is a member. List the user rights assigned to these users and groups and evaluate whether any of them are unnecessary. 1) If the rights are unnecessary, it is a finding. 2) If the account is a member of the Administrators group (Windows) or has a User Identification (UID) of 0 (i.e., is equivalent to root in UNIX), it is a finding. 3) If this account is a member of the SYSAdmin fixed server role in SQL Server, it is a finding. 4) If the account has DDL (Data Definition Language) privileges (create, drop, alter), or other system privileges, it is a finding. Search the file system to determine if these users or groups have ownership or permissions to any files or directories. Review the list of files and identify any that are outside the scope of the application. 5) If there are such files outside the scope of the application, it is a finding. Check ownership and permissions; identify permissions beyond the minimum necessary to support the application. 6) If there are instances of unnecessary ownership or permissions, it is a finding. The finding details should note the full path of the file(s) and the associated issue (i.e., outside scope, permissions improperly granted to user X, etc.). 7) If the target is a .NET application that executes with least privileges using code access security (CAS), this is not a finding.
Modify the application to remove unnecessary privileges.
Work with the application representative to identify application modules that involve user or process sessions (e.g., a user may initiate a session with a web server, which in turn maintains sessions with a backend database server). For each session type, ask the application representative the limits on: • Number of sessions per user ID • Number of sessions per application 1) If the application representative states the session limits are absent for any of the session types, it is a finding. In many cases, session configuration parameters can be examined. If configuration parameters are embedded within the application, they may not be available for review. Any configuration settings that are not configurable should be manually tested. The preferred method depends on the application environment. 2) If there is no evidence of a required session limit on one or more of the session types, it is a finding. The finding details should note specifically which types of sessions are left unbounded, and thus, more vulnerable to DoS attacks.
Implement limits on: • Number of sessions per user ID • Number of sessions per application Implement session limits.
The IAO will ensure the classification guide for the application data exists and is available to users. If the application does not process classified information, this check is not applicable. The application may already be covered by a higher level program or other classification guide. If classification guide is not written specifically to the application, the sensitive application data should be reviewed to determine whether it is contained in the classification guide. DoD 5200.1-R, January 1997 identifies requirements for security classification and/or declassification guides (http://www.dtic.mil/whs/directives/corres/pdf/520001r.pdf). Security classification guides shall provide the following information: • Identify specific items, elements, or categories of information to be protected. • State the specific classification to be assigned to each item or element of information and, when useful, specify items of information that are unclassified. • Provide declassification instructions for each item or element of information, to include the applicable exemption category for information exempted from automatic declassification. • State a concise reason for classification for each item, element, or category of information that, at a minimum, cites the applicable classification categories in Section 1.5 of E.O. 12958. • Identify any special handling caveats that apply to items, elements, or categories of information. • Identify, by name or personal identifier and position title, the original classification authority approving the guide and the date of that approval. • Provide a point-of-contact for questions about the guide and suggestions for improvement. • For information exempted from automatic declassification because its disclosure would reveal foreign government information or violate a statute, treaty, or international agreement, the security classification guide will identify the government or specify the applicable statute, treaty, or international agreement, as appropriate. 1) If the security classification guide does not exist, or does not contain data elements and their classification, it is a finding.
Create and maintain a security classification guide.
Before actual testing, determine which application functions to examine, giving preference to report generation capabilities and the most common user transactions that involve sensitive data (FOUO, secret or above). Ask the application representative for the application’s classification guide. This guide should document the data elements and their classification. Logon to the application and perform these 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 data, markings are required at a minimum at the top and the bottom of screens and reports. For FOUO data, markings are required at a minimum of the bottom of the screen or report. 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 ensure that if the users were to follow the procedures the data would be marked correctly. Also, ask how these procedures are distributed to the users. 1) If appropriate markings are not present within the application and it is technically possible to have the markings present, it is a finding. 2) 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, it is a finding. In any case of a finding, the finding details should 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. For example: utilizing a shredder or disposal in burn bags. Note: Physical markings on hardware do not meet this requirement.
Enable the application to adequately mark sensitive/classified output.
On each computer in the application infrastructure, search the file system for files created or modified in the past week. If the response is too voluminous (more than 200 files), find the files created or modified in the past day. Search through the list for files and identify those that appear to be outside the scope of the application. Ask the application representative how the file relates to the application. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If the creation or modification of the file does not have a clear purpose, it is a finding. The finding details should include the full path of the file. The method described above may not catch all instances of out-of-scope modifications because the file(s) may have been modified prior to the threshold date or because the files may be residing on a system other than those examined. If additional information is obtained later in the review regarding improper modification of files, revisit this check. This information may be uncovered when the reviewer obtains more detailed knowledge of how the application works during subsequent checks.
Restrict the application to modify data files within the scope of the application.
Review the threat model and identify the following sections are present: • Identified threats • Potential mitigations • Mitigations selected based on risk analysis Detailed information on threat modeling can be found at the Open Web Application Security Project (OWASP) website. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If the threat model does not exist, or does not have identified threats, potential mitigations, and mitigations selected based on risk analysis, as sections within the Threat Model, it is a finding. 2) If the threat model has not been updated to reflect the application release being reviewed, this is a finding. Verify the mitigations selected in the threat model have been implemented. 3) If the mitigations selected based on risk analysis have not been implemented, this is a finding. Review the identified threats from the each of the application’s networked components. For example, a backend server may accept SQL queries and SSH connections and also have an NFS share. Next, examine firewall rules and router ACLs that prevent clients from reaching these access points, effectively reducing the area of the threat surface. For example, if the backend database accepts queries but is in an enclave where there are no user workstations and firewall rules allow only web traffic, this is not a finding. For each of the remaining access points, attempt to access these resources in a similar manner as the application would without utilizing the user interface (e.g., send SQL query using a tool outside of the application or attempt to access a share using command line utilities). 4) If a user can authenticate to any of these remaining access points outside of the intended user interface, this is a finding. The finding details should note the application component accessed and the method or tool used to access it.
Establish and maintain threat models and review for each application release and when new threats are discovered. Identify potential mitigations to identified threats. Ensure mitigations are implemented to threats based on their risk analysis.
Ask the application representative if there is a documented process to remove code when it is no longer executed. Also ask if there is a documented process to ensure unnecessary code is not included into a release. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. The process may include the following: · Source code analysis tools · Development environments that indicate unused source code · Compiler options that detect unreachable code For a web-based application, conduct a spot check of the code directory (e.g., .html, .asp, .jsp, and .php files), sampling at least four files, and ensure the code is executed for the application. If a documented process is not in place, check at least 10 pieces of code. Search for possible 'include files' and scripts. Determine if the 'include files' and scripts exist. Examples of 'include files' and scripts: jsp <%@ include file="include.jsp" %> php <?php include("include.php"); ?> asp <!--#include file="include.html"--> js <script src="include.js" type="text/javascript"></script> 1) If 'include files' and scripts do not exist, it is a finding. 2) If other code is found that is not being used, this is a finding. Document the name of the file containing the offending code in the finding details. For Visual Basic or C/C++ and other applications verify that a documented process is in place to prevent unused source code from being introduced into the application. Verify the process by source code analysis tools results, development environment tools, compiler options or the mechanism documented by process that enforces unused source from being introduced into the application. 3) If the application representative does not have a documented policy or there is no evidence that mechanisms are in place to prevent the introduction of unused code into the application, this is a finding.
Establish a formal process is in place to remove unnecessary software and libraries.
Ask the application representative or examine the application documentation to determine the location of the application code and data. Examine the directory where the application code is located. 1) If the application data is located in the same directory as the code, this is a finding.
Separate the application data into a different directory than the application code.
Examine the configuration of the servers. Determine what software is installed on the servers. Determine which services are needed for the application by examining the application design and accreditation documentation and interviewing the application representative. For example, in cases where two web servers (IIS and Apache) are installed, and only one is being used. 1) If there are services or software present not needed for the application, it is a finding.
Remove unnecessary services or software.
Logon to the application. If a warning message appears, compare it to the two following banners: (Use the following banner for desktops, laptops, and other devices accommodating banners of 1300 characters) You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. At any time, the USG may inspect and seize data stored on this IS. Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. (For Blackberries and other PDAs/PEDs with severe character limitations use the following banner): I've read & consent to terms in IS user agreem't. These banners are mandatory and deviations are not permitted except as authorized in writing by the Deputy Assistant Secretary of Defense for Information and Identity Assurance. 1) If the login banner is not one of the above banners or the login banner is missing this is a finding. If the only way to access the application is through the OS, then an additional banner is not required at the application level.
Modify or configure the application to present the DoD warning banner at login.
Persistent cookies are the primary means by which an application stores authentication information over more than one browser session. If the application is a web-based application, verify that Internet Explorer (IE) is set to warn the user before accepting a cookie. Logon to the application and perform several standard operations, noting if the application ever prompts the user to accept a cookie. Log out, close the browser and check the /Windows/cookies, /Windows/profiles/xyz/cookies, and the /documents and settings/xyz/cookies directories (where xyz is replaced by the Windows user profile name). If a cookie has been placed in either of these directories, open it (using Notepad or another text editor) and search for identification or authentication data that remain after to check for sensitive application data. 1) If authentication credentials exist (e.g., a password), this is a CAT I finding. 2) If identification information (e.g., user name, ID, or key properties) exists, but is not accompanied by authentication credentials such as a password, this is a CAT II finding. The application may use means other than cookies to store user information. If the reviewer detects an alternative mechanism for storing I&A information locally, examine the credentials found. 3) If authentication data (e.g., a password) is found, this is a CAT I finding. 4) If identification information is found (e.g., user name, ID, or key properties) but is not accompanied by authentication credentials such as a password, this is a CAT II finding. 5) If the application will initiate additional sessions without requiring authentication after logging out of the application, this is a CAT I finding. Web applications using autocomplete can be setup to store passwords and sensitive data. Many operating systems centrally control the autocomplete feature and it should be disabled. Workstations that do not have this feature disabled by default have the risk of storage of password information and sensitive information. Examples include public kiosks and home workstations connecting to the NIPRNet where this feature may be disabled. View the html pages that contain password and sensitive information to determine if autocomplete feature has been turned off. Example form html: <FORM AUTOCOMPLETE = "off"> Autocompletes are explained further at the Microsoft website. http://msdn.microsoft.com/en-us/library/ms533486(VS.85).aspx 6) If the application is configured to allow autocomplete for passwords, this is a CAT I finding. 7) If the application is configured to allow for sensitive information fields, this is a CAT II finding.
Modify the application to remove authentication credentials on workstations after a session terminates.
Policy: The designer will ensure the application is organized by functionality and roles to support the assignment of specific roles to specific application functions. The IAO will ensure access to privileged accounts is limited to privileged users. The IAO will ensure non-privileged accounts are limited to non-privileged users. The IAO will ensure the application account is established and administered in accordance with a role based access scheme to enforce least privilege and separation of duties. Check: Log on as an unprivileged user. Examine the user interfaces (such as, graphical, web, and command line) to determine if any administrative functions are available. Privileged functions include the following: • Create, modify, and delete user accounts and groups • Grant, modify, and remove file or database permissions • Configure password and account lockout policy • Configure policy regarding the number and length of sessions • Change passwords or certificates of users other than oneself • Determine how the application will respond to error conditions • Determine auditable events and related parameters • Establish log sizes, fill thresholds, and fill behavior (i.e., what happens when the log is full) Some applications may only contain administrator access and no other access. For example, network appliances may have administrator only access. Web applications with no user authentication required are also considered to contain a single role, unless the web application provides administrative access to publish web server content. 1) If the application is designed specifically to only have one role, this check is not applicable. 2) If non-privileged users have the ability to perform any of the functions listed above, it is a finding. Finding details should specify which of the functions are not restricted to privileged users. Work closely with the application SA before testing any administrative changes to ensure local change management procedures are followed. Immediately back out of any changes that occur during testing. Review administrative rights assignments in all application components, including the database software and operating system. On Windows systems, review each of the User Rights to determine which users and groups are given more than default capabilities. User Rights can be viewed by using DumpSec, then selecting Reports, Dump Rights. 3) If privileged rights are granted to non-privileged users, it is a finding. *Note: Web services are required to separate functionality by roles.
Modify the application to be organized by functionality and roles to support the assignment of specific roles to specific application functions. Assign privileged accounts only to privileged users. Assign non-privileged accounts only to non-privileged users. Establish and administer accounts in accordance with a role based access scheme to enforce least privilege, and separation of duties.
Log on to the application and then attempt to log out. If this option is not available, ask the application representative to explain how this function is performed. 1) If the ability to log out is absent or is hidden to the extent most users cannot reasonably expect to easily find it, it is a finding.
Implement a capability to terminate a session and logout.
Review source code (including global.asa, if present), configuration files, scripts, HTML file, and any ASCII files to locate any instances in which a password, certificate, or sensitive data is included in code. If credentials were found, check the file permissions on the offending file. 1) If the file permissions indicate that the file has no access control permissions (everyone can read or is world readable), this is a CAT I finding. 2) If there is a level of file protection that requires that at least authenticated users have read access, this is a CAT I finding. 3) If a level of protection exists that only administrators or those with a UID of 0 can read the file, this is a CAT II finding. The finding details should note specifically where the offending credentials or data were located and what resources they enabled.
Remove embedded authentication data stored in code, configuration files, scripts, HTML file, or any ASCII files.
Search the source code for common URL prefixes and suffixes and to the extent feasible with available tools, NFS shares, NetBIOS shares and IP addresses. All such resources should be captured from configuration files (i.e., “http://”, ftp://, “.mil”, “.com”). 1) If any references are invalid, it is a finding.
Remove any invalid URL or path references from the application.
If the application does not send e-mail, this check is not applicable. If the application sends e-mail, ask for user documentation and test results of e-mail portion of application. Additionally, execute the email portion of the application. If possible, configure mail to send to an established email account. If network configurations prevent actual mail delivery, perform the check by examining the mail in the mail queue. Examine documentation and email output. 1) If any email message contains files with the following extensions (.exe, .bat, .vbs, .reg, .jse, .js, .shs, .vbe, .wsc, .sct, .wsf, .wsh), it is a finding.
Remove executable mobile code from email messages.
The designer will ensure Category 1A mobile code used in an application is signed with a DoD-approved code-signing certificate. The designer will ensure signed Category 1A mobile code used in an application is obtained from a trusted source and is designated as trusted. The designer will ensure Category 1X mobile code is not used in applications. The designer will ensure signed Category 2 mobile code used in an application is signed with a DoD-approved code signing certificate. The designer will ensure Category 2 mobile code not executing in a constrained execution environment is obtained from a trusted source over an assured channel using at least one of the following measures: Interview the application representative and examine the application documentation to determine if Category 1A or 2 mobile code is used. The URL of the application must be added to the Trusted Sites zone. This is accomplished via the Tools, Internet Options, and Security Tab. Select the Trusted Sites zone. Click the sites button. Enter the URL into the text box below the Add this site to this zone message. Click Add. Click OK. Note: This requires administrator privileges to add URL to sites on a STIG compliant workstation. Next, test the application. This testing should include functional testing from all major components of the application. If mobile code is in use, the browser will prompt to download the control. At the download prompt, the browser will indicate that code has been digitally signed. 1) If the code has not been signed or the application warns that a control cannot be invoked due to security settings, it is a finding. 2) If the code has not been signed with a DoD approved PKI certificate, it is a finding.
Sign Category 1 or Category 2 mobile code.
If the application does not contain mobile code, this is not applicable. If any mobile code is being transmitted by the application, examine the configuration of the test machine to ensure that no network connections exist. This can be accomplished by typing the netstat command from the command prompt on a Windows client. Ensure that after the mobile code is executed, network connections do not exist. 1) If the application transmits mobile code that attempts to access local operating system resources or establish network connections to servers other than the application server, it is a finding.
Remove unsigned unconstrained mobile code.
Ask the application representative and examine the documentation to determine if the application accepts file inputs via e-mail, ftp, file uploads or other automated mechanisms. If the application does not accept file uploads, this check is not applicable. If the application accepts inputs, investigate the process that is used to process the request. If the process could contain mobile code, a mechanism must exist to ensure that before mobile code is executed, its signature must be validated. The following examples are intended to show determination of the finding: Non-finding example: The application allows upload of data. The data file is parsed looking for specific pieces of information in an expected format. An application program in accordance with established business rules then processes the data. This situation would be not a finding. Finding example: The application allows upload of data. The data file is sent directly to an execution module for processing. This example could include a .doc file that is sent directly to MS Word for processing. Using this example, if there was a process in place to ensure that the document was digitally signed and validated to be a DoD approved PKI certificate before processing, this would be not a finding.
Verify mobile code before executing.
Ask the application representative for design documentation and examine the documentation to determine if additional mobile code types are being used that have not been defined in the mobile code policy. By definition, mobile code is software obtained from remote systems outside the enclave boundary, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. In order to determine if an emerging technology is covered by the current policy, excerpts of the DoD Mobile Code Policy dated 23 October 2006, and policy memorandum are included so the reviewer knows what types of technologies are included, which he or she must know to determine what is outside the scope of the policy. The memorandum containing the Mobile Code Technologies Risk Category List is available here: https://powhatan.iiie.disa.mil/mcp/mobile-code-memo-2011Mar14.pdf Items covered by the policy include: • ActiveX • Windows Scripting Host when used as mobile code • Unix Shell Scripts when used as mobile code • DOS batch scripts when used as mobile code • Java applets and other Java mobile code • Visual Basic for Applications (VBA) • LotusScript • PerfectScript • Postscript • JavaScript (including Jscript and ECMAScript variants) • VBScript • Portable Document Format (PDF) • Shockwave/Flash • Rich Internet Applications Currently the following are not designated as mobile code by the policy: • XML • SMIL • QuickTime • VRML (exclusive of any associated Java applets or JavaScript scripts) The following are outside the scope of the DoD Mobile Code Policy: • Scripts and applets embedded in or linked to web pages and executed in the context of the web server. Examples of this are Java servlets, Java Server pages, CGI, Active Server Pages, CFML, PHP, SSI, server-side JavaScript, server-side LotusScript. • Local programs and command scripts • Distributed object-oriented programming systems (e.g., CORBA, DCOM). • Software patches, updates, including self-extracting updates - software updates that must be invoked explicitly by the user are outside the mobile code policy. Examples of technologies in this area include: Netscape SmartUpdate, Microsoft Windows Update, Netscape web browser plug-ins and Linux. If other types of mobile code technologies are present that are not covered by the policy, a written waiver must be granted by the CIO (allowing use of emerging mobile code technology). Also uncategorized mobile code must be submitted for approval. 1) If the application representative is unable to present the written waiver granted by the CIO, it is finding. 2) If the application representative provides acceptable written waiver granted by the CIO, it is not a finding.
Remove uncategorized mobile code.
Check application to ensure that memory is being released. Also ensure database connections are closed, if applicable. Ask the application representative to demonstrate memory and database connections are released when the application is terminated. 1) If memory is not released and the application is not using garbage collection process for memory (e.g., Java Applications), this is a finding. 2) If the application creates new database connections on entry to the application and does not release them on exit of the application, this is a finding. Ask the application representative to access the application, perform selected actions, and exit the application. Ask the application representative to search for files recently created. For a Windows System: Use Windows Explorer to search for all files (*.*) created today, and then examine the times to narrow the scope of the files to examine. For a Unix System: Enter: # touch -t 200301211020 /tmp/testdatefile The -t flag represents the time option. The time format to be used with -t is {[CC]YYMMDDhhmm[ss]} where the century [CC] and the seconds [ss] are optional fields. The resulting file is: -rw-r--r-- 1 root root 0 Jan 21 10:20 /tmp/testdatefile Enter a second command: # find / -newer /tmp/testdatefile --> This will produce all files on the system with a date later than that of 'testdatefile'. # find ./* -newer /tmp/testdatefile --> This will produce all files, recursively, in the current directory with a date later than that of 'testdatefile'. 3) If this list includes temporary files that are not being deleted by the application, this is a finding.
Configure or redesign the application to remove all temporary files before the application exits.
Ask the application representative for the test plans for the application. Examine the test plan to determine if testing was performed for invalid input. Invalid input includes presence of scripting tags within text fields, query string manipulation, and invalid data types and sizes. If the test plans indicate these types of tests were performed, only a small sampling of testing is required. If the test plans do not exist or do not indicate that these types of tests were performed, more detailed testing is required. Testing should include logging on to the application and entering invalid data. If there are various user types defined within the system, this test should be repeated for all user types. Test the application for invalid sizes and types. Test input fields on all pages/screens of the application. Try to exceed buffer limits on the input fields. Try to put wrong types of data in the input fields. For example, put character data in a numeric field. 1) If an unauthenticated user can enter invalid input to bypass access control mechanisms, this is a CAT I finding. 2) If an authenticated user can enter invalid input to gain elevated access, this is a CAT I finding. 3) If the application requires the entry of IP addresses is not capable of handling IPv6 formats that are 128 bits long, this is a CAT II finding. 4) If the application is not capable of handling IPv6 formats and accepts characters that are of hexadecimal notation including colons, this is a CAT II finding.
Modify the application to validate all input.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details on code review and tools. If the results are provided from a manual code review, the results will need to describe how buffer overflow vulnerabilities and functions vulnerable to buffer overflows are identified during code reviews. 1) If scan results are provided and buffer overflow vulnerabilities have been identified in the report, this is a finding. 2) If scan results are provided but do not include the scan configuration settings which show that the application was tested for buffer overflows, this is a finding. 3) If manual test results are provided and the report does not confirm the lack of buffer overflows and also describe how buffer overflows and functions vulnerable to buffer overflows are identified during the code review, this is a finding. *Note: For IPV6 capable applications, check existing libraries to ensure they are capable of processing the increased size of IPv6 addresses to avoid buffer overflows.
Modify the application to protect against buffer overflows vulnerabilities.
Use the error messages generated from APP3510 as input into this check. Ensure that the application provides error handling processes. The application code should not rely on internal system generated error handling. 1) If the errors are not being handled by the application, and are being processed by the underlying internal system, this is a CAT III finding. Inspect the verbiage of the message. Ensure that the application does not provide information that can be used by an attacker. 2) If any of the following types of errors are displayed, this is a CAT II finding. Error messages should not include variable names, variable types, SQL strings, or source code. Errors that contain field names from the screen and a description of what should be in the field should not be considered a finding.
Add code to properly handle or trap errors.
The design of the application should account for the following: 1) Connections to databases are left open 2) Access control mechanisms are disabled. 3) Data left in temporary locations. Testing application failure will require taking down parts of the application. Examine application test plans and procedures to determine if this type of failure was 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. Ensure 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. 1) If any of these tests fail, it is a finding.
Fix any vulnerabilities found when the application is an insecure state (initialization, shutdown and aborts).
Ask the application SA or developer if the application enables clients to authenticate to the server or the application it is communicating with. The most common example of this type of authentication is when a client validates a server’s PKI certificate when initiating an SSL or IPSEC connection. 1) If the SA or developer answers that this capability is not present, this is a finding. If the SA or developer states that the capability is present, validate this by logging on to each component that supports authentication of servers. For web applications, note cases in which the client browser issues a warning that the server’s certificate is not valid. Reasons include: • A trusted certificate authority did not issue the certificate • The certificate has expired • The name of the certificate does not match the URL of the page you are trying to view The client application should provide a function to allow or disallow the server access to the client application. The server must be setup with a certificate for identification. Determine if the application checks for server authentication before allowing the user to continue. The server’s certificate should be checked by the user’s web browser or client application. 2) If there is no server certificate or the client application does not validate the server certificate, it is a finding.
Enable the application to use PKI for authentication.
All application ports, protocols, and services needed for application operation need to be in compliance with the DoD Ports and Protocols guidance. Check (http://iase.disa.mil/ports/index.html) to ensure the ports, protocols, and services are in compliance with the PPS CAL. Check all necessary ports and protocols needed for application operation (only those accessed from outside the local enclave) are checked against the DoD Ports and Protocols guidance to ensure compliance. Identify the ports needed for the application: • Look at System Security Plan/Accreditation documentation • Ask System Administrator • Go to Network Administrator Retina Scanner • Go to Network Reviewer • If a network scan is available, use it • Use netstat/task manager • Check /etc/services 1) If the application is not in compliance with DoD Ports and Protocols guidance, it is a finding.
Ensure your Accreditation documentation lists all interfaces and the ports, protocols, and services used. Ensure that all ports, protocols, and services are used in accordance with the DoD PPSM.
List all IA or IA enabled products that are part of the application. Such products must be satisfactorily evaluated and validated either prior to purchase or as a condition of purchase; i.e., vendors will warrant, in their responses to a solicitation and as a condition of the contract, that the vendor's products will be satisfactorily validated within a period of time specified in the solicitation and the contract. Purchase contracts shall specify that product validation will be maintained for updated versions or modifications by subsequent evaluation or through participation in the National IA Partnership (NIAP) / Common Criteria Evaluated Products. 1) If the products have not been evaluated or are in the process of being evaluated, it is a finding. According to NSTISSP 11, an IA enabled product is a product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. To meet the intent of NSTISSP 11, acquired IA enabled products must be evaluated if the IA features are going to be used to perform one of following security services: availability, integrity, confidentiality, authentication, or non-repudiation. Therefore, the determination of whether an IA enabled product must be evaluated will be dependent upon how that particular product will be used within the consumer's system architecture. Examples of such products include security enabled web browsers, screening routers, and security enabled messaging systems. Although NSTISSP 11 uses both terms, the policy as stated applies equally to both types of products. A list of certified products is available on the common criteria website: http://www.commoncriteriaportal.org/products.html Below are definitions of IA and IA enabled products from DoD Instruction 8500.2. IA Product - Product or technology whose primary purpose is to provide security services e.g., confidentiality, authentication, integrity, access control or non-repudiation of data; correct known vulnerabilities; and/or provide layered defense against various categories of non-authorized or malicious penetrations of information systems or networks. Examples include such products as data/network encryptors, firewalls, and intrusion detection devices. IA Enabled Product - Product or technology whose primary role is not security, but which provides security services as an associated feature of its intended operating capabilities. Examples include such products as security-enabled web browsers, screening routers, trusted operating systems, and security-enabled messaging systems.
Limit the acquisition of all IA, and IA enabled Commercial-off-the-Shelf (COTS) IT products, to products that have been evaluated or validated through The International Common Criteria (CC) for Information Security Technology Evaluation Mutual Recognition Arrangement or The NIAP Evaluation and Validation Program. IA and IA enabled COTS IT Products containing encryption capabilities are required to be evaluated and validated through The FIPS Validation Program
Ensure that a disaster recovery plan is in place for the application. If the application is part of the site’s disaster recovery plan, ensure that the plan contains detailed instructions pertaining to the application. Ensure that recovery procedures indicate the steps needed for secure recovery. 1) If a disaster recovery plan does not exist or the application is not part of the site’s disaster recovery plan, it is a finding. Verify that the recovery procedures include any special considerations for trusted recovery. 2) If any special considerations for trusted recovery are not documented, it is a finding.
Create and maintain a disaster recovery plan.
Check the following based on the MAC level of the application. For MAC 3 applications: Validate backup procedures exist and are performed at least weekly. A sampling of system backups should be checked to ensure compliance with the control. For MAC 2 applications: Validate backup procedures exist and are performed at least daily. Validate recovery media is stored at an off-site location and ensure the data is protected in accordance with its mission assurance category and confidentiality level. This validation can be performed by examining an SLA or MOU/MOA that states the protection levels of the data and how it should be stored. A sampling of system backups should be checked to ensure compliance with the control. Verify that the organization tests backup information to ensure media reliability and information integrity. Verify that the organization selectively uses backup information in the restoration of information system functions as part of annual contingency plan testing. For MAC 1 applications: Validate that the procedures have been defined for system redundancy and they are properly implemented and are executing the procedures. Verify that the redundant system is properly separated from the primary system (i.e., located in a different building or in a different city). This validation should be performed by examining the secondary system and ensuring its operation. Examine the SLA or MOU/MOA to ensure redundant capability is addressed. Finding details should indicate the type of validation performed. Examine the mirror capability testing procedures and results to insure the capability is properly tested at 6 month minimum intervals. 1) If any of the requirements above for the MAC level of the application are not met, it is a finding.
Develop and implement backup procedures.
Ensure a process is in place to retain application audit log files for one year and five years for SAMI data. 1) If audit logs have not been retained for one year or five years for SAMI data, this is a finding.
Retain application audit log files for one year and five years for SAMI data.
Ask if any database exports from this database are imported to development databases. If no database exports exist, this check is not applicable. If there are such exports, ask if policy and procedures are in place to require the modification of the production database account passwords after import into the development database. 1) If there are no policy and procedures in place to modify production database account passwords, it is a finding. If there are such exports, ask if the production database includes sensitive data identified by the data owner as sensitive such as passwords, financial, personnel, personal, HIPAA, Privacy Act, or classified data is included. 2) If any database exports include sensitive data and it is not modified or removed prior to or after import to the development database, it is a finding. 3) If there are no policy and procedures in place to modify production database account passwords, it is a finding. If there are such exports, ask if the production database includes sensitive data identified by the data owner as sensitive such as financial, personnel, personal, HIPAA, Privacy Act, or classified data is included. 4) If any database exports include sensitive data, and it is not modified or removed prior to or after import to the development database, it is a finding.
Remove sensitive data from production database exports.
The Program Manager will ensure all appointments to required IA roles are established in writing to include assigned duties and appointment criteria, such as training, security clearance, and IT designation. The IAO will ensure all appointments to required IA roles are established in writing to include assigned duties and appointment criteria such as training, security clearance, and IT designation. Interview the application representative and validate that the required IA roles are established in writing. These roles are DAA and the IAM/IAO. This written notification must include assigned duties and appointment criteria such as training, security clearance, and IT-designation. If a traditional review is conducted at the same time as the application review, this check is not applicable. Also validate a SSP exists and describes the technical, administrative, and procedural IA program and policies that govern the DoD information system, and identifies all IA personnel and specific IA requirements and objectives (e.g., requirements for data handling or dissemination, system redundancy and backup, or emergency response). 1) If the SSP does not exist or is incomplete, it is a finding. 2) If the IA Roles and assigned duties and appointment criteria are not made in writing, it is a finding. Ask site personnel which IAO or IAM for the systems/application is part of the application review. 3) If the IAO or IAM is unknown, or not assigned, this is a finding.
Establish the required IA roles in writing. The directive must include assigned duties and appointment criteria such as training, security clearance, and IT-designation. Prepare a SSP that describes the technical, administrative, and procedural IA program and policies that govern the DoD information system, and identifies all IA personnel and specific IA requirements and objectives (e.g., requirements for data handling or dissemination, system redundancy and backup, or emergency response).
The application and the application client (e.g., web browser, C++ application, etc.) must be designed to work on a STIG compliant platform. Vulnerabilities are discovered frequently and security updates must be applied constantly and may not be reflected in the latest baseline of a secure image of the operating system. Any finding required to make the application client operate correctly will be documented in this check. Conduct a review of the application and the application client platform using the SRR process or utilize an up to date application/client platform SRR if available. Ensure the application client platform was included in the overall application SRR review. Ensure the SRR was completed after the most recent system updates or changes. If the client is Windows based and the application uses either a browser interface or an MS Office Product, a Desktop Application review must also be conducted. 1) If the review of the application client platform produces findings indicating that the application client will not operate correctly in a STIG compliant environment, it is a finding. Ensure the application review includes test and build systems. All deployment, development, as well as test and build systems should be included in the application review to ensure the applicable DoD approved or other acceptable security configuration documents have been applied. 2) If the application review does not include all deployment, development, as well as test and build systems, it is a finding.
Configure application client, application development, as well as test and build systems using the approved DoD security guidance (e.g., DoD STIGs, NSA Guides, etc.)
Ask the application representative for the design document for the application. Review the design document. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Examine the design document and/or the threat model for the application and verify the following information is documented: - All external interfaces. - The nature of information being exchanged. - Any protections on the external interface. - User roles required for access control and the access privileges assigned to each role. - Unique security requirements (e.g., encryption of key data elements at rest). - Categories of sensitive information processed by the application, and their specific protection plans (e.g., PII, HIPAA). - Restoration priority of subsystems, processes, or information. - Verify the organization includes documentation describing the design and implementation details of the security controls employed within the information system with sufficient detail. 1) If the design document is incomplete, it is a finding.
Create and maintain the Design Document for each release of the application and identify the following: - All external interfaces (from the threat model) - The nature of information being exchanged - Categories of sensitive information processed or stored and their specific protection plans - The protection mechanisms associated with each interface - User roles required for access control - Access privileges assigned to each role - Unique application security requirements - Categories of sensitive information processed or stored and specific protection plans (e.g., Privacy Act, HIPAA, etc.) - Restoration priority of subsystems, processes, or information.
Detailed policy requirements: The Program Manager will provide an Application Configuration Guide to the application hosting providers. The Program Manager will provide a list of all potential hosting enclaves and connection rules and requirements. The Program Manager will ensure development systems, build systems, and test systems have a standardized environment and are documented in the Application Configuration Guide. The Designer will ensure known security assumptions, implications, system level protections, best practices, and required permissions are documented in the Application Configuration Guide. The Designer will ensure deployment configuration settings are documented in the Application Configuration Guide. The IAO will ensure the application is deployed in a manner consistent with the Application Configuration Guide provided by the developers. The Application Configuration Guide is any document or collection of documents used to configure the application. These documents may be part of a user guide, secure configuration guide, or any guidance that satisfies the requirements below: The Application Configuration Guide must be made available to application hosting providers. The Application Configuration Guide will contain a list of all potential hosting enclaves and connection rules and requirements. Development systems, build systems, and test systems must operate in a standardized environment. These settings are to be documented in the Application Configuration Guide. Examples include: • Versions of compilers used • Build options when creating applications and components • Versions of COTS software (used as part of the application) • For web applications, which browsers and what versions are supported All known security assumptions, implications, system level protections, best practices, and required permissions are documented in the Application Configuration Guide. All deployment configuration settings are documented in the Application Configuration Guide. Examples include: • Encryptions Settings • PKI Certificate Configuration Settings • Password Settings All deployment configuration settings from the Application Configuration Guide should be implemented. Ask the application representative for Application Configuration Guide or other guidance where these requirements are documented. Verify the configuration settings have been implemented. 1) If any of the above information is missing, or the Application Configuration Guide does not exist, it is a finding. 2) If the settings in the Application Configuration Guide are not implemented, it is a finding.
Create and maintain an Application Configuration Guide and provide it to the application hosting facility.
Interview the application representative to determine if the system documentation has identified the Mission Assurance Category (MAC) and confidentiality levels of the application. 1) If no system documentation exists that identifies the MAC and confidentiality levels, it is a finding.
Document the Mission Assurance Category (MAC) and confidentiality levels of the application.
The Program Manager will ensure the development team follows a set of coding standards. The Program Manager will ensure the development team creates a list of unsafe functions to avoid and document this list in the coding standards. The Designer will follow the established coding standards established for the project. The Designer will not use unsafe functions documented in the project coding standards. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Interview the application representative to determine if a documented set of coding standards exists. Ask the application representative to demonstrate coding standards are being followed by reviewing a sample of code. Also, check the coding standards for a list of unsafe functions or section documenting there are no unsafe functions. 1) If no coding standards exist at an organizational or project level, it is a finding. 2) If documented coding standards are not being followed, it is a finding. 3) If there is no documented list of unsafe functions, or the coding standards do not document that there are no unsafe functions (for that particular language), it is a finding.
Adopt and document coding standards.
The Program Manager will ensure COTS IA, and IA enabled products, are used to protect sensitive information when the information transits non DoD owned networks, or the system handling the information is accessible by individuals who are not authorized to access the information on the system, comply with NIAP/NSA approved protection profiles. The Program Manager will ensure COTS IA, and IA enabled products, are used to protect classified information when the information transits networks, which are at a lower classification level than the information being transported, comply with NIAP/NSA approved protection profiles. Interview the application representative and determine the IA, and IA enabled COTS products, used in the application. Also, review the confidentiality level for the application. Public releasable data requires a NIAP/NSA approved protection profile for IA, and IA enabled, COTS products. Sensitive data requires a NIAP/NSA approved protection profile for IA, and IA enabled, COTS products. Classified information, when the information transits networks which are at a lower classification level than the information being transported, requires NIAP/NSA approved protection profiles for IA, and IA enabled, COTS products. The accreditation documentation should list the products that are used. A list of validated products and protection profiles is available on the common criteria website: http://www.niap-ccevs.org/cc-scheme/pp/index.cfm 1) Compare that list against the approved products. If any of the third party products are not listed or are below the NIAP/NSA approved protection profiles required by the application, it is a finding.
Use products with suitable NIAP/NSA protection profiles.
Policy: The Program Manager will obtain DAA approval for all open source, public domain, shareware, freeware, and other software products/libraries with limited or no warranty but are required for mission accomplishment. The designer will document all open source, public domain, shareware, freeware, and other software products/libraries that have limited or no warranty, but which are required for mission accomplishment. Software products and libraries with limited or no warranty will not be used in DoD information systems unless they are necessary for mission accomplishment, and there are no alternative IT solutions available. If these products are required, they must be assessed for information assurance impacts, and must be approved for use by the DAA. Review the DoD policy regarding Open Source Software products: http://www.defenselink.mil/cio-nii/docs/OpenSourceInDoD.pdf Open Source Software: Copyrighted software distributed under a license that provides everyone the right to use, modify, and redistribute the source code of software. Public Domain Software: Software not protected by any copyright laws providing the right to use, modify, and redistribute without permission or payment to the author. Shareware: Copyrighted software distributed under a license that provides a trial right to use and redistribute the binaries. For continued usage, users are required to pay a fee. Freeware: Copyrighted software distributed under a license that provides a right to use and redistribute the binaries. Unlike shareware, there is no charge for continued use. Commercial Software: Copyrighted software sold for profit by businesses, also referred to as COTS software. 1) If software products (e.g., Open Source Software, Public Domain Software, Shareware and Freeware) and libraries with limited or no warranty are used in DoD information systems except when they are necessary for mission accomplishment and there are no alternative IT solutions available, it is a finding.
Document and obtain the DAA's acknowledgment and acceptance of risk and approval for all binary or machine executable public domain software products such as freeware/shareware and other software products with no warranty and no source code review capability. Implement policy and procedures to ensure the organization is in compliance with software licensing agreements. Implement policy and procedures to ensure the organization is in compliance with software usage restrictions.
Verify registration of the application and ports in the Ports and Protocols Database for a production site. 1) If the application requires registration, and is not registered or all ports used have not been identified in the database this is a finding.
Register the application and ports in the Ports and Protocols Database.
Detailed Policy requirements: The Program Manager will ensure all levels of program management receive security training regarding the necessity, impact, and benefits of integrating secure development practices into the development lifecycle. The Program Manager will ensure designers are provided training on secure design principles for the entire SDLC and newly discovered vulnerability types on, at least, an annual basis. The Program Manager will ensure developers are provided with training on secure design and coding practices on, at least, an annual basis. The Program Manager will ensure testers are provided training on at least an annual basis. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Interview the application representative and ask for evidence of security training for application managers, designers, developers, and testers. Examples of evidence include course completion certificates and a class roster. At a minimum, security training should include Security Awareness Training. 1) If there is no evidence of security training, it is a finding.
Provide security training for managers, designers, developers, and testers.
The Program Manager will: - Ensure users are provided with a means of obtaining updates for the application. - Ensure a mechanism is in place to notify users of security flaws, and to provide users with the availability of patches. - Ensure a comprehensive vulnerability management process, including systematic identification and mitigation of software vulnerabilities, is in place. Interview the application representative to determine if users are provided with a means of obtaining updates for the application. 1) If users are not provided with a means of obtaining updates for the application, it is a finding. 2) If updates are transmitted over a LAN, and is not IPv6 capable, it is a finding. Interview the application representative to determine if users are provided a mechanism to be notified of security flaws and the availability of patches. 3) If users are not provided security flaw and patch notifications for the application, it is a finding. 4) If security flaws and patch notifications are transmitted over a LAN, and is not IPv6 capable, it is a finding. Interview the application representative and determine if a vulnerability management process exists. 5) If no vulnerability management process or policy exists, it is a finding. Interview the application representative to determine maintenance is available for production applications. 6) If maintenance is not available for an application, it is a finding.
Provide a distribution mechanism for obtaining updates to the application.
Verify that the organization provides or uses an incident support resource that offers advice and assistance to users of the information system for the handling and reporting of security incidents. The support resource must be an integral part of the organization’s incident response capability. This capability is addressed by the DOD CNDSP Program but participation at the organization level must be verified. Interview the application representative to determine if a security incident response process for the application is established. 1) If a security incident response process for the application is not documented, it is a finding. Interview the application representative to determine if a security incident response process contains the following: Identified CNDSP. Reportable incidents are defined. INFCON outlined in the incident response standard operating procedures. A provision exists for user training and annual refresher training. Establishment of an incident response team. Procedure for the plan to be exercised annually. 2) If a security incident response process is not adequate, it is a finding. Interview the application representative to determine if a security incident response process for the application is followed. 3) If a security incident response process for the application is not followed, it is a finding.
Fully participate in the DOD CNDSP Program as described in DoD Instruction 8530.2 or develop an Incident response Plan. Exercise the Incident Response Plan annually. Provide for user incident response training. Provide an incident support resource that offers advice and assistance to users for the handling and reporting of security incidents. The support resource must be an integral part of the organization's incident response capability.
Determine the sensitivity of the data of the application by reviewing the confidentiality levels for which the system was designed. If a traditional review is being conducted at the same time as the application review, this check is not applicable. For sensitive data, the following security guidelines must be followed: • Verify the existence of policy and procedures to ensure the proper handling and storage of information at the site. • Verify system media (e.g., tapes, printouts, etc.) is controlled and the pickup, delivery, receipt, and transfer of system media is restricted to authorized personnel (NIST MP-5). • Verify there is a policy that addresses output handling and retention (NIST SI-12). • Verify policy that addresses output handling and retention is being followed (NIST SI-12). 1) If sensitive data security guidelines do not exist or not followed, it is a finding. For classified data, the following security guidelines must be followed: • Verify the existence of policy and procedures to ensure the proper handling and storage of information at the site. (e.g., end-of-day, security checks, unannounced security checks, and, where appropriate, the imposition of a two-person rule). • Verify the existence of a system of security checks at the close of each working day to ensure that the area is secure. • An SF 701: Activity Security Checklist, is required to record such checks. • An SF 702: Security Container Check Sheet, is requires to record the use of all vaults, secure rooms, and containers used for the storage of classified material. • Verify system media (e.g. tapes, printouts, etc.) is controlled and the pickup, delivery, receipt and transfer of system media is restricted to authorized personnel (NIST MP-5). • Verify there is a policy that addresses output handling and retention (NIST SI-12). • Verify policy that addresses output handling and retention is being followed (NIST SI-12). 2) If classified data security guidelines do not exist or are not followed, it is a finding.
Implement policy and procedures to ensure the proper handling and storage of information, such as end-of-day security checks, unannounced security checks, and, where appropriate, the imposition of a two-person rule within the computing facility. Establish a system of security checks at the close of each working day to ensure that the area is secure. An SF 701: Activity Security Checklist shall be used to record such checks. This form may be modified to suit the individual security (or safety) needs of the organization i.e., entries for STU-III CIK secured or coffee pot turned off. An SF 702: Security Container Check Sheet shall be used to record the use of all vaults, secure rooms, and containers used for the storage of classified material.
Interview the application representative to determine if logical separation exists between application components within the application. Review locations of the components of the application such as web server, database server, and application server. A separate machine is not required but is recommended. Separation may be accomplished through the use of different computers, different CPUs, different instances of the operating system, different network addresses, and combinations of these methods, or other methods, as appropriate. 1) If the application components are not separated in the application, this is a finding.
Separate interface services from data storage and management services.
Ask the application representative for the threat model. Review the threat model for threats regarding session hijacking. Review the threat model for common session hijacking attacks. Examples of session hijacking vulnerabilities can be obtained from the OWASP website. - Predictable session token - Session sniffing - Client-side attacks addressed in APP3580 - MITM attack - Man-in-the-browser attack 1) If the threat model documentation does not address predictable session tokens and provide details regarding the countermeasures taken within the application to mitigate this risk, or if the application representative cannot demonstrate how this risk is mitigated within the application itself, this is a CAT I finding. - Application should utilize a random method of generating session tokens so as to avoid predictable patterns or sequential numbering of session token values. Session identifiers should also utilize the largest character set available to assist randomization. - Application should expire and destroy session identifiers upon logout. - Session identifiers should never be logged. 2) If the threat model documentation does not address session sniffing and provide details regarding the countermeasures taken within the application to mitigate this risk, or if the application representative cannot demonstrate how the risk is mitigated within the application itself, this is a CAT I finding. - Application should set the secure flag when generating cookies that store or transmit session identifiers to ensure values are transmitted via SSL. If the application utilizes URLs with embedded session ids, these URLs can be forwarded in e-mails and e-mail recipients gain access to a system without authentication. Example URL with embedded session id: https://10.10.10.10:443/login.do;jsessionid=F2EE8C97B24635C9995A9D08E69D7B44 3) If URLs containing embedded session ids can be forwarded and used to gain access to the application without authentication, this is a CAT I finding. 4) If the threat model documentation does not address MITM attack, this is a CAT II finding.
Use TLS encryption to protect session information. Do not use predicable session tokens. Implement protection from client side attacks.
Ask the application representative to review the installation guide to determine what functionality is installed and enabled by default on installation of the application. Examples may include the following: Functions that send information back to the vendor. E-mail functions enabled when not required for functionality. 1) If the application installs with functionality which is unnecessary and enabled by default, it is a finding.
Remove or disable unnecessary functionality.
Ask the application representative for code review results from the entire application or the documented code review process. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. If the results are provided from a manual code review, the application representative will need to demonstrate how secure design principle vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify secure design principle vulnerabilities, this is a CAT I finding. 2) If code analysis tools are used to perform a code review and errors have not been fixed, this is a CAT II finding.
Design and code the application so the secure design principle is followed.
If the application does not implement key exchange, this check is not applicable. Identify all application or supporting infrastructure features using key exchange. Verify the application is using FIPS-140 validated cryptographic modules for encryption of key exchange algorithms. 1) If the application does not implement encryption for key exchange, it is a finding.
Use encryption for key exchange.
Interview the application representative and determine the keys resident on application servers (including X.509 certificates). For the purposes of this checklist, no more than 20 keys need to be examined. Based on the number of keys in the inventory, determine if all of the keys will be examined, or just a sample. If a sample will be selected, choose keys of a variety of types (certificate of a certificate authority, certificate of a user, private key of a user, etc.). No user or process should be able to write to any file containing keys. If keys need to be replaced or added, permissions can be changed temporarily for those events. 1) If any privileged or non-privileged user or application process has write permissions to a file containing cryptographic keys, it is a finding. Determine if when keys are read, that transaction occurs under the security context of a user account, or of the application process (which would perform the transaction on behalf of the user). Ensure that read permissions are granted only to the account(s) that must know the key to make the application function. If any user groups are granted read permissions, check that the members of these groups contain only the users that require knowledge of the key. 2) If any user accounts have read (or greater) permissions to a private or secret key, which do not require such permissions, it is a finding. 3) If any group with read permissions contains a user that does not require such permissions, it is a finding.
Remove excessive permissions on private keys.
If the application does not use a database, this check is not applicable. Ask the application representative how the application authenticates to the database. 1) If the application authenticates to the database by using a database account that has database administrator access, it is a finding.
Modify the application and the database account used for the application so administrative credentials are not required to access the database.
If the application is not a transaction based application that stores and retrieves data, this check is not applicable. Ask the application representative if the application uses a database to store information. If the application utilizes Oracle, SYBASE, or Microsoft SQL Server, then support for journaling and rollback is already present in the tools. Note: Microsoft Access does not support journaling and rollback. If Microsoft Access is used, ask the application representative to demonstrate the rollback and journaling features of the application. 1) If the application representative cannot demonstrate support for journaling and rollback, it is a finding.
Implement rollback and journaling features in the application or incorporate products with rollback and journaling features.
If the application does not contain sensitive or classified information this check does not apply. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable.. Ask the application representative to review global variables for the application. If the global variables contain sensitive information, ask the application representative if they are required to be encrypted by the data owner. If the data is required to be encrypted by the data owner, ask the application representative to demonstrate they are encrypted. Note: The .Net Framework 2.0 and higher provides a SecureString class which can encrypt sensitive string values. 1) If sensitive or classified information is required to be encrypted by the data owner and global variables containing sensitive information are not encrypted, it is a finding.
Encrypt sensitive and classified data in memory when not in use.
If the application does not contain sensitive or classified information this check is not applicable. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Ask the application representative to demonstrate how the application clears and releases memory blocks. Microsoft Visual C++ provides SecureZeroMemory that will not be optimized out of code for clearing sensitive and classified data. 1) If the application releases objects before clearing them, it is a finding.
Clear memory blocks used for storing sensitive and classified data, before release.
Ask the application representative to demonstrate the application support mechanisms assuring the integrity of all transmitted information to include labels and security parameters. Ask the application representative to login and demonstrate the application support integrity mechanisms for transmission of both incoming and outgoing files and any transmitted data. For example, hashing/digital signature and cyclic redundancy checks (CRCs) can be used to confirm integrity on data streams and transmitted files. 1) If the application does not support integrity mechanisms for any transmitted data, this is a finding. 2) If the application does not support integrity mechanisms for file transmission, this is a finding. *Note: These checks apply to all data transmitted by REST-styled or SOAP-based Web Services.
Implement integrity mechanisms for transmission of both incoming and outgoing data.
Ask the application representative to login to the application. If the application uses password authentication, the password should not be displayed as clear text. 1) If the password is displayed as clear text, this is a finding.
Use password masking to prevent display of clear text password.
Ask the application representative to demonstrate that passwords are encrypted before they are transmitted. 1) If the application does not use passwords for identification and authentication, this check is not applicable. 2) If the application does not encrypt passwords before transmitting them, it is a finding.
Modify the application to encrypt all transmitted passwords.
With respect to identification and authentication information, only administrators and the application or OS process that access the information should have any permissions to these files. In many cases, local backups of the accounts database exist so these must be included in the scope of the review. Authentication credentials such as passwords are required to be encrypted. Check the configuration of the application software to determine if encryption settings have been activated for the relevant data. 1) If these encryption settings have not been turned on, this is a CAT II finding. If the data encryption functionality is not configurable and the identification and authentication information is stored in ASCII or another readable format, examine the actual data to determine if they are in clear text. 2) If the authentication data is readable, this is a CAT I finding. Record findings, regardless of whether or not the vulnerability has been captured in another SRR. For example, any weakness in OS authentication scheme that the application leverages applies both to the OS and the application.
Store passwords in an approved encrypted format.
Identification and authentication information must be protected by appropriate file permissions. Only administrators and the application or OS process that access the information should have any permissions to access identification and authentication information. In many cases, local backups of the accounts database exist so these must be included in the scope of the review. 1) If non-privileged users have the permission to read or write password files, other than resetting their own password, this is a CAT II finding. 2) If non-privileged users can read user information (e.g., list users but not passwords), this is a CAT III finding.
Restrict access to authentication data.
Ask the application representative what system accounts are installed/created and/or enabled by default upon installation of the application. 1) If the application installs/creates/enables accounts that are not needed in order for the application to operate, it is a finding.
Remove or disable unneeded accounts.
Ask the application representative to demonstrate the application locks a user account if a user enters a password incorrectly more than three times in a 60 minute period. 1) If the account is not disabled, it is a finding.
Lock user accounts after three consecutive unsuccessful logon attempts within one hour.
Ask the application representative to demonstrate that only the administrator can unlock locked accounts. 1) If the application allows non-administrator to unlock accounts, it is a finding.
Allow only the administrator to unlock locked accounts.
Interview application representative to identify the length of time a user can be idle before the application will time out and terminate the session and require reauthentication. 1) If the application representative states that one or all of the limits are absent for one or more session types, it is a finding. In many cases, session configuration parameters can be examined. If configuration parameters are embedded within the application they may not be available for review. Any configuration settings that are not configurable should be manually tested. The preferred method depends on the application environment. Manually validate session limits by empirical testing (logon on multiple times and leaving sessions idle). In some cases, testing session limits is not feasible because they may be set too high to properly simulate them during the review. Even if the application does not provide time limits for idle sessions, such limits may exist at the transport layer (e.g., TCP timeouts). Consider all possible ways in which limits might be enforced before documenting a finding. 2) If there is no evidence of a required session timeout, it is a finding.
Implement session timeouts and automatic logout in the application.
Ask the application representative to demonstrate the application resources have appropriate access permissions. 1) If the application representative cannot demonstrate all application resources have appropriate access permissions, it is a finding. Review the locations of all configuration files used by the application. Ask the application representative to demonstrate configuration files used by the application are restricted to authorized users. 2) If access permissions to configuration files are not restricted to application administrators, it is a finding.
Correct access permissions restricting the modification of application resources.
Verify the application does not grant access solely based on a resource name (e.g., username, IP address, machine name). Also, verify a username with a blank password does not grant access to the application. 1) If authentication is granted based on a resource name only, it is a finding.
Implement authentication on systems requiring access control.
Ask the application representative to review web pages, and determine if the application sets the character set. Perl After the last header look for print "Content-Type: text/html; charset=utf-8\n\n"; PHP. Look for the header() function before any content is generated header('Content-type: text/html; charset=utf-8'); Java Servlets. Look for the setContentType method on the ServletResponse object Objectname.setContentType ("text/html;charset=utf-8"); JSP. Look for a page directives <%@ page contentType="text/html; charset=UTF-8" %> ASP Look for Response.charset <%Response.charset="utf-8"%> ASP.Net Look for Response.ContentEncoding Response.ContentEncoding = Encoding.UTF8; 1) If the application representative cannot demonstrate the above, it is a finding.
Set the character set on all web pages.
SQL Injections attacks can be used to bypass the login to the application or to provide authenticated user access to data that should not normally be provided by the application. Test applications using Oracle, Microsoft SQL Server, and other backend databases by putting a single ' in any of the fields used to login. Submit the form and check for a server error 400. If the error occurs, the application is not properly validating input fields. If an invalid user or password message is returned upon submitting the web form, the application is at least minimally protected. Fill in login fields with potentially valid user names (e.g., admin, system, root, administrator) with a comment field to ignore the rest of the SQL query. Fill in the password fields with any values and submit the form. username' -- username' # username'/* 1) If the application bypasses user authentication with these inputs, this is a CAT I finding. Try to append the "or" operator with a true value "1=1" and comment field. This will test if a SQL query could be passed into the application for execution. Fill in the login and password fields one at a time with the inputs below and submit the form. ' or 1=1-- ' or 1=1# ' or 1=1/* ') or 1=1-- ') or 1=1# ') or 1=1/* 2) If the application bypasses user authentication with these inputs, this is a CAT I finding. Also other fields not associated with the login fields should be tested. Fill in the each of the inputs one at a time with the inputs below, and submit the form. ' or 1=1-- ' or 1=1# ' or 1=1/* ') or 1=1-- ') or 1=1# ') or 1=1/* 3) If the application provides an authenticated user access or elevated access to the application to data, this is a CAT I finding. Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the application representative cannot provide results from a code review, then ask the application representative to demonstrate how the application meets the requirements below. Identify from the code review results or the application representative demonstration how the application: - Uses prepared statements for SQL queries - Does not provide direct access to tables (e.g. access is provided by views and stored procedures) - Does not use concatenation or use replacement to build SQL queries 4) If the results are not provided from a manual code review or automated tool or the application representative cannot demonstrate the application uses prepared statements for SQL queries, this is a CAT II finding. 5) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not use concatenation or use replacement to build SQL queries, this is a CAT II finding. 6) If the results are not provided from a manual code review or automated vulnerability scanning tool, or the application representative cannot demonstrate the application does not directly accesses tables in a database, this is a CAT II finding. 7) If APP3500 is a finding due to the application account being a member of the Administrators group (Windows), has a UID of 0 (i.e., is equivalent to root in UNIX), is a member of the SYSAdmin fixed server role in SQL Server, or has DDL privileges, the finding should be upgraded to a CAT I. *Note Web services are subject to the same coding practices of other web application code (e.g., SQL Injection).
Modify the application and remove SQL injection vulnerabilities.
Ask the application representative for code review results from the entire application. This can be provided as results from an automated code review tool or use static analysis tools that are known to find this class of vulnerability with few false positives. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how integer overflow vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify integer overflow vulnerabilities, it is a finding. Examples of integer overflow vulnerabilities can be obtained from the OWASP website.
Modify the application and protect against integer overflow attacks.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how format string vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify format string vulnerabilities, it is a finding. Examples of format string vulnerabilities can be obtained from the OWASP website.
Modify the application to protect against format string attacks.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how command injection vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify command injection vulnerabilities, it is a finding. Examples of Command Injection vulnerabilities can be obtained from the OWASP website. *Note: Web services are subject to the same coding practices of other web application code (e.g., command injection).
Modify the application to protect against command injection attacks.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how XSS vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify cross site scripting vulnerabilities, this is a CAT I finding. Perform query string manipulation testing to determine if the user bypasses access control functions to gain data that should be restricted based on the user's security level or role. For example, if a query string, such as www.testweb.mil/apppage.asp?xyz=113&asd=185, gives the user access to data for data identifier number 185. Try to resubmit the query string with another three digit number (e.g., 186) to see if that data is displayed. If this data can be displayed through reports or other access points in the application, this would not be considered a finding. 2) If data displayed in the query manipulation testing is above the user's security level or role, this is a CAT II finding. For script tag embedding, select a text field of the application that accepts at least 15 characters. Try to input a script tag (script) into the field. If the data is accepted without an error, access the data entered via the application (this process will vary depending upon the application). 3) If the script tag in its entirety is displayed within the application, this is a CAT II finding. Mitigate XSS vulnerabilities by using HTTP-only cookies. Examine any cookies used while the application is being executed. Verify the HttpOnly flag has been set for all cookies. 4) If the HttpOnly flag has not been set for all cookies, this is a CAT II finding. HttpOnly cookies are explained further at the Microsoft website: http://msdn.microsoft.com/en-us/library/ms533046.aspx Examples of XSS vulnerabilities can be obtained from the OWASP website.
Modify the application to protect against cross site scripting attacks.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how canonical representation vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify canonical representation vulnerabilities this is a finding. Examples of Canonical Representation vulnerabilities can be obtained from the OWASP website.
Protect against canonical representation attacks.
Ask the application representative for code review or scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool. See section 5.4 of the Application Security and Development STIG for additional details. If the results are provided from a manual code review, the application representative will need to demonstrate how hidden field vulnerabilities are identified during code reviews. Hidden fields or input parameters that utilize randomly generated token values used to address Cross Site Request Forgery (CSRF) attacks and are not used for access control are not applicable. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify hidden field vulnerabilities, this is a CAT I finding. 2) If the code review results are provided and hidden field vulnerabilities exist for user authentication, this is a CAT I finding. 3) If the code review results are provided and hidden field vulnerabilities exist allowing users to access unauthorized information, this is a CAT II finding.
Do not use Hidden fields to control access privileges.
Ask the application representative to demonstrate the application does not disclose any information about the application which could be used by an attacker to gain access to the application. UDDI registries should also not provide any information about the application which could be used by an attacker to gain access to the web service. WSDL should not provide unnecessary information (especially debugging features). Ask the application representative to login as a non-privileged user and review all screens of the application to identify any potential data that should not be disclosed to the user. 1) If the application displays any data that should not be disclosed, this is a finding.
Remove unnecessary information displayed by the application.
Policy: The designer will ensure the application is not vulnerable to race conditions. The designer will ensure the application does not use global variables when local variables could be used. The designer will ensure a multi-threaded application uses thread safe functions when threads are accessing the same object or data. The Designer will ensure global resources are locked before being accessed by the application. Check: If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Ask the application representative for code review results from the entire application. This can be provided as results from an automated code review tool. The review results should include all web services used in the application. If the results are provided from a manual code review, the application representative will need to demonstrate how the following vulnerabilities are identified during code reviews: • Race conditions • Using global variables when local variables could be used • Multi-threaded application uses thread safe functions • Global resources are locked before being accessed by the application 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify these vulnerabilities, it is a finding. Examples of race conditions vulnerabilities can be obtained from the OWASP website.
Protect against race condition vulnerabilities
Ask the application representative to login as an unprivileged user and demonstrate the application creates transaction logs for access and changes to the data. Verify transaction logs exist and the log records access and changes to the data. This check is in addition to the ECAR auditing requirements. 1) If the application representative cannot demonstrate the above, it is a finding.
Implement transaction logs which records access, and changes, to the data.
Policy: The designer will ensure the application has a capability to notify the user on logon of date and time of the user's last unsuccessful logon, IP address of the user’s last unsuccessful logon, date and time of the user's last successful logon, IP address of the user’s last successful logon, and number of unsuccessful logon attempts since the last successful logon. Check: If the application uses password authentication, try to logon to the system using an incorrect password. Restart the application and logon again using the correct password. After a successful logon to the application, logout of the application and note the date and times for the last success and unsuccessful logons. Again, logon to the application and determine whether the application correctly displays the following information immediately at logon: Unsuccessful Logon Date Time IP Address Successful Logon Date Time IP Address If the application does not correctly display the last unsuccessful and successful logon information immediately at login, it is a finding For CAC and NSA approved token authentication logons, remove the CAC or mistype the PIN to simulate an unsuccessful login.
Display last login information.
Ask the application representative to demonstrate how the application provides the users of time and date of the last change in data content. This may be demonstrated in application logs, audit logs, or database tables and logs. 1) If the application representative cannot demonstrate the above, this is a finding.
Implement transaction logs recording access and changes to the data.
Interview the designer and determine if new mobile code is in development. If no new mobile code is in development, this check is not applicable. 1) If new code is being developed determine and a risk assessment has not been performed, it is a finding.
Remove mobile code or perform a risk assessment on mobile code.
The CM repository access permissions are not reviewed at least every three months. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Ask the application representative when the last time the access privileges were reviewed. 1) If access privileges were reviewed within the last three months, this is not a finding.
Review access privileges to the CM repository at least every three months.
The Release Manager will ensure the SCM plan identifies all objects created during the development process subject to configuration control. The Release Manager will ensure the SCM plan maintains procedures for identifying individual application components, as well as, entire application releases during all phases of the software development lifecycle. The Release Manager will ensure the SCM plan identifies and tracks all actions and changes resulting from a change request from initiation to release. The Release Manager will ensure the SCM plan contains procedures to identify, document, review, and authorize any change requests to the application. The Release Manager will ensure the SCM plan defines the responsibilities, the actions to be performed, the tools, techniques and methodologies, and defines an initial set of baselined software components. The Release Manager will ensure the SCM plan objects have security classifications labels. The Release Manager will ensure the SCM plan identifies tools and version numbers used in the software development lifecycle. The Release Manager will ensure the SCM plan identifies mechanisms for controlled access of simultaneous individuals updating the same application component. The Release Manager will ensure the SCM plan assures only authorized changes by authorized persons are possible. The Release Manager will ensure the SCM plan identifies mechanisms to control access and audit changes between different versions of objects subject to configuration control. The Release Manager will ensure the SCM plan identifies mechanisms to track and audit all modifications of objects under configuration control. Audits will include the originator and date and time of the modification. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. Ask the application representative to review the applications SCM plan. The SCM plan should contain the following: • Description of the configuration control and change management process • Types of objects developed • Roles and responsibilities of the organization 1) If the SCM plan does not include the above, this is a CAT II finding. The SCM plan should also contain the following: • Defined responsibilities • Actions to be performed • Tools used in the process • Techniques and methodologies • Initial set of baselined software components 2) If the SCM plan does not include the above, this is a CAT III finding. The SCM plan should identify all objects that are under configuration management control. Ask the application representative to provide access to the configuration management repository and to identify the objects shown in the SCM plan. 3) If the application representative cannot display all types of objects under CM control, this is a CAT III finding. The SCM plan should identify third party tools and respective version numbers. 4) If the SCM plan does not identify third party tools, this is a CAT II finding. The SCM plan should identify mechanisms for controlled access of individuals simultaneously updating the same application component. 5) If the SCM plan does not identify mechanisms for controlled access, this is a CAT III finding. The SCM plan assures only authorized changes by authorized persons are allowed. 6) If the SCM plan does not assure only authorized changes are made, this is a CAT II finding. The SCM plan should identify mechanisms to control access and audit changes between different versions of objects subject to configuration control. 7) If the SCM plan does not identify mechanisms to control access and to audit changes between different versions of objects subject to configuration control, this is a CAT III finding. The SCM plan should have procedures for label versions of application components and application builds under configuration management control. Ask the application representative demonstrate the configuration management repository and contains versions and releases of the application. Ask the application representative to create a build or demonstrate a current release of the application can be recreated. 8) If the application representative cannot display releases and application component versions, this is a CAT II finding. The configuration management repository should track change requests from beginning to end. Ask the application representative to display a completed or in-process change request. 9) If the configuration management repository cannot tracks change requests, this is a CAT III finding. If the application has just completed its first release, there may not be any change requests logged in the configuration management repository. In this case, this finding is not applicable. The configuration management repository should authorize change requests to the application. Ask the application representative to display an authorized change request and identify who is responsible for authorizing change requests. 10) If the configuration management repository does not track authorized change requests, this is a CAT III finding. If the application has just completed its first release, there may not be any change requests logged in the configuration management repository. In this case, this finding is not applicable. The configuration management repository should contain security classification labels for code and documentation in the repository. Classification labels are not applicable to unclassified systems. 11) If there are no classification labels of code and documentation in the configuration management repository, this is a CAT III finding. The configuration management repository should monitor all objects under CM control for auditing. 12) If the configuration management repository does not audit for modifications, this is a CAT II finding. The SCM plan should identify all components required to be IPV6 capable. 13) If the SCM plan does not identify application components as IPV6 capable, this is a CAT III finding.
Update SCM plan to include missing items.
Interview the application representative and determine if a CCB exists. Ask about the membership of the CCB, and identify the primary members. Ask if there is a CCB charter documentation. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If there is no evidence of CCB, it is a CAT II finding. 2) If the IAM is not part of the CCB, it is a CAT II finding. Interview the application representative and determine how often the CCB meets. Ask if there is CCB charter documentation. The CCB charter documentation should indicate how often the CCB meets. If there is no charter documentation, ask when the last time the CCB met and when was the last release of the application. CCB's do not have to physically meet, and the CCB chair may authorize a release based on phone and/or e-mail conversations. 3) If there is not evidence of a CCB meeting during every release cycle, this a CAT III finding.
Setup and maintain a configuration control board.
Ask the application representative if an individual has been designated to test for security flaws. 1) If no individual has been designated to test for security flaws, it is a finding.
Designate testers for security flaws.
Interview the application representative and determine if changes to the application are assessed for IA impact prior to implementation. Review the CCB process documentation to ensure potential changes to the application are evaluated to determine impact. An informal group may be tasked with impact assessment of upcoming version changes. 1) If impact analysis is not performed, it is a finding.
Assess changes to the application for IA impact prior to implementation.
Ask the application representative to provide tests plans, procedures, and results to ensure they are updated for each application release or updates to system patches. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If test plans, procedures, and results do not exist or are not updated for each application release or updates to system patches, this is a finding.
Executed tests plans prior to release or patch update.
Ask the application representative to provide tests plans, procedures and results to ensure system initialization, shutdown, and aborts keep the system in a secure state. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If test plans, procedures, and results do not exist ,or at least executed annually, it is a finding.
Correct errors in initialization, shutdown, and aborts leaving the system in an unsecure state.
Ask the application representative to provide code coverage statistics maintained for the application. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If these code coverage statistics do not exist, it is a finding.
Create and maintain code coverage statistics for the application.
Ask the application representative to provide evidence of automated code reviews. This will be in the form of a test plan or methodology which identifies application architecture and components as well as a formal report provided by the automated code review tool plus manual testing results. This requirement requires access to the application source code, if the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If an automated application code review is not performed, this is a finding. 2) If analysis of code review results is not performed, this is a finding. 3) If all application code is not being reviewed, this is a finding. 4) If the code review report includes coding errors that have not been fixed, this is a finding. If identified coding errors have been fixed, this is not a finding. 5) If the code reviews indicate the existence of hard-coded IPv4 or IPV6 addresses, it is a finding.
Use automated code review tools, perform manual code reviews to validate and augment automated code review results. Fix identified coding errors and issues prior to releasing application for production use.
Ask the application representative to demonstrate that the configuration management repository captures flaws in the code review process. The configuration management repository may consist of a separate application for capturing code defects. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If there is no configuration management repository or the code review flaws are not captured in the configuration management repository, it is a finding.
Track flaws found during a code review.
Ask the application representative to provide vulnerability test procedures and vulnerability test results. Ask the application representative to provide the settings that were used to conduct the vulnerability testing. Verify the automated vulnerability scanning tool was appropriately configured to assure as complete a test as possible of the application architecture components. E.g. if the application includes a web server, web server tests must be included. 1) If the application test procedures and test results do not include active vulnerability and fuzz testing this is a finding. 2) If the vulnerability scan results include critical vulnerabilities, this is a finding. 3) If the vulnerability scanning tests are not relevant to the architecture of the application, it is a finding. 4) If the vulnerability scan report includes informational and/or non-critical results this is not a finding. 5) If previously identified vulnerabilities have subsequently been resolved, this is not a finding.
Perform active vulnerability and fuzz testing of the application. Ensure the vulnerability scanning tool is configured to test all application components and functionality. Address discovered vulnerabilities.
Ask the application representative to demonstrate how security flaws are integrated into the project plan. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If security flaws are not addressed in the project plan or there is no process to introduce security flaws into the project plan, it is a finding.
Address security flaws in the project plan.
Ask the application representative to review the servers where the application is deployed. Also, ask what other applications are deployed on those servers. 1) If a mission critical (MAC I) application is deployed on the same server as other applications, it is a finding.
Deploy mission critical (MAC I) applications on servers that are not shared by other applications.
If a DoD STIG or NSA guide is not available, application and application components will be configured by the following in descending order as available: (1) commercially accepted practices, (2) independent testing results, or (3) vendor literature. 1) If the application and application components do not have DoD STIG or NSA guidance available and not configured by (1) commercially accepted practices, (2) independent testing results, or (3) vendor literature, it is a finding.
If a DoD STIG or NSA guide is not available, configured the application using the following in descending order as available: (1) commercially accepted practices, (2) independent testing results, or (3) vendor literature.
Review the components of the application. Deployment personnel should be registered to receive updates to all components of the application, such as Web Server, Application Servers, and Database Servers. Also, if update notifications are provided to any custom developed software, deployment personnel should also register for these updates. Ask the application representative to demonstrate deployment personnel are registered to receive notifications for updates to all the application components including and custom developed software. 1) If the application provides automated alerts for update notifications, and no deployment personnel are registered to receive the alerts, it is a finding.
Register administrator to receive updates.
Ask the application representative to review the Configuration Management Plan. Ensure procedures exist addressing the test and implementation process for all patches, upgrades, and application deployments. Verify all IPv6 applicable patches have been applied. Verify all vendor provided IPv6 related patches been installed. 1) If required patches are missing, it is a finding. 2) If procedures do not exist or are deficient, it is a finding.
Install current patches and update configurations.
Interview the application representative and determine if all the application components are under maintenance. 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. 1) If the application or any of the application components are not being maintained, it is a finding.
Ensure there is maintenance for the application.
Interview the application representative to determine if provisions are in place to notify users when an application is decommissioned. 1) If provisions are not in place to notify users when an application is decommissioned, it is a finding.
Create and establish procedures to notify users when an application is decommissioned.
Ask the application representative to review the threat model for DoS attacks. Verify the mitigation for DoS attacks are implemented from the threat model. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If the mitigation from the threat model for DoS attacks are not implemented, it is a finding.
Implement mitigations from the threat model for DOS attacks.
Examine the system to determine if an automated, continuous on-line monitoring and audit trail creation capability is present with the capability to immediately alert personnel of any unusual or inappropriate activity with potential IA implications, and with a user configurable capability to automatically disable the system if serious IA violations are detected. 1) If this monitoring capability does not exist, it is a finding.
Implement mechanisms to alert system administrators about a low resource condition.
Interview application representative and ask for the system documentation that states how often audit logs are reviewed. Also, determine when the audit logs were last reviewed. 1) If the application representative cannot provide system documentation identifying how often the auditing logs are reviewed, or has not audited within the last time period stated in the system documentation, it is a finding.
Review audit logs on a periodic basis.
Interview the application representative and review the SOPs to ensure that violations of IA policies are analyzed and reported. 1) If there is no policy reporting IA violations, it is a finding.
Establish an IA policy for reporting violations.
Interview the application representative and determine if any logs are being automatically monitored and if alerts are sent out on any activities. 1) If there are no automated alerts, this is a finding.
Modify the application to implement automatic monitoring and alerts.
Verify that a licensed copy of the operating system software and other critical software is in a fire rated container or stored separately (offsite) from the operational software. 1) If operating system software and other critical software is not in a fire rated container, or stored offsite, it is a finding.
Store a licensed copy of the application software in a fire rated container or store it separately (off-site) from the operational software.
Validate that backup and recovery procedures incorporate protection of the backup and restoration assets. Verify assets housing the backup data (e.g., SANS, tapes, backup directories, software) and the assets used for restoration (e.g., equipment and system software) are included in the backup and recovery procedures. 1) If backup and restoration devices are not included in the recovery procedures, it is a finding.
Develop and implement procedures to insure that backup and restoral assets are properly protected and stored in an area/location where it is unlike they would be affected by an event that would affect the primary assets.
All applications should document disaster recovery procedures to include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance. Ask the application representative to review these plans. For MAC 1 applications, verify the disaster plan exists and provides for the smooth transfer of all mission or business essential functions to an alternate site for the duration of an event with little or no loss of operational continuity. For MAC 2 applications, verify the disaster plan exists and provides for the resumption of mission or business essential functions within 24 hours activation. For MAC 3 applications, verify the disaster plan exists and provides for the partial resumption of mission or business essential functions within 5 days of activation. 1) If the disaster plan does not exist or does not meet the MAC level requirements, this is a finding.
Create and maintain the disaster recovery plan.
Interview the application representative to verify that a documented process exists for user and system account creation, termination, and expiration. Obtain a list of recently departed personnel and verify that their accounts were removed or deactivated on all systems in a timely manner (e.g., less than two days). 1) If a documented account management process does not exist or unauthorized users have active accounts, it is a finding.
Establish an account management process.
Ask the application representative to examine the organization's password policy. 1) If non-human/service accounts are used and are not included in the password policy, it is a finding. 2) If non-human/service accounts policy does not require these accounts to change yearly or when someone with access to the password leaves the duty assignment, it is a finding. The configuration interface may not reveal information related to all the required elements. If this is the case, attempt to violate each element to determine if the policy is enforced. For example, attempt to change a password to one that does not meet the requirements. 3) If there are any shortcomings in the password policy or the configured behavior of any user account, it is a finding. The finding details should note which user accounts are impacted, which of the password parameters are deficient, the current values of these parameters, and the relevant required values. Also, ask the application representative to generate two user account passwords. 4) If there is a recognizable pattern in password generation, it is a finding.
Generate passwords to comply with the organization's password policy.
Ask the application representative if a group of users share login information to the system. 1) If an account that belongs to a group that can login to the system, this is a finding. 2) If there is a login shared by more than one user, this is a finding.
Remove group or shared accounts.
Interview the application representative and determine if the application is publicly accessible. 1) If the application is publicly accessible and traffic is not being routed through a DMZ, it is a finding.
Setup DMZ between DoD and public networks.
Ask the application representative for a network diagram. Review the network diagram for web servers/web services, web application servers, and database servers. If the application is a tiered web application located in the DoD DMZ and is available to the Internet, verify web servers are on logically separate network segments from the application and database servers. If the application is a tiered web application containing different data types, the application must have physically separate network connections, operating systems and application instances for each data type in the web tier when the application is available to the Internet. This check does not apply to SIPRNet DMZs or applications that are not available to the Internet. 1) In a tiered DMZ web application with similar data types, if the web server is not on a logically separate network segment from the application and database servers and the application is available to the Internet it is a finding. *Note: Physically separate networks require distinct physical network devices for connections. (e.g. two separate switches or two separate routers)
Seperate web server and place it on logically seperate network segment apart from the application and database servers.
Ask the application representative for a network diagram. Review the network diagram for web servers/web services or any server in the web tier of the DoD DMZ. Verify restricted and unrestricted servers are installed on separate VLANS. 1) If restricted and unrestricted servers in the Web Tier of the DoD DMZ are not installed on separate VLANS, it is a finding. *Note: This check does not apply to SIPRNet DMZs.
Move restricted and unrestricted data to different servers.
Ask the application representative for design documentation, review the design documentation and ensure the application employs methods for XML schema validation and disables use of inline XML Document Type Definition (DTD) schemas in XML parsing objects. Managing DTD parsing behavior is a key to preventing the invocation of XML bombs. DTD parsing is controlled within the .Net application framework in .NET applications. 1) If the design document does not exist or address the specified web service, it is a finding. 2) If the Application does not employ any method of schema validation, it is a finding. 3) If the Application does not disable the use of inline XML Document Type Definition (DTD) schemas it is a finding.
Design Web services to recognize attacks.
Ask the application representative for the design document. Review the design document for web services. Review the design and verify there is redundancy for web services. Redundancy may be accomplished by deploying the same web service over multiple network devices. For MAC I systems: 1) If the design document does not exist or does not indicate the existence of redundant web services or the application representative is not able to demonstrate redundant web services, it is a finding. 2) For MAC II and MAC III systems if the design document does not exist, it is a finding. The requirement for redundant web services is NA for MAC II and MAC III
Setup multiple instances of the web service with different URLs.
Ask the application representative for the design document. Review the design document for web services. Review the design and verify web services have been implemented differently to prevent similar attacks from a complete DoS. For MAC I and MAC II systems: 1) If the design document does not exist or does not indicate web services have been implemented with different algorithms, this is a finding. For MAC III systems: 2) If the design document does not exist this is a finding.
Implement web service critical functions using different algorithms to prevent similar attacks from a complete application level DoS.
Ask the application representative for the design document. Review the design document for web services. Review the design and verify all web services can prioritize requests. Techniques used to prioritize web services include but are not limited to using Quality of Service (QoS) or some other means of reliable messaging such as WS_Reliability or WS_ReliableMessaging 1) For MAC I and MAC II systems; If the design document does not exist or does not indicate all web services can prioritize requests, this is a finding. 2) If the system is a MAC III system this requirement is NA
Implement priority based web services requests.
Ask the application representative for execution flow diagrams. Review the execution flow diagrams and determine if all web services are covered in the flow diagrams. 1) If execution flow diagrams do not exist or are not complete, this is a finding.
Create and maintain web service execution flow diagrams.
Ask the application representative to verify whether XML based web services are used within the application. If no XML based web services are used in the application, this check is not applicable. If XML based web services are used within the application, ask the application representative for a network diagram identifying the XML firewall placement. Review the network diagrams and determine if all web services are protected by the XML firewall. 1) If network diagrams do not exist or all web services are not protected by the XML firewall, it is a finding.
Deploy XML Firewall to protect web services.
Ask the application representative for the design document. Review the design document for all web services. Review the design and verify all web services are able to detect resubmitted SOAP message requests. Look for the use of WS_Reliability or WS_ReliableMessaging standards. WS_Reliability or WS_ReliableMessaging syntax includes the use of "At-Most" semantics which guarantees that a duplicate message will not be delivered or "Exactly-Once" which guarantees a message will be delivered without duplication. If the application developer uses other reliable messaging standards to detect re-submitted messages, the developer should provide information as to how those standards meet this requirement. 1) If the design document does not indicate all web services are able to detect resubmitted SOAP message requests, this is a finding.
Design web services with the functionality to detect resubmitted SOAP messages.
If the application does not utilize UDDI registries or if the application utilizes the DISA PEO-GES managed UDDI registry and the DISA PEO-GES registry employs processes/procedures that control user access for publishing to the UDDI registry, this check is not applicable. Ask the application representative for the URL for the WSDL for all web services used in the application. Download each WSDL entry using a web browser and verify each entry has been signed by a publisher certificate. 1) If all WSDL entries have not been signed, it is a finding.
Add digital signatures to UDDI registries.
If the application does not utilize UDDI registries, this check is not applicable. Ask the application representative for design document and verify the version of the UDDI registry used. UDDI Version 3.0 and above repositories supports digital signatures for web services. 1) If the UDDI registry is not Version 3 or above, this is a finding.
UDDI repository does not support digital signature.
If the application does not utilize UDDI registries, this check is not applicable. Ask the application representative to demonstrate UDDI publishing is restricted to authenticated users. 1) If application representative is unable to demonstrate UDDI publishing is restricted to authenticated users, it is a finding.
Restrict UDDI publishing only to authenticated users.
If the application does not utilize UDDI registries, this check is not applicable. Ask the application representative to demonstrate web service inquiries to UDDI provide read-only access to the registry for anonymous users. 1) If application representative is unable to demonstrate web service inquiries to UDDI provide read-only access to the registry for anonymous users, it is a finding.
Place access control mechanisms on UDDI registries.
If the application does not utilize UDDI registries, this check is not applicable. Ask the application representative to demonstrate authentication is required when UDDI registry contains sensitive information. 1) If the application representative is unable to demonstrate authentication is required when UDDI registry contains sensitive information, it is a finding.
Add access control mechanism for access to sensitive UDDI XML.
If the application does not utilize SOAP messages, this check is not applicable. Ask the application representative for the design document. Review the design document for web services using SOAP messages. Review the design document and verify the message elements Message ID, Service Request, Timestamp and SAML Assertion are signed. 1) If the design document does not exists or does not indicate the entire SOAP messages requiring integrity do not have the appropriate fields, it is a finding.
Sign the following message elements for SOAP messages requiring integrity: -Message ID -Service Request -Timestamp -SAML Assertion.
Examine the contents of a SOAP message using WS Security, all messages should contain timestamps, sequence numbers, and expiration. 1) If messages using WS Security do not contain timestamps, sequence numbers, and an expiration, it is a finding.
Design application using WS-Security messages to use timestamps with creation and expiration times.
Ask the application representative for the design document. Review the design document for web services. Review the design document and verify validity periods are checked on all messages using WS-Security or SAML assertions. 1) If the design document does not exist, or does not indicate validity periods are checked on messages using WS-Security or SAML assertions, it is a finding.
Design the application to use validity periods are verified on all WS-Security token profiles and SAML Assertions
If the application does not utilize SAML, this check is not applicable. Ask the application representative for the design document. Review the design document for web services using SAML assertions. Review the design document and verify SAML assertion identifiers are not reused by a single asserting party. 1) If the design document does exist, or does not indicate SAML assertion identifiers which are unique for each asserting party, it is a finding.
Design each SAML asserting authority to use unique assertion identifiers.
If the application does not utilize WS-Security tokens, this check is not applicable. Ask the application representative for the design document. Review the design document for web services using WS-Security tokens. Review the design document and verify all WS-Security tokens are only transmitted after both receiving and sending services have been mutually PKI authenticated. 1) If the design document does not exist, or does not indicate all WS-Security tokens are only transmitted after both receiving and sending services have been mutually PKI authenticated, it is a finding.
Encrypt assertions or use equivalent confidentiality when sensitive assertion data is passed through an intermediary.
Verify the application environment is compliant with all DoD IPv6 Standards Profile for IPv6 Capable Products guidance for servers. 1) If the application environment is not compliant with all DoD IPv6 Standards Profile for IPv6 Capable Products guidance for servers, this is a finding.
Design application to be compliant with all DISR IPv6 profiles.
Ask the application representative for the design document. Review the design document for application services supporting IPv6. Verify supporting application layer services (such as, File Transfer Protocol (FTP), Network File system (NFS), Hyper Text Transfer Protocol (HTTP)) have been upgraded and tested for IPv6. 1) If the supporting application layer services have not been upgraded and tested for IPv6, it is a finding. Verify security functions have been updated for IPv6 addressing and network services. 2) If security functions have not been updated for IPv6 addressing and network services, it is a finding. Verify all software update, security update, driver updating, and automatic patching services which retrieve updates over a network connection have been updated to run over IPv6 transport. 3) If all software update, security update, driver updating, and automatic patching have not been updated to run over IPv6 transport, it is a finding. Verify all client-facing server interfaces have been upgraded for IPv6. 4) If all client-facing server interfaces have not been upgraded for IPv6, it is a finding.
Upgrade supporting application services and interfaces for IPv6 transport.
Ask the application representative for the design document. Review the design document for application services supporting IPv6. Verify configuration options for the application for IPv6 addresses. 1) If the application has not been upgraded to support IPv6 addresses, it is a finding. Verify configuration options for the application for IPv6 multicasting. 2) If the application has not been upgraded to support IPv6 multicasting, it is a finding.
Design the application to be compliant with IPv6 multicast addressing and features an IPv6 network configuration options as defined in RFC 4038.
Ask the application representative for the design document. Review the design document for application services supporting IPv6. Verify user interfaces, graphic user interface (GUI), and system management interfaces have been updated to support IPv6 addressing and functions. 1) If the application interfaces have not been upgraded to support IPv6 addressing and functions, it is a finding.
Design the application to be compliant with the IPv6 addressing scheme as defined in with RFC 1884.
Ask the application representative for code review results from the entire application. This can be provided as results from an automated code review tool. If the results are provided from a manual code review, the application representative will need to demonstrate how XML injection vulnerabilities are identified during code reviews. Using XML Schema Definition (XSD) Restrictions and XML Schema Regular Expressions can minimize XML injection attacks. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify XML injection vulnerabilities, it is a finding. Examples of XML Injection vulnerabilities can be obtained from the OWASP website.
Correct XML Injection flaws.
Ask the application representative for code review results from the entire application. This can be provided as results from an automated code review tool. If the results are provided from a manual code review, the application representative will need to demonstrate how CSRF vulnerabilities are identified during code reviews. 1) If the results are not provided or the application representative cannot demonstrate how manual code reviews are performed to identify CSRF, it is a finding.
Add a nonce to web forms every time the URL is requested. The nonce is in addition to the standard session identifier.
Ask the application representative for the design document. Review the design document for all software components. 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, web site toll free support phone numbers etcetera." If any of the software components are not supported by a vendor, it is a finding.
Remove or decommission all unsupported software products in the application.
Examine the contents of a SOAP message using the SubjectConfirmation element. All messages should contain the NotOnOrAfter element. This can be accomplished with a protocol analyzer like Wireshark. 1) If SOAP messages do not contain NotOnOrAfter elements, it is a finding
Use the NotOnOrAfter condition when using the SubjectConfirmation element in a SAML assertion.
Examine the contents of a SOAP message using the <Conditions> element, all messages should contain the NotBefore and NotOnOrAfter or OneTimeUse element when in a SAML Assertion. This can be accomplished using a protocol analyzer such as WireShark 1) If SOAP using the <Conditions> element do not contain NotBefore and NotOnOrAfter or OneTimeUse elements, it is a finding.
Implement the use of the NotBefore and NotOnOrAfter or OneTimeUse when using the Conditions element in a SAML assertion.
Ask the application representative for the Design Document. Verify in the Design Document asserting parties for SAML assertions use FIPS approved random numbers in the generation of SessionIndex in the Element AuthnStatement. If the application is a COTS/GOTS product or is composed of only COTS/GOTS products with no custom code, this check does not apply unless the application is being reviewed by or in conjunction with the COTS/GOTS vendor in which case this check is applicable. 1) If FIPS approved random numbers are not used in the generation of SessionIndex (in the Element AuthnStatement), it is a finding.
Use FIPS approved random numbers in the generation of SessionIndex in the SAML element AuthnStatement.
Examine the contents of a SOAP message using a SessionIndex in the SAML element AuthnStatement. Verify the information which is tied to the SessionIndex. If the SessionIndex is tied to privacy information, and it is not encrypted, it is a finding.
Encrypt messages when the SessionIndex is tied to privacy data.
Examine the contents of a SOAP message using the OneTimeUse element, all messages should contain only one instance of a OneTimeUse element in a SAML assertion. This can be accomplished using a protocol analyzer such as WireShark 1) If SOAP message uses more than one, OneTimeUse element in a SAML assertion, it is a finding.
When using OneTimeUse elements in a SAML assertion only allow one, OneTimeUse element to be used in the Conditions element of a SAML assertion.
Ask the application representative to demonstrate their cryptographic hash validation process or provide process documentation. The validation process will vary based upon the operating system used as there are numerous clients available that will display a file's cryptographic hash for validation purposes. Linux operating systems include the "sha256sum" utility. For Linux systems using sha256sum command syntax is: sha256sum [OPTION]... [FILE]... Windows does not natively provide a SHA256 checksum validation tool; however, there are utilities available that provide this capability. A validation process involves obtaining the application files’ cryptographic hash value from the programs author or other authoritative source such as the application's web site. A utility like the "sha256sum" utility is then run using the downloaded application file name as the argument. The output is the files' hash value. The two hash values are compared and if they match, then file integrity is ensured. If the application being reviewed is a COTS product and the vendor used a SHA1 or MD5 algorithm to generate a hash value, this is not a finding. If the application being reviewed is a COTS product and the vendor did not provide a hash value for validating the package, this is not a finding. If the integrity of the application files/code is not validated prior to deployment to DoD operational networks, this is a finding.
1. Developers/release managers create cryptographic hash values of application files and/or application packages prior to transitioning the application from test to a production environment. They protect cryptographic hash information so it cannot be altered and make a read copy of the hash information available to application Admins so they can validate application packages and files after they download the files. 2. Application Admins validate cryptographic hashes prior to deploying the application to production.