Vuln ID Severity Group Title Rule ID STIG ID Rule Title Discussion IA Controls Check Content Fix Text False Positives False Negatives Documentable Mitigations Potential Impact Third Party Tools Mitigation Control Responsibility Severity Override Guidance Check Content Reference Classification STIG VMS Asset Posture CCI NIST SP 800-53 Revision 4 References Legacy Prisma Cloud Compute Response

V-69239

medium

SRG-APP-000001

SV-83861r1_rule

APSC-DV-000010

The application must provide a capability to limit the number of logon sessions per user.

Application management includes the ability to control the number of users and user sessions that utilize an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to DoS attacks.

This requirement may be met via the application or by utilizing information system session control provided by a web server or other underlying solution that provides specialized session management capabilities.

If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application.

This requirement addresses concurrent sessions for individual system accounts and does not address concurrent sessions by single users via multiple system accounts.

The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.

For production environments; Review the system documentation, identify the number of application user logon sessions allowed per user, identify the methods utilized for user session management or have application administrator describe how the application implements user session management.

Utilize the management interface that is used to set the user session values, or examine configuration files in order to review user session configuration settings.

Ensure the number of sessions allowed per user is specified in accordance with the organizational requirements.

For development environments; have the developer provide design documentation or demonstrate how the application is designed to limit the number of simultaneous user logon sessions.

If the application is not configured to limit the number of logon sessions per user as defined by the organization, this is a finding.

Design and configure the application to specify the number of logon sessions that are allowed per user.

false

APSC-DV-000010

Use web or application server session management capabilities to limit the number of user application sessions or build session management capabilities into the application.

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000054 The information system limits the number of concurrent sessions for each organization-defined account and/or account type to an organization-defined number of sessions. NIST SP 800-53 :: AC-10 NIST SP 800-53A :: AC-10.1 (ii) NIST SP 800-53 Revision 4 :: AC-10

AC-10

Not supported

V-69241

medium

SRG-APP-000295

SV-83863r1_rule

APSC-DV-000060

The application must clear temporary storage and cookies when the session is terminated.

Persistent cookies are a primary means by which a web application will store application state and user information. Since HTTP is a stateless protocol, this persistence allows the web application developer to provide a robust and customizable user experience.

However, if a web application stores user authentication information within a persistent cookie or other temporary storage mechanism, this information can be stolen and used to compromise the users account.

Likewise, HTML 5 provides the developer with a client storage capability where application data larger than the 4K cookie size limit can be stored on the local client. While this can be beneficial to the developer, this is considered insecure storage and should not be used for storing sensitive session or security tokens. A cross site scripting attack can put this data at risk.

Web applications must clear sensitive data from files and storage areas on the client when the session is terminated.

Review application design documentation and interview application administrator to identify how the application makes use of temporary client storage and cookies. Identify cookie and web storage locations on the client. Clear all browser cookies and web cache.

Log on to the application and perform several standard operations, noting if the application ever prompts the user to accept a cookie. If prompted by the browser to save the user ID and password (decline to save the user ID and password), this is a finding.

Log out of the application and close the browser. Reopen the browser and examine the stored cookies. The cookies displayed should be related to the application website.

The procedure to view cookies will vary according to the browser used. Some modern browsers are making use of SQLite databases to store cookie data so use of a SQLite db reader/browser may be required.

Open the cookies related to the application website and search for any identification or authentication information. While authentication information can vary on a per application basis, this is most often specified as "username=x", or "password=x".

If the web application prompts the user to save their password, or if a username or password value exists within a cookie or within local storage locations, even if hashed, this is a finding.

The application may use means other than cookies to store user information. If the reviewer detects an alternative mechanism for storing information locally, examine the data storage to ensure no authentication or other sensitive information is present.

Design and configure the application to clear sensitive data from cookies and local storage when the user logs out of the application.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002361 The information system automatically terminates a user session after organization-defined conditions or trigger events requiring session disconnect. NIST SP 800-53 Revision 4 :: AC-12

AC-12

Using the logout feature the user’s session cookie is deleted

V-69243

medium

SRG-APP-000295

SV-83865r1_rule

APSC-DV-000070

The application must automatically terminate the non-privileged user session and log off non-privileged users after a 15 minute idle time period has elapsed.

Leaving a user’s application session established for an indefinite period of time increases the risk of session hijacking.

Session termination terminates an individual user’s logical application session after 15 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application.

Ask the application representative to demonstrate the configuration setting where the idle time out value is defined.

Alternatively, logon with a regular application user account and let the session sit idle for 15 minutes.

Attempt to access the application after 15 minutes of inactivity.

If the configuration setting is not set to time out user sessions after 15 minutes of inactivity, or if the regular user session used for testing does not time out after 15 minutes of inactivity, this is a finding.

Design and configure the application to terminate the non-privileged users session after 15 minutes of inactivity.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002361 The information system automatically terminates a user session after organization-defined conditions or trigger events requiring session disconnect. NIST SP 800-53 Revision 4 :: AC-12

AC-12

Session token lifetime can be configured. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/long_lived_tokens.html

V-69245

medium

SRG-APP-000295

SV-83867r1_rule

APSC-DV-000080

The application must automatically terminate the admin user session and log off admin users after a 10 minute idle time period is exceeded.

Leaving an admin user’s application session established for an indefinite period of time increases the risk of session hijacking.

Session termination terminates an individual user’s logical application session after 10 minutes of application inactivity at which time the user must re-authenticate and a new session must be established if the user desires to continue work in the application.

Ask the application representative to demonstrate the application configuration setting where the idle time out value is defined for admin users.

Alternatively, logon with an admin user account and let the session sit idle for 10 minutes.

Attempt to access the application after 10 minutes of inactivity.

If the configuration setting is not set to time out admin user sessions after 10 minutes of inactivity, or if the session used for testing does not time out after 10 minutes of inactivity, this is a finding.

Design and configure the application to terminate the admin users session after 10 minutes of inactivity.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002361 The information system automatically terminates a user session after organization-defined conditions or trigger events requiring session disconnect. NIST SP 800-53 Revision 4 :: AC-12

AC-12

Session token lifetime is a single global configuration session.

V-69247

medium

SRG-APP-000296

SV-83869r1_rule

APSC-DV-000090

Applications requiring user access authentication must provide a logoff capability for user initiated communication session.

If a user cannot explicitly end an application session, the session may remain open and be exploited by an attacker. Applications providing user access must provide the ability for users to manually terminate their sessions and log off.

If the application does not provide an interface for interactive user access, this is not applicable.

Log on to the application with a valid user account. Examine the user interface. Identify the command or link that provides the logoff function.

Activate the user logoff function.

Observe user interface and attempt to interact with the application. Confirm user interaction with the application is no longer possible.

If the user session is not terminated or if the logoff function does not exist, this is a finding.

Design and configure the application to provide all users with the capability to manually terminate their application session.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002363 The information system provides a logout capability for user-initiated communications sessions whenever authentication is used to gain access to organization-defined information resources. NIST SP 800-53 Revision 4 :: AC-12 (1)

AC-12 (1)

User initiated logoff is supported

V-69251

medium

SRG-APP-000311

SV-83873r1_rule

APSC-DV-000110

The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in storage.

Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.

These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.

One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in storage. If the security attributes are lost when the data is stored, there is the risk of a data compromise.

Classify the system hosting the application with default classification. Treat all unmarked data at the highest classification as the overall hosting system is classified. If there is no classification, mark system high.

Review the application documentation and interview the application administrator.

Determine if the application processes classified, FOUO, or other data that is required to be marked and identify if the application requirements specify data markings of any other types of data.

If the application does not contain classified, FOUO, or other data that is required to be marked, this requirement is not applicable.

Review the database or other storage mechanism and have the application administrator identify and demonstrate how the application assigns and maintains data markings while the data is in storage.

Typical methods for marking data include utilizing a table or data base field that contains the marking information and associating the marking information with the data.

If application data required to be marked is not marked and does not retain its marking while it is being stored, this is a finding.

Design and configure the application to assign data marking and ensure the marking is retained when the data is stored.

false

APSC-DV-000110

Classify the system hosting the application with default classification. Treat all unmarked data at the highest classification as the overall hosting system is classified.

If there is no classification, mark system high.

Create POAM documentation and plan to create and retain data markings within application.

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002262 The organization provides the means to associate organization-defined types of security attributes having organization-defined security attribute values with information in storage. NIST SP 800-53 Revision 4 :: AC-16 a

AC-16 a

No system classification capabilities. Classify Prisma Cloud Compute to the highest level of operation.

V-69253

medium

SRG-APP-000313

SV-83875r1_rule

APSC-DV-000120

The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in process.

Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.

These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.

One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in process. If the security attributes are lost when the data is being processed, there is the risk of a data compromise.

Review the application documentation and interview the application administrator.

Identify if the application requirements include data marking. Also determine if the application processes classified, FOUO or other data that is required to be marked.

If the application does not contain classified, FOUO or have data marking requirements, this requirement is not applicable.

Access the user interface for the application and navigate through the application. Perform several application actions that will manipulate data contained within the application.

For example, create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Perform an edit action on the test data that does not edit the marking itself or perform any other form of data processing such as assigning the data to another users work queue for review or printing the data, ensure the data marking is retained throughout the data processing actions.

If application data required to be marked does not retain its marking while it is being processed by the application, this is a finding.

Design and configure the application to retain the data marking when processing data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002263 The organization provides the means to associate organization-defined types of security attributes having organization-defined security attribute values with information in process. NIST SP 800-53 Revision 4 :: AC-16 a

AC-16 a

No system classification capabilities. Classify Prisma Cloud Compute to the highest level of operation.

V-69255

medium

SRG-APP-000314

SV-83877r1_rule

APSC-DV-000130

The application must associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission.

Without the association of security attributes to information, there is no basis for the application to make security related access-control decisions.

Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information.

These attributes are typically associated with internal data structures (e.g., records, buffers, files) within the information system and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy.

One example includes marking data as classified or FOUO. These security attributes may be assigned manually or during data processing but either way, it is imperative these assignments are maintained while the data is in transmission. If the security attributes are lost when the data is being transmitted, there is the risk of a data compromise.

Review the application documentation and interview the application administrator.

Identify if the application requirements include data marking also determine if the application processes classified, FOUO or other data that is required to be marked.

Access the user interface for the application and navigate through the application. Perform an application action that will transmit marked data that is contained within the application.

If the application does not contain classified, FOUO or have data marking requirements, or if the application does not transmit data, this requirement is not applicable.

E.g., create a test record and assign a data marking to the data element. Save the test record, close the data entry fields and navigate to display the test record. Initiate the application processes to transmit data. Access remote system or have person with access to remote system verify the data marking is retained after the data transmission.

If application data required to be marked does not retain its marking when it is being transmitted by the application, this is a finding.

Design and configure the application to retain the data marking when transmitting data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002264 The organization provides the means to associate organization-defined types of security attributes having organization-defined security attribute values with information in transmission. NIST SP 800-53 Revision 4 :: AC-16 a

AC-16 a

No system classification capabilities. Classify Prisma Cloud Compute to the highest level of operation.

V-69257

medium

SRG-APP-000014

SV-83879r1_rule

APSC-DV-000160

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

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Remote access is access to DoD 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.

Review the application documentation and interview the system administrator.

Identify the application encryption capabilities and methods for implementing encryption protection.

For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon. Click on the padlock icon and examine the connection information. Determine if TLS encryption is used to secure the session.

For non-web based applications, determine the TCP/IP port, protocol and method used for establishing client connections to the remote server. Review application configuration settings to ensure encryption is specified and via TLS.

If the connection is not secured with TLS, this is a finding.

Design and configure applications to use TLS encryption to protect the confidentiality of remote access sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000068 The information system implements cryptographic mechanisms to protect the confidentiality of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Prisma Cloud Compute Console’s user interface and API communication is protected by TLS v1.3

V-69259

medium

SRG-APP-000015

SV-83881r1_rule

APSC-DV-000170

The application must implement cryptographic mechanisms to protect the integrity of remote access sessions.

Without integrity protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Remote access is access to DoD 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.

Review the application documentation and interview the system administrator.

Identify the application encryption capabilities and methods for implementing encryption protection.

For web based applications; open the web browser and access the website URL. Use the browser and determine if the session is protected via TLS. A secure connection is usually indicated in the upper left hand corner of the URL by a padlock icon. Click on the padlock icon and examine the connection information. Determine if TLS encryption is used to secure the session.

For non-web based applications, determine the TCP/IP port, protocol and method used for establishing client connections to the remote server. Review application configuration settings to ensure encryption is specified and via TLS.

If the connection is not secured with TLS, this is a finding.

Design and configure applications to use TLS encryption to protect the integrity of remote access sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001453 The information system implements cryptographic mechanisms to protect the integrity of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Supported TLS cypher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

V-69261

medium

SRG-APP-000015

SV-83883r1_rule

APSC-DV-000180

Applications with SOAP messages requiring integrity must include the following message elements:-Message ID-Service Request-Timestamp-SAML Assertion (optionally included in messages) and all elements of the message must be digitally signed.

Digitally signed SOAP messages provide message integrity and authenticity of the signer of the message independent of the transport layer. Service requests may be intercepted and changed in transit and the data integrity may be at risk if the SOAP message is not digitally signed.

Functional architecture aspects of the application security plan identify the application data elements that require data integrity protection.

Review the application documentation, system security plan, application architecture diagrams and interview the application administrator.

Review the design document for web services using SOAP messages.

If the application does not utilize SOAP messages, this check is not applicable.

Review the design document and SOAP messages. Verify the Message ID, Service Request, Timestamp, and SAML Assertion are included in the SOAP message. If they are included, verify they are signed with a certificate.

If SOAP messages requiring integrity do not have the Message ID, Service Request, Timestamp, and SAML Assertion signed, or if any part of the message is not digitally signed, this is a finding.

Design and configure the application to sign the following message elements for SOAP messages requiring integrity:

- Message ID - Service Request - Timestamp - SAML Assertion - Message elements

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001453 The information system implements cryptographic mechanisms to protect the integrity of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Signing of the SAML authentication requests from Prisma Cloud Compute is not supported.

V-69283

medium

SRG-APP-000014

SV-83905r2_rule

APSC-DV-000210

The application must ensure each unique asserting party provides unique assertion ID references for each SAML assertion.

SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject> element. SAML assertion identifiers should be unique across a system implementation. Duplicate SAML assertion identifiers could lead to unauthorized access to a web service.

Ask the application representative for the design document.

Review the design document for web services using SAML assertions.

If the application does not utilize SAML assertions, this check is not applicable.

Review the design document and verify SAML assertion identifiers are not reused by a single asserting party.

If the design document does not exist, or does not indicate SAML assertion identifiers which are unique for each asserting party, this is a finding.

Design and configure each SAML assertion authority to use unique assertion identifiers.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000068 The information system implements cryptographic mechanisms to protect the confidentiality of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Prisma Cloud Compute does validate an Identity Providers signed SAML assertion.

V-69285

medium

SRG-APP-000014

SV-83907r1_rule

APSC-DV-000220

The application must ensure encrypted assertions, or equivalent confidentiality protections are used when assertion data is passed through an intermediary, and confidentiality of the assertion data is required when passing through the intermediary.

SAML is a standard for exchanging authentication and authorization data between security domains. SAML uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, (identity provider), and a SAML consumer, (service provider). SAML assertions are usually made about a subject, (user) represented by the <Subject> element.

The confidentially of the data in a message as the message is passed through an intermediary web service may be required to be restricted by the intermediary web service. The intermediary web service may leak or distribute the data contained in a message if not encrypted or protected.

Ask the application representative for the design document.

Review the design document for web services using WS-Security tokens.

If the application does not utilize WS-Security tokens, this check is not applicable.

Verify all WS-Security tokens are transmitted via an approved encryption method.

If the design document does not exist, or does not indicate all WS-Security tokens are only transmitted via an approved encryption method, this is a finding.

Encrypt assertions or use equivalent confidentiality when sensitive assertion data is passed through an intermediary.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000068 The information system implements cryptographic mechanisms to protect the confidentiality of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Encrypted SAML assertions are not supported

V-69291

medium

SRG-APP-000014

SV-83913r1_rule

APSC-DV-000250

The application must ensure if a OneTimeUse element is used in an assertion, there is only one of the same used in the Conditions element portion of an assertion.

Multiple <OneTimeUse> elements used in a SAML assertion can lead to elevation of privileges, if the application does not process SAML assertions correctly.

Ask the application representative for the design document.

Review the design document for web services using SAML assertions.

If the application does not utilize SAML assertions, this check is not applicable.

Examine the contents of a SOAP message using the OneTimeUse element; all messages should contain only one instance of a <OneTimeUse> element in a SAML assertion. This can be accomplished using a protocol analyzer such as Wireshark.

If SOAP message uses more than one, OneTimeUse element in a SAML assertion, this is a finding.

When using OneTimeUse elements in a SAML assertion only allow one, OneTimeUse element to be used in the conditions element of a SAML assertion.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000068 The information system implements cryptographic mechanisms to protect the confidentiality of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

OneTimeUse assertion validations is not used. NotBefore and NotOnOrAfter SAML attributes are use to determine the validity period of the SAML assertions.

V-69293

medium

SRG-APP-000014

SV-83915r1_rule

APSC-DV-000260

The application must ensure messages are encrypted when the SessionIndex is tied to privacy data.

When the SessionIndex is tied to privacy data (e.g., attributes containing privacy data) the message should be encrypted. If the message is not encrypted there is the possibility of compromise of privacy data.

Ask the application representative for the design document.

Review the design document for web services using SAML assertions.

If the application does not utilize SAML assertions, this check is not applicable.

Examine the contents of a SOAP message using a SessionIndex in the SAML element AuthnStatement. Verify the information which is tied to the SessionIndex.

If the SessionIndex is tied to privacy information, and it is not encrypted, this is a finding.

Encrypt messages when the SessionIndex is tied to privacy data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000068 The information system implements cryptographic mechanisms to protect the confidentiality of remote access sessions. NIST SP 800-53 :: AC-17 (2) NIST SP 800-53A :: AC-17 (2).1 NIST SP 800-53 Revision 4 :: AC-17 (2)

AC-17 (2)

Encryption of SAML assertions are not supported. Only nameID attribute is required for authentication and group membership is optional.

V-69295

medium

SRG-APP-000023

SV-83917r1_rule

APSC-DV-000280

The application must provide automated mechanisms for supporting account management functions.

Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.

Manual examples include but are not limited to admin staff logging into the system or systems and manually performing step by step actions affecting user accounts that could otherwise be automated. This does not include any manual steps taken to initiate automated processes or the use of automated systems.

A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended or terminated or by disabling accounts located in non-centralized account stores such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.

The application must be configured to automatically provide account management functions and these functions must immediately enforce the organization’s current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies that when placed together contain an overall automated mechanism supporting an organization’s automated account management requirements.

Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephonic notification to report atypical system account usage.

Review the application documentation and interview the application administrator.

Identify the account management methods, processes and procedures that are used.

If the application is utilizing a centralized authentication mechanism such as Active Directory or LDAP, verify all user account activity is conducted via that solution and no local user accounts that circumvent the automated solution are used.

Determine if automated mechanisms are used when managing application user accounts and taking management action on application user accounts. Automated methods include but are not limited to:

Taking action on accounts that have been determined to be inactive, suspended, terminated, or disabled.

Automated action examples include: deleting such accounts, reactivating accounts in conjunction with a validation or verification process, or sending notifications or reminders to the account holders that their account is about to be disabled or deleted.

Verify the action that is taken is automated and repeatable.

If the account management process is manual in nature, this is a finding.

Use automated processes and mechanisms for account management functions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000015 The organization employs automated mechanisms to support the information system account management functions. NIST SP 800-53 :: AC-2 (1) NIST SP 800-53A :: AC-2 (1).1 NIST SP 800-53 Revision 4 :: AC-2 (1)

AC-2 (1)

External account integration with LDAP, SAML and x509 is supported. If local accounts are required the Console API Users endpoint (https://cdn.twistlock.com/docs/api/twistlock_api.html#users) can be used to add, modify and delete local user accounts.

V-69297

medium

SRG-APP-000317

SV-83919r1_rule

APSC-DV-000290

Shared/group account credentials must be terminated when members leave the group.

If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.

Review the application documentation and determine if there is a requirement for shared or group accounts.

If there is no official requirement for shared or group application accounts, this requirement is not applicable.

Interview the application representative and identify shared/group accounts.

Have the application representative provide their procedures for account management as it pertains to group users.

Validate there is a procedure for deleting either member accounts or the entire group account when member leave the group.

If there is no process for handling group account credentials, this is a finding.

Create a procedure for deleting either member accounts or the entire group account when members leave the group.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002142 The information system terminates shared/group account credentials when members leave the group. NIST SP 800-53 Revision 4 :: AC-2 (10)

AC-2 (10)

Responsibility of the organization.

V-69299

medium

SRG-APP-000024

SV-83921r1_rule

APSC-DV-000300

The application must automatically remove or disable temporary user accounts 72 hours after account creation.

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 DoD-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.

If official documentation exist that disallows the use of temporary user accounts within the application, this requirement is not applicable.

Examine the application documentation or interview the application representative to identify how the application users are managed.

Navigate to the screen where user accounts are configured.

Create a test account and determine if there is a setting to specify the user account as being temporary in nature.

Determine if there is an available setting to expire the account after a period of time.

If the application has no ability to specify a user account as being temporary in nature, or if the account has no ability to automatically disable or remove the account after 72 hours after account creation, this is a finding.

Configure temporary accounts to be automatically removed or disabled after 72 hours after account creation.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000016 The information system automatically removes or disables temporary accounts after an organization-defined time period for each type of account. NIST SP 800-53 :: AC-2 (2) NIST SP 800-53A :: AC-2 (2).1 (ii) NIST SP 800-53 Revision 4 :: AC-2 (2)

AC-2 (2)

Recommend using LDAP, SAML or x509 identities and leveraging automated account policies of those identity management systems.

V-69303

medium

SRG-APP-000025

SV-83925r1_rule

APSC-DV-000330

Unnecessary application accounts must be disabled, or deleted.

Test or demonstration accounts are sometimes created during the application installation process. This creates a security risk as these accounts often remain after the initial installation process and can be used to gain unauthorized access to the application. Applications must be designed and configured to disable or delete any unnecessary accounts that may be created.

Care must be taken to ensure valid accounts used for valid application operations are not disabled or deleted when this requirement is applied.

Review the system documentation and identify any valid application accounts that are required in order for the application to operate. Accounts the application itself uses in order to function are not in scope for this requirement.

Have the application administrator generate a list of all application users. This should include relevant user metadata such as phone numbers or department identifiers.

Have the application administrator identify and validate all user accounts.

If any accounts cannot be validated and are deemed to be unnecessary, this is a finding.

Design the application so unessential user accounts are not created during installation. Disable or delete all unnecessary application user accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000017 The information system automatically disables inactive accounts after an organization-defined time period. NIST SP 800-53 :: AC-2 (3) NIST SP 800-53A :: AC-2 (3).1 (ii) NIST SP 800-53 Revision 4 :: AC-2 (3)

AC-2 (3)

No application accounts are created.

V-69305

medium

SRG-APP-000026

SV-83927r1_rule

APSC-DV-000340

The application must automatically audit account creation.

Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application owners exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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.

Examine the application documentation to identify how the application users are managed.

Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application.

If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable.

Identify the location of the audit logs and review the end of the logs.

Access the user account management functionality and create a new user account.

Examine the log file again and determine if the account creation event was logged. The information logged should, at a minimum, include enough detail to determine which account was created and when.

If the account creation event was not logged, this is a finding.

Configure the application to write a log entry when a new user account is created.

At a minimum, ensure account name, date and time of the event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000018 The information system automatically audits account creation actions. NIST SP 800-53 :: AC-2 (4) NIST SP 800-53A :: AC-2 (4).1 (i&ii) NIST SP 800-53 Revision 4 :: AC-2 (4)

AC-2 (4)

Account creation events are audited in the Console’s audit logs.

V-69307

medium

SRG-APP-000027

SV-83929r1_rule

APSC-DV-000350

The application must automatically audit account modification.

One way for an attacker to establish persistent access is for the attacker to modify or copy an existing account. Auditing of account modification is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the modification of application user accounts. Such a process greatly reduces the risk that accounts will be surreptitiously modified and provides logging that can be used for forensic purposes.

To address account requirements and to ensure application accounts follow requirements consistently, application developers are strongly encouraged to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed 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.

Examine the application documentation to identify how the application users are managed.

Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application.

If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable.

Identify the location of the audit logs and review the end of the logs.

Access the user account management functionality and modify a test user account.

Examine the log file again and determine if the account event was logged. The information logged should, at a minimum, include enough detail to determine which account was modified and when.

If the account modification event information was not logged, this is a finding.

Configure the application to write a log entry when a user account is modified.

At a minimum, ensure account name, date and time of the event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001403 The information system automatically audits account modification actions. NIST SP 800-53 :: AC-2 (4) NIST SP 800-53A :: AC-2 (4).1 (i&ii) NIST SP 800-53 Revision 4 :: AC-2 (4)

AC-2 (4)

Account modification events are audited in the Console’s audit logs.

V-69309

medium

SRG-APP-000028

SV-83931r1_rule

APSC-DV-000360

The application must automatically audit account disabling actions.

When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account disabling actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.

Examine the application documentation to identify how the application users are managed.

Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application.

If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable.

Identify the location of the audit logs and review the end of the logs.

Access the user account management functionality and disable a test user account.

Examine the log file again and determine if the account disable event was logged. The information logged should, at a minimum, include enough detail to determine which account was disabled and when.

If the account disabling event information was not logged, this is a finding.

Configure the application to write a log entry when a user account is disabled.

At a minimum, ensure account name, date and time of the event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001404 The information system automatically audits account disabling actions. NIST SP 800-53 :: AC-2 (4) NIST SP 800-53A :: AC-2 (4).1 (i&ii) NIST SP 800-53 Revision 4 :: AC-2 (4)

AC-2 (4)

Local accounts cannot be disabled. Remove account if needed.

V-69311

medium

SRG-APP-000029

SV-83933r1_rule

APSC-DV-000370

The application must automatically audit account removal actions.

When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account removal actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.

Examine the application documentation to identify how the application users are managed.

Interview the application administrator and determine if the application is configured to utilize a centralized user management system like Active Directory for user management or if the application manages user accounts within the application.

If the application is configured to use an enterprise-based application user management capability that is STIG compliant, the requirement is not applicable.

Identify the location of the audit logs and review the end of the logs.

Access the user account management functionality and remove a test user account.

Examine the log file again and determine if the account removal event was logged. The information logged should, at a minimum, include enough detail to determine which account was disabled and when.

If the account removal event information was not logged, this is a finding.

Configure the application to write a log entry when a user account is removed.

At a minimum, ensure account name, date and time of the event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001405 The information system automatically audits account removal actions. NIST SP 800-53 :: AC-2 (4) NIST SP 800-53A :: AC-2 (4).1 (i&ii) NIST SP 800-53 Revision 4 :: AC-2 (4)

AC-2 (4)

Account deletion events are audited in the Console’s audit logs.

V-69321

medium

SRG-APP-000319

SV-83943r1_rule

APSC-DV-000420

The application must automatically audit account enabling actions.

When application accounts are enabled, user accessibility is affected. Accounts are utilized for identifying individual application users or for identifying the application processes themselves. In order to detect and respond to events affecting user accessibility and application processing, applications must audit account removal actions and, as required, notify the appropriate individuals, so they can investigate the event. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.

Examine the application documentation or interview the application representative to identify how the application users are managed.

Identify the location of the audit logs and review the end of the logs.

Access the user account management functionality and enable a test user account.

Examine the log file again and determine if the account enable event was logged. The information logged should, at a minimum, include enough detail to determine which account was enabled and when.

If the account enabling event information was not logged, this is a finding.

Configure the application to write a log entry when a user account is enabled.

At a minimum, ensure account name, date and time of the event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002130 The information system automatically audits account enabling actions. NIST SP 800-53 Revision 4 :: AC-2 (4)

AC-2 (4)

Auditing is enabled by default and cannot be disabled.

V-69325

medium

SRG-APP-000323

SV-83947r1_rule

APSC-DV-000440

Application data protection requirements must be identified and documented.

Failure to protect organizational information from data mining may result in a compromise of information. In order to assign the appropriate data protections, application data must be identified and then protection requirements assigned. Access to sensitive data and sensitive data objects should be restricted to those authorized to access the data.

Examples of sensitive data include but are not limited to; Social Security Numbers, Personally Identifiable Information, or any other data that is has been identified as being sensitive in nature by the data owner.

Data storage objects include, for example, databases, database records, and database fields.

Data mining prevention and detection techniques include, for example: limiting the types of responses provided to database queries; limiting the number/frequency of database queries to increase the work factor needed to determine the contents of such databases; and notifying organizational personnel when atypical database queries or accesses occur.

Protection methods include but are not limited to data encryption, Role-Based Access Controls and access authentication.

Ask the application representative for the documentation that identifies the application data elements, the protection requirements, and any associated steps that are being taken to protect the data.

If the application data protection requirements are not documented, this is a finding.

Identify and document the application data elements and the data protection requirements.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002346 The organization employs organization-defined data mining prevention techniques for organization-defined data storage objects to adequately protect against data mining. NIST SP 800-53 Revision 4 :: AC-23

AC-23

Database data protections are implemented, sensitive database tables are encrypted (e.g. Credential Store)

V-69327

medium

SRG-APP-000324

SV-83949r1_rule

APSC-DV-000450

The application must utilize organization-defined data mining detection techniques for organization-defined data storage objects to adequately detect data mining attempts.

Failure to protect organizational information from data mining may result in a compromise of information.

Data mining occurs when the application is programmatically probed and data is automatically extracted. While there are valid uses for data mining within data sets, the organization should be mindful that adversaries may attempt to use data mining capabilities built into the application in order to completely extract application data so it can be evaluated using methods that are not natively offered by the application. This can provide the adversary with an opportunity to utilize inference attacks or obtain additional insights that might not have been intended when the application was designed.

Methods of extraction include database queries or screen scrapes using the application itself. The entity performing the data mining must have access to the application in order to extract the data. Data mining attacks will usually occur with publicly releasable data access but can also occur when access is limited to authorized or authenticated inside users.

Data storage objects include, for example, databases, database records, and database fields.

Data mining prevention and detection techniques include, for example: limiting the types of responses provided to database queries; limiting the number/frequency of database queries to increase the work factor needed to determine the contents of such databases; and notifying organizational personnel when atypical database queries or accesses occur.

Review the security plan, application and system documentation and interview the application administrator to identify data mining protections that are required of the application.

If there are no data mining protections required, this requirement is not applicable.

Review the application authentication requirements and permissions.

Review documented protections that have been established to protect from data mining.

This can include limiting the number of queries allowed.

Automated alarming on atypical query events.

Limiting the number of records allowed to be returned in a query.

Not allowing data dumps.

If the application requirements specify protections for data mining and the application administrator is unable to identify or demonstrate that the protections are in place, this is a finding.

Utilize and implement data mining protections when requirements specify it.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002347 The organization employs organization-defined data mining detection techniques for organization-defined data storage objects to adequately detect data mining attempts. NIST SP 800-53 Revision 4 :: AC-23

AC-23

All data query and retrieval is provided by the API. Data mining protections are implemented by the API.

V-69331

medium

SRG-APP-000328

SV-83953r1_rule

APSC-DV-000470

The application must enforce organization-defined discretionary access control policies over defined subjects and objects.

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 DoD-approved PKIs, all DoD 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.

Review the application documentation and interview the application administrator.

Review application data protection requirements and application integrated access control methods.

Identify if the application implements discretionary access control to application resources. Discretionary Access Controls (DAC) allows application users to determine and set permissions on application data and application objects. The result is the user is given the ability to control who has access to the data they control.

If the application does not implement discretionary access controls, this requirement is not applicable.

Resources can be a URL, a folder, a file, a process, a database record, or any other application asset that warrants sharing or authorization permission reassignment.

Create 3 test accounts.

Using test account 1 set protection control on a test user 1 controlled resource.

Grant access to test user 2 and only test user 2.

Authenticate as test user 3 and attempt to access the application resource where test user 1 and test user 2 are granted access. Access should be denied.

If the enforcement of configured access restrictions is not performed, this is a finding.

Design and configure the application to enforce discretionary access control policies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002165 The information system enforces organization-defined discretionary access control policies over defined subjects and objects. NIST SP 800-53 Revision 4 :: AC-3 (4)

AC-3 (4)

Role based access is supported. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/access_control/user_roles.html

V-69333

medium

SRG-APP-000038

SV-83955r1_rule

APSC-DV-000480

The application must enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies.

A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all system information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data.

Application specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics).

This is usually established by identifying if there are rulesets, policies or other configurations settings provided by the application which serve to control the flow of information within the system. Control of data flow is established by using labels on data and data subsets, evaluating the destination of the data within or without the system (similar security domain) and referencing a corresponding policy that is used to control the flow of data.

Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.

Review the application documentation and interview the application and system administrators.

Review application features and functions to determine if the application is designed to control the flow of information within the system. Identify:

- rulesets,- data labels, and - policies

to determine if the application is designed to control the flow of data within the system.

If the application does not provide data flow control capabilities, the requirement is not applicable.

Access the system as a user with access rights that allow the creation of test data or use of existing test data.

Create a test data set and label the data with a data label provided with or by the application, e.g., Personally Identifiable Information (PII) data.

Review the policy to determine where in the system the PII labeled data is allowed and is not allowed to go.

Using application features and functions, attempt to transmit the labeled data to an area that is prohibited by policy.

Verify the flow control policy was enforced and the data was not transmitted.

If the application does not enforce the approved authorizations for controlling data flow, this is a finding.

Configure the application to enforce data flow control in accordance with data flow control policies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001368 The information system enforces approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. NIST SP 800-53 :: AC-4 NIST SP 800-53A :: AC-4.1 (iii) NIST SP 800-53 Revision 4 :: AC-4

AC-4

Communication between the Prisma Cloud Compute components (Console and Defender) is established and protected by a mutually authenticated x.509 TLS web socket connection.

V-69335

medium

SRG-APP-000039

SV-83957r1_rule

APSC-DV-000490

The application must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies.

A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all system information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data.

Application specific examples of enforcement occurs in systems that employ rule sets or establish configuration settings that restrict information system services, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics).

This is usually established by identifying if there are rulesets, policies or other configurations settings provided by the application which serve to control the flow of information within the system. Control of data flow is established by using labels on data and data subsets, evaluating the destination of the data within or without the system (similar security domain) and referencing a corresponding policy that is used to control the flow of data.

Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy.

Review the application documentation and interview the application and system administrators.

Identify application features and functions to determine if the application is designed to control the flow of information between interconnected systems.

Identify:

- rulesets,- data labels - policies - systems

to determine if the application is designed to control the flow of data between interconnected systems.

If the application does not provide data flow control capabilities, the requirement is not applicable.

Access the system as a user with access rights allowing the creation of test data or use of existing test data.

Create a test data set and label the data with a data label provided with or by the application (for example, a Personally Identifiable Information (PII) data label).

Review the policy settings to determine where the PII labeled data is allowed and is not allowed.

Using application features and functions, attempt to transmit the labeled data to an interconnected system that is prohibited by policy.

Verify the flow control policy was enforced and the data was not transmitted.

If the application does not enforce the approved authorizations for controlling data flow, this is a finding.

Configure the application to enforce data flow control in accordance with data flow control policies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001414 The information system enforces approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. NIST SP 800-53 :: AC-4 NIST SP 800-53A :: AC-4.1 (iii) NIST SP 800-53 Revision 4 :: AC-4

AC-4

Communication between the Prisma Cloud Compute components (Console and Defender) is established and protected by a mutually authenticated x.509 TLS web socket connection.

V-69337

medium

SRG-APP-000340

SV-83959r1_rule

APSC-DV-000500

The application must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges.

Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.

Identify the application user account(s) that the application uses to run. These accounts include the application processes (defined by Control Panel Services (Windows) or ps –ef (UNIX)) or for an n-tier application, the account that connects from one service (such as a web server) to another (such as a database server).

Determine the OS user groups in which each account is a member.

List the user rights assigned to these users and groups and evaluate whether any of them are unnecessary.

If the OS rights exceed application operational requirements, this is a finding.

If the application user account is a member of the Administrators group (Windows) or has a User Identification (UID) of 0 (i.e., is equivalent to root in UNIX), this is a finding.

Search the file system to determine if the application user or groups have ownership or permissions to any files or directories.

Review the list of files and identify any that are outside the scope of the application.

If there are such files outside the scope of the application, this is a finding.

Check ownership and permissions; identify permissions beyond the minimum necessary to support the application.

If there are instances of unnecessary ownership or permissions, this is a finding.

The finding details should note the full path of the file(s) and the associated issue (i.e., outside scope, permissions improperly granted to user X, etc.).

Modify the application to limit access and prevent the disabling or circumvention of security safeguards.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002235 The information system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. NIST SP 800-53 Revision 4 :: AC-6 (10)

AC-6 (10)

Roles have defined system capabilities. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/access_control/user_roles.html

V-69341

medium

SRG-APP-000343

SV-83963r1_rule

APSC-DV-000520

The application must audit the execution of privileged functions.

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse, and identify the risk from insider threats and the advanced persistent threat.

Log on to the application as an administrative user.

Identify functionality within the application that requires utilizing the admin role.

Monitor application logs while performing privileged functions within the application.

Perform administrative types of tasks such as adding or modifying user accounts, modifying application configuration, or managing encryption keys.

Review logs for entries that indicate the administrative actions performed were logged.

Ensure the specific action taken, date and time or event is recorded.

If the execution of privileged functionality is not logged, this is a finding.

Configure the application to write log entries when privileged functions are executed. At a minimum, ensure the specific action taken, date and time of event are recorded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002234 The information system audits the execution of privileged functions. NIST SP 800-53 Revision 4 :: AC-6 (9)

AC-6 (9)

All user actions are audited.

V-69347

medium

SRG-APP-000345

SV-83969r1_rule

APSC-DV-000540

The application administrator must follow an approved process to unlock locked user accounts.

Once a user account has been locked, it must be unlocked by an administrator.

An ISSM and ISSO approved process must be created and followed to ensure the user requesting access is properly authenticated prior to access being re-established.

The process must include having the user provide information only the user would know and having the administrator verify the accuracy of the information prior to unlocking the account. This means having the user provide this information when their account is created so the information can be referenced when they are locked out.

The process utilized may be manual in nature, however it is recognized that password resets are a time consuming task. To minimize helpdesk resource constraints related to user lockout requests, procedures may be automated by administrators in order to unlock the account or reset the password.

Authentication process examples include having the user provide personal information known only by the user and provided when the account was created and/or using Out-of-Band or side channel communication methods such as text messages to the users established cell phone number in order to provide a temporary password or token that can be used to logon once and reset the password.

The OWASP site provides an acceptable password reset process that can be used as a reference. https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet.

Automated procedures should follow industry standards and best practice for securely automating password reset/account unlocks and must be reviewed, tested, and then approved by the ISSM and ISSO.

Interview the application administrator and identify the approved process for unlocking user accounts.

The process may involve a manual or automated reset after the locked out user has identified themselves using standard user identification processes outlined in the vulnerability discussion.

If the admin does not unlock the account following the approved process, and if the process does not have documented ISSO and ISSM approvals, this is a finding.

Create a standard approved process for unlocking locked application accounts which includes validating user identity prior to unlocking the account.

Use that process when unlocking application user accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002238 The information system automatically locks the account or node for either an organization-defined time period, until the locked account or node is released by an administrator, or delays the next login prompt according to the organization-defined delay algorithm when the maximum number of unsuccessful attempts is exceeded. NIST SP 800-53 Revision 4 :: AC-7 b

AC-7 b

Responsibility of the organization.

V-69357

medium

SRG-APP-000080

SV-83979r1_rule

APSC-DV-000590

The application must protect against an individual (or process acting on behalf of an individual) falsely denying having performed organization-defined actions to be covered by non-repudiation.

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).

DoD 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.

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 DoD.

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.

Configure the application to provide users with a non-repudiation function in the form of digital signatures when it is required by the organization or by the application design and architecture.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000166 The information system protects against an individual (or process acting on behalf of an individual) falsely denying having performed organization-defined actions to be covered by non-repudiation. NIST SP 800-53 :: AU-10 NIST SP 800-53A :: AU-10.1 NIST SP 800-53 Revision 4 :: AU-10

AU-10

No non-repudiation features

V-69359

medium

SRG-APP-000086

SV-83981r1_rule

APSC-DV-000600

For applications providing audit record aggregation, the application must compile audit records from organization-defined information system components into a system-wide audit trail that is time-correlated with an organization-defined level of tolerance for the relationship between time stamps of individual records in the audit trail.

Without the ability to collate records based on the time when the events occurred, the ability to perform forensic analysis and investigations across multiple components is significantly degraded.

Audit trails are time-correlated if the time stamps in the individual audit records can be reliably related to the time stamps in other audit records to achieve a time ordering of the records within organization-defined level of tolerance.

This requirement applies to applications which provide the capability to compile system-wide audit records for multiple systems or system components. However, all applications must provide the relevant log details that are used to aggregate the information.

Review the application documentation and interview the application administrator.

Determine if the application has the ability to compile audit records from multiple systems or system components.

If the application does not provide log aggregation services, this requirement is not applicable.

Identify the systems that comprise the application.

Access each system comprising the application or a random sample of several application systems. Review the application logs and obtain date and time stamps for several random audit events. Record the information.

Access the server providing the log aggregation. Access the application logs that have been written to the server and compare the samples obtained from the application systems to the aggregated logs. Ensure the dates and time stamps correlate with one another.

If the log dates and times do not correlate when the logs are aggregated, this is a finding.

Configure the application to correlate time stamps when aggregating audit records.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000174 The information system compiles audit records from organization-defined information system components into a system-wide (logical or physical) audit trail that is time-correlated to within organization-defined level of tolerance for relationship between time stamps of individual records in the audit trail. NIST SP 800-53 :: AU-12 (1) NIST SP 800-53A :: AU-12 (1).1 (iii&v) NIST SP 800-53 Revision 4 :: AU-12 (1)

AU-12 (1)

Prisma Cloud Compute Console collects audit information from the deployed Defenders. All audit log time stamps are based upon the component’s host systems clock and rendered in Coordinated Universal Time.

V-69361

medium

SRG-APP-000353

SV-83983r1_rule

APSC-DV-000610

The application must provide the capability for organization-identified individuals or roles to change the auditing to be performed on all application components, based on all selectable event criteria within organization-defined time thresholds.

If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost.

This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.

Review the application documentation and interview the application administrator to identify the auditing configuration capabilities of the application.

Access the audit management settings of the application as an authorized user and evaluate the verbosity capabilities of the log settings.

Determine if the settings are available to readily increase or decrease logging verbosity on demand for identified roles or individuals.

Review log files and identify what information is retained in the logs.

Increase logging verbosity to include additional application components or details in the logs. For example, if standard log settings do not include connection resets or process errors, add those settings to the log configuration and re-examine the logs to ensure the number of data points being logged has increased and includes those values.

Next decrease logging verbosity to the minimum data and re-examine the logs to ensure the log verbosity has changed.

If the application does not have the ability for specific roles or individuals to change the auditing verbosity performed on all application components, this is a finding.

Design the application to provide the capability for individuals or roles to change the auditing to be performed on all application components.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001914 The information system provides the capability for organization-defined individuals or roles to change the auditing to be performed on organization-defined information system components based on organization-defined selectable event criteria within organization-defined time thresholds. NIST SP 800-53 Revision 4 :: AU-12 (3)

AU-12 (3)

Audit configuration cannot be modified.

V-69363

medium

SRG-APP-000089

SV-83985r1_rule

APSC-DV-000620

The application must provide audit record generation capability for the creation of session IDs.

Applications create session IDs at the onset of a user session in order to manage user access to the application and differentiate between different user sessions. It is important to log the creation of these session ID creation events for forensic purposes.

It is equally important to not log the session ID itself. Logging the session ID puts active sessions at risk if log data is compromised. Specific session ID information should be removed, masked, sanitized, or encrypted.

A hash value of the session ID that can be mapped to the session ID is an acceptable method for assuring active session protection when logging session ID information. Alternatively, logging protections that protect the logs and defend from unauthorized access are means to assure log confidentiality and protect session integrity.

Web based applications will often utilize an application server that creates, manages and logs user session IDs. It is acceptable for the application to delegate this requirement to the application server.

Access the management interface for the application or configuration file and evaluate the log/audit management settings.

Determine if the setting that enables session ID creation event auditing is activated.

Create a new user session by logging in to the application.

Review the logs to ensure the session creation event was recorded.

If the application is not configured to log session ID creation events, or if no creation event was recorded, this is a finding.

If a web-based application delegates session ID creation to an application server, this is not a finding.

If the application generates session ID creation event logs by default, and that behavior cannot be disabled, this is not a finding.

Enable session ID creation event auditing.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

All user initiated events capture the user’s identifier within the audit logs.

V-69365

medium

SRG-APP-000089

SV-83987r1_rule

APSC-DV-000630

The application must provide audit record generation capability for the destruction of session IDs.

Applications should destroy session IDs at the end of a user session in order to terminate user access to the application session and to reduce the possibility of an unauthorized attacker high jacking the session and impersonating the user. It is important to log when session IDs are destroyed for forensic purposes.

Web based applications will often utilize an application server that creates, manages and logs session IDs. It is acceptable for the application to delegate this requirement to the application server.

Access the management interface for the application or configuration file and evaluate the log/audit management settings.

Determine if the setting that enables session ID destruction event auditing is activated.

Terminate a user session within the application and review the logs to ensure the session destruction event was recorded.

If the application is not configured to log session ID destruction events, or if the application has no means to enable auditing of session ID destruction events, this is a finding.

If a web-based application delegates session ID destruction to an application server, this is not a finding.

If the application generates audit logs by default when session IDs are destroyed, and that behavior cannot be disabled, this is not a finding.

Enable session ID destruction event auditing.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

User logout is audited with the user’s identifier.

V-69367

medium

SRG-APP-000089

SV-83989r1_rule

APSC-DV-000640

The application must provide audit record generation capability for the renewal of session IDs.

Application design sometimes requires the renewal of session IDs in order to continue approved user access to the application.

Session renewal is done on a case by case basis under circumstances defined by the application architecture. The following are some examples of when session renewal must be done; whenever there is a change in user privilege such as transitioning from a user to an admin role or when a user changes from an anonymous user to an authenticated user or when a user’s permissions have changed.

For these types of critical application functionalities, the previous session ID needs to be destroyed or otherwise invalidated and a new session ID must be created.

It is important to log when session IDs are renewed for forensic purposes.

Web based applications will often utilize an application server that creates, manages and logs session IDs. It is acceptable for the application to delegate this requirement to the application server.

Interview the system admin and review the application documentation.

Identify any web pages or application functionality where a user’s privileges or permissions will change. This is most likely to occur during the authentication stages.

Evaluate the log/audit output by opening the log files and observing changes to the logs.

Create a new user session by accessing the application.

Review the logs and save the relevant session creation event recorded.

Utilize the application pages that provide privilege escalation.

Escalate privileges by authenticating as a privileged user.

Review the logs and determine if new session information is created and being used.

If a web-based application delegates session ID renewals to an application server, this is not a finding.

If the application is not configured to log session ID renewal events this is a finding.

Design or reconfigure the application to log session renewal events on those application events that provide changes in the users privileges or permissions to the application.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

Session access is determined by the lifetime of the token. The token is automatically renewed when the time elapsed is greater than or equal to half the timeout value. Audit is not generated for this event.

V-69369

medium

SRG-APP-000089

SV-83991r1_rule

APSC-DV-000650

The application must not write sensitive data into the application logs.

It is important to identify and exclude certain types of data that is written into the logs. If the logs are compromised and sensitive data is included in the logs, this could assist an attacker in furthering their attack or it could completely compromise the system.

Examples of such data include but are not limited to; Passwords, Session IDs, Application source code, encryption keys, and sensitive data such as personal health information (PHI), Personally Identifiable Information (PII), or government identifiers (e.g., SSN).

Review the application logs and identify application logging format. Using the format of the log and the requisite search data as a guide to create your search, create search strings that could successfully identify the existence of passwords, session IDs, or other sensitive information such as SSN.

Utilizing the UNIX grep-based search utility include the following examples which are meant to illustrate the purpose of the requirement.

Password values are usually associated with usernames so searching for "username" in the provided log file will often assist in determining if password values are included.

grep -i "username" < logfile.txt

Search for social security numbers in the provided log file.

grep -i "[0-9]{3}[-]?[0-9]{2}[-]?[0-9]{4}" < logfile.txt

Use regular expressions to aid in searching log files. All search syntax cannot be provided within the STIG, the reviewer must utilize their knowledge to create new search criteria based upon the log format used and the potentially sensitive data processed by the application.

If the application logs sensitive data such as session IDs, application source code, encryption keys, or passwords, this is a finding.

Design or reconfigure the application to not write sensitive data to the logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

No sensitive data is captured in the audit logs.

V-69371

medium

SRG-APP-000089

SV-83993r2_rule

APSC-DV-000660

The application must provide audit record generation capability for session timeouts.

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.

DoD 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.

Review the application documentation and interview the application administrator to identify log locations for application session activity.

Open the log file that tracks user session activity.

Access the application as a regular user and identify the user session within the log files.

Identify the session timeout threshold defined by the application.

Perform no action within the application in order to allow the session to timeout.

Once the session timeout threshold has been exceeded, verify the session has been terminated due to the timeout event and review the logs again to ensure the session timeout event was recorded in the logs.

If a web-based application delegates session timeout auditing to an application server, this is not a finding.

If the session timeout event is not recorded in the logs, this is a finding.

Configure the application to record session timeout events in the logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

Session termination due to token lifetime expiration is an audited event.

V-69373

medium

SRG-APP-000089

SV-83995r1_rule

APSC-DV-000670

The application must record a time stamp indicating when the event occurred.

It is important to include the time stamps for when an event occurred. Failure to include time stamps in the event logs is detrimental to forensic analysis.

Review the application logs.

If the time the event occurred is not included as part of the event, this is a finding.

Configure the application to record the time the event occurred when recording the event.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

Time stamp of event is recorded within the event audit.

V-69375

medium

SRG-APP-000089

SV-83997r1_rule

APSC-DV-000680

The application must provide audit record generation capability for HTTP headers including User-Agent, Referer, GET, and POST.

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.

DoD 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.

Review the application documentation and interview the application administrator to identify log locations for application session activity.

Open the log file that tracks user session activity.

Access the application as a regular user and identify the user session within the log files.

Perform several actions within the application in order to generate HTTP header traffic.

Review the logs to ensure the HTTP header information is recorded in the logs. Header information logged will vary based upon the application and environment. Examples of headers include but are not limited to:

User-Agent: Referer: X-Forwarded-For: Date: Expires:

If HTTP headers are not logged, this is a finding.

Configure the web application and/or the web server to log HTTP headers.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

HTTP headers are audited in the Web-Application and API Security (WAAS) feature. HTTP headers are not captured in Console UI and API audit logs.

V-69377

medium

SRG-APP-000089

SV-83999r1_rule

APSC-DV-000690

The application must provide audit record generation capability for connecting system IP addresses.

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.

The IP addresses of remote systems that connect to the application are an important aspect of identifying the sources of application activity. Recording these IP addresses in the application logs provides forensic evidence and aids in investigating and identifying sources of malicious behavior related to security events.

Review the application documentation and interview the application administrator to identify where audit logs are stored.

Review audit logs and determine if the IP address information of systems that connect to the application is kept in the logs.

If connecting IP addresses are not seen in the logs, connect to the application remotely and review the logs to determine if the connection was logged.

If the IP addresses of the systems that connect to the application are not recorded in the logs, this is a finding.

Configure the application or application server to log all connecting IP address information

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

Connecting system’s IP address is captured in event audits.

V-69379

medium

SRG-APP-000089

SV-84001r1_rule

APSC-DV-000700

The application must record the username or user ID of the user associated with the event.

When users conduct activity within an application, that user’s identity must be recorded in the audit log. Failing to record the identity of the user responsible for the activity within the application is detrimental to forensic analysis.

Review and monitor the application logs.

Connect to the application and perform application activity that is allowed by the user such as accessing data or running reports.

Observe if the log includes an entry to indicate the user ID of the user that conducted the activity.

If the user ID is not recorded along with the event in the event log, this is a finding.

Configure the application to record the user ID of the user responsible for the log event entry.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000169 The information system provides audit record generation capability for the auditable events defined in AU-2 a at organization-defined information system components. NIST SP 800-53 :: AU-12 a NIST SP 800-53A :: AU-12.1 (ii) NIST SP 800-53 Revision 4 :: AU-12 a

AU-12 a

User’s identifier is captured in event audits.

V-69381

medium

SRG-APP-000091

SV-84003r2_rule

APSC-DV-000710

The application must generate audit records when successful/unsuccessful attempts to grant privileges occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

When a user is granted access or rights to application features and function not afforded to an ordinary user, they have been granted access to privilege and that action must be logged.

Review the application documentation and interview the application admin to identify application management interfaces and features.

Access the application management utility and create a test user account or use the account of a regular unprivileged user who is cooperating with the testing.

Access and open the auditing logs.

Using an account with the appropriate privileges, grant the user a privilege they previously did not have.

Attempt to grant privileges in a manner that will cause a failure event such as granting privileges to a non-existent user or attempting to grant privileges with an account that doesn’t have the rights to do so.

Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted.

If the application does not log when successful and unsuccessful attempts to grant privilege occur, this is a finding.

Configure the application to audit successful and unsuccessful attempts to grant privileges.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

User role assignment events are audited.

V-69383

medium

SRG-APP-000492

SV-84005r1_rule

APSC-DV-000720

The application must generate audit records when successful/unsuccessful attempts to access security objects occur.

Security objects represent application objects that provide or require security protections or have a security role within the application. Examples include but are not limited to, files, application modules, folders, and database records. Essentially, if permissions are assigned to protect it, it can be considered a security object. Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify application functionality that provides privilege or permission settings to security objects within the application. This can be an application function that assigns privileges to an application object or data element.

Authenticate to the application as a regular user. Using application functionality, attempt to access the security object within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure both the successful and unsuccessful access attempts are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to access security objects occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to access security objects.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Minimum role based access rules apply to Console’s UI and API. Successful and unsuccessful access attempts are audited.

V-69385

medium

SRG-APP-000493

SV-84007r1_rule

APSC-DV-000730

The application must generate audit records when successful/unsuccessful attempts to access security levels occur.

A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to access a security level can occur when a user attempts an action such as escalating their privilege from within the application itself. Attempts to access a security level can be construed as an attempt to change your user role from within the application.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator. Identify where the application logs are stored.

Identify application functionality that provides privilege escalation or access to additional security levels within the application.

This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access.

Authenticate to the application as a regular user. Using application functionality, attempt to access a different security level or domain within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure both the successful and unsuccessful access attempts are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to access security levels occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to access security levels.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Security level access is based upon role assignment. A user account can have only one role assignment. Access level enforcement is based upon the authenticated user’s role assignment.

V-69387

medium

SRG-APP-000494

SV-84009r1_rule

APSC-DV-000740

The application must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Categories of information is information that is identified as being sensitive or requiring additional protection from regular user access. The data is accessed on a need to know basis and has been assigned a category or a classification in order to assign protections and track access.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator. Identify where the application logs are stored.

Identify any data protections that are required.

Identify any categories of data or classification of data.

If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable.

Authenticate to the application as a regular user. Using application functionality, attempt to access data that has been assigned to a protected category.

Perform two access attempts, one successful and one unsuccessful.

Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you.

Review the log data and ensure both the successful and unsuccessful access attempts are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to access categories of information occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to access protected categories of information.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

No data classification within the Prisma Cloud Compute. Assumes the classification level of the environment that Prisma Cloud Compute is deployed within.

V-69389

medium

SRG-APP-000495

SV-84011r1_rule

APSC-DV-000750

The application must generate audit records when successful/unsuccessful attempts to modify privileges occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application admin to identify application management interfaces and features.

Access the application management utility and create a test user account or use the account of a regular privileged user who is cooperating with the testing.

Access and open the auditing logs.

Using an admin account, modify the privileges of a privileged user.

Attempt to modify privileges in a manner that will cause a failure event such as attempting to modify a user’s privileges with an account that doesn’t have the rights to do so.

Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted.

If the application does not log when successful and unsuccessful attempts to modify privileges occur, this is a finding.

Configure the application to audit successful and unsuccessful attempts to modify privileges.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Modification of a user’s role level is a function of the administrator role. Successful and unsuccessful changes to a user’s role are audited.

V-69391

medium

SRG-APP-000496

SV-84013r1_rule

APSC-DV-000760

The application must generate audit records when successful/unsuccessful attempts to modify security objects occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify application functionality that provides privilege or permission settings to security objects within the application. This can be an application function that assigns privileges to an application object or data element.

Authenticate to the application as a regular user. Using application functionality, attempt to modify the security object within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure the modification events both successful and unsuccessful are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to modify security objects occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to modify security objects.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

All changes to the system is based upon users role and are audited. Actual change (to, from) of the system’s configuration is audited.

V-69393

medium

SRG-APP-000497

SV-84015r1_rule

APSC-DV-000770

The application must generate audit records when successful/unsuccessful attempts to modify security levels occur.

A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to modify a security level can be construed as an attempt to change the configuration of the application so as to create a new security role or modify an existing security role. Some applications may or may not provide this capability.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify application functionality that provides privilege escalation or access to additional security levels within the application.

This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access.

Authenticate to the application as a regular user. Using application functionality, attempt to modify the permissions of a different security level or domain within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure the modify events, both successful and unsuccessful, are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to modify the permissions regarding the security levels occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to modify security levels.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

User role modifications both successful and unsuccessful are audited.

V-69395

medium

SRG-APP-000498

SV-84017r1_rule

APSC-DV-000780

The application must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify any data protections that are required.

Identify any categories of data or classification of data.

If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable.

Authenticate to the application as a regular user. Using application functionality, attempt to modify data that has been assigned to a protected category.

Perform two modification attempts, one successful and one unsuccessful.

Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you.

Review the log data and ensure both the successful and unsuccessful modification attempts are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to modify categories of information occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to modify protected categories of information.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

No data classification within the Prisma Cloud Compute. Assumes the classification level of the environment that Prisma Cloud Compute is deployed within.

V-69397

medium

SRG-APP-000499

SV-84019r1_rule

APSC-DV-000790

The application must generate audit records when successful/unsuccessful attempts to delete privileges occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application admin to identify application management interfaces and features.

Access the application management utility and create a test user account or use the account of a regular privileged user who is cooperating with the testing.

Access and open the auditing logs.

Using an admin account, delete some or all of the privileges of a privileged user.

Attempt to delete privileges in a manner that will cause a failure event such as attempting to delete a user’s privileges with an account that doesn’t have the rights to do so.

Review the application logs and ensure both events were captured in the logs. The event data should include the user’s identity and the privilege that was granted and the privilege that failed to be granted.

If the application does not log when successful and unsuccessful attempts to delete privileges occur, this is a finding.

Configure the application to audit successful and unsuccessful attempts to delete privileges.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Only the administrator role has the rights to perform user role changes. User role modifications both successful and unsuccessful are audited.

V-69399

medium

SRG-APP-000500

SV-84021r1_rule

APSC-DV-000800

The application must generate audit records when successful/unsuccessful attempts to delete security levels occur.

A security level denotes a permissions or authorization capability within the application. This is most often associated with a user role. Attempts to delete a security level can be construed as an attempt to change the configuration of the application so as to delete an existing security role. Some applications may or may not provide this capability.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify application functionality that provides privilege escalation or access to additional security levels within the application.

This can be performing a function that escalates the privileges of the user, or accessing a protected area of the application that requires additional authentication in order to access.

Authenticate to the application as a regular user. Using application functionality, attempt to delete permissions of a different security level or domain within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure the deletion events, both successful and unsuccessful are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to delete permissions regarding the security levels occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to delete security levels.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

User roles are not modifiable nor can be removed from Prisma Cloud Compute.

V-69401

medium

SRG-APP-000501

SV-84023r1_rule

APSC-DV-000810

The application must generate audit records when successful/unsuccessful attempts to delete application database security objects occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify application functionality that provides privilege or permission settings to database security objects within the application. This can be an application function that assigns privileges to an application object or data element.

Authenticate to the application as a regular user. Using application functionality, attempt to delete the database security object within the application.

Perform two attempts, one successfully and one unsuccessfully.

Review the log data and ensure the deletion events, both successful and unsuccessful, are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to delete database security objects occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to delete database security objects.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

User application functionality allows the Administrator and Operator roles to add, modify and delete policies and configuration settings. Only the administrative role has the rights to delete audit logs via the API only: https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/delete_audit_logs.html

V-69403

medium

SRG-APP-000502

SV-84025r1_rule

APSC-DV-000820

The application must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify where the application logs are stored.

Identify any data protections that are required.

Identify any categories of data or classification of data.

If the application requirements do not call for compartmentalized data and data protection, this requirement is not applicable.

Authenticate to the application as a regular user. Using application functionality, attempt to delete data that has been assigned to a protected category.

Perform two modification attempts, one successful and one unsuccessful.

Testing this will require obtaining access to test data that has been assigned to a protected category, or having an authorized user access the data for you.

Review the log data and ensure both the successful and unsuccessful deletion attempts are logged.

If the application does not generate an audit record when successful and unsuccessful attempts to delete categories of information occur, this is a finding.

Configure the application to create an audit record for both successful and unsuccessful attempts to delete protected categories of information.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Prisma Cloud Compute does not compartmentalize data.

V-69405

medium

SRG-APP-000503

SV-84027r1_rule

APSC-DV-000830

The application must generate audit records when successful/unsuccessful logon attempts occur.

Without generating audit records that are specific to the security and mission needs of the organization, 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 information system (e.g., module or policy filter).

Knowing when a user successfully or unsuccessfully logged on to the application is critical information that aids in forensic analysis.

Review and monitor the application logs.

Authenticate to the application and observe if the log includes an entry to indicate the user’s authentication was successful.

Terminate the user session by logging out.

Reauthenticate using invalid user credentials and observe if the log includes an entry to indicate the authentication was unsuccessful.

If successful and unsuccessful logon events are not recorded in the logs, this is a finding.

Configure the application or application server to write a log entry when successful and unsuccessful logon events occur.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Successful and unsuccessful logons are audited.

V-69407

medium

SRG-APP-000504

SV-84029r1_rule

APSC-DV-000840

The application must generate audit records for privileged activities or other system-level access.

Privileged activities include the tasks or actions taken by users in an administrative role (admin, backup operator, manager, etc.) which are used to manage or reconfigure application function. Examples include but are not limited to:

Modifying application logging verbosity, starting or stopping of application services, application user account management, managing application functionality, or otherwise changing the underlying application capabilities such as adding a new application module or plugin.

Privileged access does not include an application design which does not modify the application but does provide users with the functionality or the ability to manage their own user specific preferences or otherwise tailor the application to suit individual user needs based upon choices or selections built into the application.

Review and monitor the application logs.

Authenticate to the application as a privileged user and observe if the log includes an entry to indicate the user’s authentication was successful.

Perform actions as an admin or other privileged user such as modifying the logging verbosity, or starting or stopping an application service, or terminating a test user session.

If log events that correspond with the actions performed are not recorded in the logs, this is a finding.

Configure the application to write a log entry when privileged activities or other system-level events occur.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

All administrative user actions are audited.

V-69409

medium

SRG-APP-000505

SV-84031r1_rule

APSC-DV-000850

The application must generate audit records showing starting and ending time for user access to the system.

Knowing when a user’s application session began and when it ended is critical information that aids in forensic analysis.

Review and monitor the application logs.

Initiate a user session and observe if the log includes a time stamp showing the start of the session.

Terminate the user session and observe if the log includes a time stamp showing the end of the session.

If the start and the end time of the session are not recorded in the logs, this is a finding.

Configure the application or application server to record the start and end time of user session activity.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

User logon and explicit logout actions are audited. Expired sessions logouts are audited.

V-69411

medium

SRG-APP-000507

SV-84033r1_rule

APSC-DV-000860

The application must generate audit records when successful/unsuccessful accesses to objects occur.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Application objects are system or application components that comprise the application. This includes but is not limited to; application files, folders, processes and modules.

This requirement is not intended to force the use of debug logging which would be used for troubleshooting or forensic actions; rather it is intended to assure the application strikes a balance when auditing access to application objects and logs normal and potentially abnormal application activity.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator to identify log locations.

Access the application logs.

Review the logs and identify if the application is logging both successful and unsuccessful access to application objects such as files, folders, processes, or application modules and sub components, or systems.

If the application does not log application object access, this is a finding.

Configure the application to log successful and unsuccessful access to application objects.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Access to Prisma Cloud Compute’s underlying containers is not supported. Prisma Cloud Compute Runtime rules can alert and prevent access to the component’s underlying containers.

V-69413

medium

SRG-APP-000508

SV-84035r1_rule

APSC-DV-000870

The application must generate audit records for all direct access to the information system.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

When an application provides direct access to underlying OS features and functions, that access must be audited. Audit records can be generated from various components within the information system (e.g., module or policy filter).

Review the application documentation and interview the application administrator.

Identify if the application implements a direct access feature or function that allows users to directly access the underlying OS.

Direct access includes but is not limited to: executing OS commands, navigating the file system, manipulating system resources such as print queues, or reading files hosted on the OS that are not specifically shared or made available on the website.

If the application does not provide direct access to the system, this requirement is not applicable.

Access the application logs.

Access the application as a user or test user with appropriate permissions and attempt to execute application features and functions that provide direct access to the system.

Review the logs and ensure the actions executed were logged.

Log information must include the user responsible for executing the action, the action executed, and the result of the action.

If the application does not log all direct access to the system, this is a finding.

Configure the application to log all direct access to the system.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Access to Prisma Cloud Compute’s underlying containers is not supported. Prisma Cloud Compute Runtime rules can alert and prevent access to the component’s underlying containers. Shell access to the containers will generate a runtime event audit.

V-69415

medium

SRG-APP-000509

SV-84037r1_rule

APSC-DV-000880

The application must generate audit records for all account creations, modifications, disabling, and termination events.

When application user accounts are created, modified, disabled or terminated the event must be logged.

Centralized management of user accounts allows for rapid response to user related security events and also provides ease of management.

Allowing the centralized user management solution to log these events is acceptable practice; however, if the application provides a user management interface to manage these tasks, the application must also log these events.

Application developers are encouraged to integrate their applications with enterprise-level authentication/access/audit mechanisms such as Syslog, Active Directory or LDAP.

Log on to the application as an administrative user.

Navigate to the user account management functionality. If no user management capability exists within the application, refer to the Enterprise Active Directory or LDAP user management interfaces.

Monitor and review the log where the application’s user activity is recorded.

Create an application test account and then review the log to ensure a log record that documents the event is created.

Modify the test account and then review the log to ensure a log record that documents the event is created.

Disable the test account and then review the log to ensure a log record that documents the event is created.

Terminate/Remove the test account and then review the log to ensure a log record that documents the event is created.

If log events are not created that document all of these events, this is a finding.

If some, but not all of the aforementioned events are documented in the logs, this is a finding.

Findings should document which of the events was not logged.

Configure the application to log user account creation, modification, disabling, and termination events.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000172 The information system generates audit records for the events defined in AU-2 d with the content defined in AU-3. NIST SP 800-53 :: AU-12 c NIST SP 800-53A :: AU-12.1 (iv) NIST SP 800-53 Revision 4 :: AU-12 c

AU-12 c

Account creation, modification and deletion events are audited in the Console’s audit logs.

V-69419

medium

SRG-APP-000092

SV-84041r1_rule

APSC-DV-000910

The application must initiate session auditing upon startup.

If the application does not begin logging upon startup, important log events could be missed.

Examine the application design documentation and interview the application administrator to identify application logging behavior.

If the application is writing to an existing log or log file:

Open and monitor the application log.

Start the application service and view the log entries.

Log entries indicating the application is starting should commence as soon as the application starts. Determine if the log events correlate with the time the application was started and if event log entries include an application start up sequence of events.

If the application writes events to a new log on startup:

Identify location logs are written to, start the application and then identify and access the new log.

Determine if the log events correlate with the time the application was started and if event log entries include an application start up sequence of events.

If the application does not begin logging events upon start up, this is a finding.

Configure the application to begin logging application events as soon as the application starts up.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001464 The information system initiates session audits at system start-up. NIST SP 800-53 :: AU-14 (1) NIST SP 800-53A :: AU-14 (1).1 NIST SP 800-53 Revision 4 :: AU-14 (1)

AU-14 (1)

Event logging occurs at application start time.

V-69421

medium

SRG-APP-000095

SV-84043r1_rule

APSC-DV-000940

The application must log application shutdown events.

Forensics is a large part of security incident response. Applications must provide a record of their actions so application events can be investigated post-event.

Attackers may attempt to shut off the application logging capability to cover their activity while on the system. Recording the shutdown event and the time it occurred in the application or system logs helps to provide forensic evidence that aids in investigating the events.

Review and monitor the application and system logs.

If an application shutdown event is not recorded in the logs, either initiate a shutdown event and review the logs after reestablising access or request backup copies of the application or system logs that indicate shutdown events are being recorded.

Alternatively, check for a setting within the application that controls application logging events and determine if application shutdown logging is configured.

If the application is not recording application shutdown events in either the application or system log, or if the application is not configured to record shutdown events, this is a finding.

Configure the application or application server to record application shutdown events in the event logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000130 The information system generates audit records containing information that establishes what type of event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

Prisma Cloud Compute runs as containers. The termination of the container via the orchestration engine (e.g. kubernetes) will be logged within Prisma Cloud Compute’s application logs.

V-69423

medium

SRG-APP-000095

SV-84045r1_rule

APSC-DV-000950

The application must log destination IP addresses.

The IP addresses of the systems that the application connects to are an important aspect of identifying application network related activity. Recording the IP addresses of the system the application connects to in the application logs provides forensic evidence and aids in investigating and correlating the sources of malicious behavior related to security events. Logging this information can be particularly useful for Service-Oriented Applications where there is application to application connectivity.

If the application design documentation indicates the application does not initiate connections to remote systems this requirement is not applicable.

Network connections to systems used for support services such as DNS, AD, or LDAP may be stored in the system logs. These connections are applicable.

Identify log source based upon application architecture, design documents and input from application admin.

Review and monitor the application or system logs.

Connect to the application and utilize the application functionality that initiates connections to a destination system.

If the application routinely connects to remote system on a regular basis you may simply allow the application to operate in the background while the logs are observed.

Observe the log activity and determine if the log includes an entry to indicate the IP address of the destination system.

If the IP address of the remote system is not recorded along with the event in the event log, this is a finding.

Configure the application to record the destination IP address of the remote system.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000130 The information system generates audit records containing information that establishes what type of event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

Connections to external IP addresses are audited.

V-69425

medium

SRG-APP-000095

SV-84047r1_rule

APSC-DV-000960

The application must log user actions involving access to data.

When users access application data, there is risk of data compromise or seepage if the account used to access is compromised or access is granted improperly. To be able to investigate which account accessed data, the account access must be logged. Without establishing when the access event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Associating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.

Review and monitor the application logs. When accessing data, the logs are most likely database logs.

If the application design documents include specific data elements that require protection, ensure user access to those data elements are logged.

Utilize the application as a regular user and operate the application so as to access data elements contained within the application. This includes using the application user interface to browse through data elements, query/search data elements and using report generation capability if it exists.

Observe and determine if the application log includes an entry to indicate the user’s access to the data was recorded.

If successful access to application data elements is not recorded in the logs, this is a finding.

Identify the specific data elements requiring protection and audit access to the data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000130 The information system generates audit records containing information that establishes what type of event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

Data access is based upon user roles. The user’s API endpoint data request is logged. If the user does not have the appropriate role permission for the requested API endpoint data an “insufficient permission” error message is returned to the user.

V-69427

medium

SRG-APP-000095

SV-84049r1_rule

APSC-DV-000970

The application must log user actions involving changes to data.

When users change/modify application data, there is risk of data compromise if the account used to access is compromised or access is granted improperly. To be able to investigate which account accessed data, the account making the data changes must be logged. Without establishing when the data change event occurred, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Associating event types with detected events in the application and audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.

Review and monitor the application logs. When modifying data, the logs are most likely database logs.

If the application design documents include specific data elements that require protection, ensure any changes to those specific data elements are logged. Otherwise, a random check is sufficient.

If the application uses a database configured to use Transaction SQL logging this is not a finding if the application admin can demonstrate a process for reviewing the transaction log for data changes. The process must include using the transaction log and some form of query capability to identify users and the data they changed within the application and vice versa.

Utilize the application as a regular user and operate the application so as to modify a data element contained within the application.

Observe and determine if the application log includes an entry to indicate the users data change event was recorded.

If successful changes/modifications to application data elements are not recorded in the logs, this is a finding.

Configure the application to log all changes to application data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000130 The information system generates audit records containing information that establishes what type of event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

Policy and setting changes “from and to” states are recorded.

V-69429

medium

SRG-APP-000096

SV-84051r1_rule

APSC-DV-000980

The application must produce audit records containing information to establish when (date and time) the events occurred.

Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident.

In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).

Access the application logs and review the log entries for date and time. Each event written into the log must have a corresponding date and time stamp associated with it.

If the audit logs do not have a corresponding date and time associated with each event, this is a finding.

Configure the application or application server to include the date and the time of the event in the audit logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000131 The information system generates audit records containing information that establishes when an event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

All audited events are time stamped.

V-69431

medium

SRG-APP-000097

SV-84053r1_rule

APSC-DV-000990

The application must produce audit records containing enough information to establish which component, feature or function of the application triggered the audit event.

It is impossible to establish, correlate, and investigate the events relating to an incident if the details regarding the source of the event it not available.

In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know where within the application the events occurred, such as which application component, application modules, filenames, and functionality.

Associating information about where the event occurred within the application provides a means of quickly investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.

Review application administration and/or design documents.

Identify key aspects of application architecture objects and components, e.g., Web Server, Application server, Database server.

Interview the application administrator and identify the log locations.

Access the application logs and review the log entries for events that indicate the application is auditing the internal components, objects, or functions of the application.

Confirm the event logs provide information as to which component, feature, or functionality of the application triggered the event.

Examples of the types of events to look for are as follows:

- Application and Protocol events. e.g., Application loads or unloads and Protocol use. - Data Access events. e.g., Database connections.

Events could include reference to database library or executable initiating connectivity:

- Middleware events. e.g., Source code initiating calls or being invoked. - Name of application modules being loaded or unloaded. - Library loads and unloads. - Application deployment activity.

Events written into the log must be able to be traced back to the originating component, feature or function name, service name, application name, library name etcetera in order to establish which aspect of the application triggered the event.

If the audit logs do not contain enough data in the logs to establish which component, feature or functionality of the application triggered the event, this is a finding.

Configure the application to log which component, feature or functionality of the application triggered the event.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000132 The information system generates audit records containing information that establishes where the event occurred. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

All audits indicate the API endpoint used. All API endpoint reference library: https://cdn.twistlock.com/docs/api/twistlock_api.html

V-69433

medium

SRG-APP-000098

SV-84055r1_rule

APSC-DV-001000

When using centralized logging; the application must include a unique identifier in order to distinguish itself from other application logs.

Without establishing the source, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.

In the case of centralized logging, or other instances where log files are consolidated, there is risk that the application’s log data could be co-mingled with other log data. To address this issue, the application itself must be identified as well as the application host or client name.

In order to compile an accurate risk assessment, and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging.

Associating information about the source of the event within the application provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured application.

If the application is logging locally and does not utilize a centralized logging solution, this requirement is not applicable.

Review system documentation and identify log location. Access the application logs.

Review the application logs.

Ensure the application is uniquely identified either within the logs themselves or via log storage mechanisms.

Ensure the hosts or client names hosting the application are also identified. Either hostname or IP address is acceptable.

If the application name and the hosts or client names are not identified, this is a finding.

Configure the application logs or the centralized log storage facility so the application name and the hosts hosting the application are uniquely identified in the logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000133 The information system generates audit records containing information that establishes the source of the event. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

The hostname of the Console and Defender(s) will be included in the audit in compliance with RFC 5424

V-69435

medium

SRG-APP-000099

SV-84057r1_rule

APSC-DV-001010

The application must produce audit records that contain information to establish the outcome of the events.

Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system.

Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Successful application events are expected to far outnumber errors. Therefore, success events may be implied by default and not specified in the logs if this behavior is documented.

Review system and application documentation to identify application operation and function.

Access the application logs and review the logs to determine if the results of application operations are logged.

Successful application events are expected to far outnumber errors. Therefore, success events may be implied by default and not specified in the logs if this behavior is documented.

The outcome will be a log record that displays the application event/operation that occurred followed by the result of the operation such as "ERROR", "FAILURE", "SUCCESS" or "PASS".

Operation outcomes may also be indicated by numeric code where a "1" might indicate success and a "0" may indicate operation failure.

If the application does not produce audit records that contain information regarding the results of application operations, this is a finding.

Configure the application to include the outcome of application functions or events.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000134 The information system generates audit records containing information that establishes the outcome of the event. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

Outcome of actions are audited.

V-69437

medium

SRG-APP-000100

SV-84059r1_rule

APSC-DV-001020

The application must generate audit records containing information that establishes the identity of any individual or process associated with the event.

Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event.

Event identifiers (if authenticated or otherwise known) include, but are not limited to, user database tables, primary key values, user names, or process identifiers.

Review system documentation and discuss application operation with application administrator.

Identify application processes and application users. Identify application components, e.g., application features framework and function. Identify server components, such as web server, database server.

Review application logs. Ensure the application event logs include an identifier or identifiers that will allow an investigator to determine the user or the application process responsible for the application event.

If the event logs do not include the appropriate identifier or identifiers, this is a finding.

Configure the application to log the identity of the user and/or the process associated with the event.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001487 The information system generates audit records containing information that establishes the identity of any individuals or subjects associated with the event. NIST SP 800-53 :: AU-3 NIST SP 800-53A :: AU-3.1 NIST SP 800-53 Revision 4 :: AU-3

AU-3

If user information is available within the event it is captured in the audit.

V-69439

medium

SRG-APP-000101

SV-84061r1_rule

APSC-DV-001030

The application must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

Organizations consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. The additional information required is dependent on the type of information (i.e., sensitivity of the data and the environment within which it resides). At a minimum, the organization must audit either full-text recording of privileged commands or the individual identities of group users, or both. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

In addition, the application must have the capability to include organization-defined additional, more detailed information in the audit records for audit events.

Review application documentation and interview application administrator. Identify audit log locations and review audit logs.

Access the system as a privileged user and execute privileged commands.

Review the application logs and ensure that the logs contain all details of the actions performed.

If a privileged command was typed within the application that command text must be included in the logs. Authentication information provided as part of the text must NOT be logged, just the commands.

If an action was performed, such as activating a check box, that action must be logged.

Review group account users, review logs to determine if the individual users of group accounts are identified in the logs.

If the application does not log the full text recording of privileged commands or if the application does not identify and log the individuals associated with group accounts, this is a finding.

Configure the application to log the full text recording of privileged commands or the individual identities of group users.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000135 The information system generates audit records containing the organization-defined additional, more detailed information that is to be included in the audit records. NIST SP 800-53 :: AU-3 (1) NIST SP 800-53A :: AU-3 (1).1 (ii) NIST SP 800-53 Revision 4 :: AU-3 (1)

AU-3 (1)

Administrative audit are explained here: https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/audit_admin_activity.html

V-69441

medium

SRG-APP-000101

SV-84063r1_rule

APSC-DV-001040

The application must implement transaction recovery logs when transaction based.

Without required logging and access control, security issues related to data changes will not be identified. This could lead to security compromises such as data misuse, unauthorized changes, or unauthorized access.

Transaction logs contain a sequential record of all changes to the database. Using a transaction log helps with maintaining application availability and aids in speedy recovery. Transactional logging should be enabled whenever the application database offers the transactional logging capability.

Review the application documentation and interview the application administrator. Have the application administrator provide configuration settings that demonstrate transaction logging is enabled.

Review configuration settings for the location of transaction specific logs and verify transaction logs exist and the log records access and changes to the data.

If the application is not configured to utilize transaction logging, this is a finding.

Configure the application database to utilize transactional logging.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000135 The information system generates audit records containing the organization-defined additional, more detailed information that is to be included in the audit records. NIST SP 800-53 :: AU-3 (1) NIST SP 800-53A :: AU-3 (1).1 (ii) NIST SP 800-53 Revision 4 :: AU-3 (1)

AU-3 (1)

Database transaction logs are stored within the Console container’s /var/lib/twistlock/log/db.log

V-69443

medium

SRG-APP-000356

SV-84065r1_rule

APSC-DV-001050

The application must provide centralized management and configuration of the content to be captured in audit records generated by all application components.

Without the ability to centrally manage the content captured in the audit records, identification, troubleshooting, and correlation of suspicious behavior would be difficult and could lead to a delayed or incomplete analysis of an ongoing attack.

This requirement requires that the content captured in audit records be managed from a central location (necessitating automation). Centralized management of audit records and logs provides for efficiency in maintenance and management of records, as well as the backup and archiving of those records. Application components requiring centralized audit log management must have the capability to support centralized management.

This requirement applies to centralized management applications or similar types of applications designed to manage and configure audit record capture.

Review the application documentation and interview the application administrator to determine the logging architecture of the application.

If the application is configured to log application event entries to a centralized, enterprise based logging solution that meets this requirement, the requirement is not applicable.

Review the application components and the log management capabilities of the application.

Verify the application log management interface includes the ability to centrally manage the configuration of what is captured in the logs of all application components.

If the application does not provide the ability to centrally manage the content captured in the audit logs, this is a finding.

Configure the application to utilize a centralized log management system that provides the capability to configure the content of audit records.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001844 The information system provides centralized management and configuration of the content to be captured in audit records generated by organization-defined information system components. NIST SP 800-53 Revision 4 :: AU-3 (2)

AU-3 (2)

Prisma Cloud Compute Console is the centralized management for all audit collections

V-69445

medium

SRG-APP-000358

SV-84067r1_rule

APSC-DV-001070

The application must off-load audit records onto a different system or media than the system being audited.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. In addition, attackers often manipulate logs to hide or obfuscate their activity.

The goal is to off-load application logs to a separate server as quickly and efficiently as possible so as to mitigate these risks.

A centralized logging solution offering applications an enterprise designed and managed logging capability which is the desired solution.

However, when a centralized logging solution is not an option due to the operational environment or other situations where the risk has been officially recognized and accepted, off-loading is a common process utilized to address this type of scenario.

Review application documentation and interview application administrator. Identify log functionality and locations of log files. Obtain risk acceptance documentation and task scheduling information.

If the application is configured to utilize a centralized logging solution, this requirement is not applicable.

Evaluate log management processes and determine if there are automated tasks that move the logs off of the system hosting the application.

Verify automated tasks are performed on an ISSO approved schedule (hourly, daily etc.). Automation can be via scripting, log management oriented tools or other automated means.

Review risk acceptance documentation for not utilizing a centralized logging solution.

If the logs are not automatically moved off the system as per approved schedule, or if there is no formal risk acceptance documentation, this is a finding.

Configure the application to off-load audit records onto a different system as per approved schedule.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001851 The information system off-loads audit records per organization-defined frequency onto a different system or media than the system being audited. NIST SP 800-53 Revision 4 :: AU-4 (1)

AU-4 (1)

Audit events can be send to host nodes’ syslog that can be collected by a centralizing SIEM tool, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/logging.html

V-69447

medium

SRG-APP-000515

SV-84069r1_rule

APSC-DV-001080

The application must be configured to write application logs to a centralized log repository.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. In addition, attackers often manipulate logs to hide or obfuscate their activity.

Off-loading is a common process in information systems with limited audit storage capacity or when trying to assure log availability and integrity.

This requirement is meant to address space limitations and integrity issues that can be encountered when storing logs on the local server.

The goal of the requirement being to offload application logs to a separate server as quickly and efficiently as possible so as to mitigate these risks.

Review application documentation and interview application administrator.

Evaluate application log management processes and determine if the system is configured to utilize a centralized log management system for the hosting and management of application audit logs.

If the system is not configured to write the application logs to the centralized log management repository in an expeditious manner, this is a finding.

Configure the application to utilize a centralized log repository and ensure the logs are off-loaded from the application system as quickly as possible.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001851 The information system off-loads audit records per organization-defined frequency onto a different system or media than the system being audited. NIST SP 800-53 Revision 4 :: AU-4 (1)

AU-4 (1)

Application logs can be collected by a centralizing SIEM tool, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/logging.html

V-69449

medium

SRG-APP-000359

SV-84071r1_rule

APSC-DV-001090

The application must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of repository maximum audit record storage capacity.

If security personnel are not notified immediately upon storage volume utilization reaching 75%, they are unable to plan for storage capacity expansion.

Due to variances in application usage and audit records storage usage, the SA and the ISSO may evaluate usage patterns and determine if a higher percentage of usage is warranted before an alarm is sent. The intent of the requirement is to provide a warning that will allow the SA and ISSO ample time to plan and implement an audit storage capacity expansion that will provide for the increased audit log storage requirements without forcing an emergency or otherwise negatively impacting the recording of audit events.

The requirement will take into account a reasonable amount of processing time such as 1 or 2 minutes that may be required of the system in order to satisfy the requirement.

Review system documentation and interview application administrator for details regarding logging configuration.

If the application utilizes a centralized logging system that provides storage capacity alarming, this requirement is not applicable.

Identify application alarming capability relating to storage capacity alarming for the log repository. Coordinate with the appropriate personnel regarding the generation of test alarms.

Review log alarm settings and ensure audit log storage capacity alarming is enabled and set to alarm when the storage threshold exceeds 75% of disk storage capacity or the capacity value the SA and ISSO have determined will provide adequate time to plan for capacity expansion.

Ensure the alarm will be sent to the ISSO and the application administrator when the utilization threshold is exceeded by changing the threshold settings to below the current disk space utilization. An alarm should be triggered at that point and forwarded to the ISSO and the SA/application admin.

If the application is not configured to send an alarm when storage volume exceeds 75% of disc capacity or if the designated alarm recipients did not receive an alarm when the test was conducted, this is a finding.

Configure the application to send an immediate alarm to the application admin/SA and the ISSO when the allocated log storage capacity exceeds 75% of usage or exceeds the capacity value the SA and ISSO have determined will provide adequate time to plan for capacity expansion.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001855 The information system provides a warning to organization-defined personnel, roles, and/or locations within organization-defined time period when allocated audit record storage volume reaches organization-defined percentage of repository maximum audit record storage capacity. NIST SP 800-53 Revision 4 :: AU-5 (1)

AU-5 (1)

Audit log rotation is implemented, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/log_rotation.html

V-69451

medium

SRG-APP-000360

SV-84073r1_rule

APSC-DV-001100

Applications categorized as having a moderate or high impact must provide an immediate real-time alert to the SA and ISSO (at a minimum) for all audit failure events.

Applications that are categorized as having a high or moderate impact on the organization must provide immediate alerts when encountering failures with the application audit system. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

While alerts provide organizations with urgent messages containing important information regarding application audit log activity, real-time alerts provide these messages at information technology speed (i.e., the time from event detection to alert occurs in seconds or no more than 1-2 minutes).

Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.

Review system documentation and interview application administrator for details regarding application security categorization and logging configuration.

If the application utilizes a centralized logging system that provides the real-time alarms, this requirement is not applicable.

Review application log alert configuration.

Identify audit failure events and associated alarming configuration.

If the application is categorized as having a moderate or high impact and is not configured to provide a real-time alert that indicates the audit system has failed or is failing, this is a finding.

Configure the log alerts to send an alarm when the audit system is in danger of failing or has failed.

Configure the log alerts to be immediately sent to the application admin/SA and ISSO.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001858 The information system provides a real-time alert in organization-defined real-time period to organization-defined personnel, roles, and/or locations when organization-defined audit failure events requiring real-time alerts occur. NIST SP 800-53 Revision 4 :: AU-5 (2)

AU-5 (2)

Incidents can be alerted upon in real time, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/runtime_defense/incident_explorer.html

V-69453

medium

SRG-APP-000108

SV-84075r1_rule

APSC-DV-001110

The application must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Review system documentation and interview application administrator for details regarding logging configuration.

If the application utilizes a centralized logging system that provides the audit processing failure alarms, this requirement is not applicable.

Identify application alarming capability regarding audit processing failure events.

Verify the application is configured to alarm when the auditing system fails.

Example alarm events include but are not limited to:

hardware failure events failures to capture audit record events audit storage errors

If the application is not configured to alarm on alerts that indicate the audit system has failed or is failing, this is a finding.

Configure the application to send an alarm in the event the audit system has failed or is failing.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000139 The information system alerts designated organization-defined personnel or roles in the event of an audit processing failure. NIST SP 800-53 :: AU-5 a NIST SP 800-53A :: AU-5.1 (ii) NIST SP 800-53 Revision 4 :: AU-5 a

AU-5 a

Not available

V-69455

medium

SRG-APP-000109

SV-84077r1_rule

APSC-DV-001120

The application must shut down by default upon audit failure (unless availability is an overriding concern).

It is critical that when the application is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

When availability is an overriding concern, other approved actions in response to an audit failure are as follows:

(i) If the failure was caused by the lack of audit record storage capacity, the application must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.

(ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the application must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Review system documentation and interview application administrator for details regarding logging configuration.

Identify application shut down capability regarding audit processing failure events. Locate and verify application logging settings that specify the application will halt processing on detected audit failure.

If ISSO approval to continue operating and not shut down the application upon an audit failure exists and is documented, validate the application is configured as follows:

If logging locally and the failure is attributed to a lack of disk space:

Ensure the application is configured to overwrite the oldest logs first so as to maintain the most up to date audit events in the event of an audit failure.

When logging centrally:

Ensure the application is configured to locally spool/queue audit events in the event an audit failure is detected with the centralized system.

If the application does not shut down processing when an audit failure is detected, or if the application does not take steps needed to ensure audit events are not lost due to audit failure, this is a finding.

Configure the application to cease processing if the audit system fails or configure the application to continue logging in a manner that compensates for the audit failure.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000140 The information system takes organization-defined actions upon audit failure (e.g., shut down information system, overwrite oldest audit records, stop generating audit records). NIST SP 800-53 :: AU-5 b NIST SP 800-53A :: AU-5.1 (iv) NIST SP 800-53 Revision 4 :: AU-5 b

AU-5 b

Not available

V-69457

medium

SRG-APP-000111

SV-84079r1_rule

APSC-DV-001130

The application must provide the capability to centrally review and analyze audit records from multiple components within the system.

Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. If the application does not provide the ability to centrally review the application logs, forensic analysis is negatively impacted.

Segregation of logging data to multiple disparate computer systems is counterproductive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system or application has multiple logging components written to different locations or systems.

Automated mechanisms for centralized reviews and analyses include, for example, Security Information Management products.

Review system documentation and interview application administrator for details regarding application architecture and logging configuration. Identify the application components, the logs that are associated with the components and the locations of the logs.

If the application utilizes a centralized logging system that provides the capability to review the log files from one central location, this requirement is not applicable.

Access the application’s log management utility and review the log files. Ensure all of the applications logs are reviewable from within the centralized log management function and access to other systems in order to review application logs are not required.

If all of the application logs are not reviewable from a central location, this is a finding.

Configure the application so all of the applications logs are available for review from one centralized location.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000154 The information system provides the capability to centrally review and analyze audit records from multiple components within the system. NIST SP 800-53 :: AU-6 (4) NIST SP 800-53A :: AU-6 (4).1 NIST SP 800-53 Revision 4 :: AU-6 (4)

AU-6 (4)

Audit logs from deployed Defenders can be viewed within the Console

V-69459

medium

SRG-APP-000115

SV-84081r1_rule

APSC-DV-001140

The application must provide the capability to filter audit records for events of interest based upon organization-defined criteria.

The ability to specify the event criteria that are of interest provides the persons reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded.

Events of interest can be identified by the content of specific audit record fields including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. This requires applications to provide the capability to customize audit record reports based on organization-defined criteria.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components as well as the locations of the logs.

If the application utilizes a centralized logging system that provides the capability to filter log events based upon the following events, this requirement is not applicable.

Review the application log management utility.

Ensure the application provides the ability to filter on audit events based upon the following minimum criteria:

Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error Key words: e.g., a specific search string

Additional details may be logged as needed or prescribed by operational requirements.

If the application does not provide the ability to filter audit events, this is a finding.

Configure the application filters to search event logs based on defined criteria.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000158 The information system provides the capability to process audit records for events of interest based on organization-defined audit fields within audit records. NIST SP 800-53 :: AU-7 (1) NIST SP 800-53A :: AU-7 (1).1 NIST SP 800-53 Revision 4 :: AU-7 (1)

AU-7 (1)

Audit log viewer has search capability

V-69461

medium

SRG-APP-000181

SV-84083r1_rule

APSC-DV-001150

The application must provide an audit reduction capability that supports on-demand reporting requirements.

The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization’s ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad-hoc, and as-needed) reports.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

If the application utilizes a centralized logging system that provides the capability to generate reports based on filtered log events, this requirement is not applicable.

Using the relevant application features for generating reports and/or searching application data, (this is usually executed directly within a logging utility or within a reports feature or function) configure a filter based on any of the security criteria provided below.

Alternatively, you can use security-oriented criteria provided by the application administrator.

Once the data filter has been selected, filter the audit event data so only filtered data is displayed and generate the report.

The report can be any combination of screen-based, soft copy, or a printed report.

Criteria: Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error

If the application does not provide on demand reports based on the filtered audit event data, this is a finding.

Configure the application to generate soft copy, hard copy and/or screen-based reports based on the selected filtered event data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001876 The information system provides an audit reduction capability that supports on-demand reporting requirements. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Alerts can be configured to notify specific groups of specific events, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/alerts.html

V-69463

medium

SRG-APP-000364

SV-84085r1_rule

APSC-DV-001160

The application must provide an audit reduction capability that supports on-demand audit review and analysis.

The ability to perform on-demand audit review and analysis, including after the audit data has been subjected to audit reduction, greatly facilitates the organization’s ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

Audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Audit reduction does not alter original audit records. The report generation capability provided by the application must support on-demand (i.e., customizable, ad-hoc, and as-needed) reports.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

If the application utilizes a centralized logging system that provides the capability to generate reports based on filtered log events, this requirement is not applicable.

Using the relevant application features for generating reports and/or searching application data, (this is usually executed directly within a logging utility or within a reports feature or function) configure a filter based on any of the security criteria provided below.

Alternatively, you can use security-oriented criteria provided by the application administrator.

Once the data filter has been selected, filter the audit event data so only filtered data is displayed and generate the report.

The report can be any combination of screen-based, soft copy, or a printed report.

Criteria: Users: e.g., specific users or groups Event types: Event dates and time: System resources involved: e.g., application components or modules. IP addresses: Information objects accessed: Event level categories: e.g., high, critical, warning, error

If the application does not provide an audit reduction capability that supports on-demand reports based on the filtered audit event data, this is a finding.

Configure the application to log to a centralized auditing capability that provides on-demand reports based on the filtered audit event data or design or configure the application to meet the requirement.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001875 The information system provides an audit reduction capability that supports on-demand audit review and analysis. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Audit log viewer has search capability

V-69465

medium

SRG-APP-000365

SV-84087r1_rule

APSC-DV-001170

The application must provide an audit reduction capability that supports after-the-fact investigations of security incidents.

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 DoD 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.

Review application documentation and interview application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering).

If the application uses a centralized logging solution that performs the audit reduction (event filtering) functions, the requirement is not applicable.

Examine the log files; take note of dates and times of events such as logon events.

Note: dates and times as well as the original content and any unique record identifiers.

Record the identifying information as well as the dates and times and content of the audit records.

Apply filters to reduce the amount of audit records displayed to just the logon events for the day.

Review the records and ensure the application provides the ability to filter on audit events.

If the application does not provide an audit reduction (event filtering) capability, this is a finding.

Configure the application to provide an audit reduction capability that supports forensic investigations.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001877 The information system provides an audit reduction capability that supports after-the-fact investigations of security incidents. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Forensic reporting exportation, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/runtime_defense/incident_explorer.html

V-69467

medium

SRG-APP-000366

SV-84089r1_rule

APSC-DV-001180

The application must provide a report generation capability that supports on-demand audit review and analysis.

The report generation capability must support on-demand review and analysis in order to facilitate the organization’s ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

Report generation must be capable of generating on-demand (i.e., customizable, ad-hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective.

Audit reduction and report generation capabilities do not always reside on the same information system or within the same organizational entities conducting auditing activities. The audit reduction capability can include, for example, modern data mining techniques with advanced data filters to identify anomalous behavior in audit records. The report generation capability provided by the information system can generate customizable reports. Time ordering of audit records can be a significant issue if the granularity of the time stamp in the record is insufficient.

This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand audit review and analysis.

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reporting.

If the application uses a centralized logging solution that provides immediate, customizable audit review and analysis functions, the requirement is not applicable.

Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged.

Review the report and ensure the data in the report coincides with event filters used to create the report.

If the application does not provide an immediate, ad-hoc audit review and analysis capability, this is a finding.

Design or configure the application to provide an immediate audit review capability or utilize a centralized utility designed for the purpose of on-demand log management and reporting.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001878 The information system provides a report generation capability that supports on-demand audit review and analysis. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Logs can be exported/downloaded at any time

V-69469

medium

SRG-APP-000367

SV-84091r1_rule

APSC-DV-001190

The application must provide a report generation capability that supports on-demand reporting requirements.

The report generation capability must support on-demand reporting in order to facilitate the organization’s ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

The report generation capability provided by the application must be capable of generating on-demand (i.e., customizable, ad-hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective.

This requirement is specific to applications with report generation capabilities; however, applications need to support on-demand reporting requirements.

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering).

If the application uses a centralized logging solution that provides immediate, customizable, ad-hoc report generation functions, the requirement is not applicable.

Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged.

Review the report and ensure the data in the report coincides with event filters used to create the report.

If the application does not provide customizable, immediate, ad-hoc audit log reporting, this is a finding.

Design or configure the application to provide an on-demand report generation capability or utilize a centralized utility designed for the purpose of on-demand log management and reporting.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001879 The information system provides a report generation capability that supports on-demand reporting requirements. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Log download and Forensic event downloads can be programmatically obtained via the API

V-69471

medium

SRG-APP-000368

SV-84093r1_rule

APSC-DV-001200

The application must provide a report generation capability that supports after-the-fact investigations of security incidents.

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 DoD 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.

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering).

If the application uses a centralized logging solution that performs the report generation functions, the requirement is not applicable.

Create an event report. Report data can be based on date ranges, times or events, or other criteria that could be used in an investigation. Use of data from previous checks for audit reduction is encouraged.

Review the report and ensure the data in the report coincides with event filters used to create the report.

If the application does not have a report generation capability that supports after the fact security investigations, this is a finding.

Design or configure the application to provide after-the-fact report generation capability or utilize a centralized utility designed for the purpose of log management and reporting.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001880 The information system provides a report generation capability that supports after-the-fact investigations of security incidents. NIST SP 800-53 Revision 4 :: AU-7 a

AU-7 a

Forensic reporting exportation, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/runtime_defense/incident_explorer.html

V-69473

medium

SRG-APP-000369

SV-84095r1_rule

APSC-DV-001210

The application must provide an audit reduction capability that does not alter original content or time ordering of audit records.

If the audit reduction capability alters the content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this.

Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering).

If the application uses a centralized logging solution that performs the audit reduction (event filtering) functions, the requirement is not applicable.

Examine the log files; take note of dates and times of events such as logon events.

Note: dates and times as well as the original content and any unique record identifiers.

Record the identifying information as well as the dates and times and content of the audit records.

Apply filters to reduce the amount of audit records displayed to just the logon events for the day.

Review the records and ensure nothing in the records has changed. Once validated, clear the filter and review the records again to validate nothing changed within the audit record itself.

If the application of event filters modifies the original log records, this is a finding.

Configure the application to not alter original log content or time ordering of audit records.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001881 The information system provides an audit reduction capability that does not alter original content or time ordering of audit records. NIST SP 800-53 Revision 4 :: AU-7 b

AU-7 b

Audit log reduction is not a supported capability.

V-69475

medium

SRG-APP-000370

SV-84097r1_rule

APSC-DV-001220

The application must provide a report generation capability that does not alter original content or time ordering of audit records.

If the audit report generation capability alters the original content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this.

The report generation capability provided by the application can generate customizable reports.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Review the application documentation and interview the application administrator for details regarding audit reduction (log record event filtering).

Access the application with user rights sufficient to read and filter audit records.

Navigate the application user interface and select the application functionality that provides access and interface to audit records and audit reduction (event filtering).

If the application does not provide a report generation capability, the requirement is not applicable.

Examine the log files; take note of dates and times of events such as logon events.

Note: dates and times as well as the original content and any unique record identifiers.

Record the identifying information as well as the dates and times and content of the audit records.

Apply filters to reduce the amount of audit records displayed to just the logon events for the day.

Review the records and ensure nothing in the records has changed. Once validated, clear the filter and review the records again to validate nothing changed within the audit record itself.

If the application of event filters modifies the original log records, this is a finding.

Configure and design the application to not modify source logs when filtering events.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001882 The information system provides a report generation capability that does not alter original content or time ordering of audit records. NIST SP 800-53 Revision 4 :: AU-7 b

AU-7 b

Audit log search and download capabilities do not alter audit logs.

V-69477

medium

SRG-APP-000116

SV-84099r1_rule

APSC-DV-001250

The applications must use internal system clocks to generate time stamps for audit records.

Without an internal clock used as the reference for the time stored on each event to provide a trusted common reference for the time, forensic analysis would be impeded. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events.

If the internal clock is not used, the system may not be able to provide time stamps for log messages. Additionally, externally generated time stamps may not be accurate. Applications can use the capability of an operating system or purpose-built module for this purpose.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

Ensure the time written into the logs coincides with the OS timeclock.

Access random audit records and review the most recent logs.

Access the system OS hosting the application and use the related OS commands to determine the time of the system.

Perform an action in the application that causes a log event to be written and review the log to ensure the system times and the application log times correlate; compensating for any time delays that may have occurred between running the OS time command and running the application action.

If the application doesn’t use the internal system clocks to generate time stamps for the audit event logs, this is a finding.

Configure the application to use the hosting systems internal clock for audit record generation.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000159 The information system uses internal system clocks to generate time stamps for audit records. NIST SP 800-53 :: AU-8 NIST SP 800-53A :: AU-8.1 NIST SP 800-53 Revision 4 :: AU-8 a

AU-8 a

Prisma Cloud Compute audit log time stamps are based upon host system’s clock.

V-69479

medium

SRG-APP-000374

SV-84101r1_rule

APSC-DV-001260

The application must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).

If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.

Time stamps generated by the application include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

If the application utilizes the underlying OS system clock, and the system clock is mapped to UTC or GMT, this is not a finding.

Identify where clock settings are configured within the application.

Access the configuration settings and determine if the application is configured to set the time stamps for audit records according to UTC or GMT (e.g., East coast standard time is represented as GMT -5, east coast daylight savings time is represented as GMT-4).

If the application is not configured to map to UTC or GMT, this is a finding.

Configure the application to use the underlying system clock that maps to relevant UTC or GMT timezone.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001890 The information system records time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). NIST SP 800-53 Revision 4 :: AU-8 b

AU-8 b

Audit log time stamps are in Coordinated Universal Time (UTC)

V-69481

medium

SRG-APP-000375

SV-84103r1_rule

APSC-DV-001270

The application must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.

Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records.

Time stamps generated by the application include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.

Review the system documentation and interview the application administrator to determine where application audit logs are written and how time stamps are recorded.

If the application utilizes the underlying OS for time stamping and time synchronization when writing the audit logs, this requirement is not applicable.

Access and review log files over a period of at least 10 minutes; compare time stamps written in the application log to the system clock to ensure time is synchronized to within 1 second of precision.

If the application audit log time stamps differ from the OS time source by more than one second, this is a finding.

Configure the application to leverage the underlying operating system as the time source when recording time stamps or design the application to ensure granularity of 1 second as the minimum degree of precision.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001889 The information system records time stamps for audit records that meets organization-defined granularity of time measurement. NIST SP 800-53 Revision 4 :: AU-8 b

AU-8 b

Audit log time stamp precision is to milliseconds

V-69483

medium

SRG-APP-000118

SV-84105r1_rule

APSC-DV-001280

The application must protect audit information from any type of unauthorized read access.

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access.

This requirement can be achieved through multiple methods which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories.

Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

Identify the roles and users allowed to access audit information and the circumstances in which they are allowed to read or otherwise access the data.

Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof.

For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

Permissions must be configured to limit access to only those who have been identified and whose access has been approved.

If file permissions are configured to allow unapproved access, this is a finding.

For application-oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account.

If a non-privileged user account is allowed to access the audit data or the audit configuration settings, this is a finding.

Configure the application to protect audit data from unauthorized access. Limit users to roles that are assigned the rights to view, edit or copy audit data, and establish permissions that control access to the audit logs and audit configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000162 The information system protects audit information from unauthorized access. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

Audit logs are stored within the Prisma Cloud Compute Console and Defenders’ containers root only access /var/lib/twistlock/log folder

V-69485

medium

SRG-APP-000119

SV-84107r1_rule

APSC-DV-001290

The application must protect audit information from unauthorized modification.

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.

This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions, and limiting log data locations.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

Identify the roles and users allowed to modify audit information and the circumstances in which they are allowed to modify the data.

Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof.

For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

Permissions must be configured to limit write/modify access to only those who have been identified and whose access has been approved.

If file permissions are configured to allow unapproved write/modify access, this is a finding.

For application oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. Once access has been established, attempt to modify an audit record and attempt to modify the audit settings.

If a non-privileged user account is allowed to modify the audit data or the audit configuration settings, this is a finding.

Configure the application to protect audit data from unauthorized modification and changes. Limit users to roles that are assigned the rights to edit audit data and establish permissions that control access to the audit logs and audit configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000163 The information system protects audit information from unauthorized modification. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

Audit logs are stored within the Prisma Cloud Compute Console and Defenders’ containers root only access /var/lib/twistlock/log folder. Audit logs can be deleted only by the administrator role.

V-69487

medium

SRG-APP-000120

SV-84109r1_rule

APSC-DV-001300

The application must protect audit information from unauthorized deletion.

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.

Some commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.

Review the system documentation and interview the application administrator for details regarding application architecture and logging configuration.

Identify the application components and the logs associated with the components.

Identify the roles and users allowed to delete audit information and the circumstances in which they are allowed to delete the data.

Identify the methods used to manage audit records and audit components. Typical methods are file system-based, via an application user interface via database access or a combination thereof.

For file system access: Review file system permissions to ensure the audit logs and the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

Permissions must be configured to limit deletions to only those who have been identified and whose rights to delete audit data and audit configurations has been approved.

If file permissions are configured to allow unapproved deletions of audit settings and data, this is a finding.

For application oriented and database access: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account. Once access has been established, attempt to delete a test audit record and attempt to delete a test audit settings.

If a non-privileged user account is allowed to delete the audit data or the audit configuration settings, this is a finding.

Configure the application to protect audit data from unauthorized deletion. Limit users to roles that are assigned the rights to delete audit data and establish permissions that control access to the audit logs and audit configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000164 The information system protects audit information from unauthorized deletion. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

Audit logs can be deleted only by the administrator role.

V-69489

medium

SRG-APP-000121

SV-84111r1_rule

APSC-DV-001310

The application must protect audit tools from unauthorized access.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and audit tools.

Identify the application audit tools and their locations.

If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable.

Identify the methods used for implementing the audit tool functionality within the application. Typical methods are file system-based, e.g., a separate executable file that when invoked provides audit functionality, an application user interface to an audit module, or a combination thereof.

For file system access: Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

Permissions must be configured to limit access to only those who have been identified and whose access has been approved.

If file permissions are configured to allow unapproved access, this is a finding.

For circumstances where audit tools are accessed via application sub-modules or menus: Identify the application module that provides access to audit settings and audit data. Attempt to access audit configuration features and logs by using a regular non-privileged application or database user account.

If a non-privileged user account is allowed to access the audit data or the audit configuration settings, this is a finding.

Configure the application to protect audit data from unauthorized access. Limit users to roles that are assigned the rights to view, edit or copy audit data, and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001493 The information system protects audit tools from unauthorized access. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

To view audit logs the user must have access to the Prisma Cloud Compute Console and have the role of Auditor or higher, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/authentication/user_roles.html

V-69491

medium

SRG-APP-000122

SV-84113r1_rule

APSC-DV-001320

The application must protect audit tools from unauthorized modification.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools.

Identify the application audit tools and their locations.

If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable.

Identify the methods used for implementing an audit tool functionality that is separate from the application. Typical methods are file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs.

Identify the users with the rights to modify the audit tools. This capability will usually be reserved for admin staff.

Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

File permissions must be configured to limit access to only those users who have been identified and whose access has been approved.

If file permissions are configured so as to allow unapproved modifications to the audit tools, this is a finding.

Configure the application to protect audit tools from unauthorized modifications. Limit users to roles that are assigned the rights to edit or update audit tools and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001494 The information system protects audit tools from unauthorized modification. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

To view audit logs the user must have access to the Prisma Cloud Compute Console and have the role of Auditor or higher, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/authentication/user_roles.html

V-69493

medium

SRG-APP-000123

SV-84115r1_rule

APSC-DV-001330

The application must protect audit tools from unauthorized deletion.

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods and provided audit tools.

Identify the application audit tools and their locations.

If the application does not provide a distinct audit tool oriented functionality that is a separate tool with an ability to view and manipulate log data, this requirement is not applicable.

Identify the methods used for implementing an audit tool functionality that is separate from the application. Typical methods are file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs.

Identify the users with the rights to delete the audit tools. This capability is normally reserved for admin staff.

Review file system permissions to ensure the application audit components such as executable files and libraries are protected by adequate file permission restrictions.

File permissions must be configured to limit access to only those users who have been identified and whose access has been approved.

If file permissions are configured to allow unapproved deletions of the audit tools, this is a finding.

Configure the application to protect audit tools from unauthorized deletions. Limit users to roles that are assigned the rights to edit or delete audit tools and establish file permissions that control access to the audit tools and audit tool capabilities and configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001495 The information system protects audit tools from unauthorized deletion. NIST SP 800-53 :: AU-9 NIST SP 800-53A :: AU-9.1 NIST SP 800-53 Revision 4 :: AU-9

AU-9

Deletion of an audit log is only available via the API and must be performed by an administrator, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/audit/delete_audit_logs.html

V-69495

medium

SRG-APP-000125

SV-84117r1_rule

APSC-DV-001340

The application must back up audit records at least every seven days onto a different system or system component than the system or component being audited.

Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on an organizationally defined frequency helps to assure in the event of a catastrophic system failure, the audit records will be retained.

This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.

This requirement only applies to applications that have a native backup capability for audit records. Operating system backup requirements cover applications that do not provide native backup functions.

Review the application documentation and interview the application administrator.

Identify log functionality and locations of log files.

If the application does not include a built-in backup capability for backing up its own audit records, this requirement is not applicable.

Access the management interface for configuring application audit logs and review the backup settings.

If the application backup settings are not configured to backup application audit records every 7 days, this is a finding.

Configure application backup settings to backup application audit logs every 7 days.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001348 The information system backs up audit records on an organization-defined frequency onto a different system or system component than the system or component being audited. NIST SP 800-53 :: AU-9 (2) NIST SP 800-53A :: AU-9 (2).1 (iii) NIST SP 800-53 Revision 4 :: AU-9 (2)

AU-9 (2)

Weekly system backups are automatically performed. Audit logs can be downloaded on demand.

V-69497

medium

SRG-APP-000126

SV-84119r1_rule

APSC-DV-001350

The application must use cryptographic mechanisms to protect the integrity of audit information.

Audit records may be tampered with; if the integrity of audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve.

Protection of audit records and audit data is of critical importance. Cryptographic mechanisms are the industry established standard used to protect the integrity of audit data. An example of a cryptographic mechanism is the computation and application of a cryptographic-signed hash using asymmetric cryptography.

This requirement applies to applications that generate, process or manage audit records and is applied once audit processing has completed and the audit record is being stored.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools.

Identify the location of the application audit information.

If the application is configured to utilize a centralized audit log solution that uses cryptographic methods that meet this requirement such as creating cryptographic hash values or message digests that can be used to validate integrity of audit files, the requirement is not applicable.

Ask application administrator to demonstrate the cryptographic mechanisms used to protect the integrity of audit data.

Verify when application logs are stored on the file system, a process that includes the creation of an integrity check of the audit file being stored is utilized. This integrity check can be the creation of a checksum, message digest or other one-way cryptographic hash of the audit file that is created.

If an integrity check is not created to protect the integrity of the audit information, this is a finding.

Configure the application to create an integrity check consisting of a cryptographic hash or one-way digest that can be used to establish the integrity when storing log files.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001350 The information system implements cryptographic mechanisms to protect the integrity of audit information. NIST SP 800-53 :: AU-9 (3) NIST SP 800-53A :: AU-9 (3).1 NIST SP 800-53 Revision 4 :: AU-9 (3)

AU-9 (3)

Not applicable

V-69499

medium

SRG-APP-000290

SV-84121r1_rule

APSC-DV-001360

Application audit tools must be cryptographically hashed.

Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.

To address this risk, audit tools must be cryptographically signed/hashed and the resulting value securely stored in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced.

Some OSs provide a native command line tool capable of extracting or creating a hash value. Care must be taken to ensure any hashing algorithm strength used is acceptable. An example is UNIX OS variants that provide the "shasum" utility with SHA256 capabilities. Windows is not known to provide a native cryptographic tool that utilizes an acceptable hashing algorithm. The Windows fciv.exe checksum tool currently only utilizes MD5 and SHA1 which are not acceptable hashing algorithms.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools.

Identify the location of the application audit tools.

Separate audit tools will be file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs.

If the application does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data, or generate reports, this requirement is not applicable.

If the system hosting the application has a separate file monitoring utility installed that is configured to identify changes to audit tools and alarm on changes to audit tools, this is not applicable.

Ask application administrator to demonstrate the cryptographic hashing mechanisms used to create the one way hashes that can be used to validate the integrity of audit tools.

For example, "shasum /path/to/file > checksum.filename".

Ask the application administrator to provide the list of checksum values and the associated file names of the audit tools.

If a cryptographic checksum or hash value of the audit tool file is not created for future reference, this is a finding.

Cryptographically hash the audit tool files used by the application. Store and protect the generated hash values for future reference.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001496 The information system implements cryptographic mechanisms to protect the integrity of audit tools. NIST SP 800-53 :: AU-9 (3) NIST SP 800-53A :: AU-9 (3).1 NIST SP 800-53 Revision 4 :: AU-9 (3)

AU-9 (3)

Not applicable

V-69501

medium

SRG-APP-000290

SV-84123r2_rule

APSC-DV-001370

The integrity of the audit tools must be validated by checking the files for changes in the cryptographic hash value.

Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.

To address this risk, audit tools must be cryptographically signed/hashed in order to provide the capability to identify when the audit tools have been modified, manipulated or replaced. An example is a checksum hash of the file or files.

Review the system documentation and interview the application administrator for details regarding application architecture, audit methods, and provided audit tools.

Identify the location of the application audit tools.

Separate audit tools will be file-oriented in nature, e.g., the application includes a separate executable file or library that when invoked allows users to view and manipulate logs.

If the application does not provide a separate tool in the form of a file which provides an ability to view and manipulate application log data, query data or generate reports, this requirement is not applicable.

If the system hosting the application has a separate file monitoring utility installed that is configured to identify changes to audit tools and alarm on changes to audit tools, this is not applicable.

Ask the application administrator to provide their process for periodically checking the list of checksum values against the associated file names of the audit tools to ensure none of the audit tools have been tampered with.

If a cryptographic checksum or hash value of the audit tool file is not periodically checked to ensure the integrity of audit tools, this is a finding.

Establish a process to periodically check the audit tool cryptographic hashes to ensure the audit tools have not been tampered with.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001496 The information system implements cryptographic mechanisms to protect the integrity of audit tools. NIST SP 800-53 :: AU-9 (3) NIST SP 800-53A :: AU-9 (3).1 NIST SP 800-53 Revision 4 :: AU-9 (3)

AU-9 (3)

Not applicable

V-69503

medium

SRG-APP-000378

SV-84125r1_rule

APSC-DV-001390

The application must prohibit user installation of software without explicit privileged status.

Allowing regular users to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Application functionality will vary, and while users are not permitted to install unapproved applications, there may be instances where the organization allows the user to install approved software packages such as from an approved software repository.

The application must enforce software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization.

This requirement applies, for example, to applications that provide the ability to extend application functionality (e.g., plug-ins, add-ons) and software management applications.

Review the application documentation and interview the application administrator to determine the capabilities of the application as it relates to software installation or product function extension.

Identify any software configuration change capabilities which are allowed by design and incorporated into the user interface. An example is utilizing a known software repository of tested and approved extensions, plugins or modules which can be used by application users to extend application features or functions.

If the application does not provide the ability to install software components, modules, plugins, or extensions, the requirement is not applicable.

Access the application user interface as a regular user, navigate to the application screen that provides the software installation function and attempt to install software components, modules, extensions, or plugins.

If the application utilizes an approved repository of approved software that has been tested and approved for all application users to install, this is not a finding.

If the application allows regular users to install untested or unapproved software components, extensions, modules, or plugins without explicit authorization, this is a finding.

Configure the application to prohibit user installation of software without explicit permission.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001812 The information system prohibits user installation of software without explicit privileged status. NIST SP 800-53 Revision 4 :: CM-11 (2)

CM-11 (2)

Not applicable

V-69505

medium

SRG-APP-000380

SV-84127r1_rule

APSC-DV-001410

The application must enforce access restrictions associated with changes to application configuration.

Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system.

When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can potentially have significant effects on the overall security of the system.

Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications.

Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).

Review the application documentation and configuration settings.

Access the application configuration settings interface as a regular non-privileged user. Attempt to make configuration changes to the application.

If configuration changes can be made by regular non-privileged users, this is a finding.

Review the locations of all configuration files used by the application.

Examine the file permission settings and determine who has access to the configuration files.

If access permissions to configuration files are not restricted to application administrators, this is a finding.

Configure the application to limit access to configuration settings to only authorized users.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001813 The information system enforces access restrictions. NIST SP 800-53 Revision 4 :: CM-5 (1)

CM-5 (1)

Only the administrator role has the ability to perform system configuration changes

V-69507

medium

SRG-APP-000381

SV-84129r1_rule

APSC-DV-001420

The application must audit who makes configuration changes to the application.

Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions.

Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after-the-fact.

If application configuration is maintained by using a text editor to modify a configuration file, this function may be delegated to an operating system file monitoring/auditing capability.

Review the application documentation and configuration settings.

Access the application configuration settings interface as a privileged user.

Make configuration changes to the application.

Review the application audit logs and ensure a log entry is made identifying the privileged user account that was used to make the changes.

If application configuration is maintained by using a text editor to modify a configuration file, modify the configuration file with a text editor. Review the system logs and ensure a log entry is made for the file modification that identifies the user that was used to make the changes.

If the user account is not logged, or is a group account such as "root", this is a finding.

If the user account used to make the changes is not logged in the audit records, this is a finding.

Configure the application to create log entries that can be used to identify the user accounts that make application configuration changes.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001814 The Information system supports auditing of the enforcement actions. NIST SP 800-53 Revision 4 :: CM-5 (1)

CM-5 (1)

All changes are audited

V-69509

medium

SRG-APP-000131

SV-84131r1_rule

APSC-DV-001430

The application must have the capability to prevent the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate that is recognized and approved by the organization.

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 DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved 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.

Review the application documentation and interview the application administrator to determine the process and commands used for patching the application.

Access application configuration settings.

Review commands and procedures used to patch the application and ensure a capability exists to prevent unsigned patches from being applied.

If the application is not capable of preventing installation of patches and packages that are not signed, or if the vendor does not provide a cryptographic hash value that can be manually checked prior to installation, this is a finding.

Design and configure the application to have the capability to prevent unsigned patches and packages from being installed.

Provide a cryptographic hash value that can be verified by a system administrator prior to installation.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001749 The information system prevents the installation of organization-defined software components without verification the software component has been digitally signed using a certificate that is recognized and approved by the organization. NIST SP 800-53 Revision 4 :: CM-5 (3)

CM-5 (3)

All releases provide a checksum of the release package allowing the customer to perform validation that the package has not been altered

V-69511

medium

SRG-APP-000133

SV-84133r1_rule

APSC-DV-001440

The applications must limit privileges to change the software resident within software libraries.

If the application were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to applications with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals will be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Review the application documentation and interview the application administrator to identify the application architecture.

Identify application folders where application libraries are stored.

Review permissions of application folders and library files contained with the folders to ensure file permissions restrict access to authorized users or processes.

Access application configuration settings.

Examine settings for capability to update software libraries or extend application functionality via the application.

Review user roles and access rights within the application to determine if access to this capability is restricted to authorized users.

If file restrictions do not limit write access to library files and if the application does not restrict access to library update functionality, this is a finding.

Configure the application OS file permissions to restrict access to software libraries and configure the application to restrict user access regarding software library update functionality to only authorized users or processes.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001499 The organization limits privileges to change software resident within software libraries. NIST SP 800-53 :: CM-5 (6) NIST SP 800-53A :: CM-5 (6).1 NIST SP 800-53 Revision 4 :: CM-5 (6)

CM-5 (6)

Application libraries are stored within a root only permissioned location of the Console and Defender images.

V-69513

medium

SRG-APP-000516

SV-84135r1_rule

APSC-DV-001460

An application vulnerability assessment must be conducted.

An application vulnerability assessment is a test conducted in order to identify weaknesses and security vulnerabilities that may exist within an application. The testing must cover all aspects and components of the application architecture. If an application consists of a web server and a database, then both components must be tested for vulnerabilities to the fullest extent possible.

Vulnerability assessment tests normally utilize a combination of specialized software called application vulnerability scanners as well as custom scripts and manual tests. In some instances, multiple tools are required in order to test all aspects of application features, functions and architecture. The vulnerability scanner is typically configured to communicate with the application through the user interface or via an applications communication port. In addition to using automated tools, manual tests conducted from the OS console such as executing custom scripts or reviewing configuration settings for known vulnerabilities may also be included as part of the test.

Testers will typically utilize application user test accounts in order to test application features and functionality such as adding content, executing queries and completing transactions. The vulnerability testing software utilizes user actions and access as well as a list of known security vulnerabilities in order to detect and identify weak security controls or misconfigurations that could potentially be manipulated by the user or create a security vulnerability.

The Open Web Application Security Project (OWASP) top 10 for 2013 includes the following top issues that should be tested. The site is available by pointing your browser to https://www.owasp.org.

A1 Injection A2 Weak authentication and session management A3 XSS A4 Insecure Direct Object References A5 Security Misconfiguration A6 Sensitive Data Exposure A7 Missing Function Level Access Control A8 Cross Site Request Forgery A9 Using Components with Known Vulnerabilities A10 Unvalidated Redirects and Forwards

The OWASP top 10 are categories of tests that can be applied to most but not necessarily all applications and are provided as an example of what to test for. Scanning tools include a multitude of tests that fall under these categories but may refer to these tests by a different name.

Testing must be conducted on a periodic basis while the application is in production and subsequent to system changes to ensure any changes made to the system do not introduce new security vulnerabilities.

Review the application documentation to understand application architecture.

Interview the application administrator, obtain and review their application vulnerability scanning process.

Request the latest scan results including scan configuration settings.

Review scan configurations and ensure coverage of all application architecture has been tested. The proper scanning tool or combination of tools must be utilized in order to ensure the full range of application features and functionality is tested.

For example, if the application includes a web interface and a SQL database, then ensure test results for web and SQL vulnerabilities are provided. Although web and SQL applications are included as examples and are the prevalent types of applications, this requirement is not intended to be limited to just the aforementioned application architectures. Ensure test results are provided from all testing tools employed during vulnerability testing.

If high risk security vulnerabilities are identified in the scan results, request subsequent test results that indicate the issues have been fixed or mitigated.

If the high risk issues identified in the report have not been fixed or mitigated to a level accepted by the ISSO and the ISSM, or if the application administrator cannot produce vulnerability security testing results that cover the range of application functionality, this is a finding.

Configure the application vulnerability scanners to test all components of the application, conduct vulnerability scans on a regular basis and remediate identified issues. Retain scan results for compliance verification.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000366 The organization implements the security configuration settings. NIST SP 800-53 :: CM-6 b NIST SP 800-53A :: CM-6.1 (iv) NIST SP 800-53 Revision 4 :: CM-6 b

CM-6 b

All releases are scanned for vulnerabilities and are corrected accordingly

V-69515

medium

SRG-APP-000384

SV-84137r1_rule

APSC-DV-001480

The application must prevent program execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.

Control of application execution is a mechanism used to prevent execution of unauthorized applications in order to follow the rules of least privilege. Some applications may provide a capability that runs counter to the mission or provides users with functionality that exceeds mission requirements.

Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Removal of executable programs is not always possible; therefore, establishing a method of preventing program execution is critical to maintaining a secure system baseline.

Software program restrictions include restricting execution of programs in certain environments, while preventing execution in other environments; or limiting execution of certain application functionality based on organization-defined criteria (e.g., privileges, subnets, sandboxed environments, security managers, roles).

Review the application documentation and interview the application administrator to determine if policies, rules, or restrictions exist regarding application usage or terms which authorize the conditions of application use.

If the policy, terms, or conditions state there are no usage restrictions, this requirement is not applicable.

Interview the application administrator, review policy, terms, and conditions documents to determine what the terms and conditions of application usage are.

Have the application administrator demonstrate how the program execution is restricted in accordance with the policy terms and conditions. Typical methods include but are not limited to the use of Windows Group Policy, AppLocker, Software Restriction Policies, Java Security Manager, and Role-Based Access Control (RBAC).

If application requirements or policy documents specify application execution restriction requirements and the execution of the application or its subcomponents are not restricted in accordance with requirements or policy, this is a finding.

Restrict application execution in accordance with the policy, terms, and conditions specified.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001764 The information system prevents program execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage. NIST SP 800-53 Revision 4 :: CM-7 (2)

CM-7 (2)

Not applicable

V-69517

medium

SRG-APP-000386

SV-84139r1_rule

APSC-DV-001490

The application must employ a deny-all, permit-by-exception (whitelist) policy to allow the execution of authorized software programs.

Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities.

The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting.

Verification of whitelisted software can occur either prior to execution or at system startup.

This requirement applies to configuration management applications or similar types of applications designed to manage system processes and configurations (e.g., HBSS and software wrappers).

If the application is not a configuration management or similar type of application designed to manage system processes and configurations, this requirement is not applicable.

Review the application documentation and interview the application administrator to identify if application whitelisting specifying which applications or application subcomponents are allowed to execute is in use.

Check for the existence of policy settings or policy files that can be configured to restrict application execution. Have the application administrator demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction.

Some methods for restricting execution include but are not limited to the use of custom capabilities built into the application or leveraging of Windows Group Policy, AppLocker, Software Restriction Policies, Java Security Manager or Role-Based Access Controls (RBAC).

If application whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.

Configure the application to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001774 The organization employs an deny-all, permit-by-exception policy to allow the execution of authorized software programs on the information system. NIST SP 800-53 Revision 4 :: CM-7 (5) (b)

CM-7 (5) (b)

Prisma Cloud Compute runtime “whitelist” policy learning and enforcement applies to the Console and Defender container runtime behaviors.

V-69519

medium

SRG-APP-000141

SV-84141r1_rule

APSC-DV-001500

The application must be configured to disable non-essential capabilities.

It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

Examples of non-essential capabilities include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled.

Review the application guidance, application requirements documentation, and interview the application administrator.

Identify the application’s operational requirements and what services the application is intended to provide users.

Review the overall application features and functionality via the user interface.

Review and identify installed application software modules via configuration settings.

Using the relevant OS commands, identify services running on the system and have the application administrator identify the services related to the application.

If the application is operating with extraneous capabilities that have not been defined as required in order to meet mission objectives, this is a finding.

Disable application extraneous application functionality that is not required in order to fulfill the application’s mission.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000381 The organization configures the information system to provide only essential capabilities. NIST SP 800-53 :: CM-7 NIST SP 800-53A :: CM-7.1 (ii) NIST SP 800-53 Revision 4 :: CM-7 a

CM-7 a

Prisma Cloud Compute Console and Defender images are purpose built for their intended functionality.

V-69521

medium

SRG-APP-000142

SV-84143r1_rule

APSC-DV-001510

The application must be configured to use only functions, ports, and protocols permitted to it in the PPSM CAL.

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.

Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., email and web services; however, doing so increases risk over limiting the services provided by any one component.

To support the requirements and principles of least functionality, the application must support the organizational requirements providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Review the application documentation and configuration.

Interview the application administrator.

Identify the network ports and protocols that are utilized by the application.

Using a combination of relevant OS commands and application configuration utilities identify the TCP/IP port numbers the application is configured to utilize and is utilizing.

Review the PPSM web page at:

http://www.disa.mil/Network-Services/Enterprise-Connections/PPSM

Review the PPSM Category Assurance List (CAL) directly at the following link:

https://disa.deps.mil/ext/cop/iase/ppsm/Pages/cal.aspx

Verify the ports used by the application are approved by the PPSM CAL.

If the ports are not approved by the PPSM CAL, this is a finding.

Configure the application to utilize application ports approved by the PPSM CAL.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000382 The organization configures the information system to prohibit or restrict the use of organization defined functions, ports, protocols, and/or services. NIST SP 800-53 :: CM-7 NIST SP 800-53A :: CM-7.1 (iii) NIST SP 800-53 Revision 4 :: CM-7 b

CM-7 b

Prisma Cloud Compute TCP port usage is configurable. Default configuration: TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console <→ Defender communication via mutual TLS v1.2 web socket session

V-69523

medium

SRG-APP-000389

SV-84145r1_rule

APSC-DV-001520

The application must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.

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 DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

Review the application guidance and interview the application administrator.

Identify the application user roles.

Identify the methods and manner in which an application user is allowed to escalate their privileges or change their role.

Create or utilize an account that has 2 roles within the application, both should be non-administrator. Example: User role and Report Creator role.

Authenticate to the application as the user in the User role.

Access the application functionality that allows the user to change their role and change from the User role to the Report Creator role.

If the user is not prompted to reauthenticate before the user’s role is changed, this is a finding.

Log out of the application and log back in as the User role.

Access the application functionality that allows the user to escalate their privileges to an administrative user.

Attempt to escalate the privileges of the user.

If the user is not prompted to reauthenticate before the user is allowed to proceed with escalated privileges, this is a finding.

Configure the application to require reauthentication before user privilege is escalated and user roles are changed.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002038 The organization requires users to reauthenticate when organization-defined circumstances or situations requiring reauthentication. NIST SP 800-53 Revision 4 :: IA-11

IA-11

Expiration of access token will require re-authentication. Lifetime of token is configurable, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/long_lived_tokens.html

V-69525

medium

SRG-APP-000390

SV-84147r1_rule

APSC-DV-001530

The application must require devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication.

Without reauthenticating devices, unidentified or unknown devices may be introduced; thereby facilitating malicious activity.

In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of devices, including (but not limited to), the following other situations:

(i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) After a fixed period of time; or (v) Periodically.

For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.

Gateways and SOA applications are examples of where this requirement would apply.

Review the application guidance and interview the application administrator.

Identify the methods and manner in which application devices such as an XML gateway, SOA application gateway, or application firewall is allowed to access the application. Most devices themselves will not change role or authenticators once they are established but will need to periodically re-authenticate.

Review the configuration setting in the application where the time period is set to force the device to reauthenticate.

Review local policy requirements to determine if reauthentication intervals are specified.

If the device is not forced to reauthenticate periodically, this is a finding.

Configure the application to require reauthentication periodically.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002039 The organization requires devices to reauthenticate when organization-defined circumstances or situations requiring reauthentication. NIST SP 800-53 Revision 4 :: IA-11

IA-11

Expiration of access token will require re-authentication. Lifetime of token is configurable, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/long_lived_tokens.html

V-69529

medium

SRG-APP-000149

SV-84151r1_rule

APSC-DV-001550

The application must use multifactor (Alt. Token) authentication for network access to privileged accounts.

Multifactor authentication requires using two or more factors to achieve authentication and access.

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).

Multifactor authentication decreases the attack surface by virtue of the fact that attackers must obtain two factors, a physical token or a biometric and a PIN, in order to authenticate. It is not enough to simply steal a user’s password to obtain access.

A privileged account is defined as an information system account with authorizations of a privileged user.

An Alt. Token is a separate CAC like token used specifically for administrative account access and serves as a separate identifier much like a separate user account.

Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the Internet).

Review the application documentation and interview the application administrator to identify application access methods.

Ask the application administrator to present both their primary CAC and their Alt. Token. Ask the application administrator to log on to the application using application relevant network based access methods. Attempt to use both CAC and Alt. Tokens to authenticate to the application.

Validate the application requests the user to input their CAC PIN and that they cannot perform administrative functions.

Have user logoff and reauthenticate with their Alt. Token and that they can perform administrative functions.

If the application allows administrative access to the application without requiring an Alt. Token, this is a finding.

Configure the application to use an Alt. Token when providing network access to privileged application accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000765 The information system implements multifactor authentication for network access to privileged accounts. NIST SP 800-53 :: IA-2 (1) NIST SP 800-53A :: IA-2 (1).1 NIST SP 800-53 Revision 4 :: IA-2 (1)

IA-2 (1)

Direct CAC (x509) authentication is supported. Other multi factor authentication mechanisms can be leveraged by other authentication sources (LDAP, SAML & OpenID Connect)

V-69531

medium

SRG-APP-000391

SV-84153r1_rule

APSC-DV-001560

The application must accept Personal Identity Verification (PIV) credentials.

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access.

DoD 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.

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.

Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials.

Validate the application prompts the user to provide a certificate from the CAC.

If the application allows access without requiring a CAC, this is a finding.

Configure the application to require CAC authentication.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001953 The information system accepts Personal Identity Verification (PIV) credentials. NIST SP 800-53 Revision 4 :: IA-2 (12)

IA-2 (12)

Direct CAC (x509) authentication is supported.https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/authenticate_console_with_certs.html

V-69533

medium

SRG-APP-000392

SV-84155r1_rule

APSC-DV-001570

The application must electronically verify Personal Identity Verification (PIV) credentials.

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access.

DoD 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.

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.

Ask the application administrator to log on to the application.

Validate the application prompts the user to provide a certificate from the CAC.

Validate the application requests the user to input their CAC PIN.

If the application allows access without requiring a CAC, this is a finding.

Configure the application to require CAC authentication.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001954 The information system electronically verifies Personal Identity Verification (PIV) credentials. NIST SP 800-53 Revision 4 :: IA-2 (12)

IA-2 (12)

Direct CAC (x509) authentication is supported.https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/authenticate_console_with_certs.html

V-69535

medium

SRG-APP-000150

SV-84157r1_rule

APSC-DV-001580

The application must use multifactor (e.g., CAC, Alt. Token) authentication for network access to non-privileged accounts.

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 DoD Active Directory and utilize the DoD CAC are an example of compliant multifactor authentication solutions.

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.

Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials.

Validate the application prompts the user to provide a certificate from the CAC.

Validate the application requests the user to input their CAC PIN.

If the application allows access without requiring a CAC or Alt. Token, this is a finding.

Configure the application to require CAC or Alt. Token authentication for non-privileged network access to non-privileged accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000766 The information system implements multifactor authentication for network access to non-privileged accounts. NIST SP 800-53 :: IA-2 (2) NIST SP 800-53A :: IA-2 (2).1 NIST SP 800-53 Revision 4 :: IA-2 (2)

IA-2 (2)

Direct CAC (x509) authentication is supported. Other multi factor authentication mechanisms can be leveraged by other authentication sources (LDAP, SAML & OpenID Connect)

V-69537

medium

SRG-APP-000151

SV-84159r1_rule

APSC-DV-001590

The application must use multifactor (Alt. Token) authentication for local access to privileged accounts.

Multifactor authentication requires using two or more factors to achieve authentication and access.

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).

Multifactor authentication decreases the attack surface by virtue of the fact that attackers must obtain two factors, a physical token or a biometric and a PIN, in order to authenticate. It is not enough to simply steal a user’s password to obtain access.

A privileged account is defined as an information system account with authorizations of a privileged user.

An Alt. Token is a separate CAC or token used specifically for administrative account access and serves as a separate identifier much like a separate user account.

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.

Review the application documentation and interview the application administrator to identify application access methods.

Ask the application administrator to present both their primary CAC and their Alt. Token. Ask the application administrator to log on to the application using the local application console.

Attempt to use both the CAC and Alt. Tokens to authenticate to the application.

Validate the application requests the user to input their CAC PIN and that they cannot perform administrative functions.

Have user logoff and reauthenticate with their Alt. Token and that they can perform administrative functions.

If the application allows administrative access to the application without requiring an Alt. Token, this is a finding.

Configure the application to only use Alt. Tokens when locally accessing privileged application accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000767 The information system implements multifactor authentication for local access to privileged accounts. NIST SP 800-53 :: IA-2 (3) NIST SP 800-53A :: IA-2 (3).1 NIST SP 800-53 Revision 4 :: IA-2 (3)

IA-2 (3)

Not applicable, no local application console

V-69539

medium

SRG-APP-000152

SV-84161r1_rule

APSC-DV-001600

The application must use multifactor (e.g., CAC, Alt. Token) authentication for local access to non-privileged accounts.

To assure accountability, prevent unauthenticated access, and prevent misuse of the system, privileged users must utilize 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 non-privileged account is defined as an information system account with authorizations of a regular or non-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 DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.

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.

Ask the application administrator to log on to the application. Have the application admin use their non-privileged credentials.

Validate the application prompts the user to provide a certificate from the CAC.

Validate the application requests the user to input their CAC PIN.

If the application allows access without requiring a CAC or Alt. Token, this is a finding.

Configure the application to require CAC or Alt. Token authentication for non-privileged network access.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000768 The information system implements multifactor authentication for local access to non-privileged accounts. NIST SP 800-53 :: IA-2 (4) NIST SP 800-53A :: IA-2 (4).1 NIST SP 800-53 Revision 4 :: IA-2 (4)

IA-2 (4)

Not applicable, no local application console

V-69541

medium

SRG-APP-000153

SV-84163r1_rule

APSC-DV-001610

The application must ensure users are authenticated with an individual authenticator prior to using a group authenticator.

To assure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated. Individual accountability mandates that each user is uniquely identified.

A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account.

If an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality.

Some applications may not have the need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.

There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server which contains publicly releasable information.

Review the application documentation, examine user accounts, group membership and interview the application administrator to identify group or shared accounts. Document the group or shared account information.

If the application does not use group or shared accounts, this requirement is not applicable.

Create a test account or use an existing group member account.

Ensure the test account is not authenticated to the application and attempt to access the application with the group account credentials.

If the application allows access without first requiring the group member to authenticate with their individual credentials, this is a finding.

Design and configure the application to individually authenticate group account members prior to allowing access.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000770 The organization requires individuals to be authenticated with an individual authenticator when a group authenticator is employed. NIST SP 800-53 :: IA-2 (5) (b) NIST SP 800-53A :: IA-2 (5).2 (ii) NIST SP 800-53 Revision 4 :: IA-2 (5)

IA-2 (5)

Not applicable

V-69543

medium

SRG-APP-000156

SV-84165r1_rule

APSC-DV-001620

The application must implement replay-resistant authentication mechanisms for network access to privileged accounts.

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.

A privileged account is any information system account with authorizations of a privileged user.

Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

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 DoD CAC as per DoD 8520, this requirement is not applicable.

Review to ensure the application is utilizing TLSV1.1 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.

Design and configure the application to utilize replay-resistant mechanisms when authenticating privileged accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001941 The information system implements replay-resistant authentication mechanisms for network access to privileged accounts. NIST SP 800-53 Revision 4 :: IA-2 (8)

IA-2 (8)

TLS v1.2 protects all communication between the Console and user’s browser.

V-69545

medium

SRG-APP-000157

SV-84167r1_rule

APSC-DV-001630

The application must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.

A replay attack is a man-in-the-middle style attack which allows an attacker to repeat or alter a valid data transmission that may enable unauthorized access to the application. Authentication sessions between the authenticating client and the application server validating the user credentials must not be vulnerable to a replay attack.

The protection methods selected to protect against a replay attack will vary according to the application architecture.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.

A non-privileged account is any operating system account with authorizations of a non-privileged user.

Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one time use) or challenges (e.g., TLS, WS_Security) and PKI certificates. Additional techniques include time-synchronous or challenge-response one-time authenticators.

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 DoD CAC as per DoD 8520, this requirement is not applicable.

Review to ensure the application is utilizing TLSV1.1 or greater to protect communication and non-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.

Design and configure the application to utilize replay-resistant mechanisms when authenticating non-privileged accounts.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001942 The information system implements replay-resistant authentication mechanisms for network access to non-privileged accounts. NIST SP 800-53 Revision 4 :: IA-2 (9)

IA-2 (9)

TLS v1.2 protects all communication between the Console and user’s browser.

V-69547

medium

SRG-APP-000158

SV-84169r1_rule

APSC-DV-001640

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

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.

With one way SSL authentication which is the typical form of SSL authentication done between a web browser client and a web server, the client requests the server certificate to validate the server’s identity and establish a secure connection.

When SSL mutual authentication is used, the server is configured to request the client’s certificate as well so the server can also identify the client.

For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.

This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply.

Review the application documentation and interview the application administrator.

Determine if mutual authentication is mandated by the data owner or by mission data protection objectives and data type.

Review application architecture and design documents.

Identify endpoint devices that interact with the application. These can be SOA gateways, VOIP phones, or other devices that are used to connect to and exchange data with the application.

If the design documentation specifies, this could potentially also include remote client workstations.

In order for two way SSL/mutual authentication to work properly, the server must be configured to request client certificates.

Access the applications management console.

Navigate to the SSL management utility or web page that is used to configure two way mutual authentication.

Verify endpoints are configured for client authentication (mutual authentication).

Some application architectures such as Java configure their settings in text/xml formatted files; in that case, have the application administrator identify the configuration files used by the application. E.g., web.xml stored in WEB-INF/ sub directory of the application root folder.

Open the web.xml file using a text editor.

Verify the application deployment descriptor for the application and the resource requiring protection under the "login-config" element is set to CLIENT-CERT.

If SSL mutual authentication is required and is not being utilized, this is a finding.

Configure the application to utilize mutual authentication when specified by data protection requirements.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000778 The information system uniquely identifies an organization defined list of specific and/or types of devices before establishing a local, remote, or network connection. NIST SP 800-53 :: IA-3 NIST SP 800-53A :: IA-3.1 (ii) NIST SP 800-53 Revision 4 :: IA-3

IA-3

Console <→ Defender communication via mutual TLS v1.2 web socket session

V-69549

medium

SRG-APP-000394

SV-84171r1_rule

APSC-DV-001650

The application must authenticate all network connected endpoint devices before establishing any connection.

Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.

For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of authentication claims may be made by services separate from the services acting on those decisions.

In such situations, it is necessary to provide authentication decisions (as opposed to the actual authenticators) to the services that need to act on those decisions.

This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs).

Gateways and SOA applications are examples of where this requirement would apply.

End point devices are not: Client desktop workstations only offer browser-based web application access where the user authenticates at the app layer.

Device authentication is a solution enabling an organization to manage devices. It is an additional layer of authentication ensuring only specific pre-authorized devices can access the system.

Review the application documentation, implementation documentation and interview the application administrator.

Identify if the application utilizes Web Services/Service-Oriented Architecture (SOA). Using the web services framework that has been implemented, have the application administrator identify the remote devices allowed to communicate to the service provider.

If the application is designed to provide end-user, interactive application access only and does not use web services or allow connections from remote devices, this requirement is not applicable.

Identify the authentication mechanism used to authenticate the remote consumers/devices. Commonly available authentication methods are Client Certificate Authentication and Basic Authentication.

The Basic Authentication method provides insufficient protection for authentication sessions and is not allowed.

If no authentication mechanism is used to authenticate remote service consumers/devices, or if Basic Authentication is used to authentication remote service consumers/devices, this is a finding.

Configure the application to authenticate all network connected endpoint devices/service consumers before establishing connections.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001958 The information system authenticates an organization defined list of specific and/or types of devices before establishing a local, remote, or network connection. NIST SP 800-53 Revision 4 :: IA-3

IA-3

A Prisma Cloud Console and associated Defenders will only communicate via a mutually established TLS v1.2 web socket session

V-69551

medium

SRG-APP-000395

SV-84173r1_rule

APSC-DV-001660

Service-Oriented Applications handling non-releasable data must authenticate endpoint devices via mutual SSL/TLS.

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.

One way SSL/TLS authentication is the typical form of authentication done between a web browser client and a web server. The client requests the server certificate to validate the server’s identity and establish a secure connection.

When SSL/TLS mutual authentication is used, the server is configured to request the client’s certificate as well so the server can also identify the client. This form of authentication is normally chosen for system to system communications that leverage HTTP as the transport.

It should be noted that SSL is being deprecated and replaced with TLS.

For distributed architectures (e.g., service-oriented architectures), the decisions regarding the validation of identification claims may be made by services separate from the services acting on those decisions. In such situations, it is necessary to provide the identification decisions (as opposed to the actual identifiers) to the services that need to act on those decisions.

This requirement applies to applications that connect either locally, remotely, or through a network to an endpoint device (including but not limited to: workstations, printers, servers (outside a datacenter), VoIP Phones, VTC CODECs). Gateways and SOA applications are examples of where this requirement would apply.

Review application documentation and interview application administrator.

Identify application data elements and determine if the application is handling/processing non-releasable data.

Review the application architecture and design documents.

Identify endpoint devices that interact with the application. These can be SOA gateways, VOIP phones, or other devices that are used to connect to and exchange data with the application.

If the design documentation specifies it, this could also include remote client workstations. However, this requirement is usually reserved for system-oriented endpoints rather than client workstations.

In order for two way SSL/TLS mutual authentication to work properly, the server must be configured to request client certificates.

Access the applications management console and navigate to the SSL/TLS management utility or web page that is used to configure two-way mutual authentication.

Verify endpoints are configured for client authentication (mutual authentication).

Some application architectures configure their settings in text/xml formatted files; in that case, have the application administrator identify the configuration files used by the application (e.g., web.xml stored in WEB-INF/ sub directory of the application root folder).

Open the web.xml file using a text editor and verify the application deployment descriptor for the application and the resource requiring protection under the "login-config" element is set to CLIENT-CERT.

If SSL/TLS mutual authentication is required due to the application processing non-releasable data and SSL/TLS mutual authentication not being utilized, this is a finding.

Configure the application to utilize mutual authentication when the application is processing non-releasable data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001967 The information system authenticates organization-defined devices and/or types of devices before establishing a local, remote and/or network connection using bidirectional authentication that is cryptographically based. NIST SP 800-53 Revision 4 :: IA-3 (1)

IA-3 (1)

Console <→ Defender communication via mutual TLS v1.2 web socket session

V-69553

medium

SRG-APP-000163

SV-84175r2_rule

APSC-DV-001670

The application must disable device identifiers after 35 days of inactivity unless a cryptographic certificate is used for authentication.

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, 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 utilize 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 DoD PKI policy and can be revoked by a trusted 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.

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 DoD PKI certificates to authenticate these devices, this requirement is NA.

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.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000795 The organization manages information system identifiers by disabling the identifier after an organization defined time period of inactivity. NIST SP 800-53 :: IA-4 e NIST SP 800-53A :: IA-4.1 (iii) NIST SP 800-53 Revision 4 :: IA-4 e

IA-4 e

By default Defenders that have not communicated with its controlling Console will be removed after 24 hours of no communications. The time period is configurable, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/install/install_defender/decommission_defender.html

V-69557

medium

SRG-APP-000166

SV-84179r1_rule

APSC-DV-001690

The application must enforce password complexity by requiring that at least one upper-case character be used.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

When prompted to provide the password, attempt to create a password that does not have one upper-case character.

If a password without at least one upper-case character can be created, this is a finding.

Configure the application to require at least one upper-case character in the password.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000192 The information system enforces password complexity by the minimum number of upper case characters used. NIST SP 800-53 :: IA-5 (1) (a) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (a)

IA-5 (1) (a)

Strong password enforcement for local accounts: Cannot be the same as username Must be at least 12 characters Must contain one of each of the following: uppercase character, lowercase character, number, special character List of special characters: ~!@#$%^&*()-_=+|[{}];:’\",<.>/?"

V-69559

medium

SRG-APP-000167

SV-84181r1_rule

APSC-DV-001700

The application must enforce password complexity by requiring that at least one lower-case character be used.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

When prompted to provide the password, attempt to create a password that does not have one lower-case character.

If a password without at least one lower-case character can be created, this is a finding.

Configure the application to require at least one lower-case character in the password.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000193 The information system enforces password complexity by the minimum number of lower case characters used. NIST SP 800-53 :: IA-5 (1) (a) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (a)

IA-5 (1) (a)

Must contain one of each of the following: uppercase character, lowercase character, number, special character

V-69561

medium

SRG-APP-000168

SV-84183r1_rule

APSC-DV-001710

The application must enforce password complexity by requiring that at least one numeric character be used.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

When prompted to provide the password, attempt to create a password that does not have one numeric character.

If a password without at least one numeric character can be created, this is a finding.

Configure the application to require at least one numeric character in the password.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000194 The information system enforces password complexity by the minimum number of numeric characters used. NIST SP 800-53 :: IA-5 (1) (a) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (a)

IA-5 (1) (a)

Must contain one of each of the following: uppercase character, lowercase character, number, special character

V-69563

medium

SRG-APP-000169

SV-84185r1_rule

APSC-DV-001720

The application must enforce password complexity by requiring that at least one special character be used.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

When prompted to provide the password, attempt to create a password that does not have one special character.

If a password without at least one special character can be created, this is a finding.

Configure the application to require at least one special character in the password.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001619 The information system enforces password complexity by the minimum number of special characters used. NIST SP 800-53 :: IA-5 (1) (a) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (a)

IA-5 (1) (a)

Must contain one of each of the following: uppercase character, lowercase character, number, special character

V-69565

medium

SRG-APP-000170

SV-84187r1_rule

APSC-DV-001730

The application must require the change of at least 8 of the total number of characters when passwords are changed.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

When prompted to provide the password, attempt to change less than 8 characters of the total number of characters in the password.

If less than 8 characters of the password are changed, this is a finding.

Configure the application to require the change of at least 8 characters in the password when passwords are changed.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000195 The information system, for password-based authentication, when new passwords are created, enforces that at least an organization-defined number of characters are changed. NIST SP 800-53 :: IA-5 (1) (b) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (b)

IA-5 (1) (b)

Must be at least 12 characters

V-69571

medium

SRG-APP-000173

SV-84193r1_rule

APSC-DV-001760

The application must enforce 24 hours/1 day as the minimum password lifetime.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and create a test user account or logon to the system with a test account and access the functionality that provides password change capabilities.

Attempt to change the password more than once.

If a password can be changed more than once within 24 hours, the minimum lifetime setting is not set and this is a finding.

Configure the application to have a minimum password lifetime of 24 hours.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000198 The information system enforces minimum password lifetime restrictions. NIST SP 800-53 :: IA-5 (1) (d) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (d)

IA-5 (1) (d)

Not available, use external identity providers (LDAP, SAML & OpenID Connect) for this functionality

V-69573

medium

SRG-APP-000174

SV-84195r1_rule

APSC-DV-001770

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

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

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 60 days.

If user passwords are not configured to expire after 60 days, or if the application does not have the ability to control this setting, this is a finding.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000199 The information system enforces maximum password lifetime restrictions. NIST SP 800-53 :: IA-5 (1) (d) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (d)

IA-5 (1) (d)

Not available, use external identity providers (LDAP, SAML & OpenID Connect) for this functionality

V-69575

medium

SRG-APP-000165

SV-84197r1_rule

APSC-DV-001780

The application must prohibit password reuse for a minimum of five generations.

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 DoD employee, member of the military, or a DoD 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.

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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and view the user password settings page.

Review user password settings and validate the application is configured to prohibit password reuse for a minimum of 5 password generations.

If the application does not prevent users from reusing their previous 5 passwords, or if the application does not have the ability to control this setting, this is a finding.

Configure the application to prohibit password reuse for up to 5 passwords.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000200 The information system prohibits password reuse for the organization defined number of generations. NIST SP 800-53 :: IA-5 (1) (e) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (e)

IA-5 (1) (e)

Not available, use external identity providers (LDAP, SAML & OpenID Connect) for this functionality

V-69577

medium

SRG-APP-000397

SV-84199r1_rule

APSC-DV-001790

The application must allow the use of a temporary password for system logons with an immediate change to a permanent password.

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 DoD employee, member of the military, or a DoD 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.

Without providing this capability, an account may be created without a password. Non-repudiation 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.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Access the application management interface and view the user password settings page.

Review user password settings and validate the application is configured to specify when a password is temporary and force a password change when the administrator either creates a new user account or changes a user’s password.

If the application can not specify a password as temporary and force the user to change the temporary password upon successful authentication, this is a finding.

Configure the application to specify when a password is temporary and change the temporary password on the first use.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002041 The information system allows the use of a temporary password for system logons with an immediate change to a permanent password. NIST SP 800-53 Revision 4 :: IA-5 (1) (f)

IA-5 (1) (f)

Not available, use external identity providers (LDAP, SAML & OpenID Connect) for this functionality

V-70145

medium

ASDV-PL-001795

SV-84767r1_rule

APSC-DV-001795

The application password must not be changeable by users other than the administrator or the user with which the password is associated.

If the application allows user A to change user B’s password, user B can be locked out of the application, and user A is provided the ability to grant themselves access to the application as user B. This violates application integrity and availability principles.

Many applications provide a password reset capability that allows the user to reset their password if they forget it.

Protections must be utilized when establishing a password change or reset capability to prevent user A from changing user B’s password.

Protection is usually accomplished by having each user provide an out of bounds (OOB) communication address such as a separate email address or SMS/text address (mobile phone) that can be used to transmit password reset/change information.

This OOB information is usually provided by the user when the user account is created. The OOB information is validated as part of the user account creation process by sending an account validation request to the OOB address and having the user respond to the request.

Applications must prevent users other than the administrator or the user associated with the account from changing the account password.

Review the application documentation and interview application administrator.

Determine if the application utilizes passwords. If the application does not utilize passwords, the requirement is NA.

Identify the processes, commands or web pages the application uses to allow application users to change their own passwords. This includes but is not limited to password resets.

If the application does not allow users to change or reset their passwords, the requirement is NA.

Obtain two application test accounts, referred to here as User A and User B. Access the application as User A. Utilize the application password reset or change processes and determine if User A is allowed to specify or otherwise force a password change for User B.

If User A is allowed to change or force a reset of User B’s password, this is a finding.

Use a CAC to authenticate users instead of using passwords. If application users are prohibited or prevented from obtaining a CAC due to DoD 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.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000184 The organization manages information system authenticators by requiring individuals to take, and having devices implement, specific security safeguards to protect authenticators. NIST SP 800-53 :: IA-5 i NIST SP 800-53A :: IA-5.1 (ii) NIST SP 800-53 Revision 4 :: IA-5 i

IA-5 i

Only the user change their password, an administrator can change other users passwords

V-70147

medium

SRG-APP-000400

SV-84769r2_rule

APSC-DV-001800

The application must terminate existing user sessions upon account deletion.

The application must ensure that a user does not retain any rights that may have been granted or retain access to the application after the user’s authorization or role within the application has been deleted or modified. This means once a user’s role/account within the application has been modified, deleted or disabled, the changes must be enforced immediately within the application. Any privileges or access the user had prior to the change must not be retained. For example; any application sessions that the user may have already established prior to the configuration change must be terminated when the user account changes occur.

Simply removing a user from a web application without terminating any existing application user sessions can introduce a scenario where the deleted user still has access to the application even though their account has been deleted from the authentication store. This can be attributed to browser caching and session management on the web server.

To address this, the web application must provide a means for ensuring this type of "zombie" access does not occur. Applications must provide a user management feature or function that will terminate any existing user sessions at the same time or just before the user account is terminated from the authoritative authentication source.

Review the application documentation and interview the application administrator.

Identify the user management functions of the application and create a test user account.

Access the application and perform application functions as the test user.

Access the user management functions and delete the test account while the test user sessions are still active.

Verify the test user application sessions are terminated by attempting to perform additional application functions.

If the test user retains access after the test account has been deleted, this is a finding.

Configure the application to terminate existing sessions of users whose accounts are deleted.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002007 The information system prohibits the use of cached authenticators after an organization defined time period. NIST SP 800-53 Revision 4 :: IA-5 (13)

IA-5 (13)

When a user account is deleted that user’s active session is not terminated. Users session is based upon the lifetime of the access token.

V-70153

medium

SRG-APP-000177

SV-84775r1_rule

APSC-DV-001830

The application must map the authenticated identity to the individual user or group account for PKI-based authentication.

Without mapping the certificate used to authenticate to a corresponding user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.

Some CAs will include identifying information like an email address within the certificate itself. When the email is assigned to an individual, this helps to identify the individual user who has been assigned the certificate. When identifying information is not available within the certificate itself, the application must provide a mapping that allows administrators to quickly determine who the owner of the certificate is. When responding to a security incident, particularly involving user access violations, time is of the essence so this information must be readily available to investigators.

Review the application documentation and interview the application administrator to identify how the application maps individual user certificates or group accounts to individual users.

Access the application as a regular user while reviewing the application logs to determine if the application records the individual name of the user or if the application only includes certificate information.

If the application only logs certificate information which contains no discernable user data, ask the system admin what their process is for mapping the certificate information to the user.

If the application does not map the certificate data to an individual user or group, or if the administrator has no automated process established for determining the identity of the user, this is a finding.

Configure the application to map certificate information to individual users or group accounts or create a process for automatically determining the individual user or group based on certificate information provided in the logs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000187 The information system, for PKI-based authentication, maps the authenticated identity to the account of the individual or group. NIST SP 800-53 :: IA-5 (2) NIST SP 800-53A :: IA-5 (2).1 NIST SP 800-53 Revision 4 :: IA-5 (2) (c)

IA-5 (2) (c)

X509 certificate to local user identity is based upon the client authentication certificate’s SubjectAlternativeName → PrincipalName value matching the local account’s username.

V-70155

medium

SRG-APP-000401

SV-84777r1_rule

APSC-DV-001840

The application, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

A local cache of revocation data is also known as a CRL list. This list contains a list of revoked certificates and can be periodically downloaded to ensure certificates can still be checked for revocation when network access is not available or access to the Online Certificate Status Protocol OCSP server is not available.

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).

Review the application documentation and interview the system administrator to identify how the application checks certificate revocation.

If the application resides on the SIPRNET and does not have access to the root CAs this requirement is not applicable.

Different application frameworks may handle this requirement for the developer or the developer may have chosen to implement their own implementation for managing and implementing the CRL.

Have the administrator demonstrate the process used for obtaining and importing the CRL. CAs may publish the CRL in an LDAP directory or it may be posted to an HTTP server.

Verify the application is configured to import the CRL on a regular basis.

Have the administrator demonstrate the configuration setting that enables CRL checking in the event the OCSP server is not available.

If the application is not configured to implement a CRL, this is a finding.

Implement a Certificate Revocation List (CRL) import process and configure the application to check the CRL if OCSP is not available.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001991 The information system, for PKI-based authentication, implements a local cache of revocation data to support path discovery and validation in case of inability to access revocation information via the network. NIST SP 800-53 Revision 4 :: IA-5 (2) (d)

IA-5 (2) (d)

Not supported. OCSP is the certificate revocation check mechanism. If the Console is unable to perform the network based OCSP check, revocation checking can be disabled.

V-70159

medium

SRG-APP-000179

SV-84781r2_rule

APSC-DV-001860

The application must use mechanisms meeting the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module.

A cryptographic module is a hardware or software device or component that performs cryptographic operations securely within a physical or logical boundary, using a hardware, software or hybrid cryptographic engine contained within the boundary, and cryptographic keys that do not leave the boundary. Based on the criticality of the application, system designers might choose to utilize a hardware based cryptographic module due to the protections and security benefits a hardware based solution provides over a software based solution. Due to various factors, including expense, hardware based encryption modules are usually relegated to only those applications where the system requirements specify it as a required protection. Examples include applications that handle extremely sensitive data or those used in life and death situations, e.g., weapons systems. General purpose applications such as a web site will often opt to leverage an underlying software based encryption capability that is offered by the OS, database or application development framework. Operating systems or database products often provide their own cryptographic modules that are FIPS 140-2 compliant and can meet the authentication to the crypto module requirement via their Role Based Access Controls (users and groups) built into the product. In all cases, user’s accessing the cryptographic module must be authenticated and granted the appropriate rights in order to access the encryption module. Any encryption utilized by the access control mechanisms must be FIPS 140-2 compliant.

Review the application documentation and interview the application administrator.

Identify if the application provides access to cryptographic modules and if access is required in order to manage cryptographic modules contained within the application.

If the application does not provide authenticated access to a cryptographic module, the requirement is not applicable.

Review and identify the cryptographic module. Refer to the NIST website listing all FIPS-approved cryptographic modules.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

If the cryptographic module that requires authentication is not on the FIPS-approved module list, this is a finding.

Use FIPS-approved cryptographic modules.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000803 The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication. NIST SP 800-53 :: IA-7 NIST SP 800-53A :: IA-7.1 NIST SP 800-53 Revision 4 :: IA-7

IA-7

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

V-70161

medium

SRG-APP-000180

SV-84783r1_rule

APSC-DV-001870

The application must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).

Lack of authentication and identification enables non-organizational users to gain access to the application or possibly other information systems and provides an opportunity for intruders to compromise resources within the application or information system.

Non-organizational users include all information system users other than organizational users which include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors and guest researchers).

Non-organizational users must be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access, such as accessing a web server.

Review the application documentation and interview the application administrator.

If the application does not host non-organizational users, this requirement is not applicable.

Review the application and verify authentication is enabled and required in order for users to access the application.

Review the application user base and determine if all user accounts are documented and assigned to a unique individual.

Review risk acceptance documentation to determine if there are specific accesses identified that do not require authentication.

If the application does not identify and authenticate non-organizational users and there is no risk acceptance documentation approving the exception, this is a finding.

Configure the application to identify and authenticate all non-organizational users.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000804 The information system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). NIST SP 800-53 :: IA-8 NIST SP 800-53A :: IA-8.1 NIST SP 800-53 Revision 4 :: IA-8

IA-8

Not applicable

V-70163

medium

SRG-APP-000402

SV-84785r1_rule

APSC-DV-001880

The application must accept Personal Identity Verification (PIV) credentials from other federal agencies.

Access may be denied to authorized users if federal agency PIV credentials are not accepted.

Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.

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-DoD) 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.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002009 The information system accepts Personal Identity Verification (PIV) credentials from other federal agencies. NIST SP 800-53 Revision 4 :: IA-8 (1)

IA-8 (1)

Prisma Cloud Compute can be configured to allow x509 authentication of smart cards issued from different certification authorities.

V-70165

medium

SRG-APP-000403

SV-84787r2_rule

APSC-DV-001890

The application must electronically verify Personal Identity Verification (PIV) credentials from other federal agencies.

Inappropriate access may be granted to unauthorized users if federal agency PIV credentials are not electronically verified.

Personal Identity Verification (PIV) credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.

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-DoD) 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.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002010 The information system electronically verifies Personal Identity Verification (PIV) credentials from other federal agencies. NIST SP 800-53 Revision 4 :: IA-8 (1)

IA-8 (1)

Direct PIV (x509) authentication is supported

V-70167

medium

SRG-APP-000404

SV-84789r1_rule

APSC-DV-001900

The application must accept FICAM-approved third-party credentials.

FICAM establishes a federated identity framework for the Federal Government. FICAM provides Government-wide 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.

A Trust Framework that is comparable to federal standards is adopted through this process, which allows Federal Government Relying Parties (Federal Government web sites or RP’s) to trust Credential Service Providers a.k.a. Identity Providers that have been assessed under that particular trust framework. This allows federal government relying parties to trust such credentials at their approved assurance levels.

This requirement only applies to applications that are intended to be accessible to non-federal government agencies and other partners through FICAM.

Third-party credentials are those credentials issued by non-federal government entities approved by the Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions initiative.

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 partners this requirement is not applicable.

Ask the application administrator to demonstrate how the application is configured to allow the use of third-party credentials, verify the third-party credentials are FICAM approved.

If the application does not accept FICAM approved credentials when accepting third-party credentials, this is a finding.

Configure applications intended to be accessible to non-federal government agencies to use FICAM-approved third-party credentials.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002011 The information system accepts FICAM-approved third-party credentials. NIST SP 800-53 Revision 4 :: IA-8 (2)

IA-8 (2)

Prisma Cloud Compute Console can be configured as a SAML v2.0 relying party to FICAM identity providers.

V-70169

medium

SRG-APP-000405

SV-84791r1_rule

APSC-DV-001910

The application must conform to FICAM-issued profiles.

FICAM establishes a federated identity framework for the Federal Government. FICAM provides Government-wide 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 that are intended to be accessible to non-federal government agencies and other partners or non-organizational (non-DoD) 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 by pointing your web browser to: info.idmanagement.gov/2012/10/what-are-ficam-technical-profiles-and.html

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 partners this requirement is not applicable.

This requirement applies to DoD 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 doesn’t conform to FICAM-issued profiles, this is a finding.

Configure the application to conform to FICAM-issued technical profiles when providing services that rely on external (Federal Government) identity providers.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002014 The information system conforms to FICAM-issued profiles. NIST SP 800-53 Revision 4 :: IA-8 (4)

IA-8 (4)

SAML and OpenID Connect is supported

V-70171

medium

SRG-APP-000409

SV-84793r1_rule

APSC-DV-001930

Applications used for non-local maintenance sessions must audit non-local maintenance and diagnostic sessions for organization-defined auditable events.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

If events associated with non-local administrative access or diagnostic sessions are not logged and audited, a major tool for assessing and investigating attacks would not be available.

This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Review the application documentation and interview the application administrator to identify application maintenance functions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

Identify the maintenance functions/capabilities that are provided by the application and performed by an individual which can be performed remotely.

For example, the application may provide the ability to clean up a folder of temporary files, add users, remove users, restart processes, backup certain files, manage logs, or execute diagnostic sessions.

Identify and open the audit logs that capture maintenance actions performed by the application.

Accessing the application in the appropriate role to execute maintenance tasks, perform several maintenance tasks and observe the logs.

If the application provides maintenance functions and capabilities and those functions are not logged when they are executed, this is a finding.

Configure the application to log when application maintenance functionality is executed remotely.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002884 The organization audits nonlocal maintenance and diagnostic sessions' organization-defined audit events. NIST SP 800-53 Revision 4 :: MA-4 (1) (a)

MA-4 (1) (a)

All non-local account actions are audited

V-70175

medium

SRG-APP-000411

SV-84797r1_rule

APSC-DV-001940

Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the integrity of non-local maintenance and diagnostic communications.

Privileged access contains control and configuration information which is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms to protect integrity.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

The application can meet this requirement through leveraging a cryptographic module.

Review the application documentation and interview the application administrator to identify application maintenance functions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

Identify the maintenance functions/capabilities that are provided by the application and performed by an individual which can be performed remotely.

For example, the application may provide the ability to clean up a folder of temporary files, add users, remove users, restart processes, backup certain files, manage logs, or execute diagnostic sessions.

Access the application in the appropriate role needed to execute maintenance tasks. Observe the manner in which the application is connecting and ensure the session is being encrypted.

For example, observe the browser to ensure the session is being encrypted with TLS/SSL.

If the application provides remote access to maintenance functions and capabilities and the remote access methods are not encrypted, this is a finding.

Configure the application to encrypt remote application maintenance sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002890 The information system implements cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications. NIST SP 800-53 Revision 4 :: MA-4 (6)

MA-4 (6)

TLS v1.2 protects all communication between the Console and user’s browser.

V-70177

medium

SRG-APP-000412

SV-84799r1_rule

APSC-DV-001950

Applications used for non-local maintenance sessions must implement cryptographic mechanisms to protect the confidentiality of non-local maintenance and diagnostic communications.

Privileged access contains control and configuration information which is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms to protect confidentiality.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

The application can meet this requirement through leveraging a cryptographic module.

Review the application documentation and interview the application administrator to identify application maintenance functions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

Identify the maintenance functions/capabilities that are provided by the application and performed by an individual which can be performed remotely.

For example, the application may provide the ability to clean up a folder of temporary files, add users, remove users, restart processes, backup certain files, manage logs, or execute diagnostic sessions.

Access the application in the appropriate role needed to execute maintenance tasks. Observe the manner in which the application is connecting and verify the session is being encrypted.

For example, observe the browser to ensure the session is being encrypted with TLS/SSL.

If the application provides remote access to maintenance functions and capabilities and the remote access methods are not encrypted, this is a finding.

Configure the application to encrypt remote application maintenance sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003123 The information system implements cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications. NIST SP 800-53 Revision 4 :: MA-4 (6)

MA-4 (6)

TLS v1.2 protects all communication between the Console’s API and remote application.

V-70179

medium

SRG-APP-000413

SV-84801r1_rule

APSC-DV-001960

Applications used for non-local maintenance sessions must verify remote disconnection at the termination of non-local maintenance and diagnostic sessions.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

If the remote connection is not closed and verified as closed, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Remote connections must be disconnected and verified as disconnected when non-local maintenance sessions have been terminated and are no longer available for use.

Review the application documentation and interview the application administrator to identify application maintenance functions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

Identify the maintenance functions/capabilities that are provided by the application, performed by an individual/admin and which can be performed remotely.

Examples include but are not limited to:

The application may provide the ability to clean up a folder of temporary files, add users, remove users, restart processes, backup certain files, manage logs, or execute diagnostic sessions.

Identify the IP address of the source system used to originate testing traffic. The IP address will be used to identify sessions on the application host so verify traffic is not traversing a proxy connection in order to reach the application host.

Access the operating system of the application host and execute the relevant OS commands to identify active TCP/IP sessions on the application host.

For example, the "netstat -a" command will provide a status of all TCP/IP connections on both Windows and UNIX systems.

Netstat output can be redirected to a file or the grep command can be used on UNIX systems to identify the specific application processes and network connections.

netstat -a |grep -i "application process name" > filename or netstat -a |grep -i source IP address > filename

Utilizing the application, access using the appropriate role needed to execute maintenance tasks.

Execute a maintenance task or tasks from within the application.

Re-execute the netstat commands and identify what network connections and process IDs were created to handle the new application session.

Terminate the application session via the application interface and then execute the netstat commands a third time. The network connections should terminate or change to a state that indicates the connections are closed or are in the process of closing. Continue to execute netstat command until it is verified that the application has terminated the process sessions and closed the network connections.

Review the application logs to ensure the application has logged the disconnection event thereby verifying the disconnection.

If the application provides remote access to maintenance functions and capabilities and the remote access connections are not terminated and then verified, this is a finding.

Configure the application to verify termination of remote maintenance sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002891 The information system implements remote disconnect verification at the termination of nonlocal maintenance and diagnostic sessions. NIST SP 800-53 Revision 4 :: MA-4 (7)

MA-4 (7)

HTTPS TCP session termination is a function of the underlying operating system

V-70181

medium

SRG-APP-000185

SV-84803r1_rule

APSC-DV-001970

The application must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Review the application documentation and interview the application administrator to identify application maintenance functions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

Identify the maintenance functions/capabilities that are provided by the application, performed by an individual/admin and which can be performed remotely.

Examples include but are not limited to:

The application may provide the ability to clean up a folder of temporary files, add users, remove users, restart processes, backup certain files, manage logs, or execute diagnostic sessions.

Have the application admin authenticate to the application in an administrative role and verify that strong credentials (CAC) are required to access when performing application maintenance.

Have the application admin authenticate to the application host OS and verify that strong credentials (CAC) are required to access when performing application maintenance.

If the application administrator is prevented from accessing the OS by policy requirement or separation of duties requirements, this is not a finding.

If a CAC is not used when remotely accessing the application for maintenance or diagnostic sessions, this is a finding.

Configure the application to use strong authentication (CAC) when accessing the application for maintenance purposes.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000877 The organization employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions. NIST SP 800-53 :: MA-4 c NIST SP 800-53A :: MA-4.1 (iv) NIST SP 800-53 Revision 4 :: MA-4 c

MA-4 c

Direct CAC (x509) authentication is supported.https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/authenticate_console_with_certs.html

V-70183

medium

SRG-APP-000186

SV-84805r1_rule

APSC-DV-001980

The application must terminate all sessions and network connections when non-local maintenance is completed.

If a maintenance session or connection remains open after maintenance is completed, it may be hijacked by an attacker and used to compromise or damage the system.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Review the application documentation and interview the system administrator to determine how the application is configured to terminate network sessions after sessions have been idle for a period of time. Identify any documented exceptions.

If the application does not provide non-local maintenance and diagnostic capability, this requirement is not applicable.

For privileged management sessions the period of time is 10 minutes of inactivity.

For regular user or non-privileged sessions, the period of time is 15 minutes of inactivity.

Authenticate to the application using normal in-band access methods and as an application admin.

Perform any operation to verify access and then leave the session idle for 10 minutes and perform no activity within the application.

Access the application after the period of inactivity has expired and determine if the application still allows access.

If necessary, logout of the application, clear the browser cache, and repeat the same test procedure using the account privileges of a regular user. Leave the session inactive for 15 minutes.

If the application does not deny access after each user session has exceeded the relevant idle timeout period and there is no documented risk exceptions needed to fulfill mission requirements, this is a finding.

Configure the application to expire idle user sessions after 10 minutes of inactivity for admin users and after 15 minutes of inactivity for regular users.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000879 The organization terminates sessions and network connections when nonlocal maintenance is completed. NIST SP 800-53 :: MA-4 e NIST SP 800-53A :: MA-4.1 (vi) NIST SP 800-53 Revision 4 :: MA-4 e

MA-4 e

User can actively logout out of their current session. Lifetime of access token can be adjusted

V-70185

medium

ASDV-PL-001995

SV-84807r1_rule

APSC-DV-001995

The application must not be vulnerable to race conditions.

A race condition is a timing event within an application that can become a security vulnerability. A race condition can occur when a pair of programming calls operating simultaneously do not work in a sequential or coordinated manner. A race condition is a timing event within software that can become a security vulnerability if the calls are not performed in the correct order.

There are different types of race conditions and they are dependent upon the action that the application is undertaking when the race condition occurs. Some examples of race conditions include but are not limited to:

- Time of check, time of use: the time in which a given resource is checked, and the time that resource is used. - Thread based: two threads of execution use a resource simultaneously, resource may be invalid when used. - Switch based: variable switches values while switch statement is in progress.

Developers must be cognizant of programming sequence and use sanity checks to validate data prior to acting upon it.

A code review or a static code analysis is the method used to identify race conditions.

Review the application documentation and architecture.

If the application is a COTS application and the vendor will not provide code review test results that demonstrate the application has been tested and is not susceptible to race conditions, the requirement is NA.

Interview the application admin and identify the most recent code testing and analysis that has been conducted.

Review the test results; verify configuration of analysis tools are set to check for the existence of race conditions.

If race conditions are identified in the test results, verify the latest test results are being used, if not, ensure remediation has been completed.

If the test results show race conditions exist and no remediation evidence is presented, or if test results are not available, this is a finding.

Be aware of potential timing issues related to application programming calls when designing and building the application.

Validate that variable values do not change while a switch event is occurring.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003178 The organization requires the developer of the information system, system component, or information system service to correct flaws identified during security testing/evaluation. NIST SP 800-53 Revision 4 :: SA-11 e

SA-11 e

Not applicable

V-70187

medium

SRG-APP-000190

SV-84809r1_rule

APSC-DV-002000

The application must terminate all network connections associated with a communications session at the end of the session.

Networked applications routinely open connections to and from other systems as part of their design and function. When connections are opened by the application, system resources are consumed. Terminating the network connection at the end of the application session frees up these resources for later use and aids in maintaining system stability.

Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection.

This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Many applications rely on the underlying OS to control the network connection aspect of the application which is perfectly acceptable.

Additionally, application specific operational issues may occasionally be encountered which dictate exceptions be granted to this requirement in order to ensure continuity of operations and application availability.

When the aforementioned type of situation occurs, the root cause of the issue as well as the mitigations implemented in order to prevent a loss of availability must be documented. Common mitigation procedures include but are not limited to stopping and restarting application or system services in order to manually release system resources.

Review the application documentation and interview the system administrator to determine how the application is designed and configured to terminate network connections at the end of the application session.

Identify any documented exceptions to the requirement and review associated mitigations.

If the application provides a management interface for controlling or monitoring application network sessions, access that management interface. Monitor application network activity.

If the application utilizes the underlying OS to control network connections, access the command prompt of the OS. Run the OS command for observing network connections at the OS. For Windows and Unix OS’s, use the "netstat" command. Include command parameters that identify the application and/or process ID. netstat /? or -h provides the list of available parameters.

Observe network activity and associate application processes with network connections. Repeat use of the command to identify changing network state.

Determine if application session network connections are being terminated at the end of the session by observing the "state" column of the netstat command output with each iteration.

If the application does not terminate network connections when application sessions end, this is a finding.

If exceptions are documented with no mitigation this is a finding.

Configure or design the application to terminate application network sessions at the end of the session.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001133 The information system terminates the network connection associated with a communications session at the end of the session or after an organization-defined time period of inactivity. NIST SP 800-53 :: SC-10 NIST SP 800-53A :: SC-10.1 (ii) NIST SP 800-53 Revision 4 :: SC-10

SC-10

User can actively logout out of their current session. Lifetime of access token can be adjusted

V-70189

medium

SRG-APP-000416

SV-84811r2_rule

APSC-DV-002010

The application must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect classified data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Advanced Encryption Standard (AES) Symmetric block cipher used for information protection FIPS Pub 197 Use 256 bit keys to protect up to TOP SECRET

Elliptic Curve Diffie-Hellman (ECDH) Key Exchange Asymmetric algorithm used for key establishment NIST SP 800-56A Use Curve P-384 to protect up to TOP SECRET.

Elliptic Curve Digital Signature Algorithm (ECDSA) Asymmetric algorithm used for digital signatures FIPS Pub 186-4 Use Curve P-384 to protect up to TOP SECRET.

Secure Hash Algorithm (SHA) Algorithm used for computing a condensed representation of information FIPS Pub 180-4

Use SHA-384 to protect up to TOP SECRET.

Diffie-Hellman (DH) Key Exchange Asymmetric algorithm used for key establishment IETF RFC 3526 Minimum 3072-bit modulus to protect up to TOP SECRET

RSA Asymmetric algorithm used for key establishment NIST SP 800-56B rev 1 Minimum 3072-bit modulus to protect up to TOP SECRET

RSA Asymmetric algorithm used for digital signatures FIPS PUB 186-4 Minimum 3072 bit-modulus to protect up to TOP SECRET.

Review the application documentation, system security plan and interview the application administrator to determine if the application processes classified data.

If the application does not process classified data, this requirement is not applicable.

Identify the data classifications and the cryptographic protections established to protect the application data.

Verify the application is configured to utilize the appropriate encryption based upon data classification, cryptographic tasks that need to be performed (information protection, hashing, signing) and information protection requirements.

NIST-certified cryptography must be used to store classified non-Sources and Methods Intelligence (SAMI) information if required by the information owner.

NSA-validated type-1 encryption must be used for all SAMI data stored in the enclave.

If the application is not configured to utilize the NSA-approved cryptographic modules in accordance with data protection requirements specified in the security plan, this is a finding.

Configure application to encrypt stored classified information; Ensure encryption is performed using NIST FIPS 140-2-validated encryption.

Encrypt stored, non-SAMI classified information using NIST FIPS 140-2-validated encryption.

Implement NSA-validated type-1 encryption of all SAMI data stored in the enclave.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002450 The information system implements organization-defined cryptographic uses and type of cryptography required for each use in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. NIST SP 800-53 Revision 4 :: SC-13

SC-13

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. AES 256 encryption algorithm is used

V-70191

medium

SRG-APP-000514

SV-84813r2_rule

APSC-DV-002020

The application must utilize FIPS-validated cryptographic modules when signing application components.

Applications that distribute components of the application must sign the components to provide an identity assurance to consumers of the application component. Components can include application messages or application code.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to validate the author of application components. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance the modules have been tested and validated.

If the application resides on a National Security System (NSS) it must not use algorithms weaker than SHA-384.

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, DoD PKI policy prohibits the use of SHA1 as of December 2016. See DoD CIO Memo Subject: Revised Schedule to Update DoD 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.

Utilize FIPS-validated algorithms when signing application components.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002450 The information system implements organization-defined cryptographic uses and type of cryptography required for each use in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. NIST SP 800-53 Revision 4 :: SC-13

SC-13

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. TLS cypher suites used: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

V-70193

medium

SRG-APP-000514

SV-84815r2_rule

APSC-DV-002030

The application must utilize FIPS-validated cryptographic modules when generating cryptographic hashes.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

If the application resides on a National Security System (NSS) it must not use a hashing algorithm weaker than SHA-384.

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, DoD PKI policy prohibits the use of SHA1 as of December 2016. See DoD CIO Memo Subject: Revised Schedule to Update DoD 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.

Configure the application to use a FIPS-validated hashing algorithm when creating a cryptographic hash.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002450 The information system implements organization-defined cryptographic uses and type of cryptography required for each use in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. NIST SP 800-53 Revision 4 :: SC-13

SC-13

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. Uses SHA256 hashing algorithm

V-70195

medium

SRG-APP-000514

SV-84817r1_rule

APSC-DV-002040

The application must utilize FIPS-validated cryptographic modules when protecting unclassified information that requires cryptographic protection.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Interview the system administrator, review the application components, and the application requirements to determine if the application processes data requiring cryptographic protection.

Review the application documentation and interview the application administrator to identify the cryptographic modules used by the application.

Access the NIST site to determine if the cryptographic modules used by the application have been FIPS-validated.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

If the application is using cryptographic modules that are not FIPS-validated to protect unclassified data, this is a finding.

Configure the application to use a FIPS-validated cryptographic module.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002450 The information system implements organization-defined cryptographic uses and type of cryptography required for each use in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. NIST SP 800-53 Revision 4 :: SC-13

SC-13

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module.

V-70197

medium

SRG-APP-000514

SV-84819r1_rule

APSC-DV-002050

Applications making SAML assertions must use FIPS-approved random numbers in the generation of SessionIndex in the SAML element AuthnStatement.

A predictable SessionIndex could lead to an attacker computing a future SessionIndex, thereby, possibly compromising the application.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Interview the system administrator, review the application components, and the application requirements to determine if the application uses SAML assertions.

If the application does not use SAML assertions, the requirement is not applicable.

Review the application documentation and interview he application administrator to identify the cryptographic modules used by the application.

Access the NIST site to determine if the cryptographic modules used by the application have been FIPS-validated.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

If the application is using cryptographic modules that are not FIPS-validated when generating the SessionIndex in the SAML AuthnStatement, this is a finding.

Configure the application to use a FIPS-validated cryptographic module.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002450 The information system implements organization-defined cryptographic uses and type of cryptography required for each use in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. NIST SP 800-53 Revision 4 :: SC-13

SC-13

Prisma Cloud Compute can be configured as a SAML relying party. It is not an identity provider and does not generate SAML assertions

V-70199

medium

SRG-APP-000211

SV-84821r1_rule

APSC-DV-002150

The application user interface must be either physically or logically separated from data storage and management interfaces.

Application management functionality includes functions necessary for administration and requires privileged user access. Allowing non-privileged users to access application management functionality capabilities increases the risk that non-privileged users may obtain elevated privileges.

The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, different TCP/UDP ports, virtualization techniques, combinations of these methods, or other methods, as appropriate.

An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different security domain and with additional access controls.

Review the application documentation and interview the application administrator.

Review the design documents and the interfaces used by the application.

Verify that the application provides separate interfaces for user traffic and for management traffic. The separation may be virtual in nature (virtual host, virtual NIC, virtual network) or physically separate.

If the application user interface and the application management interface are shared, this is a finding.

Configure the application so user interface to the application and management interface to the application is separated.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001082 The information system separates user functionality (including user interface services) from information system management functionality. NIST SP 800-53 :: SC-2 NIST SP 800-53A :: SC-2.1 NIST SP 800-53 Revision 4 :: SC-2

SC-2

Prisma Cloud Compute user interface and API access is on TCP 8083 (HTTPS). The user interface interacts with the API and all functionality is provided by the API. Every API endpoint has a role based permissions assigned

V-70201

medium

SRG-APP-000219

SV-84823r1_rule

APSC-DV-002210

The application must set the HTTPOnly flag on session cookies.

HTTPOnly is a flag included in a Set-Cookie HTTP response header. If the HTTPOnly flag is included in the HTTP response header, the cookie cannot be accessed through client side scripts like JavaScript.

If the HTTPOnly flag is set, even if a cross-site scripting (XSS) flaw in the application exists, and a user accidentally accesses a link that exploits this flaw, the browser will not reveal the cookie to a third party.

The HTTPOnly setting is browser dependent however most popular browsers support the feature. If a browser does not support HTTPOnly and a website attempts to set an HTTPOnly cookie, the HTTPOnly flag will be ignored by the browser, thus creating a traditional, script accessible cookie. As a result, the cookie (typically the session cookie) becomes vulnerable to theft or modification by a malicious script running on the client system.

Review the application documentation and interview the application administrator to identify when session cookies are created.

Identify any mitigating controls the application developer may have implemented. Examples include utilizing a separate Web Application Firewall that is configured to provide this capability or configuring the web server with Mod_Security or ESAPI WAF with the HTTPOnly flag directives enabled.

Reference the most recent vulnerability scan documentation.

Verify the configuration settings for the scan include web application checks including HTTPOnly tests.

Review the scan results and determine if vulnerabilities related to HTTPOnly flag not being set for session cookies have been identified.

Utilize a web browser or other web application diagnostic tool to view the session cookies the application sets on the client.

Internet Explorer versions 8, 9, and 10 includes a utility called Developer tools.

Access the application website and establish an application session.

Access the page that sets the session cookie.

Press “F12” to open Developer Tools.

Select "cache" and then "view cookie information".

Identify the session cookies. An example of an HTTPOnly session cookie is as follows:

Set-Cookie: SessionId=z5ymkk45aworjo2l31tlhqqv; path=/; HttpOnly

If the application does not set the HTTPOnly flag on session cookies or if the application administrator cannot demonstrate mitigating controls, this is a finding.

Configure the application to set the HTTPOnly flag on session cookies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001184 The information system protects the authenticity of communications sessions. NIST SP 800-53 :: SC-23 NIST SP 800-53A :: SC-23.1 NIST SP 800-53 Revision 4 :: SC-23

SC-23

HTTPOnly flag true for all session cookies

V-70203

medium

SRG-APP-000219

SV-84825r1_rule

APSC-DV-002220

The application must set the secure flag on session cookies.

Many web development frameworks such as PHP, .NET, ASP as well as application servers include their own mechanisms for session management. Whenever possible it is recommended to utilize the provided session management framework.

Setting the secure bit on session cookie ensures the session cookie is only sent via TLS/SSL HTTPS connections. This helps to ensure confidentiality as the session cookie is not able to be viewed by unauthorized parties as it transits the network.

Setting the secure flag on all cookies may also be warranted depending upon application design but at a minimum, the session cookie must always be secured.

Review the application documentation and interview the application administrator to identify when session cookies are created.

If vulnerability scan results are available, reference the most recent vulnerability scan results.

Verify that the scan configuration includes checks for the secure flag on session cookies. If scan configuration settings are not available, follow the manual procedure provided below.

Review the scan results and determine if the secure flag not being set was identified as a vulnerability.

To manually perform the check, open a web browser, logon to the web application and use the web browser to view the new session cookie.

The procedures used for viewing and clearing browser cookies will vary based upon the web browser used. Providing steps for every browser is outside the scope of the STIG. There are numerous sites that document how to view cookies using various web browsers.

For IE11: Alt-X >> Internet options >> General >> Settings >> View Files

A windows explorer box will open that contains the contents of the Temporary Internet Files. Browse the folder and locate the application session cookie(s). View the contents of the cookie(s).

If the "secure" flag is not set on the session cookie, or if the vulnerability scan results indicate the application does not set the secure flag on cookies, this is a finding.

Configure the application to ensure the secure flag is set on session cookies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001184 The information system protects the authenticity of communications sessions. NIST SP 800-53 :: SC-23 NIST SP 800-53A :: SC-23.1 NIST SP 800-53 Revision 4 :: SC-23

SC-23

Secure flag is not set. Recommend use of TLS v1.2 communication to the Console’s UI and API

V-70209

medium

SRG-APP-000223

SV-84831r1_rule

APSC-DV-002250

Applications must use system-generated session identifiers that protect against session fixation.

Session fixation allows an attacker to hijack a valid user’s application session. The attack focuses on the manner in which a web application manages the user’s session ID. Applications become vulnerable when they do not assign a new session ID when authenticating users thereby using the existing session ID.

Many web development frameworks such as PHP, .NET, and ASP include their own mechanisms for session management. Whenever possible it is recommended to utilize the provided session management framework.

In many cases, creating a new session ID cookie containing a new unique value whenever authentication is performed will address the issue of session fixation.

Allowing the user to submit a session ID also introduces the risk that the application could be subject to a session fixation attack.

Review the application documentation and interview the application administrator to identify how the application generates user session IDs.

Application session testing is required in order to verify this requirement.

Request the latest application vulnerability or penetration test results.

Verify the test configuration includes session handling vulnerability tests.

If the application is re-using/copying the users existing session ID that was created on one system in order to maintain user state when traversing multiple application servers in the same domain, this is not a finding.

If the session testing results indicate application session IDs are re-used after the user has logged out, this is a finding.

Design the application to generate new session IDs with unique values when authenticating user sessions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001664 The information system recognizes only session identifiers that are system-generated. NIST SP 800-53 :: SC-23 (3) NIST SP 800-53A :: SC-23 (3).1 (ii) NIST SP 800-53 Revision 4 :: SC-23 (3)

SC-23 (3)

SessionIDs are generated for each authentication

V-70211

medium

SRG-APP-000223

SV-84833r1_rule

APSC-DV-002260

Applications must validate session identifiers.

Many web development frameworks such as PHP, .NET, and ASP include their own mechanisms for session management. Whenever possible it is recommended to utilize the provided session management framework.

Review the application documentation and interview the application administrator.

Identify how the application validates session IDs.

If using a web development framework, ask the application administrator to provide details on the framework’s session configuration as it relates to session validation.

If the application is not configured to validate user session identifiers, this is a finding.

Configure the application to configure user session identifiers.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001664 The information system recognizes only session identifiers that are system-generated. NIST SP 800-53 :: SC-23 (3) NIST SP 800-53A :: SC-23 (3).1 (ii) NIST SP 800-53 Revision 4 :: SC-23 (3)

SC-23 (3)

SessionIDs are generated for each authentication

V-70213

medium

SRG-APP-000223

SV-84835r1_rule

APSC-DV-002270

Applications must not use URL embedded session IDs.

Many web development frameworks such as PHP, .NET, and ASP include their own mechanisms for session management. Whenever possible it is recommended to utilize the provided session management framework.

Using a session ID that is copied to the URL introduces the risks that the session ID information will be written to log files, made available in browser history files, or made publicly available within the URL.

Using cookies to establish session ID information is desired.

Review the application documentation and interview the application administrator.

Identify how the application generates session IDs.

If using a web development framework, ask the application administrator to provide details on the framework’s session configuration.

Review the framework configuration setting to determine how the session identifiers are created.

Identify any compensating controls that may be leveraged to minimize risk to user sessions.

If the framework or the application is configured to transmit cookies within the URL or via URL rewriting, or if the session ID is created using a GET method and there are no compensating controls configured to address user session security, this is a finding.

Configure the application to transmit session ID information via cookies.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001664 The information system recognizes only session identifiers that are system-generated. NIST SP 800-53 :: SC-23 (3) NIST SP 800-53A :: SC-23 (3).1 (ii) NIST SP 800-53 Revision 4 :: SC-23 (3)

SC-23 (3)

SessionID is within the cookie

V-70215

medium

SRG-APP-000223

SV-84837r1_rule

APSC-DV-002280

The application must not re-use or recycle session IDs.

Many web development frameworks such as PHP, .NET, and ASP include their own mechanisms for session management. Whenever possible it is recommended to utilize the provided session management framework.

Session identifiers are assigned to application users so they can be uniquely identified. This allows the user to customize their web application experience and also allows the developer to differentiate between users thereby providing the opportunity to customize the user’s features and functions.

Once a user has logged out of the application or had their session terminated, their session IDs should not be re-used. Session IDs should also not be used for other purposes such as creating unique file names and they should also not be re-assigned to other users once the original user has logged out or otherwise quit the application.

Allowing session ID reuse increases the risk of replay attacks.

Session testing is a detailed undertaking and is usually done in the course of a web application vulnerability or penetration assessment.

Review the application documentation and interview the application administrator to identify how the application generates user session IDs.

Application session testing is required in order to verify this requirement.

Request the latest application vulnerability or penetration test results.

Verify the test configuration includes session handling vulnerability tests.

If the application is re-using/copying the users existing session ID that was created on one system in order to maintain user state when traversing multiple application servers in the same domain, this is not a finding.

If the session testing results indicate application session IDs are re-used after the user has logged out, this is a finding.

Design the application to not re-use session IDs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001664 The information system recognizes only session identifiers that are system-generated. NIST SP 800-53 :: SC-23 (3) NIST SP 800-53A :: SC-23 (3).1 (ii) NIST SP 800-53 Revision 4 :: SC-23 (3)

SC-23 (3)

SessionIDs are not reused

V-70217

medium

SRG-APP-000224

SV-84839r1_rule

APSC-DV-002290

The application must use the Federal Information Processing Standard (FIPS) 140-2-validated cryptographic modules and random number generator if the application implements encryption, key exchange, digital signature, and hash functionality.

Sequentially generated session IDs can be easily guessed by an attacker. Employing the concept of randomness in the generation of unique session identifiers helps to protect against brute-force attacks to determine future session identifiers.

Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions.

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).

Review the application documentation and interview the application administrator.

Identify if the application implements encryption, key exchange, digital signature, or hash functionality.

Identify the cryptographic modules utilized by the application for these functions. The application may be designed to use the crypto functionality of the underlying OS or it may be a product of the application itself.

Identify the cryptographic service provider utilized by the application and reference the NIST validation website to ensure the algorithms utilized are approved.

http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm

If the application does not use FIPS 140-2-approved encryption algorithms, this is a finding.

Configure the application to use FIPS 140-2-validated cryptographic modules when the application implements encryption, key exchange, digital signatures, random number generators, and hash functionality.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001188 The information system generates unique session identifiers for each session with organization-defined randomness requirements. NIST SP 800-53 :: SC-23 (4) NIST SP 800-53A :: SC-23 (4).1 (ii) NIST SP 800-53 Revision 4 :: SC-23 (3)

SC-23 (3)

Prisma Cloud Compute uses the Golang’s crypto library which is not a NIST validated cryptographic module. Uses NIST approved algorithms

V-70219

medium

SRG-APP-000427

SV-84841r1_rule

APSC-DV-002300

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

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established.

The DoD will only accept PKI certificates obtained from a DoD-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).

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 DoD-approved PKI and ECA certificates, this is a finding.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002470 The information system only allows the use of organization-defined certificate authorities for verification of the establishment of protected sessions. NIST SP 800-53 Revision 4 :: SC-23 (5)

SC-23 (5)

Prisma Cloud Compute Console’s TLS v1.2 (HTTPS) communications can be configured to use DoD issued TLS certificates, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/configure/custom_certs_console_access.html

V-70223

medium

SRG-APP-000226

SV-84845r1_rule

APSC-DV-002320

In the event of a system failure, applications must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes.

Review application documentation, interview application administrator to identify how the application logs error events.

The application operational requirements documentation should provide the specific information that must be preserved in order to return the application back into operation as quickly and efficiently as possible. The application administrator will need to identify and provide the information based upon operational requirements documents.

Application diagnostic information should be kept in logs for evaluation and investigation into root cause.

If documentation is provided stating that no particular information needs to be retained in order to expediently bring the application back online, this is not a finding.

If the application does not log the data required to determine root cause of application failure, or if information specified as required in order to expediently bring the application back online is not retained, this is a finding.

Create operational configuration documentation that identifies information needed for the application to return back into service or specify no such data is required, and retain data required to determine root cause of application failures.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001665 The information system preserves organization-defined system state information in the event of a system failure. NIST SP 800-53 :: SC-24 NIST SP 800-53A :: SC-24.1 (v) NIST SP 800-53 Revision 4 :: SC-24

SC-24

Application diagnostic audits are captured within the debug logs

V-70225

medium

SRG-APP-000231

SV-84847r1_rule

APSC-DV-002330

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

Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive and tape drive) within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered.

Applications and application users generate information throughout the course of their application use, including data that is stored in areas of volatile memory. Volatile memory must not be overlooked when assigning protections.

This requirement addresses protection of user-generated data, as well as, operating system-specific configuration data.

Applications must employ mechanisms to achieve confidentiality and integrity protections, as appropriate, in accordance with the security category and/or classification of the information.

This can include segmenting and controlling access to the data such as utilizing file permissions to restrict access, using role based controls to restrict access or applying a cryptographic hash to the data and evaluating hash values for changes made to data.

Review the application documentation and interview the application administrator.

Identify the data processed by the application and the accompanying data protection requirements.

Determine if the data owner has specified stored data protection requirements.

Determine if the application is processing publicly releasable, FOUO or classified stored data.

Determine if the application configuration information contains sensitive information.

Access the data repository and have the application administrator, application developer or designer identify the data integrity and confidentiality protections utilized to protect stored data.

If the application processes classified data or if the data owner has specified data protection requirements and the application administrator is unable to demonstrate how the data is protected, this is a finding.

Identify data elements that require protection. Document the data types and specify protection requirements and methods used.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001199 The information system protects the confidentiality and/or integrity of organization-defined information at rest. NIST SP 800-53 :: SC-28 NIST SP 800-53A :: SC-28.1 NIST SP 800-53 Revision 4 :: SC-28

SC-28

Prisma Cloud Compute operates completely within the environment it is deployed, thus assuming the classification level of the environment it is protecting

V-70227

medium

SRG-APP-000428

SV-84849r1_rule

APSC-DV-002340

The application must implement approved cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest on organization-defined information system components.

Applications handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest.

Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Review the documentation and interview the application administrator.

Identify the data processed by the application and the accompanying data protection requirements.

Determine if the data owner has specified data protection encryption requirements regarding modification of data.

Determine if the application is processing publicly releasable, FOUO or classified data.

Determine if the application configuration information contains sensitive information.

If the data is strictly publicly releasable information and system documentation specifies no data encryption is required for any hosted application data, this is not applicable.

Access the data repository and have the application administrator identify the encryption protections that are utilized.

If the application processes classified data or if the data owner has specified encryption requirements and the application administrator is unable to demonstrate how the data is encrypted, this is a finding.

Identify data elements that require protection.

Document the data types and specify encryption requirements.

Encrypt data according to DoD policy or data owner requirements.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002475 The information system implements cryptographic mechanisms to prevent unauthorized modification of organization-defined information at rest on organization-defined information system components. NIST SP 800-53 Revision 4 :: SC-28 (1)

SC-28 (1)

The Prisma Cloud database is not encrypted at rest, however all credentials and otherwise secure information is encrypted with AES 256 bit encryption. If you require data at rest to be encrypted, then underlying persistence storage /var/lib/twistlock can be mounted with one of the many options that support this.

V-70229

medium

SRG-APP-000429

SV-84851r1_rule

APSC-DV-002350

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

Applications handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest.

Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Special care must be taken to cryptographically protect classified data.

Review the application documentation and interview the application administrator.

Identify the data processed by the application and the accompanying data protection requirements.

Determine if the application is processing publicly releasable, SBU, FOUO, or classified data.

If the data is strictly publicly releasable information with no SBU, FOUO, or classified and system documentation specifies no data encryption is required for any hosted application data, this requirement is not applicable.

Have the application administrator identify the encryption protections that are utilized.

Validate the application is using encryption protections that are commensurate with the data being protected.

If the application is processing classified data, type 1, suite B cryptography, or hardware-based encryption solutions; meeting NSA encryption requirements for classified data processing and storage is required.

If the application processes classified data or if the data owner has specified encryption requirements and the application administrator is unable to demonstrate the type of encryption used or if the application processes classified and does not use type 1, suite B, or NSA-approved hardware-based encryption, this is a finding.

Identify data elements that require protection.

Document the data types and specify encryption requirements.

Encrypt classified data using Type 1, Suite B, or other NSA-approved encryption solutions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002476 The information system implements cryptographic mechanisms to prevent unauthorized disclosure of organization-defined information at rest on organization-defined information system components. NIST SP 800-53 Revision 4 :: SC-28 (1)

SC-28 (1)

The Prisma Cloud database is not encrypted at rest, however all credentials and otherwise secure information is encrypted with AES 256 bit encryption. If you require data at rest to be encrypted, then underlying persistence storage /var/lib/twistlock can be mounted with one of the many options that support this.

V-70231

medium

SRG-APP-000233

SV-84853r1_rule

APSC-DV-002360

The application must isolate security functions from non-security functions.

An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions.

Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based.

Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. Applications restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities.

Review the application documentation and interview the application administrator.

Identify if the application utilizes access controls.

Commonly employed access controls include Role-Based Access Controls (RBAC), Access Control Lists (ACL) and Mandatory Access Controls (MAC).

Ensure the application utilizes a control structure that is capable of protecting security assets such as policy and configuration settings from unauthorized modification.

If the application does not protect security functions that enforce security policy and protect security configuration settings, this is a finding.

Implement controls within the application that limits access to security configuration functionality and isolates regular application function from security-oriented function.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001084 The information system isolates security functions from nonsecurity functions. NIST SP 800-53 :: SC-3 NIST SP 800-53A :: SC-3.1 (ii) NIST SP 800-53 Revision 4 :: SC-3

SC-3

Prisma Cloud Compute enforces role based access, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/access_control/user_roles.html

V-70233

medium

SRG-APP-000431

SV-84855r1_rule

APSC-DV-002370

The application must maintain a separate execution domain for each executing process.

Applications can maintain separate execution domains for each executing process by assigning each process a separate address space. Each process has a distinct address space so that communication between processes is performed in a manner controlled through the security functions, and one process cannot modify the executing code of another process. Maintaining separate execution domains for executing processes can be achieved, for example, by implementing separate address spaces.

An example is a web browser with process isolation that provides tabs that are separate processes using separate address spaces to prevent one tab crashing the entire browser.

Review the application documentation, the architecture documentation and interview the application administrator.

Identify if the application architecture provides the capability to sandbox executing processes so as to prevent a process in one application domain from sharing another application domain.

Ask the application administrator to demonstrate how the application processes are separated. This may be demonstrated by examining the OS processes running on the system and identifying the separate application processes.

If the application does not maintain a separate execution domain for each executing process, this is a finding.

Design and configure applications to maintain a separate execution domain for each executing process.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002530 The information system maintains a separate execution domain for each executing process. NIST SP 800-53 Revision 4 :: SC-39

SC-39

Prisma Cloud Compute runs as containers, uses cgroups for memory, cpu and i/o isolation

V-70235

medium

SRG-APP-000243

SV-84857r1_rule

APSC-DV-002380

Applications must prevent unauthorized and unintended information transfer via shared system resources.

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 DoD 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.

Review the application documentation and interview the application administrator to identify if the application shares information resources via file sharing protocol or if the application includes configuration settings that provide access to data files on the hard drive.

Also determine if the application transfers data via shared system resources.

If the application shares system resources with other applications, verify that a security boundary exists which controls and prevents other applications, processes, or users from accessing application data. The control mechanism will vary based upon the resource that is being shared. Hard disk sharing could possibly utilize file permissions restrictions, whereas shared overall system resources could implement virtualization or containers that restrict access.

If the application does not prevent unauthorized and unintended information transfer via shared system resources, this is a finding.

 Configure or design the application to utilize a security control that will implement a boundary that will prevent unauthorized and unintended information transfer via shared system resources.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001090 The information system prevents unauthorized and unintended information transfer via shared system resources. NIST SP 800-53 :: SC-4 NIST SP 800-53A :: SC-4.1 NIST SP 800-53 Revision 4 :: SC-4

SC-4

Prisma Cloud Compute runs as containers, uses cgroups for memory, cpu and i/o isolation

V-70237

medium

SRG-APP-000435

SV-84859r1_rule

APSC-DV-002390

XML-based applications must mitigate DoS attacks by using XML filters, parser options, or gateways.

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

XML-based applications are susceptible to DoS attacks due to the nature of XML parsing being processor intensive and complicated.

Best practice for parsing XML to avoid DoS include:

- Using a proven XML parser - Using an XML gateway that provides DoS protection - Using parser options that provide limits on recursive payloads, oversized payloads, and entity expansion.

This requirement addresses the configuration of applications to mitigate the impact of DoS attacks that have occurred or are ongoing on application availability. For each application, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the application opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Review the application architecture documentation and interview the application administrator to identify what steps have been taken to protect the XML aspect of the application from DoS attacks.

If the application does not contain or utilize XML, the requirement is not applicable.

Ask the application administrator to demonstrate how the application is configured to provide the following protections:

- Validation against recursive payloads - Validation against oversized payloads - Protection against XML entity expansion - Validation against overlong element names - Optimized configuration for maximum message throughput

If the application administrator cannot demonstrate how these protections are implemented either within the application itself or by third-party tools or utilities like an XML gateway, this is a finding.

Implement:

- Validation against recursive payloads - Validation against oversized payloads - Protection against XML entity expansion - Validation against overlong element names - Optimized configuration for maximum message throughput in order to ensure DoS attacks against web services are limited.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002385 The information system protects against or limits the effects of organization-defined types of denial of service attacks by employing organization-defined security safeguards. NIST SP 800-53 Revision 4 :: SC-5

SC-5

Not applicable, Prisma Cloud Compute is a JSON-based application

V-70239

medium

SRG-APP-000246

SV-84861r1_rule

APSC-DV-002400

The application must restrict the ability to launch Denial of Service (DoS) attacks against itself or other information systems.

Denial of Service (DoS) is a condition where a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

Individuals of concern can include hostile insiders or external adversaries that have access or have successfully breached the information system and are using the system as a platform to launch cyber attacks on the application, the application host or other third-parties.

Application developers and application administrators must take the steps needed to ensure an application cannot be used to launch DoS attacks against the application itself, the application host or other systems and networks.

Application developers should be cognizant that many attackers using DoS techniques will attempt to identify resource intensive processes and functions within the application. For web applications, this can be application objects that perform database queries or other resource intensive tasks. Improper application memory management can also lead to memory leaks which can exhaust system resources forcing a system or application restart.

Limiting attempts to repeatedly execute application processes by validating the requests also reduces the ability to launch some DoS attacks.

For application administrators, ensuring network access controls are in place to protect the application host.

The methods employed to counter DoS risks are dependent upon the application layer methods that can be used to exploit it.

Review the application documentation and interview the application administrator.

Ask the application administrator if any anti-DoS technology or anti-DoS emergency response services are deployed to protect the application.

Check for code review, penetration or vulnerability test results that attempt to DoS the application or use the application as a DoS tool.

Examine test results and testing configuration to ensure that the application was tested and the application was not reported as being susceptible to DoS attacks either from external sources or from the application itself. Also verify the testing results show that the application cannot be weaponized to attack other systems.

If the test results indicate the application is susceptible to DoS attacks or can be weaponized to attack other applications or systems, this is a finding.

Design and deploy the application to utilize controls that will prevent the application from being affected by DoS attacks or being used to attack other systems. This includes but is not limited to utilizing throttling techniques for application traffic such as QoS or implementing logic controls within the application code itself that prevents application use that results in network or system capabilities being exceeded.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001094 The information system restricts the ability of individuals to launch organization-defined denial of service attacks against other information systems. NIST SP 800-53 :: SC-5 (1) NIST SP 800-53A :: SC-5 (1).1 NIST SP 800-53 Revision 4 :: SC-5 (1)

SC-5 (1)

Scan intervals are configurable. Throttling measure have been implemented to reduce the chance of denial of service

V-70241

medium

SRG-APP-000247

SV-84863r1_rule

APSC-DV-002410

The web service design must include redundancy mechanisms when used with high-availability systems.

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

In the case of application DoS attacks, care must be taken when designing the application to ensure the application makes the best use of system resources. SQL queries have the potential to consume large amounts of CPU cycles if they are not tuned for optimal performance. Web services containing complex calculations requiring large amounts of time to complete can bog down if too many requests for the service are encountered within a short period of time.

The methods employed to meet this requirement will vary depending upon the technology the application utilizes. However, a variety of technologies exist to limit or, in some cases, eliminate the effects of application related DoS attacks. Employing increased capacity and bandwidth combined with specialized application layer protection devices and service redundancy may reduce the susceptibility to some DoS attacks.

Interview the application administrator and review the system documentation to determine if the application has been designated as a high availability system and if the application is designed to operate in a high availability environment.

If the application has not been designated as a high availability system, this requirement is not applicable.

Review the application architecture documentation and identify solutions that provide application DoS protections.

Verify the application has been built to work in a clustered or otherwise high availability environment in accordance with documented availability requirements.

This includes:

- load balancers - redundant systems such as multiple web, application servers or DB servers - high bandwidth or redundant data circuits - multiple data centers (geographic dispersal) - server clusters

If the application has been designated as high availability but the architecture is not built to high availability standards, this is a finding.

Build the application to address issues that are found in a redundant environment and utilize redundancy mechanisms to provide high availability.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001095 The information system manages excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of denial of service attacks. NIST SP 800-53 :: SC-5 (2) NIST SP 800-53A :: SC-5 (2).1 NIST SP 800-53 Revision 4 :: SC-5 (2)

SC-5 (2)

The adoption of container orchestrators, such as Kubernetes and OpenShift, continues to increase, and orchestrators offer powerful, built-in high availability capabilities. We recommend that customers start migrating their Console deployments to orchestrated environments for their high availability needs.

V-70247

medium

SRG-APP-000440

SV-84869r1_rule

APSC-DV-002450

The application must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).

Data is subject to manipulation and other integrity related attacks whenever that data is transferred across a network. To protect data integrity during transmission, the application must implement mechanisms to ensure the integrity of all transmitted information.

All transmitted information means that the protections are not restricted to just the data itself. Protection mechanisms must be extended to include data labels, security parameters, or metadata if data protection requirements specify.

Modern web application data transfer methods can be complex and are not necessarily just point-to-point in nature. Service-Oriented Architecture (SOA) and RESTFUL web services allow for XML-based application data to be transmitted in a manner similar to network traffic wherein the application data is transmitted along multiple servers' hops.

In such cases, point-to-point protection methods like TLS or SSL may not be the best choice for ensuring data integrity and alternative data integrity protection methods like XML Integrity Signature protections where the XML payload itself is signed may be required as part of the application design.

Overall application design and architecture must always be taken into account when establishing data integrity protection mechanisms. Custom-developed solutions that provide a file transfer capability should implement data integrity checks for incoming and outgoing files. Transmitted information requires mechanisms to ensure the data integrity (e.g., digital signatures, SSL, TLS, or cryptographic hashing).

Review the application documentation, the application architecture designs and interview the application administrator.

Ask the application admin to identify the network path taken by the application data and demonstrate the application support integrity mechanisms for transmission of both incoming and outgoing files and any transmitted data.

For example, hashing/digital signature and cyclic redundancy checks (CRCs) can be used to confirm integrity on data streams and transmitted files.

Use of TLS can be used to assure integrity in point-to-point communication sessions.

When the application uses messaging or web services or other technologies where the data can traverse multiple hops, the individual message or packet must be encrypted to protect the integrity of the message.

If the application is not configured to provide cryptographic protections to application data while it is transmitted unless protected by alternative safety measures like a PDS, this is a finding.

Configure the application to use cryptographic protections to prevent unauthorized disclosure of application data based upon the application architecture.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002421 The information system implements cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by organization-defined alternative physical safeguards. NIST SP 800-53 Revision 4 :: SC-8 (1)

SC-8 (1)

Prisma Cloud Compute is deployed within the customer’s environment. The routing path to the Console is dependent upon the location of the Console and users’ workstations

V-70249

medium

SRG-APP-000441

SV-84871r1_rule

APSC-DV-002460

The application must maintain the confidentiality and integrity of information during preparation for transmission.

Data is subject to manipulation and other integrity related attacks whenever that data is transferred across a network. To protect data integrity during transmission, the application must implement mechanisms to ensure the integrity of all transmitted information. All transmitted information means that the protections are not restricted to just the data itself. Protection mechanisms must be extended to include data labels, security parameters or metadata if data protection requirements specify. Modern web application data transfer methods can be complex and are not necessarily just point-to-point in nature. Service-Oriented Architecture (SOA) and RESTFUL web services allow for XML-based application data to be transmitted in a manner similar to network traffic wherein the application data is transmitted along multiple servers' hops. In such cases, point-to-point protection methods like TLS or SSL may not be the best choice for ensuring data integrity and alternative data integrity protection methods like XML Integrity Signature protections where the XML payload itself is signed may be required as part of the application design. Overall application design and architecture must always be taken into account when establishing data integrity protection mechanisms. Custom-developed solutions that provide a file transfer capability should implement data integrity checks for incoming and outgoing files. Transmitted information requires mechanisms to ensure the data integrity (e.g., digital signatures, SSL, TLS, or cryptographic hashing).

Review the application documentation and interview the application administrator.

Identify web servers and associated network connections.

Access the application with a web browser.

Verify the web browser goes secure automatically by automatically redirecting the browser to a secure port running TLS encryption, or ensure the port used by the application uses TLS encryption by default.

For tiered applications, (web server, application server, database server) verify the communication channels between the tiers is also encrypted.

If the application does not utilize TLS to protect the confidentiality and integrity of transmitted information, this is a finding.

Configure all of the application systems to require TLS encryption.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002420 The information system maintains the confidentiality and/or integrity of information during preparation for transmission. NIST SP 800-53 Revision 4 :: SC-8 (2)

SC-8 (2)

TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console <→ Defender communication via mutual TLS v1.2 web socket session

V-70251

medium

SRG-APP-000442

SV-84873r1_rule

APSC-DV-002470

The application must maintain the confidentiality and integrity of information during reception.

Data is subject to manipulation and other integrity related attacks whenever that data is transferred across a network. To protect data integrity during transmission, the application must implement mechanisms to ensure the integrity of all transmitted information. All transmitted information means that the protections are not restricted to just the data itself. Protection mechanisms must be extended to include data labels, security parameters or metadata if data protection requirements specify. Modern web application data transfer methods can be complex and are not necessarily just point-to-point in nature. Service-Oriented Architecture (SOA) and RESTFUL web services allow for XML-based application data to be transmitted in a manner similar to network traffic wherein the application data is transmitted along multiple servers' hops. In such cases, point-to-point protection methods like TLS or SSL may not be the best choice for ensuring data integrity and alternative data integrity protection methods like XML Integrity Signature protections where the XML payload itself is signed may be required as part of the application design. Overall application design and architecture must always be taken into account when establishing data integrity protection mechanisms. Custom-developed solutions that provide a file transfer capability should implement data integrity checks for incoming and outgoing files. Transmitted information requires mechanisms to ensure the data integrity (e.g., digital signatures, SSL, TLS, or cryptographic hashing).

Review the application documentation and interview the application administrator.

Identify web servers and associated network connections.

Access the application with a web browser.

Verify the web browser goes secure automatically by automatically redirecting the browser to a secure port running TLS encryption, or ensure the port used by the application uses TLS encryption by default.

For tiered applications, (web server, application server, database server) ensure the communication channels between the tiers is also encrypted.

If the application does not utilize TLS to protect the confidentiality and integrity of transmitted information, this is a finding.

Configure all of the application systems to require TLS encryption.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002422 The information system maintains the confidentiality and/or integrity of information during reception. NIST SP 800-53 Revision 4 :: SC-8 (2)

SC-8 (2)

TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console <→ Defender communication via mutual TLS v1.2 web socket session

V-70253

medium

SRG-APP-000441

SV-84875r1_rule

APSC-DV-002480

The application must not disclose unnecessary information to users.

Applications should not disclose information not required for the transaction. (e.g., a web application should not divulge the fact there is a SQL server database and/or its version).

These events usually occur when the web application has not been configured to send specific error messages for error events. Instead, when a processing anomaly occurs, the application displays technical information about the type of application server, database in use, or other technical details.

This provides attackers additional information which they can use to find other attack avenues, or tailor specific attacks, on the application.

Review the application system documentation and interview the application administrators.

Ask them to demonstrate how the web server and application configuration does not disclose any information about the application which could be used by an attacker to gain access to the application.

Ask the application representative to logon as a non-privileged user and review all screens of the application to identify any potential data that should not be disclosed to the user.

Review web server configuration and determine if custom error pages are configured to display on error events.

Review error pages sent to application users to verify the pages are generic in nature and provide no technical details related to application architecture.

If the application displays any application technical data such as database version, application server information, or any other technical details that should not be disclosed to a regular user, this is a finding.

Configure the application to not display technical details about the application architecture on error events.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002420 The information system maintains the confidentiality and/or integrity of information during preparation for transmission. NIST SP 800-53 Revision 4 :: SC-8 (2)

SC-8 (2)

User session errors contain minimal information as to the technical implementation

V-70259

medium

SRG-APP-000251

SV-84881r1_rule

APSC-DV-002500

The application must protect from Cross-Site Request Forgery (CSRF) vulnerabilities.

Cross-Site Request Forgery (CSRF) is an attack where a website user is forced to execute an unwanted action on a website that he or she is currently authenticated to. An attacker, through social engineering (e.g., e-mail or chat) creates a hyperlink which executes unwanted actions on the website the victim is authenticated to and sends it to the victim. If the victim clicks on the link, the action is executed unbeknownst to the victim.

A CSRF attack executes a website request on behalf of the user which can lead to a compromise of the user’s data. What is needed to be successful is for the attacker to know the URL, an authenticated application user, and trick the user into clicking the malicious link.

While XSS is not needed for a CSRF attack to work, XSS vulnerabilities can provide the attacker with a vector to obtain information from the user that may be used in mitigating the risk. The application must not be vulnerable to XSS as an XSS attack can be used to help defeat token, double-submit cookie, referrer and origin-based CSRF defenses.

Review the application documentation, the code review reports and the vulnerability assessment scan results from the automated vulnerability assessment tools.

Verify scan configuration settings include web-based application settings which include XSS tests.

Review the scan results for CSRF vulnerabilities.

If the scan results indicate aspects of the application are vulnerable to CSRF, request subsequent scan data that shows the CSRF vulnerabilities previously detected have been fixed.

If results that show compliance are not available, request proof of any steps that have been taken to mitigate the risk.

Mitigation steps include using web reputation filters to identify sources of exploits delivered via CSRF, web application firewalls that validate cookie and the referrer field in the HTTP headers, or product specific IPS filters that identify and intercept known CSRF vulnerabilities in web-based applications.

If scan results are not available ask the application administrator to provide evidence that shows the application is designed to address CSRF security issues. There are various methods for mitigating the risk, including using a challenge token that is tied to the users session.

If application scan results show an unremediated CSRF vulnerability, or if no scan results are available, or no mitigations have been enabled, this is a finding.

Configure the application to use unpredictable challenge tokens and check the HTTP referrer to ensure the request was issued from the site itself. Implement mitigating controls as required such as using web reputation services.

false

APSC-DV-002500

Use web reputation services web application, validate cookie and the referrer field in the HTTP headers, or use product specific IPS filters that identify and intercept known CSRF vulnerabilities in web-based applications.

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001310 The information system checks the validity of organization-defined inputs. NIST SP 800-53 :: SI-10 NIST SP 800-53A :: SI-10.1 NIST SP 800-53 Revision 4 :: SI-10

SI-10

Implement Prisma Cloud Compute Web-Application and API Security (WAAS) to protect Console API from common web based attacks, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/firewalls/deploy_waas.html

V-70263

medium

SRG-APP-000251

SV-84885r1_rule

APSC-DV-002520

The application must protect from canonical representation vulnerabilities.

Canonical representation vulnerabilities can occur when a data conversion process does not convert the data to its simplest form resulting in the possible misrepresentation of the data.

The application may behave in an unexpected manner when acting on input that has not been sanitized or normalized.

Vulnerable application code is written to expect one form of data and executes its program logic on another form of data thereby creating instability or unexpected behavior.

The Open Web Application Security Project (OWASP) website provides test and remediation procedures that can be used for testing if vulnerability scan tools or results are not available.

The site is available by pointing your browser to https://www.owasp.org.

Review the application documentation and interview the application administrator for details regarding security assessment code reviews or vulnerability scans.

Review the scan results from the entire application. This can be provided as results from an automated code review or a vulnerability scanning tool.

Review the scan results to determine if there are any existing canonical representation vulnerabilities.

Review web server and application configuration.

The OWASP website provides the following test procedures:

"Investigate the web application to determine if it asserts an internal code page, locale, or culture.

If the default character set, locale is not asserted it will be one of the following:

HTTP Posts. Interesting tidbit: All HTTP posts are required to be ISO 8859-1, which will lose data for most double byte character sets. You must test your application with your supported browsers to determine if they pass in fully encoded double byte characters safely

HTTP Gets. Depends on the previously rendered page and per-browser implementations, but URL encoding is not properly defined for double byte character sets. IE can be optionally forced to do all submits as UTF-8 which is then properly canonicalized on the server

.NET: Unicode (little endian)

JSP implementations, such as Tomcat: UTF8 - see “javaEncoding” in web.xml by many servlet containers

Java: Unicode (UTF-16, big endian, or depends on the OS during JVM startup)

PHP: Set in php.ini, ISO 8859-1”

If the results are not provided or the application representative cannot demonstrate that the application does not use Unicode encoding, this is a finding.

A suitable canonical form should be chosen and all user input canonicalized into that form before any authorization decisions are performed.

Security checks should be carried out after decoding is completed. Moreover, it is recommended to check that the encoding method chosen is a valid canonical encoding for the symbol it represents.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001310 The information system checks the validity of organization-defined inputs. NIST SP 800-53 :: SI-10 NIST SP 800-53A :: SI-10.1 NIST SP 800-53 Revision 4 :: SI-10

SI-10

Implement Prisma Cloud Compute Web-Application and API Security (WAAS) to protect Console API from common web based attacks, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/firewalls/deploy_waas.html

V-70265

medium

SRG-APP-000251

SV-84887r1_rule

APSC-DV-002530

The application must validate all input.

Checking the valid syntax and semantics of information system inputs (e.g., character set, length, numerical range, and acceptable values) verifies that inputs match specified definitions for format and content. Software applications typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components.

Structured messages can contain raw or unstructured data interspersed with metadata or control information. If software applications use attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata.

Consequently, the module or component that receives the tainted output will perform the wrong operations or otherwise interpret the data incorrectly. Prescreening inputs prior to passing to interpreters prevents the content from being unintentionally interpreted as commands. Input validation helps to ensure accurate and correct inputs and prevent attacks such as cross-site scripting and a variety of injection attacks.

Absence of input validation opens an application to improper manipulation of data. The lack of input validation can lead immediate access of application, denial of service, and corruption of data.

Invalid input includes presence of scripting tags within text fields, query string manipulation, and invalid data types and sizes.

When an application validates input, it will only execute provided input after it has evaluated the input, validated the input and determined the data is in an expected format, and content is not extraneous or malformed.

Comprehensive application security testing and code reviews are required to ensure the application is not vulnerable to input validation vulnerabilities.

Application security code reviews should be conducted during the development phase to find and address input validation errors. When code reviews are not possible, fuzz testing can be performed on the application to attempt and identify vulnerable data input fields.

Review the application documentation, the code review reports and the vulnerability assessment scan results from automated vulnerability assessment tools.

Verify scan configuration settings include input validation and fuzzing tests.

Test data entry fields on all pages/screens of the application.

Procedures on testing input are relevant to the architecture of the application.

A reference on input validation testing is included at the OWASP website. The site includes testing procedures for input validation that affect many different technologies.

Identify the relevant testing procedures based upon the application architecture and components being tested.

https://www.owasp.org/index.php/Testing_for_Input_Validation

If test results include input validation errors, or if no test results exist, this is a finding.

Design and configure the application to validate input prior to executing commands.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001310 The information system checks the validity of organization-defined inputs. NIST SP 800-53 :: SI-10 NIST SP 800-53A :: SI-10.1 NIST SP 800-53 Revision 4 :: SI-10

SI-10

All input is validated

V-70273

medium

SRG-APP-000266

SV-84895r1_rule

APSC-DV-002570

The application must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization’s operational state or can identify application components. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Error messages should not include variable names, variable types, SQL strings, or source code. Errors that contain field names from the screen and a description of what should be in the field should not be considered a finding.

Review the application documentation and interview the application administrator for details regarding how the application displays error messages.

Utilize the application as a non-privileged user and attempt to execute functionality that will generate error messages.

Review the error messages displayed to ensure no sensitive information is provided to end users.

If error messages are designed to provide users with just enough detail to pass along to support staff in order to aid in troubleshooting such as date, time, or other generic information, this is not a finding.

If variable names, SQL strings, system path information, or source or program code are displayed in error messages sent to non-privileged users, this is a finding.

Configure the server to not send error messages containing system information or sensitive data to users.

Use generic error messages.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001312 The information system generates error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. NIST SP 800-53 :: SI-11 b NIST SP 800-53A :: SI-11.1 (iii) NIST SP 800-53 Revision 4 :: SI-11 a

SI-11 a

Audit logs are only viewable by the administrator, operator and auditor roles

V-70275

medium

SRG-APP-000267

SV-84897r1_rule

APSC-DV-002580

The application must reveal error messages only to the ISSO, ISSM, or SA.

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization’s operational state or can identify application components. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Error messages should not include variable names, variable types, SQL strings, or source code. Errors that contain field names from the screen and a description of what should be in the field should not be considered a finding.

Review the application documentation and interview the application administrator for details regarding how the application displays error messages.

Authenticate to the application as a non-privileged user and attempt to execute functionality that will generate error messages.

Review the error messages displayed to ensure no sensitive information is provided to end users.

Authenticate as a privileged user and repeat tests.

If error messages are designed to provide users with just enough detail to pass along to support staff in order to aid in troubleshooting such as date, time or other generic information, this is not a finding.

If detailed error messages are provided to privileged users, this is not a finding.

If variable names, SQL strings, system path information, or source or program code are displayed in error messages sent to non-privileged users, this is a finding.

Configure the server to only send error messages containing system information or sensitive data to privileged users.

Use generic error messages for non-privileged users.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001314 The information system reveals error messages only to organization-defined personnel or roles. NIST SP 800-53 :: SI-11 c NIST SP 800-53A :: SI-11.1 (iv) NIST SP 800-53 Revision 4 :: SI-11 b

SI-11 b

Alerts can be configured to notify specific groups, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/alerts.html

V-70279

medium

SRG-APP-000454

SV-84901r1_rule

APSC-DV-002610

The application must remove organization-defined software components after updated versions have been installed.

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Review the application documentation and interview the application admin to identify application locations on system.

Identify application versions that are installed on the system.

Review the file system structure to see if older versions of the application are still installed.

If old versions of the application or components are still installed on the system, this is a finding.

Configure or design the application to remove old components when updating.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002617 The organization removes organization-defined software components (e.g., previous versions) after updated versions have been installed. NIST SP 800-53 Revision 4 :: SI-2 (6)

SI-2 (6)

Prisma Cloud Compute are distributed as docker images. Every release consists of Console and Defender images.When you upgrade Console, the old Console container is completely replaced with a new container. Because Prisma Cloud stores state information outside of the container, all your rules and settings are immediately available to the upgraded Prisma Cloud containers.

V-70281

medium

SRG-APP-000456

SV-84903r1_rule

APSC-DV-002630

Security-relevant software updates and patches must be kept up to date.

Security flaws with software applications are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.

Organization-defined time periods for updating security-relevant software may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).

This requirement will apply to software patch management solutions that are used to install patches across the enclave and also to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.

The application, or the patch management solution that is configured to patch the application, must be configured to check for and install security-relevant software updates and patches at least weekly. Patches must be applied immediately or in accordance with POA&Ms, IAVMs, CTOs, DTMs or other authoritative patching guidelines or sources.

Review the application documentation to identify application versions and patching.

Interview the application administrator and inquire about patching process.

Review IAVMs and CTOs to determine if the application is being updated in accordance with authoritative sources.

If application updates are not checked on at least on a weekly basis and applied immediately or in accordance with POA&Ms, IAVMs, CTOs, DTMs or other authoritative patching guidelines or sources, this is a finding.

Check for application updates at least weekly and apply patches immediately or in accordance with POA&Ms, IAVMs, CTOs, DTMs or other authoritative patching guidelines or sources.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002605 The organization installs security-relevant software updates within organization-defined time period of the release of the updates NIST SP 800-53 Revision 4 :: SI-2 c

SI-2 c

Every release address, mitigates and updates identified vulnerabilities.

V-70283

medium

SRG-APP-000472

SV-84905r1_rule

APSC-DV-002760

The application performing organization-defined security functions must verify correct operation of security functions.

Without verification, security functions may not operate correctly and this failure may go unnoticed.

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

This requirement applies to applications performing security functions and security function verification/testing.

Review the application documentation and interview the system administrator to determine if the application performs security function testing.

If the application is not designed or intended to perform security function testing, the requirement is not applicable.

Access the application design documents and determine if the application is designed to verify the correct operation of security functions.

Review application logs and take note of log entries that indicate security function testing is being performed and verified.

If the application is designed to perform security function testing and does not verify the correct operation of security functions, this is a finding.

Design the application to verify the correct operation of security functions.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002696 The information system verifies correct operation of organization-defined security functions. NIST SP 800-53 Revision 4 :: SI-6 a

SI-6 a

Not applicable

V-70285

medium

SRG-APP-000473

SV-84907r1_rule

APSC-DV-002770

The application must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days.

Without verification, security functions may not operate correctly and this failure may go unnoticed.

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.

This requirement applies to applications performing security functions and the applications performing security function verification/testing.

Review the application documentation and interview the system administrator to determine if the application performs security function testing.

If the application is not designed or intended to perform security function testing, the requirement is not applicable.

Access the application design documents or have the system administrator provide proof if the application is designed to verify the correct operation of security functions.

Review application logs and take note of log entries that indicate security function testing is being performed and verified on startup, restart, or on command by an authorized user.

If the application is designed to perform security function testing and does not verify the correct operation of security functions on startup, restart, or upon command by a privileged user, this is a finding.

Design the application to verify the correct operation of security functions on command and on application startup and restart.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002699 The information system performs verification of the correct operation of organization-defined security functions: when the system is in an organization-defined transitional state; upon command by a user with appropriate privileges; and/or on an organization-defined frequency. NIST SP 800-53 Revision 4 :: SI-6 b

SI-6 b

Not applicable

V-70289

medium

SRG-APP-000206

SV-84911r1_rule

APSC-DV-002870

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

Use of un-trusted Level 1A mobile code technologies can introduce security vulnerabilities and malicious code into the client system.

1A code is defined as:

- ActiveX controls - Mobile code script (JavaScript, VBScript) - Windows Scripting Host (WSH) (downloaded via URL or email)

When JavaScript and VBScript execute within the browser they are Category 3, however, when they execute in WSH, they are 1A.

Review the application documentation and interview the application administrator to identify any mobile code that is provided by the application for client consumption.

If the application does not contain mobile code, or if the mobile code executes within the client browser, this is not applicable.

The URL of the application must be added to the Trusted Sites zone. This is accomplished via the Tools, Internet Options, and “Security” Tab.

Select the “Trusted Sites” zone. Click the “sites” button. Enter the URL into the text box below the “Add this site to this zone” message. Click "Add”. Click “OK”.

Note: This requires administrator privileges to add URL to sites on a STIG compliant workstation.

Next, test the application. This testing should include functional testing from all major components of the application.

If mobile code is in use, the browser will prompt to download the control. At the download prompt, the browser will indicate that code has been digitally signed.

If the code has not been signed or the application warns that a control cannot be invoked due to security settings, this is a finding.

Configure the application so Category 1A mobile code is signed.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001166 The information system identifies organization-defined unacceptable mobile code. NIST SP 800-53 :: SC-18 (1) NIST SP 800-53A :: SC-18 (1).1 (i) NIST SP 800-53 Revision 4 :: SC-18 (1)

SC-18 (1)

Prisma Cloud Compute implements Category 3 JavaScript for the user interface

V-70291

medium

ASDV-PL-002880

SV-84913r1_rule

APSC-DV-002880

The ISSO must ensure an account management process is implemented, verifying only authorized users can gain access to the application, and individual accounts designated as inactive, suspended, or terminated are promptly removed.

A comprehensive account management process will ensure that only authorized users can gain access to applications and that individual accounts designated as inactive, suspended, or terminated are promptly deactivated. Such a process greatly reduces the risk that accounts will be misused, hijacked, or data compromised.

Interview the application representative to verify that a documented process exists for user and system account creation, termination, and expiration.

Obtain a list of recently departed personnel and verify that their accounts were removed or deactivated on all systems in a timely manner (e.g., less than two days).

If a documented account management process does not exist or unauthorized users have active accounts, this is a finding.

Establish an account management process.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002121 The organization defines the procedures or conditions to be employed when creating, enabling, modifying, disabling, and removing information system accounts. NIST SP 800-53 Revision 4 :: AC-2 f

AC-2 f

Prisma Cloud Compute can be integrated into an organization’s identity management policies and procedures. Recommend use of external identity providers (LDAP, SAML & OpenID Connect) for integration into existing identity management implementations.

V-70295

medium

ASDV-PL-002900

SV-84917r1_rule

APSC-DV-002900

The ISSO must ensure application audit trails are retained for at least 1 year for applications without SAMI data, and 5 years for applications including SAMI data.

Log files are a requirement to trace intruder activity or to audit user activity.

Verify a process is in place to retain application audit log files for one year and five years for SAMI data.

If audit logs have not been retained for one year or five years for SAMI data, this is a finding.

Retain application audit log files for one year and five years for SAMI data.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000167 The organization retains audit records for an organization-defined time period to provide support for after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements. NIST SP 800-53 :: AU-11 NIST SP 800-53A :: AU-11.1 (iii) NIST SP 800-53 Revision 4 :: AU-11

AU-11

Download audit logs on a periodic bases and retain for required period of time.

V-70297

medium

ASDV-PL-002910

SV-84919r1_rule

APSC-DV-002910

The ISSO must review audit trails periodically based on system documentation recommendations or immediately upon system security events.

Without access control the data is not secure. It can be compromised, misused, or changed by unauthorized access at any time.

Interview the application representative and ask for the system documentation that states how often audit logs are reviewed. Also, determine when the audit logs were last reviewed.

If the application representative cannot provide system documentation identifying how often the auditing logs are reviewed, or has not audited within the last time period stated in the system documentation, this is a finding.

Establish a scheduled process for reviewing logs.

Maintain a log or records of dates and times audit logs are reviewed.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001872 The organization adjusts the level of audit review and analysis within the information system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information. NIST SP 800-53 Revision 4 :: AU-6 (10)

AU-6 (10)

Audit logs can be viewed via the user interface and can be downloaded for further review

V-70301

medium

ASDV-PL-002920

SV-84923r1_rule

APSC-DV-002920

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

Violations of IA policies must be reviewed and reported. If there are no policies regarding the reporting of IA violations, IA violations may not be tracked or addressed in a proper manner.

Interview the application representative and review the SOPs to ensure that violations of IA policies are analyzed and reported.

If there is no policy for reporting IA violations, this is a finding.

Create and maintain a policy to report IA violations.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000149 The organization reports any findings to organization-defined personnel or roles for indications of organization-defined inappropriate or unusual activity. NIST SP 800-53 :: AU-6 a NIST SP 800-53A :: AU-6.1 (iii) NIST SP 800-53 Revision 4 :: AU-6 b

AU-6 b

Events can trigger alerts to the appropriate organization-defined personnel

V-70303

medium

ASDV-PL-002930

SV-84925r1_rule

APSC-DV-002930

The ISSO must ensure active vulnerability testing is performed.

Use of automated scanning tools accompanied with manual testing/validation which confirms or expands on the automated test results is an accepted best practice when performing application security testing. Automated scanning tools expedite and help to standardize security testing, they can incorporate known attack methods and procedures, test for libraries and other software modules known to be vulnerable to attack and utilize a test method known as "fuzz testing". Fuzz testing is a testing process where the application is provided invalid, unexpected, or random data. Poorly designed and coded applications will become unstable or crash. Properly designed and coded applications will reject improper and unexpected data input from application clients and remain stable.

Many vulnerability scanning tools provide automated fuzz testing capabilities for the testing of web applications. All of these tools help to identify a wide range of application vulnerabilities including, but not limited to; buffer overflows, cross-site scripting flaws, denial of service format bugs and SQL injection, all of which can lead to a successful compromise of the system or result in a denial of service.

Due to changes in the production environment, it is a good practice to schedule periodic active testing of production web applications. Ideally, this will occur prior to deployment and after updates or changes to the application production environment.

It is imperative that automated scanning tools are configured properly to ensure that all of the application components that can be tested are tested. In the case of web applications, some of the application code base may be accessible on the website and could potentially be corrected by a knowledgeable system administrator. Active testing is different from code review testing in that active testing does not require access to the application source code base. A code review requires complete code base access and is normally performed by the development team.

If vulnerability testing is not conducted, there is the distinct potential that security vulnerabilities could be unknowingly introduced into the application environment.

The following website provides an overview of fuzz testing and examples:

http://www.owasp.org/index.php/Fuzzing

Ask the application representative to provide vulnerability test procedures and vulnerability test results.

Ask the application representative to provide the settings that were used to conduct the vulnerability testing.

Verify the automated vulnerability scanning tool was appropriately configured to assure as complete a test as possible of the application architecture components. E.g., if the application includes a web server, web server tests must be included.

If the vulnerability scan report includes informational and/or non-critical results this is not a finding.

If previously identified vulnerabilities have subsequently been resolved, this is not a finding.

If the application test procedures and test results do not include active vulnerability and fuzz testing this is a finding.

If the vulnerability scan results include critical vulnerabilities, this is a finding.

If the vulnerability scanning tests are not relevant to the architecture of the application, this is a finding.

Perform active vulnerability and fuzz testing of the application.

Verify the vulnerability scanning tool is configured to test all application components and functionality.

Address discovered vulnerabilities.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000256 The organization includes as part of security control assessments announced or unannounced, one or more of the following: in-depth monitoring, vulnerability scanning; malicious user testing; insider threat assessment; performance/load testing and organization-defined other forms of security assessment on an organization-defined frequency. NIST SP 800-53 :: CA-2 (2) NIST SP 800-53A :: CA-2 (2).1 (i) NIST SP 800-53 Revision 4 :: CA-2 (2)

CA-2 (2)

All releases are scanned for vulnerabilities and are remediated accordingly

V-70307

medium

ASDV-PL-002950

SV-84929r1_rule

APSC-DV-002950

Execution flow diagrams and design documents must be created to show how deadlock and recursion issues in web services are being mitigated.

In order to understand data flows within web services, the process flow of data must be developed and documented.

There are several different ways that web service deadlock occurs, many times it is due to when a client invokes a synchronous method on a web service, the client will block waiting for the method to complete. If attempts to call the client (invoke a callback) while the client is waiting for the original method to complete, then each party will deadlock waiting for the other.

This is referred to as deadlock. The same situation could occur if a callback handler attempted to call a synchronous method on its caller.

Applications that utilize web services must account for and document how they deal with a deadlock issue. This can be accomplished by documenting data flow and specifically accounting for the risk in the design of the application.

Review the application documentation and the system diagrams detailing application system to system and service to service communication methods.

Interview the application admin to identify any application web services that are deployed by the application.

If the application does not deploy web services, the requirement is not applicable.

If the application consumes web services but is not responsible for development of the services, the requirement is not applicable.

Review the data flow diagrams and the system documentation to determine if the issue of web service deadlock is addressed.

If the issue is not addressed in the documentation or configuration settings, ask the application admin to demonstrate how deadlock issues are addressed.

If deadlock issues are not being addressed via documented web service configuration or design, this is a finding.

Develop web services to account for deadlock issues.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000336 The organization, after the information system is changed, checks the security functions to verify the functions are operating as intended. NIST SP 800-53 :: CM-4 (2) NIST SP 800-53A :: CM-4 (2).1 NIST SP 800-53 Revision 4 :: CM-4 (2)

CM-4 (2)

Prisma Cloud Compute accounts for deadlock issues

V-70309

medium

ASDV-PL-002960

SV-84931r1_rule

APSC-DV-002960

The designer must ensure the application does not store configuration and control files in the same directory as user data.

Application configuration settings and user data are required to be stored in separate locations in order to prevent application users from possibly being able to access application configuration settings or application data files. Without proper access controls and separation of application configuration settings from user data, there is the potential that existing code or configuration settings could be changed by users. These changes in code can lead to a Denial of Service (DoS) attack or allow malicious code to be placed within the application. In addition, collocating application data and code complicates many issues such as backup, recovery, directory access privilege, and upgrades.

Review the application documentation and interview the application administrator.

Ask the application administrator or examine the application documentation to determine the file location of the application configuration settings and user data.

Identify the directory where the application code, configuration settings and other application control data are located.

Identify where user data is stored.

Examine file permissions to application folder.

If the application user data is located in the same directory as the application configuration settings or control files, or if the file permissions allow application users write access to application configuration settings, this is a finding.

Separate the application user data into a different directory than the application code and user file permissions to restrict user access to application configuration settings.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000345 The organization enforces logical access restrictions associated with changes to the information system. NIST SP 800-53 :: CM-5 NIST SP 800-53A :: CM-5.1 NIST SP 800-53 Revision 4 :: CM-5

CM-5

Prisma Cloud Compute configuration files and database are located within the root only permissioned location /var/lib/twistlock

V-70311

medium

ASDV-PL-002970

SV-84933r1_rule

APSC-DV-002970

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

Not all COTS products are covered by a STIG. Those products not covered by a STIG, should follow commercially accepted best practices, independent testing results and vendors lock down guides and recommendations if they are available.

Review the application documentation to identify application name, features and version.

Identify if a DoD 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 DoD 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.

Configure the application according to the product STIG or when a STIG is not available, utilize:

- commercially accepted practices,- independent testing results, or - vendor literature and lock down guides.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000363 The organization defines security configuration checklists to be used to establish and document configuration settings for the information system technology products employed. NIST SP 800-53 :: CM-6 a NIST SP 800-53A :: CM-6.1 (i) NIST SP 800-53 Revision 4 :: CM-6 a

CM-6 a

Prisma Cloud Compute ships with default vulnerability, compliance and runtime rules. DISA STIGs for the configuration of Prisma Cloud Compute are in development.

V-70313

medium

ASDV-PL-002980

SV-84935r1_rule

APSC-DV-002980

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 DoD Ports, Protocols, and Services Management (DoD PPSM).

Failure to comply with DoD 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.

All application ports, protocols, and services needed for application operation need to be in compliance with the DoD Ports and Protocols guidance.

Check:

http://iase.disa.mil/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 DoD Ports and Protocols guidance to ensure compliance.

Identify the ports needed for the application:

- Look at System Security Plan/Accreditation documentation - Ask System Administrator - Go to Network Administrator - 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 DoD Ports and Protocols guidance, this is a finding.

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 DoD PPSM.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000388 The organization ensures compliance with organization defined registration requirements for functions, ports, protocols, and services. NIST SP 800-53 :: CM-7 (3) NIST SP 800-53A :: CM-7 (3).1 (ii) NIST SP 800-53 Revision 4 :: CM-7 (3)

CM-7 (3)

Prisma Cloud Compute TCP port usage is configurable. Default configuration: TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console <→ Defender communication via mutual TLS v1.2 web socket session

V-70317

medium

ASDV-PL-002990

SV-84939r2_rule

APSC-DV-002990

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

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

Verify registration of the application and ports in the Ports and Protocols Database for a production site.

If the application requires registration, and is not registered or all ports used have not been identified in the database, this is a finding.

Register the application and ports in the Ports and Protocols Database.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000388 The organization ensures compliance with organization defined registration requirements for functions, ports, protocols, and services. NIST SP 800-53 :: CM-7 (3) NIST SP 800-53A :: CM-7 (3).1 (ii) NIST SP 800-53 Revision 4 :: CM-7 (3)

CM-7 (3)

Prisma Cloud Compute TCP port usage is configurable. Default configuration: TCP 8081 Console user interface and API (HTTP) - disabled by default TCP 8083 Console user interface and API TLS v1.2 (HTTPS) TCP 8084 Console <→ Defender communication via mutual TLS v1.2 web socket session

V-70339

medium

ASDV-PL-002995

SV-84961r1_rule

APSC-DV-002995

The Configuration Management (CM) repository must be properly patched and STIG compliant.

A Configuration Management (CM) repository is used to manage application code versions and to securely store application code.

Failure to properly apply security patches and secure the software Configuration Management system could affect the confidentiality and integrity of the application source-code.

Compromise of the Configuration Management system could lead to unauthorized changes to applications including the addition of malware, root kits, back doors, logic bombs or other malicious functions into valid application code.

This requirement is intended to be applied to application developers or organizations responsible for code management or who have and operate an application CM repository.

Review the application system documentation and interview the application administrator.

Identify if the STIG is being applied to application developers or organizations responsible for code management or who have and operate an application CM repository. If this is not the case, the requirement is not applicable.

Review CM patch management processes and procedures. Have the system and CM admins demonstrate their patch management processes and verify the system has the latest security patches applied.

Review the ATO documentation and verify the system that operates the CM repository software has had all relevant STIGs applied.

If CM repository is not at the latest security patch level and is not operating on a STIG compliant system, this is a finding.

Patch the CM system when new security patches are made available and apply the relevant STIGs.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001795 The organization implements a configuration management plan for the information system that establishes a process for managing the configuration of the configuration items. NIST SP 800-53 Revision 4 :: CM-9 b

CM-9 b

GitHub is utilized as the Configuration Management tool. Every release is scanned with the xccdf_org.ssgproject.content_profile_ospp-rhel7-server SCAP profile and all findings are addressed

V-70341

medium

ASDV-PL-003000

SV-84963r1_rule

APSC-DV-003000

Access privileges to the Configuration Management (CM) repository must be reviewed every three months.

A Configuration Management (CM) repository is used to manage application code versions and to securely store application code.

Incorrect access privileges to the CM repository can lead to malicious code or unintentional code being introduced into the application.

This requirement is intended to be applied to application developers or organizations responsible for code management or who have and operate an application CM repository.

Review the application system documentation.

Interview the application administrator.

Identify if development of the application is done in house and if application configuration management repository exists.

If application development is not done in house and if a code configuration management repository does not exist, the requirement is not applicable.

Review CM management processes and procedures.

Verify the CM repository access permissions are reviewed at least every three months.

Ask the application administrator or the CM administrator when the last time the CM access privileges were reviewed.

If CM access privileges have not been reviewed within the last three months, this is a finding.

Review access privileges to the CM repository at least every three months.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001795 The organization implements a configuration management plan for the information system that establishes a process for managing the configuration of the configuration items. NIST SP 800-53 Revision 4 :: CM-9 b

CM-9 b

GitHub access manage is provided by Palo Alto Networks corporate SAML identity provider. Multi-factor authentication is required. Access requirements are integrated with existing corporate policies, procedures and identity management systems.

V-70343

medium

ASDV-PL-003010

SV-84965r1_rule

APSC-DV-003010

A Software Configuration Management (SCM) plan describing the configuration control and change management process of application objects developed by the organization and the roles and responsibilities of the organization must be created and maintained.

Software Configuration Management (SCM) is very important in tracking code releases, baselines, and managing access to the configuration management repository. The SCM plan identifies what should be under configuration management control.

Without an SCM plan that addresses code security issues, code releases can be tracked and vulnerabilities can be inserted intentionally or unintentionally into the code base of the application.

This requirement is intended to be applied to application developers or organizations responsible for code management or who have and operate an application configuration management repository (CMR).

The SCM plan identifies all objects created during the development process subject to configuration control.

The SCM plan maintains procedures for identifying individual application components, as well as, entire application releases during all phases of the software development lifecycle.

The SCM plan identifies and tracks all actions and changes resulting from a change request from initiation to release.

The SCM plan contains procedures to identify, document, review, and authorize any change requests to the application.

The SCM plan defines the responsibilities, the actions to be performed, the tools, techniques and methodologies, and defines an initial set of baselined software components.

The SCM plan objects have security classifications labels.

The SCM plan identifies tools and version numbers used in the software development lifecycle.

The SCM plan identifies mechanisms for controlled access of simultaneous individuals updating the same application component.

The SCM plan assures only authorized changes by authorized persons are possible.

The SCM plan identifies mechanisms to control access and audit changes between different versions of objects subject to configuration control.

The SCM plan identifies mechanisms to track and audit all modifications of objects under configuration control. Audits include the originator and date and time of the modification.

The SCM plan should contain the following:

- Description of the configuration control and change management process - Types of objects developed - Roles and responsibilities of the organization

The SCM plan should also contain the following:

- Defined responsibilities - Actions to be performed - Tools used in the process - Techniques and methodologies - Initial set of baselined software components

The SCM plan should identify all objects that are under configuration management control.

The SCM plan should identify third-party tools and respective version numbers.

The SCM plan should identify mechanisms for controlled access of individuals simultaneously updating the same application component.

The SCM plan assures only authorized changes by authorized persons are allowed.

The SCM plan should identify mechanisms to control access and audit changes between different versions of objects subject to configuration control.

The SCM plan should have procedures for label versions of application components and application builds under configuration management control.

The configuration management repository (CMR) should track change requests from beginning to end.

The configuration management repository (CMR) should authorize change requests to the application.

The configuration management repository (CMR) should contain security classification labels for code and documentation in the repository. Classification labels are not applicable to unclassified systems.

The configuration management repository (CMR) should monitor all objects under CMR control for auditing.

Interview ISSM or application administrator.

Identify if development of the application is done in house and if application configuration management repository exists.

If application development is not done in house and if a code configuration management repository does not exist, the requirement is not applicable.

Verify the SCM plan identifies all objects created during the development process subject to configuration control.

Verify the SCM plan maintains procedures for identifying individual application components, as well as, entire application releases during all phases of the software development lifecycle.

Verify the SCM plan identifies and tracks all actions and changes resulting from a change request from initiation to release.

Verify the SCM plan contains procedures to identify, document, review, and authorize any change requests to the application.

Verify the SCM plan defines the responsibilities, the actions to be performed, the tools, techniques and methodologies, and defines an initial set of base-lined software components.

Verify the SCM plan objects have security classifications labels if processing classified data.

Verify the SCM plan identifies tools and version numbers used in the software development lifecycle.

Verify the SCM plan identifies mechanisms for controlled access of simultaneous individuals updating the same application component.

Verify the SCM plan assures only authorized changes by authorized persons are possible.

Verify the SCM plan identifies mechanisms to control access and audit changes between different versions of objects subject to configuration control.

Verify the SCM plan identifies mechanisms to track and audit all modifications of objects under configuration control. Audits will include the originator and date and time of the modification.

Ask the application representative to review the applications SCM plan.

The SCM plan should contain the following:

- Description of the configuration control and change management process - Types of objects developed - Roles and responsibilities of the organization - Defined responsibilities - Actions to be performed - Tools used in the process - Techniques and methodologies - Initial set of baselined software components

If the SCM plan does not include the above, this is a finding.

The SCM plan should identify all objects that are under configuration management control. Ask the application representative to provide access to the CMR and to identify the objects shown in the SCM plan.

If the application representative cannot display all types of objects under CMR control, this is a finding.

The SCM plan should identify third-party tools and respective version numbers.

If the SCM plan does not identify third-party tools, this is a finding.

The SCM plan should identify mechanisms for controlled access of individuals simultaneously updating the same application component.

If the SCM plan does not identify mechanisms for controlled access, this is a finding.

The SCM plan assures only authorized changes by authorized persons are allowed.

If the SCM plan does not assure only authorized changes are made, this is a finding.

The SCM plan should identify the mechanisms used to control access and audit changes between different versions of objects subject to CMR control.

If the SCM plan does not identify mechanisms used to control access and to audit changes between different versions of objects subject to CMR control, this is a finding.

The SCM plan should have procedures for label versions of application components and application builds under configuration management control. Ask the application representative to demonstrate the CMR and ensure it contains versions and releases of the application. Ask the application representative to create a build or demonstrate a current release of the application that can be recreated.

If the application representative cannot display releases and application component versions, this is a finding.

The CMR should track change requests from beginning to end. Ask the application representative to display a completed or in-process change request.

If the CMR cannot track change requests, this is a finding.

If the application has just completed its first release, there may not be any change requests logged in the CMR. In this case, this finding is not applicable.

The CMR should authorize change requests to the application. Ask the application representative to display an authorized change request and identify who is responsible for authorizing change requests.

If the CMR does not track authorized change requests, this is a finding.

If the application has just completed its first release, there may not be any change requests logged in the CMR. In this case, this finding is not applicable.

The CMR should contain security classification labels for code and documentation in the repository.

Classification labels are not applicable to unclassified systems. If the applications managed by the CMR are not classified, this requirement is not applicable.

If the CMR manages classified applications and there are no classification labels of code and documentation in the CMR, this is a finding.

The CMR should audit all objects under CM control for modification.

If the CMR does not audit for modifications, this is a finding.

Create and update a SCM plan describing the configuration control and change management process of application objects developed by the organization and the roles and responsibilities of the organization. Configure CMR to comply.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001795 The organization implements a configuration management plan for the information system that establishes a process for managing the configuration of the configuration items. NIST SP 800-53 Revision 4 :: CM-9 b

CM-9 b

Software Configuration Management is employed with policy and technology (GitHub). Prisma Cloud Compute release support lifecycle is explained here, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/welcome/support_lifecycle.html

V-70345

medium

ASDV-PL-003020

SV-84967r2_rule

APSC-DV-003020

A Configuration Control Board (CCB) that meets at least every release cycle, for managing the Configuration Management (CM) process must be established.

Software Configuration Management (SCM) is very important in tracking code releases, baselines, and managing access to the configuration management repository. An SCM plan or charter identifies what should be under configuration management control. Without an SCM plan and a CCB, application releases can’t be tracked and vulnerabilities can be inserted intentionally or unintentionally into the code base of the application.

This requirement is intended to be applied to application developers or organizations responsible for code management or who have and operate an application CM repository.

Interview the application representative and determine if application development is performed on site by the organization.

If application development is not done in house, the requirement is not applicable.

If so, determine if a CCB exists. Ask about the membership of the CCB, and identify the primary members. Ask if there is CCB charter documentation.

Interview the application representative and determine how often the CCB meets.

Ask if there is CCB charter documentation. The CCB charter documentation should indicate how often the CCB meets.

If there is no charter documentation, ask when the last time the CCB met and when was the last release of the application.

CCBs do not have to physically meet, and the CCB chair may authorize a release based on phone and/or e-mail conversations.

If there is no evidence of CCB activity or meetings prior to the last release cycle, this is a finding.

Setup and maintain a Configuration Control Board.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-001795 The organization implements a configuration management plan for the information system that establishes a process for managing the configuration of the configuration items. NIST SP 800-53 Revision 4 :: CM-9 b

CM-9 b

Configuration Control Board meets weekly

V-70347

medium

ASDV-PL-003030

SV-84969r1_rule

APSC-DV-003030

The application services and interfaces must be compatible with and ready for IPv6 networks.

If the application has not been upgraded to execute on an IPv6-only network, there is a possibility the application will not execute properly, and as a result, a denial of service could occur.

In order to operate on an IPV6 network, the application must be capable of making IPV6 compatible network socket calls.

Verify the application environment is compliant with all DoD IPv6 Standards Profile for IPv6 Capable Products guidance for servers.

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

Design application to be compliant with all Department of Defense (DoD) Information Technology Standards Registry (DISR) IPv6 profiles.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002853 The information system provides the capability to employ organization-defined alternative communications protocols in support of maintaining continuity of operations. NIST SP 800-53 Revision 4 :: CP-11

CP-11

IPv6 is not supported

V-70349

medium

ASDV-PL-003040

SV-84971r1_rule

APSC-DV-003040

The application must not be hosted on a general purpose machine if the application is designated as critical or high availability by the ISSO.

Critical applications should not be hosted on a multi-purpose server with other applications. Applications that share resources are susceptible to the other shared application security defects. Even if the critical application is designed and deployed securely, an application that is not designed and deployed securely, can cause resource issues and possibly crash effecting the critical application.

Ask the application representative to review the servers where the application is deployed.

Ask what other applications are deployed on those servers.

Identify the criticality of the applications installed on the system.

If a mission critical application is deployed onto the same server as non-mission critical applications, this is a finding.

Deploy mission critical applications on servers that are not shared by other less critical applications.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-002828 The organization identifies critical information system assets supporting essential missions. NIST SP 800-53 Revision 4 :: CP-2 (8)

CP-2 (8)

Prisma Cloud Compute components run as containers and can be deployed using orchestration (e.g. kubernetes, OpenShift, etc.).

V-70351

medium

ASDV-PL-003050

SV-84973r1_rule

APSC-DV-003050

A disaster recovery/continuity plan must exist in accordance with DoD policy based on the applications availability requirements.

All applications must document disaster recovery/continuity procedures to include business recovery plans, system contingency plans, facility disaster recovery plans, and plan acceptance.

Review disaster recovery/continuity plans.

For high risk applications, verify the disaster plan exists and provides for the smooth transfer of all mission or business essential functions to an alternate site for the duration of an event with little or no loss of operational continuity.

For moderate risk applications, verify the disaster recovery/continuity plan exists and provides for the resumption of mission or business essential functions within 24 hours activation.

For low risk applications, verify the disaster recovery/continuity plan exists and provides for the partial resumption of mission or business essential functions within 5 days of activation.

If the disaster recovery/continuity plan does not exist or does not meet the severity level requirements, this is a finding.

Create and maintain the disaster recovery/continuity plan.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000445 The organization develops a contingency plan for the information system that identifies associated contingency requirements. NIST SP 800-53 :: CP-2 a NIST SP 800-53A :: CP-2.1 (i) NIST SP 800-53 Revision 4 :: CP-2 a 1

CP-2 a 1

Guidance for disaster recovery, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/configure/disaster_recovery.html

V-70353

medium

ASDV-PL-003060

SV-84975r1_rule

APSC-DV-003060

Recovery procedures and technical system features must exist so recovery is performed in a secure and verifiable manner. The ISSO will document circumstances inhibiting a trusted recovery.

Without a disaster recovery plan, the application is susceptible to interruption in service due to damage within the processing site.

If the application is part of the site’s disaster recovery plan, ensure that the plan contains detailed instructions pertaining to the application. Verify that recovery procedures indicate the steps needed for secure and trusted recovery.

Review disaster recovery plan.

Verify that a disaster recovery plan is in place for the application.

Verify that the recovery procedures include any special considerations for trusted recovery.

If the application is not part of the site’s disaster recovery plan, or if any special considerations for trusted recovery are not documented, this is a finding.

Create and maintain a disaster recovery plan.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000448 The organization develops a contingency plan for the information system that provides metrics. NIST SP 800-53 :: CP-2 a NIST SP 800-53A :: CP-2.1 (i) NIST SP 800-53 Revision 4 :: CP-2 a 2

CP-2 a 2

Guidance for disaster recovery, https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-09/prisma-cloud-compute-edition-admin/configure/disaster_recovery.html

V-70355

medium

ASDV-PL-003070

SV-84977r1_rule

APSC-DV-003070

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

Without proper backups, the application is not protected from the loss of data or the operating environment in the event of hardware or software failure.

Interview the application and system admins and review documented backup procedures.

Check the following based on the risk level of the application.

For low risk applications:

Validate backup procedures exist and are performed at least weekly.

A sampling of system backups should be checked to ensure compliance with the control.

For medium risk applications:

Validate backup procedures exist and are performed at least daily.

Validate recovery media is stored at an off-site location and ensure the data is protected in accordance with its risk category and confidentiality level. This validation can be performed by examining an SLA or MOU/MOA that states the protection levels of the data and how it should be stored.

A sampling of system backups should be checked to ensure compliance with the control.

Verify that the organization tests backup information to ensure media reliability and information integrity.

Verify that the organization selectively uses backup information in the restoration of information system functions as part of annual contingency plan testing.

For high risk applications:

Validate that the procedures have been defined for system redundancy and they are properly implemented and are executing the procedures.

Verify that the redundant system is properly separated from the primary system (i.e., located in a different building or in a different city). This validation should be performed by examining the secondary system and ensuring its operation.

Examine the SLA or MOU/MOA to ensure redundant capability is addressed. Finding details should indicate the type of validation performed. Examine the mirror capability testing procedures and results to insure the capability is properly tested at 6 month minimum intervals.

If any of the requirements above for the associated risk level of the application are not met, this is a finding.

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

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000537 The organization conducts backups of system-level information contained in the information system per organization-defined frequency that is consistent with recovery time and recovery point objectives. NIST SP 800-53 :: CP-9 (b) NIST SP 800-53A :: CP-9.1 (v) NIST SP 800-53 Revision 4 :: CP-9 (b)

CP-9 (b)

Prisma Cloud Compute automatically creates and maintains daily, weekly, and monthly backups. These are known as system backups. You can also make your own backups at any point in time. These are known as manual backups.

V-70357

medium

ASDV-PL-003080

SV-84979r1_rule

APSC-DV-003080

Back-up copies of the application software or source code must be stored in a fire-rated container or stored separately (offsite).

Application developers and application administrators must take steps to ensure continuity of development effort and operations should a disaster strike.

Steps include protecting back-up copies of development code and application software.

Improper storage of the back-up copies can result in extended outages of the information system in the event of a fire or other situation that results in destruction of the back-up as well as the operating copy.

To address this risk, copies of application software and application source code must be stored in a fire-rated container or separately (offsite) from the operational or development environments.

When reviewing a COTS or GOTS application, verify that a back-up copy of the software is stored in a fire rated container or is stored separately (offsite) from the operational environment.

Determine if application development is done in-house.

If application development occurs in-house and source code is available, verify a back-up copy of the source code is kept in a fire-rated container or stored offsite from the development environment.

If back-up copies of the application software or source code are not stored in a fire-rated container or stored separately (offsite) from their respective environments, this is a finding.

Store a back-up copy of the application software and source code in a fire-rated container or store it separately (offsite) from their respective environments.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000540 The organization protects the confidentiality, integrity, and availability of backup information at storage locations. NIST SP 800-53 :: CP-9 (d) NIST SP 800-53A :: CP-9.2 NIST SP 800-53 Revision 4 :: CP-9 (d)

CP-9 (d)

Not applicable, responsibility of the customer

V-70359

medium

ASDV-PL-003090

SV-84981r1_rule

APSC-DV-003090

Procedures must be in place to assure the appropriate physical and technical protection of the backup and restoration of the application.

Protection of backup and restoration assets is essential for the successful restore of operations after a catastrophic failure or damage to the system or data files. Failure to follow proper procedures may result in the permanent loss of system data and/or the loss of system capability resulting in failure of the customer’s mission.

Validate that backup and recovery procedures incorporate protection of the backup and restoration assets.

Verify assets housing the backup data (e.g., SANS, tapes, backup directories, software) and the assets used for restoration (e.g., equipment and system software) are included in the backup and recovery procedures.

If backup and restoration devices are not included in the recovery procedures, this is a finding.

Develop and implement procedures to insure that backup and restoration assets are properly protected and stored in an area/location where it is unlikely they would be affected by an event that would affect the primary assets.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000540 The organization protects the confidentiality, integrity, and availability of backup information at storage locations. NIST SP 800-53 :: CP-9 (d) NIST SP 800-53A :: CP-9.2 NIST SP 800-53 Revision 4 :: CP-9 (d)

CP-9 (d)

Not applicable, responsibility of the customer

V-70361

medium

ASDV-PL-003100

SV-84983r1_rule

APSC-DV-003100

The application must use encryption to implement key exchange and authenticate endpoints prior to establishing a communication channel for key exchange.

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 DoD data.

If the application does not implement key exchange, this check is not applicable.

Identify all application or supporting infrastructure features using key exchange.

Verify the application is using FIPS-140-2 validated cryptographic modules for encryption of keys during key exchange.

If the application does not implement encryption for key exchange, this is a finding.

Use encryption for key exchange.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000201 The organization protects authenticators commensurate with the security category of the information to which use of the authenticator permits access. NIST SP 800-53 :: IA-5 (6) NIST SP 800-53A :: IA-5 (6).1 NIST SP 800-53 Revision 4 :: IA-5 (6)

IA-5 (6)

TLS v1.2 protocol key exchanges

V-70369

medium

ASDV-PL-003140

SV-84991r2_rule

APSC-DV-003140

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

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 DoD approved standard for cryptographic hash functions. DoD application developers must use SHA256 when creating cryptographic hashes; however, some non-DoD 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 DoD 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 DoD 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.

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] <String[]> [-Algorithm <String>] [<CommonParameters>]

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 DoD operational networks, this is a finding.

Developers/release managers create cryptographic hash values of application files and/or application packages prior to transitioning the application from test to a production environment. They protect cryptographic hash information so it cannot be altered and make a read copy of the hash information available to application Admins so they can validate application packages and files after they download the files.

Application Admins validate cryptographic hashes prior to deploying the application to production.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-000698 The organization requires the developer of the information system, system component, or information system service to enable integrity verification of software and firmware components. NIST SP 800-53 :: SA-10 (1) NIST SP 800-53A :: SA-10 (1).1 NIST SP 800-53 Revision 4 :: SA-10 (1)

SA-10 (1)

All releases provide a checksum of the release package allowing the customer to perform to validate the package has not been altered

V-70371

medium

ASDV-PL-003150

SV-84993r1_rule

APSC-DV-003150

At least one tester must be designated to test for security flaws in addition to functional testing.

If there is no person designated to test for security flaws, vulnerabilities can potentially be missed during testing.

This requirement is meant to apply to developers or organizations that are doing development work.

Review the organization chart and interview the admin staff.

Identify personnel designated as application security testers.

If the organization operating the application is not doing development work, this requirement is not applicable.

If the organization has not designated personnel to conduct security testing, this is a finding.

Designate personnel to conduct security testing on the applications.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003182 The organization requires the developer of the information system, system component, or information system service to perform testing/evaluation of the as-built system, component, or service subsequent to threat and vulnerability analysis. NIST SP 800-53 Revision 4 :: SA-11 (2)

SA-11 (2)

All releases are tested for security and functionality flaws

V-70375

medium

ASDV-PL-003170

SV-84997r1_rule

APSC-DV-003170

An application code review must be performed on the application.

A code review is a systematic evaluation of computer source code conducted for the purposes of identifying and remediating the security flaws in the software.

This requirement is meant to apply to developers or organizations that are doing application development work and have the responsibility for maintaining the application source code.

Examples of security flaws include but are not limited to:

- format string exploits - memory leaks - buffer overflows - race conditions - sql injection - dead/unused/commented code - input validation exploits

The code review is conducted during the application development phase, this allows discovered security issues to be corrected prior to release.

Code reviews performed after the development phase must eventually go back to development for correction so conducting the code review during development is the logical and preferred action.

Automated code review tools are to be used whenever reviewing application source code. These tools are often incorporated into Integrated Development Environments (IDE) so code reviews can be conducted during all stages of the development life cycle. Periodically reviewing code during the development phase makes transition to a production environment easier as flaws are continually identified and addressed during the development phase rather than en masse at the end of the development effort.

Code review processes and the tools used to conduct the code review analysis will vary depending upon application architecture and the development languages utilized.

In addition to automated testing, manual code reviews may also be used to validate or augment automated code review results. Larger projects will have a large code base and will require the use of automated code review tools in order to achieve complete code review coverage.

A manual code review may consist of a peer review wherein other programmers on the team manually examine source code and automated code review results for known flaws that introduce security bugs into the application.

As with any testing, there is no single best approach and the tests must be tailored to the application architecture. Use of automated tools along with manual review of code and testing results is considered a best practice when conducting code reviews. This method is the most likely way to ensure the maximum number of errors are caught and addressed prior to implementing the application in a production environment.

This requirement is meant to apply to developers or organizations that are doing the application development work and have the responsibility for maintaining the application source code. Otherwise, the requirement is not applicable.

Review the system documentation and ask the application representative to describe the code review process or provide documentation outlining the organizations code review process.

If code reviews are conducted with software tools, have the application representative provide the latest code review report for the application.

Ensure the code review looks for all known security flaws including but not limited to:

- format string exploits - memory leaks - buffer overflows - race conditions - sql injection - dead/unused/commented code - input validation exploits

If the organization does not conduct code reviews on the application that attempt to identify all known and potential security issues, or if code review results are not available for review, this is a finding.

Conduct and document code reviews on the application during development and identify and remediate all known and potential security vulnerabilities prior to releasing the application.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003187 The organization requires the developer of the information system, system component, or information system service to perform a manual code review of organization-defined specific code using organization defined processes, procedures, and/or techniques. NIST SP 800-53 Revision 4 :: SA-11 (4)

SA-11 (4)

Application code reviews are performed

V-70379

medium

ASDV-PL-003190

SV-85001r1_rule

APSC-DV-003190

Flaws found during a code review must be tracked in a defect tracking system.

This requirement is meant to apply to developers or organizations that are doing application development work.

If flaws are not tracked they may possibly be forgotten to be included in a release. Tracking flaws in the configuration management repository will help identify code elements to be changed, as well as the requested change.

This requirement is meant to apply to developers or organizations that are doing application development work.

If application development is not being done or managed by the organization, this requirement is not applicable.

Ask the application representative to demonstrate that the configuration management repository captures flaws in the code review process. The configuration management repository may consist of a separate application for capturing code defects.

If there is no configuration management repository or the code review flaws are not captured in the configuration management repository, this is a finding.

Track software defects in a defect tracking system.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003197 The organization requires the developer of the information system, system component, or information system service to document the results of the dynamic code analysis. NIST SP 800-53 Revision 4 :: SA-11 (8)

SA-11 (8)

GitHub is used to track all issues

V-70381

medium

ASDV-PL-003200

SV-85003r1_rule

APSC-DV-003200

The changes to the application must be assessed for IA and accreditation impact prior to implementation.

When changes are made to an application, either in the code or in the configuration of underlying components such as the OS or the web or application server, there is the potential for security vulnerabilities to be opened up on the system.

IA assessment of proposed changes is necessary to verify security integrity is maintained within the application.

Interview the application and system administrators and determine if changes to the application are assessed for IA impact prior to implementation.

Review the CCB process documentation to ensure potential changes to the application are evaluated to determine impact. An informal group may be tasked with impact assessment of upcoming version changes.

If IA impact analysis is not performed, this is a finding.

Review IA impact to the system prior to implementing changes.

false

M

Unclass

Application Security and Development Security Technical Implementation Guide :: Version 4, Release: 11 Benchmark Date: 24 Jul 2020

3009

CCI-003173 The organization requires the developer of the information system, system component, or information system service to perform unit, integration, system, and/or regression testing/evaluation at organization-defined depth and coverage. NIST SP 800-53 Revision 4 :: SA-11 b

SA-11 b

Prisma Cloud Compute is released as container images, these images can be ran within the customer’s security evaluation environment before production deployment

V-70383

medium

ASDV-PL-003210

SV-85005r1_rule

APSC-DV-003210

Security flaws must be fixed or addressed in the project plan.

This requirement is meant to apply to developers or organizations that are doing application development work.

Application development efforts include the creation of a project plan to track and organize the development work.

If security flaws are not tracked within the project plan, it is possible the flaws will be overlooked and included in a release.

Tracking flaws in the project plan will help identify code elements to be changed as well as the requested change.

This requirement is meant to apply to developers or organizations that are doing application development work. If the organization managing the application is not performing or managing the development of the application the requirement is not applicable.

Ask the application representative to demonstrate how security flaws are integrated into the project plan.

If security flaws are not addressed in the project plan or there is no process to introduce security flaws into the project plan, this is a finding.

Address security flaws within a project plan to ensure they are tracked and addressed by management.

false

M

Unclass

Application