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-69279

high

SRG-APP-000014

SV-83901r1_rule

APSC-DV-000190

Messages protected with WS_Security must use time stamps with creation and expiration times.

The lack of time stamps could lead to the eventual replay of the message, leaving the application susceptible to replay events which may result in an immediate loss of confidentiality.

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

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

Examine the contents of a SOAP message using WS Security; all messages should contain time stamps, sequence numbers, and expiration.

If messages using WS Security do not contain time stamps, sequence numbers, and expiration, this is a finding.

Design and configure applications using WS-Security messages to use time stamps with creation and expiration times and sequence numbers.

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)

Console session token has a configurable timeout. By default, the timeout is 1440 minutes (24 hours). This configurable timeout value also controls the validity period for API tokens. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/long_lived_tokens.html

V-69281

high

SRG-APP-000014

SV-83903r1_rule

APSC-DV-000200

Validity periods must be verified on all application messages using WS-Security or SAML assertions.

When using WS-Security in SOAP messages, the application should check the validity of the time stamps with creation and expiration times. Time stamps that are not validated may lead to a replay event and provide immediate unauthorized access of the application. Unauthorized access results in an immediate loss of confidentiality.

Ask the application representative for the design document.

Review the design document for web services.

If the application does not utilize WSS or SAML assertions, this requirement is not applicable.

Review the design document and verify validity periods are checked on all messages using WS-Security or SAML assertions.

If the design document does not exist, or does not indicate validity periods are checked on messages using WS-Security or SAML assertions, this is a finding.

Design and configure the application to use validity periods, ensure validity periods are verified on all WS-Security token profiles and SAML Assertions.

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 supports SAML v2.0 federation. SAML assertions must be signed by the IdP and are validated by Prisma Cloud Compute. The IssueInstant value if evaluated.

V-69287

high

SRG-APP-000014

SV-83909r1_rule

APSC-DV-000230

The application must use the NotOnOrAfter condition when using the SubjectConfirmation element in a 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.

When a SAML assertion is used with a <SubjectConfirmation> element, a begin and end time for the <SubjectConfirmation> should be set to prevent reuse of the message at a later time. Not setting a specific time period for the <SubjectConfirmation>, may grant immediate access to an attacker and result in an immediate loss of confidentiality.

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 <SubjectConfirmation> element. All messages should contain the <NotOnOrAfter> element. This can be accomplished if the application allows the ability to view XML messages or via a protocol analyzer like Wireshark.

If SOAP messages do not contain <NotOnOrAfter> elements, this is a finding.

Design and configure the application to use the <NotOnOrAfter> condition when using the <SubjectConfirmation> element in 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)

Prisma Cloud Compute SAML module validates the IdP authentication response’s Condition NotOnOrBefore and NotOnOrAfter assertions.

V-69289

high

SRG-APP-000014

SV-83911r1_rule

APSC-DV-000240

The application must use both the NotBefore and NotOnOrAfter elements or OneTimeUse element when using the Conditions element in a 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.

When a SAML assertion is used with a <Conditions> element, a begin and end time for the <Conditions> element should be set in order to specify a timeframe in which the assertion is valid. Not setting a specific time period for the <Conditions> element, the possibility exists of granting immediate access or elevated privileges to an attacker which results in an immediate loss of confidentiality.

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 <Conditions> element; all messages should contain the <NotBefore> and <NotOnOrAfter> or <OneTimeUse> element when in a SAML Assertion. This can be accomplished using a protocol analyzer such as Wireshark.

If SOAP using the <Conditions> element does not contain <NotBefore> and <NotOnOrAfter> or <OneTimeUse> elements, this is a finding.

Design and configure the application to implement the use of the <NotBefore> and <NotOnOrAfter> or <OneTimeUse> when using the <Conditions> element in 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)

Prisma Cloud Compute SAML module validates the IdP authentication response’s Condition NotOnOrBefore and NotOnOrAfter assertions.

V-69329

high

SRG-APP-000033

SV-83951r1_rule

APSC-DV-000460

The application must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

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 a restricted asset or security boundary.

Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization.

Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset.

Information systems use access control policies and enforcement mechanisms to implement this requirement.

Access control policies include identity-based policies, role-based policies, and attribute-based policies.

Access enforcement mechanisms include access control lists, access control matrices, and cryptography.

These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

This requirement is applicable to access control enforcement applications (e.g., authentication servers) and other applications that perform information and system access control functions.

Review the application documentation and interview the application administrator.

Review application data protection requirements.

Identify application resources that require protection and authentication over and above the authentication required to access the application itself.

This can be access to a URL, a folder, a file, a process or a database record that should only be available to certain individuals.

Identify the access control methods utilized by the application in order to control access to the resource.

Examples include Role-Based Access Control policies (RBAC).

Using RBAC as an example, utilize a test account placed into a test role.

Set a protection control on a resource and explicitly deny access to the role assigned to the test user account.

Try to access an application resource that is not configured to allow access. Access should be denied.

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

Design or configure the application to enforce access to application resources.

false

M

Unclass

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

3009

CCI-000213 The information system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. NIST SP 800-53 :: AC-3 NIST SP 800-53A :: AC-3.1 NIST SP 800-53 Revision 4 :: AC-3

AC-3

Prisma Cloud Compute supports assigning roles to users and groups to control their level of access to Prisma Cloud. Roles determine what a user can do and see in Console, and API access. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/access_control/user_roles.html

V-69339

high

SRG-APP-000342

SV-83961r1_rule

APSC-DV-000510

The application must execute without excessive account permissions.

Applications are often designed to utilize a user account. The account represents a means to control application permissions and access to OS resources, application resources or both.

When the application is designed and installed, care must be taken not to assign excessive permissions to the user account that is used by the application.

An application operating with unnecessary privileges can potentially give an attacker access to the underlying operating system or if the privileges required for application execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by organizations.

Applications must be designed and configured to operate with only those permissions that are required for proper operation.

Review the system documentation or interview the application representative and identify if the application utilizes an account in order to operate.

Determine the OS user groups in which each application account is a member. List the user rights assigned to these users and groups using relevant OS commands and evaluate whether any of them provide admin rights or if they are unnecessary or excessive.

If the application connects to a database, open an admin console to the database and view the database users, their roles and group rights.

Locate the application user account used to access the database and examine the accounts privileges. This includes group privileges.

If the application user account has excessive OS privileges such as being in the admin group, database privileges such as being in the DBA role, has the ability to create, drop, alter the database (not application database tables), or if the application user account has other excessive or undefined system privileges, this is a finding.

Configure the application accounts with minimalist privileges. Do not allow the application to operate with admin credentials.

false

M

Unclass

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

3009

CCI-002233 The information system prevents organization-defined software from executing at higher privilege levels than users executing the software. NIST SP 800-53 Revision 4 :: AC-6 (8)

AC-6 (8)

Prisma Cloud Compute Console and Defender(s) run as containers within your microservices environment. The Console can be configured to run under the “twistlock” account (non-root). The Defender Defender container run as root, further explanation can be found here: https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/technology_overviews/defender_architecture.html

V-69343

high

SRG-APP-000065

SV-83965r1_rule

APSC-DV-000530

The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15 minute time period.

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced.

Limits are imposed by locking the account.

User notification when three failed logon attempts are exceeded is an operational consideration determined by the application owner. In some instances the operational situation may dictate that no notice is to be provided to the user when their account is locked. In other situations, the user may be notified their account is now locked. This decision is left to the application owner based upon their operational scenarios.

All testing must be performed within a 15-minute window.

Log on to the application with a test user account.

Intentionally enter an incorrect user password or pin.

Repeat 2 times within 15 minutes for a total of three failed attempts.

Notification of a locked account may or may not be provided.

Using the correct user password or pin, attempt to logon a 4th time.

If the logon is successful upon the 4th attempt the account was not locked after the third failed attempt and this is a finding.

Configure the application to enforce an account lock after 3 failed logon attempts occurring within a 15-minute window.

false

M

Unclass

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

3009

CCI-000044 The information system enforces the organization-defined limit of consecutive invalid logon attempts by a user during the organization-defined time period. NIST SP 800-53 :: AC-7 a NIST SP 800-53A :: AC-7.1 (ii) NIST SP 800-53 Revision 4 :: AC-7 a

AC-7 a

Prisma Cloud Compute username/password authentication does not enforce a password brute force account lock out. Username/password authentication can be disabled and password brute force protections can be applied via a 3rd party authentications source (e.g. LDAP, SAML, X.509). All authentication attempts are logged. Direct X.509 (DoD CAC) authentication is supported.

V-69527

high

SRG-APP-000148

SV-84149r1_rule

APSC-DV-001540

The application must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system.

Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors).

Organizational users (and any processes acting on behalf of users) must be uniquely identified and authenticated for all accesses, except the following:

(i) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and (ii) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Review the application documentation and interview the application administrator to determine how organizational users access the application.

If the application is publicly available, providing access to publicly releasable data and the users are non-organizational users such as individuals who no longer have a CAC (e.g., retirees) or members of the public with no requirement for DoD credentials, this requirement is not applicable.

The requirement still applies to DoD organizational users and admins when accessing the non-public data areas or system resources of the system.

Attempt to access the application and confirm that a unique user account and password or CAC token and pin are required in order to access the application.

If the application does not uniquely identify and authenticate users, this is a finding.

Configure the application to uniquely identify and authenticate users and user processes.

false

M

Unclass

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

3009

CCI-000764 The information system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). NIST SP 800-53 :: IA-2 NIST SP 800-53A :: IA-2.1 NIST SP 800-53 Revision 4 :: IA-2

IA-2

All account creation, maintenance, deletion and role assignment is the responsibility of the Prisma Cloud Compute Administrator(s). There are no built-in local accounts. Prisma Cloud Compute can be integrated with 3rd party authentication stores that implement an organization’s approved identity management policies and procedures. Role assignment can get associated with the identity provider’s group assignments. Direct X.509 (DoD CAC) authentication is supported.

V-69555

high

SRG-APP-000164

SV-84177r1_rule

APSC-DV-001680

The application must enforce a minimum 15-character password length.

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Use of passwords for application authentication is intended only for limited situations and should not be used as a replacement for two-factor CAC-enabled authentication.

Examples of situations where a user ID and password might be used include but are not limited to:

- When the application user base does not have a CAC and is not a current 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. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

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 shorter than 15 characters in length.

If a password shorter than 15 characters can be created, this is a finding.

Configure the application to require 15 characters 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-000205 The information system enforces minimum password length. NIST SP 800-53 :: IA-5 (1) (a) NIST SP 800-53A :: IA-5 (1).1 (i) NIST SP 800-53 Revision 4 :: IA-5 (1) (a)

IA-5 (1) (a)

Prisma Cloud Compute can enforce the use of a strong password: cannot be the same as the 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: ~!@#$%^&*()-_=+|[{}];:’\”,<.>/?" For 15 character password use 3rd party authentication (LDAP, SAML). Direct X.509 (DoD CAC) authentication is supported.

V-69567

high

SRG-APP-000171

SV-84189r1_rule

APSC-DV-001740

The application must only store cryptographic representations of passwords.

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.

Passwords need to be protected at all times and using a strong one-way hashing encryption algorithm with a salt is the standard method for providing a means to validate a user’s password without having to store the actual password.

Performance and time required to access are factors that must be considered and the one way hash is the most feasible means of securing the password and providing an acceptable measure of password security. If passwords are stored in clear text, they can be plainly read and easily compromised.

In many instances, verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash.

A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random SALT value as follows:

H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt))

Where n is a cryptographically-strong random [*3] number. Hn is stored, along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares Hn with the stored Hn.

A SALT is essentially a fixed-length cryptographically-strong random value.

Another method used is utilizing a keyed hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key.

Applications must only store passwords that have been cryptographically protected.

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.

Have the application administrator identify the application’s password storage locations. Potential locations include the local file system where the application is stored or in an application-related database table that should not be accessible to application users.

Review application files and folders using a text editor or by using a database tool that allows you to view data stored in database tables. Look for indications of stored user information and review that information. Determine if password strings are readable/discernable.

Determine if the application uses the MD5 hashing algorithm to create password hashes.

If the passwords are readable or there is no indication the application utilizes cryptographic hashing to protect passwords, or if the MD5 hash algorithm is used to create password hashes, this is a finding.

Use strong cryptographic hash functions when creating password hash values.

Utilize random salt values when creating the password hash.

Ensure strong access control permissions on data files containing authentication data.

false

M

Unclass

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

3009

CCI-000196 The information system, for password-based authentication, stores only encrypted representations of passwords. NIST SP 800-53 :: IA-5 (1) (c) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (c)

IA-5 (1) (c)

Prisma Cloud Compute stores local username/password accounts within a local database table using the HMAC256. Username/password authentication can be disabled and authentication can be provided by a 3rd party authentications source (e.g. LDAP, SAML, X.509). Direct X.509 (DoD CAC) authentication is supported.

V-69569

high

SRG-APP-000172

SV-84191r1_rule

APSC-DV-001750

The application must transmit only cryptographically-protected passwords.

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.

Passwords need to be protected at all times and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Applications can accomplish this by making direct function calls to encryption modules or by leveraging operating system encryption capabilities.

Review the application documentation and interview the application administrator to identify if the application uses passwords for user authentication.

If the application does not use passwords, the requirement is not applicable.

Identify when the application transmits passwords. This will most likely be when the user authenticates to the application or when the application authenticates to another resource.

Access the application management interface with a test account and access the functionality that requires a password be provided. If the interface is via a web browser, verify the web browser has gone secure prior to entering any password or authentication information.

This can be done by viewing the browser and observing a “lock” icon displayed somewhere in the browser as well as an https:// to indicate an SSL connection. Most browsers display this in the upper left hand corner.

If the application is transmitting the password rather than the user, obtain design documentation from the application admin that provides the details on how they are protecting the password during transmission. This will usually be via a TLS/SSL tunneled connection or VPN.

If the passwords are not encrypted when being transmitted, this is a finding.

Configure the application to encrypt passwords when they are being transmitted.

false

M

Unclass

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

3009

CCI-000197 The information system, for password-based authentication, transmits only encrypted representations of passwords. NIST SP 800-53 :: IA-5 (1) (c) NIST SP 800-53A :: IA-5 (1).1 (v) NIST SP 800-53 Revision 4 :: IA-5 (1) (c)

IA-5 (1) (c)

All communication to the Prisma Cloud Compute Console and API is protected by TLS. https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/configure/custom_certs_console_access.html

V-70149

high

SRG-APP-000175

SV-84771r1_rule

APSC-DV-001810

The application, when utilizing PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.

A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.

When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.

This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.

Review the application documentation, the application architecture and interview the application administrator to identify the method employed by the application for validating certificates.

Review the method to determine if a certification path that includes status information is constructed when certificate validation occurs.

Some applications may utilize underlying OS certificate validation and certificate path building capabilities while others may build the capability into the application itself.

The certification path will include the intermediary certificate CAs along with a status of the CA server’s signing certificate and will end at the trusted root anchor.

If the application does not construct a certificate path to an accepted trust anchor, this is a finding.

Design the application to construct a certification path to an accepted trust anchor when using PKI-based authentication.

false

M

Unclass

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

3009

CCI-000185 The information system, for PKI-based authentication validates certifications by constructing and verifying a certification path to an accepted trust anchor including checking certificate status information. NIST SP 800-53 :: IA-5 (2) NIST SP 800-53A :: IA-5 (2).1 NIST SP 800-53 Revision 4 :: IA-5 (2) (a)

IA-5 (2) (a)

Direct X.509 (DoD CAC) authentication is supported. PKI chain validation (chain of trust, CRL and OCSP) is performed upon the user’s authentication certificate.

V-70151

high

SRG-APP-000176

SV-84773r1_rule

APSC-DV-001820

The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key.

If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure.

The cornerstone of the PKI is the private key used to encrypt or digitally sign information.

If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user.

Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.

Review the application documentation and interview the application administrator to identify where the application’s private key is stored.

If the application does not perform code signing or other cryptographic tasks requiring a private key, this requirement is not applicable.

Ask the administrator to demonstrate where the application private key(s) are stored. Examine access restrictions and ensure access controls are in place to restrict access to the private key(s).

If the key(s) are stored on the file system, ensure adequate file permissions are set so as to only allow authorized users and processes.

If the key(s) are maintained or available via an application interface, ensure the application provides access controls that limit access via the application interface to only authorized users and processes.

Review access controls and attempt to use a relevant user account, group or application role that is not allowed access to the private key.

Verify access to the keys is denied.

If unauthorized access is granted to the private key(s), this is a finding.

Configure the application or relevant access control mechanism to enforce authorized access to the application private key(s).

false

M

Unclass

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

3009

CCI-000186 The information system, for PKI-based authentication enforces authorized access to the corresponding private key. NIST SP 800-53 :: IA-5 (2) NIST SP 800-53A :: IA-5 (2).1 NIST SP 800-53 Revision 4 :: IA-5 (2)

IA-5 (2)

The private X.509 keys used for Console and API TLS transport protection are stored within a file system directory that has permission mask of 600 is owned by root user and group.

V-70157

high

SRG-APP-000178

SV-84779r2_rule

APSC-DV-001850

The application must not display passwords/PINs as clear text.

To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.

Obfuscation of user-provided information when typed into the system is a method used in addressing this risk.

For example, displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.

Another method is to display authentication feedback for a very limited time, usually in fractions of a second. This occurs during password character entry where the password characters are displayed for a very small window of time and then automatically obfuscated. This allows users with just enough time to confirm their password as they type it while limiting the ability of "shoulder surfers" to covertly witness the values.

A common tactic employed to circumvent password obfuscation is to copy the obfuscated password and paste it to a text file. Proper obfuscation techniques will not paste the clear text password.

Ask the application admin to log on to the application.

Observe the authentication process and verify any display feedback provided when the admin enters her/his password is obfuscated and not clear text.

For applications that display authentication feedback for a very limited time, ensure the feedback time the character is displayed is only momentary i.e., fractions of a second.

Using a text editor, copy the obfuscated password and paste to a text file. Do not save the file.

If the application displays clear text when the password/PIN is entered, or if the time period for displayed feedback exceeds fractions of a second, or if the clear text password/PIN is displayed when pasted, this is a finding.

Configure the application to obfuscate passwords and PINs when they are being entered so they cannot be read.

Design the application so obfuscated passwords cannot be copied and then pasted as clear text.

false

M

Unclass

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

3009

CCI-000206 The information system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. NIST SP 800-53 :: IA-6 NIST SP 800-53A :: IA-6.1 NIST SP 800-53 Revision 4 :: IA-6

IA-6

The Prisma Cloud Compute UI authentication page obfuscates the password characters that are entered.

V-70205

high

SRG-APP-000219

SV-84827r1_rule

APSC-DV-002230

The application must not expose session IDs.

Authenticity protection provides protection against man-in-the-middle attacks/session hijacking and the insertion of false information into sessions.

Application communication sessions are protected utilizing transport encryption protocols, such as SSL or TLS. SSL/TLS provides web applications with a means to be able to authenticate user sessions and encrypt application traffic. Session authentication can be single (one-way) or mutual (two-way) in nature. Single authentication authenticates the server for the client, whereas mutual authentication provides a means for both the client and the server to authenticate each other.

This requirement applies to applications that utilize communications sessions. This includes, but is not limited to, web-based applications and Service-Oriented Architectures (SOA).

This requirement addresses communications protection at the application session, versus the network packet, and establishes grounds for confidence at both ends of communications sessions in ongoing identities of other parties and in the validity of information transmitted. Depending on the required degree of confidentiality and integrity, web services/SOA will require the use of SSL/TLS mutual authentication (two-way/bidirectional).

Review the application documentation and configuration.

Interview the application administrator and obtain implementation documentation identifying system architecture.

Identify the application communication paths. This includes system to system communication and client to server communication that transmit session identifiers over the network.

Have the application administrator identify the methods and mechanisms used to protect the application session ID traffic. Acceptable methods include SSL/TLS both one-way and two-way and VPN tunnel.

The protections must be implemented on a point-to-point basis based upon the architecture of the application.

For example; a web application hosting static data will provide SSL/TLS encryption from web client to the web server. More complex designs may encrypt from application server to application server (if applicable) and application server to database as well.

If the session IDs are unencrypted across network segments, this is a finding.

Configure the application to protect session IDs from interception or from manipulation.

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

One-way TLS encryption is implemented with HTTP Strict Transport Security (HSTS)

V-70207

high

SRG-APP-000220

SV-84829r1_rule

APSC-DV-002240

The application must destroy the session ID value and/or cookie on logoff or browser close.

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 cookies contain application session information that can be used to impersonate the web application user or hijack their application session. Once the user’s session has terminated, these session IDs must be destroyed and not reused.

Review the application documentation and interview the application administrator.

Identify how the application destroys session IDs.

If using a web development framework, ask the application administrator to provide details on the framework’s session configuration.

Review framework configuration setting to determine how the session identifiers are destroyed.

Review the client system and using a browser or other tool capable of viewing client cookies, identify cookies set by the application and verify that application session ID cookies are destroyed once the user has logged off or the browser has closed.

If the session IDs and associated cookies are not destroyed on logoff or browser close, this is a finding.

Configure the application to destroy session ID cookies once the application session has terminated.

false

M

Unclass

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

3009

CCI-001185 The information system invalidates session identifiers upon user logout or other session termination. NIST SP 800-53 :: SC-23 (1) NIST SP 800-53A :: SC-23 (1).1 NIST SP 800-53 Revision 4 :: SC-23 (1)

SC-23 (1)

Session token is deleted when logout is performed.

V-70221

high

SRG-APP-000225

SV-84843r1_rule

APSC-DV-002310

The application must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Applications or systems that fail suddenly and with no incorporated failure state planning may leave the hosting system available but with a reduced security protection capability. Preserving information system state information also facilitates system restart and return to the operational mode of the organization with less disruption of mission-essential processes.

In general, application security mechanisms should be designed so that a failure will follow the same execution path as disallowing the operation. For example, security methods, such as isAuthorized(), isAuthenticated(), and validate(), should all return false if there is an exception during processing. If security controls can throw exceptions, they must be very clear about exactly what that condition means.

Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations.

Review application design documentation, vulnerability scanner reports and interview application administrator to identify application components.

The design of the application should account for the following:

- Connections to databases are left open - Access control mechanisms are disabled - Data left in temporary locations

Testing application failure will require taking down parts of the application.

Review the vulnerability assessment configuration settings included in vulnerability report.

Examine the application test plans and procedures to determine if this type of failure was previously tested.

If test plans exist, validate the tests by performing a subset of the checks.

If test plans do not exist, an application failure must be simulated.

Simulate a failure. This can be accomplished by stopping the web server service and/or the database service. Also, for applications using web services stop the web service and/or the database.

Check to ensure that application data is still protected. Some examples of tests follow:

- Try to submit SQL queries to the database. Verify that the database requires authentication before returning data. - Try to read the application source files; access should not be granted to these files because the application is not operating. - Try to open database files; data should not be available because the application is not operational.

If the application fails in such a way that the application security controls are rendered inoperable, this is a finding.

Fix any vulnerability found when the application is an insecure state (initialization, shutdown and aborts).

false

M

Unclass

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

3009

CCI-001190 The information system fails to an organization-defined known-state for organization-defined types of failures. NIST SP 800-53 :: SC-24 NIST SP 800-53A :: SC-24.1 (iv) NIST SP 800-53 Revision 4 :: SC-24

SC-24

The Prisma Cloud Compute Defender is explicitly designed to be survivable even in the case of a prolonged (multi-hour) disconnection from Console.  Defender caches all policy locally, executes actions based on this cached policy, and spools logs locally until connectivity is restored.  Defender will automatically, continuously work to re-establish connectivity and, once accomplished, will automatically re-sync policy and send spooled events.

V-70245

high

SRG-APP-000439

SV-84867r1_rule

APSC-DV-002440

The application must protect the confidentiality and integrity of transmitted information.

Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.

This requirement applies to those applications that transmit data, or allow access to data non-locally. Application and data owners have a responsibility for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process.

Application and data owners need to identify the data that requires cryptographic protection. If no data protection requirements are defined as to what specific data must be encrypted and what data is non-sensitive and doesn’t require encryption, all data must be encrypted.

When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, SSL VPNs, or IPSEC.

Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.

Review the application documentation and interview the application administrator.

Identify application clients, servers and associated network connections including application networking ports.

Identify the types of data processed by the application and review any documented data protection requirements.

Identify the application communication protocols.

Review application documents for instructions or guidance on configuring application encryption settings.

Verify the application is configured to enable encryption protections for data in accordance with the data protection requirements. If no data protection requirements exist, ensure all application data is encrypted.

If the application does not utilize TLS, IPsec or other approved encryption mechanism to protect the confidentiality and integrity of transmitted information, this is a finding.

Configure all of the application systems to require TLS encryption in accordance with 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-002418 The information system protects the confidentiality and/or integrity of transmitted information. NIST SP 800-53 Revision 4 :: SC-8

SC-8

All communication between the Prisma Cloud Compute Console and associated deployed Defenders is TCP based and protected by a mutually authenticated X.509 TLS session.

V-70255

high

SRG-APP-000441

SV-84877r1_rule

APSC-DV-002485

The application must not store sensitive information in hidden fields.

Hidden fields allow developers to process application data without having to display it on the screen. Using hidden fields to pass data in forms is a common practice among web applications and by itself is not a security risk.

However, hidden fields are not secure and can be easily manipulated by users. Information requiring confidentiality or integrity protections must not be placed in a hidden field. If data that is sensitive must be stored in a hidden field, it must be encrypted.

Furthermore, hidden fields used to control access decisions can lead to a complete compromise of access control mechanisms allowing immediate compromise of the user’s application session.

Interview application administrator and review application documentation to identify and familiarize with the application features and functions.

Request most recent code review and vulnerability scan results. Review test configuration to ensure testing for hidden fields was conducted. Review test results for incidents of hidden data fields.

Examine identified hidden fields and determine what type of data is stored in the hidden fields.

If the data stored in the hidden fields are determined to be authentication or session related data, or if the code review or vulnerability scan results are not available and configured to test for hidden fields, this is a finding.

Design and configure the application to not store sensitive information in hidden fields.

Encrypt sensitive information stored in hidden fields using DoD-approved encryption and use server side session management techniques for user session management.

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)

There are no hidden fields in the UI. The UI is built upon the REST API which is fully documented here: https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/api.html

V-70257

high

SRG-APP-000251

SV-84879r1_rule

APSC-DV-002490

The application must protect from Cross-Site Scripting (XSS) vulnerabilities.

XSS attacks are essentially code injection attacks against the various language interpreters contained within the browser. XSS can be executed via HTML, JavaScript, VBScript, ActiveX; essentially any scripting language a browser is capable of processing.

XSS vulnerabilities are created when a website does not properly sanitize, escape, or encode user input. For example, "<;" is the HTML encoding for the "<" character. If the encoding is performed, the script code will not execute.

There are 3 parties involved in an XSS attack, the attacker, the trusted and vulnerable website, and the victim. An attacker will take advantage of a vulnerable website that does not properly validate user input by inserting malicious code into any data entry field.

When the victim visits the trusted website and clicks on the malicious link left by the attacker, the attacker’s script is executed in the victims browser with the trust permissions assigned to the site.

There are several different types of XSS attack and the complete details regarding XSS cannot be described completely here.

To address the issue of XSS, web application developers must escape, encode or otherwise validate all user input that is processed and output by the web server. They should also use web templates or a web development framework that provides the capability to encode or otherwise validate user input.

Examples of XSS vulnerabilities can be obtained from the Open Web Application Security Project (OWASP) website.

The site is available by pointing your browser to https://www.owasp.org.

Review the application documentation and the vulnerability assessment scan results from automated vulnerability assessment tools.

Verify scan configuration settings include web-based applications settings which include XSS tests.

Review scan results for XSS vulnerabilities.

If the scan results indicate aspects of the application are vulnerable to XSS, request subsequent scan data that shows the XSS vulnerabilities previously detected have been fixed.

If results that show compliance are not available, request proof of any steps that have been taken to mitigate the risk. This can include using network-based IPS to detect and prevent XSS attacks from occurring.

If scan results are not available, perform manual testing in various data entry fields to determine if XSS exist.

Navigate through the web application as a regular user and identify any data entry fields where data can be input.

Input the following strings:

<script>alert('hello')</script> <img src=x onerror="alert(document.cookie);"

If the script pop up box is displayed, or if scan reports show unremediated XSS results and no mitigating steps have been taken, this is a finding.

Verify user input is validated and encode or escape user input to prevent embedded script code from executing.

Develop your application using a web template system or a web application development framework that provides auto escaping features rather than building your own escape logic.

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

Each release of Prisma Cloud Compute has a security assessment performed. If XSS vulnerabilities are identified they are remediated before release.

V-70261

high

SRG-APP-000251

SV-84883r1_rule

APSC-DV-002510

The application must protect from command injection.

A command injection attack is an attack on a vulnerable application where improperly validated input is passed to a command shell setup in the application. The result is the ability of an attacker to execute OS commands via the application.

A command injection allows an attacker to execute their own commands with the same privileges as the application executing.

The following is an example of a URL based command injection attack.

Before alteration: http://sitename/cgi-bin/userData.pl?doc=user1.txt

Example URL modified: http://sitename/cgi-bin/userData.pl?doc=/bin/ls|

The result is the execution of the command “/bin/ls” which could allow the attacker to list contents of the directory via the browser.

The following is a list of functions vulnerable to command injection sorted according to language.

Language Functions/Characters - C/C++ - system(), popen(), execlp(), execvp(), ShellExecute(), ShellExecuteEx(), _wsystem() - Perl - system, exec, `,open, |, eval, /e - Python - exec, eval, os.system, os.popen, execfile, input, compile - Java - Class.forName(), Class.newInstance(), Runtime.exec()

Review the application documentation and the system configuration settings.

Interview the application administrator for details regarding security assessment including automated code review and vulnerability scans conducted to test for command injection.

Review the scan results from the entire application.

Verify scan configuration is set to check for command injection vulnerabilities.

If results indicate vulnerability, verify a subsequent scan has been run to ensure the issue has been remediated.

Manual test procedures are available on the OWASP website. Procedures may need to be modified to suit application architecture.

https://www.owasp.org/index.php/Testing_for_Command_Injection_%28OTG-INPVAL-013%29

If testing results are not provided demonstrating the vulnerability does not exist, or if the application representative cannot demonstrate how actions are taken to identify and protect from command injection vulnerabilities, this is a finding.

Modify the application so as to escape/sanitize special character input or configure the system to protect against command injection attacks based on application architecture.

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 to the application is via the REST API. All input (POST & GET) is validated.

V-70267

high

SRG-APP-000251

SV-84889r1_rule

APSC-DV-002540

The application must not be vulnerable to SQL Injection.

SQL Injection is a code injection attack against database applications. Malicious SQL statements are inserted into an application data entry field where they are submitted to the database and executed. This is a direct result of not validating input that is used by the application to perform a command or execute an action.

Successful attacks can read data, write data, execute administrative functions within the database, shutdown the DBMS, and in some cases execute OS commands.

Best practices to reduce the potential for SQL Injection vulnerabilities include:

Not using concatenation or replacement to build SQL queries.

Using prepared statements with parameterized queries that have been tested and validated not to be vulnerable to SQL Injection.

Using stored procedures that have been tested and validated not to be vulnerable to SQL Injection.

Escaping all user supplied input.

Additional steps to prevent SQL Injection can be found at the OWASP website:

https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Review the application documentation and interview the application administrator.

Request the latest vulnerability scan test results.

Verify the scan configuration is configured to test for SQL injection flaws.

Review the scan results to determine if any SQL injection flaws were detected during application testing.

If SQL injection flaws were discovered, request a subsequent scan that will show that the issues have been remediated.

If the scan results are not available, identify the database product in use and refer to the OWASP web application testing guide for detailed instructions on performing a manual SQL injection test. The instructions are located here and many tests are organized by database product:

https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL-005%29

If the application is vulnerable to SQL injection attack, contains SQL injection flaws, or if scan results do not exist, this is a finding.

Modify the application and remove SQL injection vulnerabilities.

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

Each release of Prisma Cloud Compute has a security assessment performed. If SQL injection vulnerabilities are identified they are remediated before release.

V-70269

high

SRG-APP-000251

SV-84891r1_rule

APSC-DV-002550

The application must not be vulnerable to XML-oriented attacks.

Extensible Markup Language (XML) is widely employed in web technology and applications like web services (SOAP, REST, and WSDL) and is also used for configuration files. XML vulnerability examples include XML injection, XML Spoofing, XML-based Denial of Service attacks and information disclosure attacks.

When utilizing XML, web applications must take steps to ensure they are addressing XML-related security issues. This is accomplished by choosing well-designed application components, building application code that follows security best practices and by patching application components when vulnerabilities are identified.

XML firewalls or gateways may be employed to assist in protecting applications by controlling access to XML-based applications, filtering XML content, rate-limiting requests, and validating XML traffic.

Review the application documentation, the application architecture and interview the application administrator.

Identify any XML-based web services or XML functionality performed by the application.

Determine if an XML firewall is deployed to protect application from XML-related attacks.

If the application does not process XML, the requirement is not applicable.

Review the latest application vulnerability assessment and verify the scan was configured to test for XML-related vulnerabilities and security issues.

Examples include but are not limited to:

XML Injection XML related Denial of Service XPATH injection XML Signature attacks XML Spoofing

If an XML firewall is deployed, request configuration information regarding the application and validate the firewall is configured to protect the application.

If the vulnerability scan is not configured to scan for XML-oriented vulnerabilities, if no scan results exist, or if the XML firewall is not configured to protect the application, this is a finding.

Design the application to utilize components that are not vulnerable to XML attacks.

Patch the application components when vulnerabilities are discovered.

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/output to the application is via the REST API in JSON format. No XML is used.

V-70271

high

SRG-APP-000447

SV-84893r1_rule

APSC-DV-002560

The application must not be subject to input handling vulnerabilities.

A common application vulnerability is unpredictable behavior due to improper input validation. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state.

Data received from the user should always be suspected as being malicious and always validated prior to using it as input to the application.

Some examples of input methods:

- Forms Data - URL parameters - Hidden Fields - Cookies - HTTP Headers or anything in the HTTP request - Client data entry fields

Items to validate:

- Out of range values/Boundary - Data length - Validate types of characters allowed - Whitelist validation for known good data input while denying all other input.

Other recommendations include:

- Using drop down menus for lists - Validating input on the server, not on the client.

If validating on the client, also validate on the server:

- Using regular expressions to validate input - Using HTML filter libraries that implement input validation tasks.

Review the application documentation and interview the application administrator.

If working with the developer, request documentation on their development processes and what their standard operating procedure is for sanitizing all application input.

Identify the latest vulnerability scan results.

Review the scan results and scan configuration settings.

Verify the scan was configured to identify input validation vulnerabilities.

If the scan results detected high risk vulnerabilities, verify a more recent scan shows remediation of the vulnerabilities is available for examination.

Review any risk acceptance documentation that indicates the ISSO has reviewed and accepted the risk.

If the vulnerability scan is not configured to test for input validation vulnerabilities if the most recent scan results show that high risk input validation vulnerabilities exist and a documented risk acceptance from the ISSO is not available, or if the scan results do not exist, this is a finding.

Follow best practice when accepting user input and verify that all input is validated before the application processes the input.

Remediate identified vulnerabilities and obtain documented risk acceptance for those issues that cannot be remediated immediately.

false

M

Unclass

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

3009

CCI-002754 The information system behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. NIST SP 800-53 Revision 4 :: SI-10 (3)

SI-10 (3)

All input to the application is via the REST API. All input (POST & GET) is validated.

V-70277

high

SRG-APP-000450

SV-84899r1_rule

APSC-DV-002590

The application must not be vulnerable to overflow attacks.

A buffer overflow occurs when a program exceeds the amount of data allocated to a buffer. The buffer is a sequential section of memory and when the data is written outside the memory bounds, the program can crash or malicious code can be executed.

Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism.

Buffer overflows can manifest as stack overflows, heap overflows integer overflows and format string overflows. Each type of overflow is dependent upon the underlying application language and the context in which the overflow is executed.

Integer overflows can lead to infinite looping when loop index variables are compromised and cause a denial of service. If the integer is used in data references, the data can become corrupt. Also, using the integer in memory allocation can cause buffer overflows, and a denial of service. Integers used in access control mechanisms can potentially trigger buffer overflows, which can be used to execute arbitrary code.

Almost all known web servers, application servers, and web application environments are susceptible to buffer overflows. Proper validation of user input is required to mitigate the risk. Notably, limiting the size of the strings a user is allowed to input to a program to a predetermined, acceptable length.

A code review, static code analysis or active vulnerability or fuzz testing are methods used to identify overflows within application code.

Review the application documentation and architecture.

Interview the application admin and identify the most recent code testing and analysis that has been conducted.

Review the test results; verify configuration of analysis tools are set to check for the existence of overflows. This includes but is not limited to buffer overflows, stack overflows, heap overflows, integer overflows and format string overflows.

If overflows are identified in the test results, verify the latest test results are being used, if not, ensure remediation has been completed.

If the test results show overflows exist and no remediation evidence is presented, or if test results are not available, this is a finding.

Design the application to use a language or compiler that performs automatic bounds checking.

Use an abstraction library to abstract away risky APIs.

Use compiler-based canary mechanisms such as StackGuard, ProPolice, and the Microsoft Visual Studio/GS flag.

Use OS-level preventative functionality and control user input validation.

Patch applications when overflows are identified in vendor products.

false

M

Unclass

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

3009

CCI-002824 The information system implements organization-defined security safeguards to protect its memory from unauthorized code execution. NIST SP 800-53 Revision 4 :: SI-16

SI-16

All input to the application is via the REST API. All input (POST & GET) is validated.

V-70293

high

ASDV-PL-002890

SV-84915r1_rule

APSC-DV-002890

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

A tiered application usually consists of 3 tiers, the web layer (presentation tier), the application layer (application logic tier), and the database layer (data storage tier).

Using one system for hosting all 3 tiers introduces risk that if one tier is compromised, there are no additional protection layers available to defend the other tiers. Security controls must be in place in order to provide different levels and types of defenses for each type of server based upon data protection requirements identified by policy or data owner.

DoD DMZ policy specifies that logical separation is allowed but when hosting different data types on the same server, physical separation is required.

1) Unrestricted web servers and Restricted web servers must be on separate virtual or physical servers from Private web servers, application servers, or database servers. 2) Unrestricted web servers and Restricted web servers can either be on separate physical servers from each other, or they can be on separate virtual servers. 3) If application and database servers have been separated by service type into Unrestricted, Restricted, and Private servers (permitted but not required in Increment 1 Phase 1), they must be on separate virtual or physical servers from each other by server type (Application or Database) and by service type (Unrestricted, Restricted, or Private).

Reference the DoD DMZ STIG for details on data types and separation requirements.

Security controls include firewalls or other forms of access controls that restrict the ability to traverse the network from one system to the other.

Separation can be performed either physically or logically based upon data protection and application protection design requirements.

Physically separate networks require distinct physical network devices for connections (e.g., two separate switches or two separate routers).

Physically separate machines utilize a non-virtual OS.

Logically separate networks are usually implemented via a VLAN.

Logically separate systems are implemented with virtual machines or other system emulation.

Security controls are firewall rules or ACLs that provide access restrictions on network traffic and limit communications between systems to only application and application/system support traffic.

For complete explanation of DoD DMZ requirements, reference DoD DMZ requirements.

Review the application documentation.

Review the application data protection requirements and identify if all data types hosted on server are identical.

Review the network diagram and identify web servers/web services, web application servers, and database servers.

If the application is not hosted in the DoD DMZ, this requirement is not applicable.

Verify the application web servers are separated from the application and database servers if the application is a tiered design as per DoD DMZ STIG requirements.

If the application is tiered and the network infrastructure hosting the application is not configured to provide separation and security access controls between the tiered layers in accordance with DoD DMZ requirements, this is a finding.

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

false

M

Unclass

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

3009

CCI-002225 The information system provides separate processing domains to enable finer-grained allocation of user privileges. NIST SP 800-53 Revision 4 :: AC-6 (4)

AC-6 (4)

Prisma Cloud Compute is a containerized micro serviced solution. The architecture is based upon two containers (Console & Defender). One Console command and controls multiple Defenders. The Console runs as a container and hosts the web based UI and API. The database is created within the local filesystem of the container (PersistentVolume). The Defender is a “lights-out” container that has no user interaction. It receives all policies from its controlling Console. The Defender does not store any persistent data. All data is communicated back to the controlling Console.

V-70363

high

ASDV-PL-003110

SV-84985r1_rule

APSC-DV-003110

The application must not contain embedded authentication data.

Authentication data stored in code could potentially be read and used by anonymous users to gain access to a backend database or application servers. This could lead to compromise of application data.

Review the application documentation and any available source code; this includes configuration files such as global.asa, if present, scripts, HTML files, and any ASCII files.

Identify any instances of passwords, certificates, or sensitive data included in code.

If credentials were found, check the file permissions and ownership of the offending file.

If access to the folder hosting the file is not restricted to the related application process and administrative users, this is a finding.

The finding details should note specifically where the offending credentials or data were located and what resources they enabled.

Remove embedded authentication data stored in code, configuration files, scripts, HTML file, or any ASCII files.

false

M

Unclass

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

3009

CCI-002367 The organization ensures unencrypted static authenticators are not embedded in applications. NIST SP 800-53 Revision 4 :: IA-5 (7)

IA-5 (7)

There are no built-in local accounts.

V-70365

high

ASDV-PL-003120

SV-84987r1_rule

APSC-DV-003120

The application must have the capability to mark sensitive/classified output when required.

Failure to properly mark output could result in a disclosure of sensitive or classified data which is an immediate loss in confidentiality.

Review the application documentation and interview the application administrator.

Ask the application representative for the application’s classification guide. This guide should document the data elements and their classification.

Determine which application functions to examine, giving preference to report generation capabilities and the most common user transactions that involve sensitive data (FOUO, secret or above).

Log on to the application and perform these in sequence, printing output when applicable. The application representative’s assistance may be required to perform these steps. For each function, note whether the appropriate markings appear on the displayed and printed output. If a classification document does not exist, data must be marked at the highest classification of the system.

Appropriate markings for an application are as follows: For classified data, markings are required at a minimum at the top and the bottom of screens and reports.

For FOUO data, markings are required at a minimum of the bottom of the screen or report. In some cases, technology may prohibit the appropriate markings on printed documents. For example, in some cases, it is not possible to mark all pages top and bottom when a user prints from a browser. If this is the case, ask the application representative if user procedures exist for manually marking printed documents. If procedures do exist, examine the procedures to verify if the users were to follow the procedures the data would be marked correctly.

Ask how these procedures are distributed to the users.

If appropriate markings are not present within the application and it is technically possible to have the markings present, this is a finding.

If it is not technically feasible to meet the minimum marking requirement and no user procedures exist or if followed the procedures will result in incorrect markings, or the procedures are not readily available to users, this is a finding.

In any case of a finding, the finding details should specify which functions failed to produce the desired results.

After completing the test, destroy all printed output using the site’s preferred method for disposal. For example: utilizing a shredder or disposal in burn bags.

Enable the application to adequately mark sensitive/classified output.

false

M

Unclass

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

3009

CCI-001010 The organization marks information system media indicating the distribution limitations, handling caveats, and applicable security markings (if any) of the information. NIST SP 800-53 :: MP-3 a NIST SP 800-53A :: MP-3.1 (ii) NIST SP 800-53 Revision 4 :: MP-3 a

MP-3 a

Prisma Cloud Compute can run in any environment that supports microservices regardless of classification levels. No data is exported from the system unless performed by the administrator. It is the administrators responsibility to handle the exported data to the classification level of the environment that Prisma Cloud Compute is deployed.

V-70395

high

ASDV-PL-003240

SV-85017r2_rule

APSC-DV-003240

All products must be supported by the vendor or the development team.

Unsupported commercial and government developed software products should not be used because fixes to newly identified bugs will not be implemented by the vendor or development team. The lack of security updates can result in potential vulnerabilities.

Review the application documentation and interview the application administrator.

Identify all software components.

Review the version information and identify the vendor if COTS software.

Access the vendor website to verify the version is still supported.

Ask the application representative for proof that the application and all of its components are supported.

Examples of proof may include:

design documentation that includes support information, support specific contract documentation, successful creation of vendor support tickets, website toll free support phone numbers etcetera.

If any of the software components are not supported by a COTS vendor or a GOTS organization, this is a finding.

Remove or decommission all unsupported software products in the application.

false

M

Unclass

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

3009

CCI-003376 The organization replaces information system components when support for the components is no longer available from the developer, vendor, or manufacturer. NIST SP 800-53 Revision 4 :: SA-22 a

SA-22 a

Prisma Cloud Compute is a fully supported product from Palo Alto Networks. Product documentation can be found here: https://docs.paloaltonetworks.com/prisma/prisma-cloud/20-04/prisma-cloud-compute-edition-admin/welcome/getting_started.html

V-70397

high

ASDV-PL-003250

SV-85019r1_rule

APSC-DV-003250

The application must be decommissioned when maintenance or support is no longer available.

Unsupported software products should not be used because fixes to newly identified bugs will not be implemented by the vendor or development team. The lack of security updates can result in potential vulnerabilities.

When maintenance updates and patches are no longer available, the application is no longer considered supported, and should be decommissioned.

Interview the application representative and determine if all the application components are under maintenance contract. The entire application may be covered by a single maintenance agreement. The application should be decommissioned if maintenance or security support is no longer being provided by the vendor or by the development staff of a custom developed application.

If the application or any of the application components are not being maintained, this is a finding.

Ensure there is maintenance for the application.

false

M

Unclass

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

3009

CCI-003376 The organization replaces information system components when support for the components is no longer available from the developer, vendor, or manufacturer. NIST SP 800-53 Revision 4 :: SA-22 a

SA-22 a

Palo Alto Networks supports n-1 of the major releases of Prisma Cloud Compute. Major versions (features) are released every quarter. Minor versions (bug fix and vulnerabilities remediation) are released durning a Major release’s lifecycle.

V-70403

high

ASDV-PL-003280

SV-85025r1_rule

APSC-DV-003280

Default passwords must be changed.

Default passwords can easily be compromised by attackers allowing immediate access to the applications.

Identify the application name and version and do an Internet search for the product name and the string "default password".

If default passwords are found, attempt to authenticate with the published default passwords.

If authentication is successful, this is a finding.

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

false

M

Unclass

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

3009

CCI-003109 The organization requires the developer of the information system, system component, or information system service to deliver the system, component, or service with organization-defined security configurations implemented. NIST SP 800-53 Revision 4 :: SA-4 (5) (a)

SA-4 (5) (a)

There are no built-in local accounts. Local username/password do not expire. It is recommended to disable username/password authentication and authentication can be provided by a 3rd party authentications source (e.g. LDAP, SAML, X.509). Direct X.509 (DoD CAC) authentication is supported.