What changed in Application Security and Development STIG V6R5V6R5 changes

Title

The application must implement DoDW-approved encryption to protect the confidentiality of remote access sessions.

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection thereby providing a degree of confidentiality. The encryption strength of mechanism is selected based on the security categorization of the information.

V-222396 in V6R5

Discussion

Without integrity protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection. Without integrity protection mechanisms, unauthorized individuals may be able to insert inauthentic content into a remote session. The encryption strength of mechanism is selected based on the security categorization of the information.

V-222397 in V6R5

Discussion

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, the application must be configured to automatically terminate these types of accounts after a DoDDoW-defined time period of 72 hours starting from the point of account creation. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms meeting or exceeding access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

V-222409 in V6R5

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoDDoW-approved PKIs, all DoDDoW systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to a restricted asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.

V-222425 in V6R5

Discussion

Discretionary Access Control allows users to determine who is allowed to access their data. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoDDoW-approved PKIs, all DoDDoW systems (e.g., networks, web servers, and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.

V-222426 in V6R5

Title

The application must display the Standard Mandatory DoDW Notice and Consent Banner before granting access to the application.

Check text

If the application has no interactive user interface, this requirement is not applicable. Log on to the application as a user. Observe the screen and ensure the DoDDoW-approved banner is displayed prior to obtaining access to the application. Refer to the vulnerability discussion for the approved text. If the only way to access the application is through the OS console, e.g., a fat client application installed on a GFE desktop or laptop, and that GFE is configured to display the DoDDoW banner, an additional banner is not required at the application level. If the standard DoDDoW-approved banner is not displayed prior to obtaining access, this is a finding.

Fix text

Configure the application to present the standard DoDW-approved banner prior to granting access to the application.

Discussion

Display of the DoDDoW-approved use notification before granting access to the application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for applications that can accommodate 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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't."

V-222434 in V6R5

Title

The application must retain the Standard Mandatory DoDDoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.

Check text

If the application has no interactive user interface, this requirement is not applicable. If the user interface is only available via the OS console, e.g., a fat client application installed on a GFE desktop or laptop, and that GFE is configured to display the DoDDoW banner, this requirement is not applicable. Access the application and authenticate if necessary. Verify the banner is displayed and action must be taken to accept terms of use. If the banner is not displayed or no action must be taken to accept terms of use, this is a finding.

Fix text

Configure the application to retain the standard DoDW-approved banner until the user accepts the usage conditions prior to granting access to the application.

Discussion

The banner must be acknowledged by the user prior to allowing the user access to the application. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoDDoW will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".

V-222435 in V6R5

Title

The publicly accessible application must display the Standard Mandatory DoDW Notice and Consent Banner before granting access to the application.

Check text

This requirement only applies to publicly accessible applications. If the application is not publicly accessible, this requirement is not applicable. Access the application and observe the screen to ensure the DoDDoW-approved banner is displayed prior to obtaining full access to the application. Refer to the vulnerability discussion for the approved banner text. If the standard DoDDoW-approved banner is not displayed prior to obtaining access, this is a finding.

Fix text

Configure the application to present the standard DoDW-approved banner prior to granting access to the application.

V-222436 in V6R5

Check text

Review the application documentation, the design requirements if available and interview the application administrator. Identify application services or application commands that are formerly required and designed to provide non-repudiation services (e.g., digital signatures). If the application documentation specifically states that non-repudiation services for application users are not defined as part of the application design, this requirement is not applicable. Email is one example of an application specifically required to provide non-repudiation services for application users within the DoDDoW. Interview the application administrators and have them describe which aspect of the application, if any, is required to provide digital signatures. Access the application as a test user or observe the application administrator as they demonstrate the applications signature capabilities. If the application is required to provide non-repudiation services and does not, or if the non-repudiation functionality fails on demonstration, this is a finding.

Discussion

Without non-repudiation, it is impossible to positively attribute an action to an individual (or process acting on behalf of an individual). Non-repudiation services can be used to determine if information originated from a particular individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Non-repudiation protects individuals against later claims by an author of not having authored a particular document, a sender of not having transmitted a message, a receiver of not having received a message, or a signatory of not having signed a document. The application will be configured to provide non-repudiation services for an organization-defined set of commands that are used by the user (or processes action on behalf of the user). DoDDoW PKI provides for non-repudiation through the use of digital signatures. Non-repudiation requirements will vary from one application to another and will be defined based on application functionality, data sensitivity, and mission requirements.

V-222438 in V6R5

Discussion

When a user's session times out, it is important to be able to identify these events in the application logs. Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoDDoW has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Web-based applications will often utilize an application server that creates, manages, and logs session timeout information. It is acceptable for the application to delegate this requirement to the application server.

V-222445 in V6R5

Discussion

HTTP header information is a critical component of data that is used when evaluating forensic activity. Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. Audit records can be generated from various components within the application (e.g., process, module). Certain specific application functionalities may be audited as well. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoDDoW has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions.

V-222447 in V6R5

Discussion

If the audit reduction capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoDDoW policies. Audit reduction capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with audit reduction capabilities.

V-222491 in V6R5

Discussion

If the report generation capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack, or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoDDoW policies. The report generation capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.

V-222494 in V6R5

Discussion

Changes to any software components can have significant effects on the overall security of the application. Verifying software components have been digitally signed using a certificate that is recognized and approved by the organization ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, or application components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The application should not have to verify the software again. This requirement does not mandate DODDoW certificates for this purpose; however, the certificate used to verify the software must be from an approved certificate authority (CA). If this capability is not present, the vendor must provide a cryptographic hash value that can be verified by a system administrator prior to installation.

V-222513 in V6R5

Discussion

Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices in other situations, including (but not limited to) the following circumstances: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DODDoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

V-222520 in V6R5

Check text

Review the application documentation and interview the application administrator to determine how organizational users access the application. If the application is publicly available, providing access to publicly releasable data and the users are non-organizational users such as individuals who no longer have a CAC (e.g., retirees) or members of the public with no requirement for DoDDoW credentials, this requirement is not applicable. The requirement still applies to DoDDoW organizational users and admins when accessing the non-public data areas or system resources of the system. Attempt to access the application and confirm that a unique user account and password or CAC token and pin are required in order to access the application. If the application does not uniquely identify and authenticate users, this is a finding.

V-222522 in V6R5

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoDDoW has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.

V-222524 in V6R5

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoDDoW has mandated the use of the CAC to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems. If the application does not verify the credentials provided, user authentication cannot be established which places the integrity and confidentiality of the application at risk.

V-222525 in V6R5

Discussion

To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, CAC/SIPRNet token); or (iii) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Applications integrating with the DoDDoW Active Directory and utilize the DoDDoW CAC are an example of compliant multifactor authentication solutions.

V-222526 in V6R5

Discussion

To assure accountability, prevent unauthenticated access, and prevent misuse of the system, privileged users must utilize multifactor authentication (MFA) for local access. MFA is defined as using two or more factors to achieve authentication. Factors include: (i) Something a user knows (e.g., password/PIN); (ii) Something a user has (e.g., cryptographic identification device, token); or (iii) Something a user is (e.g., biometric). A nonprivileged account is defined as an information system account with authorizations of a regular or nonprivileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. Applications integrating with the DODDoW Active Directory and utilize the DODDoW CAC are examples of compliant multifactor authentication solutions.

V-222528 in V6R5

Check text

Review application documentation and interview application administrator to identify what authentication mechanisms are used when accessing the application. If the application is hosting publicly releasable information that does not require authentication, or if the application users are not eligible for a DoDDoW CAC as per DoD 8520, this requirement is not applicable. Review to ensure the application is utilizing TLSV1.2 or greater to protect communication and privileged user authentication traffic. Verify the application utilizes a strong authentication mechanism such as Kerberos, IPSEC, or Secure Shell (SSH). - Cryptographically sign web services packets. - Time stamps and cryptographic hashes are used with web services packets. - Use WS_Security for web services. Request the most recent vulnerability scan results and configuration settings. Verify the configuration is set to test for known replay vulnerabilities. Request code review results (if available) and review for issues that have been identified as potential replay attack vulnerabilities. Verify identified issues have been remediated. If the application is not implementing replay-resistant authentication methods applicable to the application architecture, this is a finding.

V-222530 in V6R5

Check text

Review the application documentation and interview the application administrator to identify what authentication mechanisms are used when accessing the application. If the application is hosting publicly releasable information that does not require authentication, or if the application users are not eligible for a DODDoW CAC as per DOD 8520, this requirement is Not Applicable. Review to ensure the application is utilizing TLSV1.2 or greater to protect communication and nonprivileged user authentication traffic. Verify the application utilizes a strong authentication mechanism such as Kerberos, IPSEC, or Secure Shell (SSH). - Cryptographically sign web services packets. - Time stamps and cryptographic hashes are used with web services packets. - Use WS_Security for web services. Request the most recent vulnerability scan results and configuration settings. Verify the configuration is set to test for known replay vulnerabilities. Request code review results (if available) and review for issues that have been identified as potential replay attack vulnerabilities. Verify identified issues have been remediated. If the application is not implementing replay-resistant authentication methods applicable to the application architecture, this is a finding.

V-222531 in V6R5

Title

The application must utilize mutual authentication when endpoint device non-repudiation protections are required by DoDW policy or by the data owner.

V-222532 in V6R5

Check text

Review the application documentation and interview the application administrator. If the application is not designed to authenticate devices (such as mobile phones, gateways or other smart devices), or uses DODDoW PKI certificates to authenticate these devices, this requirement is Not Applicable. Access the user management interface for the application. Identify application device IDs. If the application utilizes approved certificates or a centralized authentication store (Active Directory or LDAP) as the authoritative source for application authentication, and the authentication store is configured to meet the requirement to disable device IDs after 35 days of inactivity, this is not a finding. Accounts such as guest and anonymous as well as roles and groups or other identities used to operate the application or to provide limited guest access are not applicable. Access the application user management interface and review the account settings that pertain to devices. Verify the application is configured to disable device accounts that have not been active or logged into the application for the past 35 days. If the application does not disable accounts used to authenticate devices after 35 days of inactivity, this is a finding.

Fix text

Configure the application to disable device accounts after 35 days of inactivity or to utilize DODoW PKI certificates that provide an expiration date.

Discussion

Device identifiers are used to identify hardware devices that interact with the application much like a user account is used to identify an application user. Examples of hardware devices include but are not limited to mobile phones, application gateways, or other types of smart hardware. This requirement does not apply to individual application user accounts. This requirement is not applicable to shared information system accounts, application groups, or roles (e.g., guest and anonymous accounts) that are used by the application itself in order to function. Care must be taken to not disable identifiers that are used by the application in order to function. Inactive device identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Applications need to track periods of device inactivity and disable the device identifier after 35 days of inactivity. This is usually accomplished by disabling the account used by the device to access the application. Applications that use cryptographic certificates for device authentication may use the expiration date assigned to the certificate to meet this requirement with the understanding that the certificate is created and managed in accordance with DODDoW PKI policy and can be revoked by a trusted certificate authority (CA). To avoid having to build complex device management capabilities directly into their application, developers should leverage the underlying OS or other account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements. Applications are encouraged to utilize a centralized data store such as Active Directory or LDAP to offload device management requirements and ensure compliance with policy requirements.

V-222535 in V6R5

Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

V-222536 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.

V-222537 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

V-222538 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

V-222539 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

V-222540 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

V-222541 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Passwords need to be protected at all times and using a strong one-way hashing encryption algorithm with a salt is the standard method for providing a means to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered and the one way hash is the most feasible means of securing the password and providing an acceptable measure of password security. If passwords are stored in clear text, they can be plainly read and easily compromised. In many instances, verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random SALT value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) Where n is a cryptographically-strong random [*3] number. Hn is stored, along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares Hn with the stored Hn. A SALT is essentially a fixed-length cryptographically-strong random value. Another method used is utilizing a keyed hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. Applications must only store passwords that have been cryptographically protected.

V-222542 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DoDDoW employee, member of the military, or a DoDDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. and - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Applications can accomplish this by making direct function calls to encryption modules or by leveraging operating system encryption capabilities.

V-222543 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement. Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

V-222544 in V6R5

Title

The application must enforce a 6180-day maximum password lifetime restriction.

Check text

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication. If the application does not use passwords, this requirement is Not Applicable. Access the application management interface and view the user password settings page. Review user password settings and validate the application is configured to expire and force a password change after 60180 days. If user passwords are not configured to expire after 60180 days, or if the application does not have the ability to control this setting, this is a finding.

Fix text

Configure the application to have a maximum password lifetime of 6180 days.

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor common access card (CAC)-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed at specific intervals. One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised. This requirement does not include emergency administration accounts which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.

V-222545 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. To meet password policy requirements, passwords need to be changed at specific policy-based intervals. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements.

V-222546 in V6R5

Discussion

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication. Examples of situations where a user ID and password might be used include but are not limited to: - When the application user base does not have a CAC and is not a current DODDoW employee, member of the military, or a DODDoW contractor. - When an application user has been officially designated as a Temporary Exception User; one who is temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. Without providing this capability, an account may be created without a password. Nonrepudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access to applications when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.

V-222547 in V6R5

Fix text

Use a CAC to authenticate users instead of using passwords. If application users are prohibited or prevented from obtaining a CAC due to DoDDoW policy requirements and passwords are the only viable option, design the application to utilize a secure password change or password reset process. Utilize out of band (OOB) communication techniques to communicate password change requests to users. Ensure verification processes exist that allow users to validate the change request prior to implementing the password change. Ensure users are only allowed to change their own passwords.

V-222548 in V6R5

Check text

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. If the application is only deployed to SIPRNet, this requirement is not applicable. If the application is not intended to be available to Federal government (non-DoDDoW) partners this requirement is not applicable. Ask the application administrator to demonstrate how the application is configured to allow the use of PIV credentials from other agencies. If the application is required to provide authenticated access to Federal agencies and it does not accept a PIV, this is a finding.

Fix text

Configure the application to accept PIV credentials when utilizing authentication provided by Federal (Non-DoDW) agencies.

V-222557 in V6R5

Check text

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PK-enabled due to the hosted data being publicly releasable, this check is not applicable. If the application is only deployed to SIPRNet, this requirement is not applicable. If the application is not intended to be available to Federal government (non-DoDDoW) partners this requirement is not applicable. Ask the application administrator to demonstrate how the application is configured to verify the PIV credentials from other agencies when they are presented as an authentication token. If the application is required to provide authenticated access to Federal agencies and it does not verify the PIV, this is a finding.

Fix text

Configure the application to verify the PIV credentials presented when utilizing authentication provided by Federal (Non-DoDW) agencies.

V-222558 in V6R5

Check text

Review the application documentation and interview the application administrator to identify application access methods. If the application is not PKI-enabled due to the hosted data being publicly releasable, this check is Not Applicable. If the application is only deployed to SIPRnet, this requirement is Not Applicable. If the application is not intended to be available to federal government partners this requirement is Not Applicable. This requirement applies to DODDoW service providers who are relying parties of external (federal government) identity providers. Ask the application administrator to demonstrate how the application conforms to FICAM issued profiles such as SAML or OPENID. If the application is designed to be a service provider utilizing an external identify provider and does not conform to FICAM-issued profiles, this is a finding.

Discussion

FICAM establishes a federated identity framework for the federal government. FICAM provides governmentwide services for common Identity, Credential, and Access Management (ICAM) requirements. The FICAM Trust Framework Solutions (TFS) is the federated identity framework for the U.S. federal government. The TFS is a process by which Industry Trust Frameworks (the codification of requirements for credentials and their issuance, privacy and security requirements, as well as auditing qualifications and processes) are evaluated and assessed for potential use by the government. This requirement only applies to applications intended to be accessible to nonfederal government agencies and other partners or nonorganizational (non-DODDoW) users. Without conforming to FICAM-issued profiles, the information system may not be interoperable with FICAM-authentication protocols, such as SAML 2.0, OpenID 2.0 or other protocols such as the FICAM backend Attribute Exchange. This requirement addresses open identity management standards. More information regarding these standards is available here: https://www.idmanagement.gov/fpki/#federal-pki-policies-and-profiles

V-222560 in V6R5

Check text

Review the application documentation and interview the application administrator to identify the cryptographic modules used by the application. Review the application components and application requirements. Interview application developers and application admins to determine if code signing is performed on distributable application components, files or packages. For example, a developer may sign application code components or an admin may sign application files or packages in order to provide application consumers with integrity assurances. If signing has been identified in the application security plan as not being required and if a documented acceptance of risk is provided, this is not a finding. Have the application admin or the developer demonstrate how the signing algorithms are used and how signing of components including files, code and packages is performed. While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this algorithm, DoDDoW PKI policy prohibits the use of SHA1 as of December 2016. See DoDDoW CIO Memo Subject: Revised Schedule to Update DoDDoW Public Key Infrastructure Certificates to Secure Hash Algorithm-256. If the application signing process does not use FIPS validated cryptographic modules, or if the signing process includes SHA1 or MD5 hashing algorithms, this is a finding.

V-222570 in V6R5

Check text

Review the application components and the application requirements to determine if the application is capable of generating cryptographic hashes. Review the application documentation and interview the application developer or administrator to identify the cryptographic modules used by the application. If hashing of application components has been identified in the application security plan as not being required and if a documented acceptance of risk is provided, this is not a finding. Have the application admin or the developer demonstrate how the application generates hashes and what hashing algorithms are used when generating a hash value. While SHA1 is currently FIPS-140-2 approved, due to known vulnerabilities with this algorithm, DoDDoW PKI policy prohibits the use of SHA1 as of December 2016. See DoDDoW CIO Memo Subject: Revised Schedule to Update DoDDoW Public Key Infrastructure Certificates to Secure Hash Algorithm-256. If the application resides on a National Security System (NSS) and uses an algorithm weaker than SHA-384, this is a finding. If FIPS-validated cryptographic modules are not used when generating hashes or if the application is configured to use the MD5 or SHA1 hashing algorithm, this is a finding.

V-222571 in V6R5

Title

The application must only allow the use of DoDW-approved certificate authorities for verification of the establishment of protected sessions.

Check text

Review the application documentation and interview the application administrator to identify certificate location. 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 DoDDoW-approved PKI and ECA certificates, this is a finding.

Fix text

Configure the application to utilize DoDW-approved PKI established CAs when verifying DoDW-signed certificates.

Discussion

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoDDoW systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoDDoW-approved CA, trust of this CA has not been established. The DoDDoW will only accept PKI certificates obtained from a DoDDoW-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to applications that utilize communications sessions. This includes, but is not limited to, web-based applications and Service-Oriented Architectures (SOA).

V-222584 in V6R5

Title

The application must protect the confidentiality and integrity of stored information when required by DODoW policy or the information owner.

V-222587 in V6R5

Fix text

Identify data elements that require protection. Document the data types and specify encryption requirements. Encrypt data according to DODDoW policy or data owner requirements.

V-222588 in V6R5

Title

The application must use appropriate cryptography in order to protect stored DODoW information when required by the information owner or DODoW policy.

V-222589 in V6R5

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoDDoW or other government agencies. There may be shared resources with configurable protections (e.g., files on storage) that may be assessed on specific information system components.

V-222592 in V6R5

Fix text

Design and configure the application to not store sensitive information in hidden fields. Encrypt sensitive information stored in hidden fields using DoDDoW-approved encryption and use server side session management techniques for user session management.

V-222601 in V6R5

Title

Unsigned Category 1A mobile code must not be used in the application in accordance with DoDW policy.

V-222618 in V6R5

Title

Application web servers must be on a separate network segment from the application and database servers if it is a tiered application operating in the DoDW DMZ.

Check text

Review the application documentation. Review the application data protection requirements and identify if all data types hosted on server are identical. Review the network diagram and identify web servers/web services, web application servers, and database servers. If the application is not hosted in the DoDDoW DMZ, this requirement is not applicable. Verify the application web servers are separated from the application and database servers if the application is a tiered design as per DoDDoW DMZ STIG requirements. If the application is tiered and the network infrastructure hosting the application is not configured to provide separation and security access controls between the tiered layers in accordance with DoDDoW DMZ requirements, this is a finding.

Fix text

Separate web server from other application tiers and place it on a separate network segment apart from the application and database servers in accordance with DoDDoW DMZ data access controls requirements.

Discussion

A tiered application usually consists of 3 tiers, the web layer (presentation tier), the application layer (application logic tier), and the database layer (data storage tier). Using one system for hosting all 3 tiers introduces risk that if one tier is compromised, there are no additional protection layers available to defend the other tiers. Security controls must be in place in order to provide different levels and types of defenses for each type of server based upon data protection requirements identified by policy or data owner. DoDDoW DMZ policy specifies that logical separation is allowed but when hosting different data types on the same server, physical separation is required. 1) Unrestricted web servers and Restricted web servers must be on separate virtual or physical servers from Private web servers, application servers, or database servers. 2) Unrestricted web servers and Restricted web servers can either be on separate physical servers from each other, or they can be on separate virtual servers. 3) If application and database servers have been separated by service type into Unrestricted, Restricted, and Private servers (permitted but not required in Increment 1 Phase 1), they must be on separate virtual or physical servers from each other by server type (Application or Database) and by service type (Unrestricted, Restricted, or Private). Reference the DoDDoW DMZ STIG for details on data types and separation requirements. Security controls include firewalls or other forms of access controls that restrict the ability to traverse the network from one system to the other. Separation can be performed either physically or logically based upon data protection and application protection design requirements. Physically separate networks require distinct physical network devices for connections (e.g., two separate switches or two separate routers). Physically separate machines utilize a non-virtual OS. Logically separate networks are usually implemented via a VLAN. Logically separate systems are implemented with virtual machines or other system emulation. Security controls are firewall rules or ACLs that provide access restrictions on network traffic and limit communications between systems to only application and application/system support traffic. For complete explanation of DoDDoW DMZ requirements, reference DoDDoW DMZ requirements.

V-222620 in V6R5

Title

The ISSO must report all suspected violations of IA policies in accordance with DoDW information system IA procedures.

V-222623 in V6R5

Title

The ISSO must ensure if a DoDW STIG or NSA guide is not available, a third-party product will be configured by following available guidance.

Check text

Review the application documentation to identify application name, features and version. Identify if a DoDDoW STIG or NSA guide is available. If no STIG is available for the product, the application and application components must be configured by the following as available: - commercially accepted practices, - independent testing results, or - vendor literature and lock down guides. If the application and application components do not have DoDDoW STIG or NSA guidance available and are not configured according to: commercially accepted practices, independent testing results, or vendor literature and lock down guides, this is a finding.

V-222627 in V6R5

Title

New IP addresses, data services, and associated ports used by the application must be submitted to the appropriate approving authority for the organization, which in turn will be submitted through the DoDDoW Ports, Protocols, and Services Management (DoDDoW PPSM)

Check text

All application ports, protocols, and services needed for application operation need to be in compliance with the DoDDoW Ports and Protocols guidance. Check: http://iase.disa.mil/ppsm/Pages/index.aspx to verify 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 DoDDoW 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 - Go to Network Reviewer - If a network scan is available, use it - Use netstat/task manager - Check /etc./services If the application is not in compliance with DoDDoW Ports and Protocols guidance, this is a finding.

Fix text

Verify the accreditation documentation lists all interfaces and the ports, protocols, and services used. Verify that all ports, protocols, and services are used in accordance with the DoDDoW PPSM.

Discussion

Failure to comply with DoDDoW Ports, Protocols, and Services (PPS) Vulnerability Analysis and associated PPS mitigations may result in compromise of enclave boundary protections and/or functionality of the application.

V-222628 in V6R5

Title

The application must be registered with the DoDW Ports and Protocols Database.

Discussion

Failure to register the applications usage of ports, protocols, and services with the DoDDoW PPS Database may result in a Denial of Service (DoS) because of enclave boundary protections at other end points within the network.

V-222629 in V6R5

Check text

Verify the application environment is compliant with all DoDDoW IPv6 Standards Profile for IPv6 Capable Products guidance for servers. If the application environment is not compliant with all DoDDoW IPv6 Standards Profile for IPv6 Capable Products guidance for servers, this is a finding.

V-222634 in V6R5

Title

A contingency plan must exist in accordance with DODoW policy based on the application's availability requirements.

V-222636 in V6R5

Title

Data backup must be performed at required intervals in accordance with DoDW policy.

Fix text

Develop and implement backup procedures based on risk level of the system and in accordance with DoDW policy.

V-222638 in V6R5

Discussion

If the application does not use encryption and authenticate endpoints prior to establishing a communication channel and prior to transmitting encryption keys, these keys may be intercepted, and could be used to decrypt the traffic of the current session, leading to potential loss or compromise of DoDDoW data.

V-222641 in V6R5

Check text

Review the application documentation and interview the application administrator. Ask the application representative for the application’s classification guide. This guide should document the data elements and their classification. Determine which application functions to examine, giving preference to report generation capabilities and the most common user transactions that involve sensitive data (CUI, secret, or above). Log on to the application and perform these steps in sequence, printing output when applicable. The application representative’s assistance may be required to perform these steps. For each function, note whether the appropriate markings appear on the displayed and printed output. If a classification document does not exist, data must be marked at the highest classification of the system. Appropriate markings for an application are as follows: For classified and CUI data, markings are required at a minimum at the top and the bottom of screens and reports. In some cases, technology may prohibit the appropriate markings on printed documents. For example, in some cases, it is not possible to mark all pages top and bottom when a user prints from a browser. If this is the case, ask the application representative if user procedures exist for manually marking printed documents. If procedures do exist, examine the procedures to verify the data would be marked correctly if the users follow the procedures. Ask how these procedures are distributed to the users. For systems that do not process sensitive/classified/CUI information, and do not require classification markings, this is not applicable. If appropriate markings are not present within the application and it is technically possible to have the markings present, this is a finding. If it is not technically feasible to meet the minimum marking requirement and no user procedures exist, or if followed the procedures will result in incorrect markings, or the procedures are not readily available to users, this is a finding. In any case of a finding, the finding details must specify which functions failed to produce the desired results. After completing the test, destroy all printed output using the site’s preferred method for disposal. Examples are using a shredder or disposing in burn bags.

V-222643 in V6R5

Title

Application files must be cryptographically hashed prior to deploying to DoDW operational networks.

Check text

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]... Recent Windows PowerShell versions include the "get-filehash" PowerShell cmdlet. The default algorithm value used is SHA256. Syntax is: Get-FileHash [-Path] &ltString[]> [-Algorithm &ltString>] [&ltCommonParameters>] A validation process involves obtaining the application files’ cryptographic hash value from the programs author or other authoritative source such as the application's website. 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 DoDDoW operational networks, this is a finding.

Discussion

When application code and binaries are transferred from one environment to another, there is the potential for malware to be introduced into either the application code or even the application binaries themselves. Care must be taken to ensure that application code and binaries are validated for integrity prior to deployment into a production environment. To ensure file integrity, application files and/or application packages are cryptographically hashed using a strong hashing algorithm. Comparing hashes after transferring the files makes it possible to detect changes in files that could indicate potential integrity issues with the application. Currently, SHA256 is the DoDDoW approved standard for cryptographic hash functions. DoDDoW application developers must use SHA256 when creating cryptographic hashes; however, some non-DoDDoW vendors might still use MD5 or SHA1 when generating a checksum hash for their application packages. It is important to use the same algorithms when validating the hash. If a non DoDDoW vendor uses SHA1 when hashing their files, you must use SHA1 to validate the hash. Otherwise, the hashes will not match and a false positive indication of tampering will result. Prior to release of the application receiving an ATO/IATO for deployment into a DoDDoW operational network, the application must be validated for integrity to ensure no tampering of source code or binaries has occurred. Failure to validate the integrity of application code and/or application binaries prior to deploying an application into a production environment may compromise the operational network.

V-222645 in V6R5

Check text

Review the application documentation and identify if the application creates or utilizes built-in accounts. Examine 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. If the account is required in order for the application to operate properly, verify the account password has been changed to a DoDDoW acceptable value. If these accounts are not necessary to run the application, or if the accounts are required and the password has not been changed to meet DoDDoW password requirements, this is a finding.

V-222661 in V6R5

Fix text

Configure the application to use strong authenticators instead of passwords when possible. Otherwise, change default passwords to a DoDDoW-approved strength password and follow all guidance for passwords.

V-222662 in V6R5

Title

Connections between the DoDW enclave and the Internet or other public or commercial wide area networks must require a DMZ.

Fix text

Setup a DMZ between DoDW and public networks.

Discussion

In order to protect DoDDoW data and systems, all remote access to DoDDoW information systems must be mediated through a managed access control point, such as a remote access server in a DMZ.

V-222671 in V6R5