What changed in Mainframe Product Security Requirements Guide V3R6V3R6 changes

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. 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-205445 in V3R6

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 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. This requirement also applies to Zero Trust initiatives.

V-205451 in V3R6

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 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. This requirement also applies to Zero Trust initiatives.

V-205452 in V3R6

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 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. This requirement also applies to Zero Trust initiatives.

V-205453 in V3R6

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-205457 in V3R6

Title

The Mainframe Product must provide audit record generation capability for DoDW-defined auditable events within all application components.

Check text

Examine Mainframe Product documentation. Refer to NIST SP 800-53 AU-2 or the Risk Management Knowledge Service (RMKS) for DoDDoW auditing events. Examine configuration settings. Compare available auditing events. If available auditing events do not include all DoDDoW-defined auditing events, this is a finding. If auditing is not available for all components of the Mainframe Product, this is a finding.

Fix text

Configure the Mainframe Product to audit all DoDW-defined auditing events within all Mainframe Product components.

Discussion

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-205459 in V3R6

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 must 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 CA.

V-205483 in V3R6

Discussion

To assure accountability and prevent unauthenticated access, non-privileged users must use 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, 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 using the DoDDoW CAC are examples of compliant multifactor authentication solutions.

V-205490 in V3R6

Discussion

To ensure accountability and prevent unauthenticated access, privileged users must use multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication 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 privileged account is defined as an information system account with authorizations of a privileged 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 using the DODDoW CAC are examples of compliant multifactor authentication solutions.

V-205491 in V3R6

Discussion

To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, nonprivileged users must use multifactor authentication for local access. Multifactor authentication 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 using the DODDoW CAC are examples of compliant multifactor authentication solutions.

V-205492 in V3R6

Title

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

Check text

If the Mainframe Product employs an external security manager (ESM) for all account management functions, this is not applicable. Examine user account management configurations. If the Mainframe Product account management configuration does not enforce a 60180-day maximum password lifetime restriction, this is a finding.

Fix text

Configure the Mainframe Product account management settings to enforce a 6180-day maximum password lifetime restriction.

V-205504 in V3R6

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DoDDoW data may be compromised. Applications using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DoDDoW requirements.

V-205509 in V3R6

Discussion

Decisions regarding the employment of mobile code within applications are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. DoDDoW has identified prohibited mobile code in DoDI 8552.01 as: all Category 1X mobile code, unsigned Category 1A mobile code, Category 2 mobile code that violates usage requirements, all Emerging Technologies mobile code (all mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been assigned to a risk category), and all mobile code that downloads via an email body or email attachment that executes automatically when the user opens the email body or attachment. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and anti-virus applications).

V-205513 in V3R6

Discussion

Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. DoDDoW has defined the corrective actions to be taken, when prohibited mobile code is identified, in DoDI 8552.01, "Use of Mobile Code Technologies in DoDDoW Information Systems". DoDDoW has identified prohibited mobile code in DoDI 8552.01 as: all Category 1X mobile code, unsigned Category 1A mobile code, Category 2 mobile code that violates usage requirements, all Emerging Technologies mobile code (all mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been assigned to a risk category), and all mobile code that downloads via an email body or email attachment that executes automatically when the user opens the email body or attachment. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and anti-virus applications). Corrective actions when unacceptable mobile code is detected include, for example, blocking, quarantine, or alerting administrators. Blocking includes, for example, preventing transmission of word processing files with embedded macros when such macros have been defined to be unacceptable mobile code.

V-205514 in V3R6

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-205558 in V3R6

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-205561 in V3R6

Check text

If the Mainframe Product uses an external security manager for all account management, this is not applicable. Examine user account management configurations. If the Mainframe Product account management is not configured to accept PIV credentials, this is a finding.

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-205570 in V3R6

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-205571 in V3R6

Title

The Mainframe Product must be configured in accordance with the security configuration settings based on DoDDoW security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

Discussion

Configuring the application to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoDDoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements.

V-205622 in V3R6