DoD Compliance · STIG

CA API Gateway ALG Security Technical Implementation Guide

V1R3 · · 1.8 years ago · Released 24 Jul 2024 · 82 rules

Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.

Digest of Updates vs. V1R2 · 28 Apr 2017 +82 −81

Comparison against the immediately-prior release (V1R2). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Added rules 82

V-237342 Medium The CA API Gateway must enforce approved authorizations for logical access to information and system resources by employing identity-based, role-based, and/or attribute-based security policies.
V-237343 Medium The CA API Gateway must enforce approved authorizations for controlling the flow of information within the network based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.
V-237344 Medium The CA API Gateway must restrict or block harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.
V-237345 Medium The CA API Gateway providing user access control intermediary services must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the network.
V-237346 Medium The CA API Gateway providing user access control intermediary services must retain the Standard Mandatory DoD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.
V-237347 Medium The CA API Gateway providing user access control intermediary services for publicly accessible applications must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the system.
V-237348 Medium The CA API Gateway providing user access control intermediary services must limit users to two concurrent sessions.
V-237349 Medium The CA API Gateway providing intermediary services for remote access communications traffic must use encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions.
V-237350 Medium The CA API Gateway that stores secret or private keys must use FIPS-approved key management technology and processes in the production and control of private/secret cryptographic keys.
V-237351 Medium The CA API Gateway that provides intermediary services for TLS must be configured to comply with the required TLS settings in NIST SP 800-52.
V-237352 Medium The CA API Gateway providing intermediary services for remote access communications traffic must use NIST FIPS-validated cryptography to protect the integrity of remote access sessions.
V-237353 Medium The CA API Gateway must produce audit records containing information to establish the source of the events.
V-237354 Medium The CA API Gateway must produce audit records containing information to establish the outcome of the events.
V-237355 Medium The CA API Gateway must generate audit records containing information to establish the identity of any individual or process associated with the event.
V-237356 Medium The CA API Gateway must protect audit information from unauthorized read access.
V-237357 Medium The CA API Gateway must protect audit information from unauthorized deletion.
V-237358 Medium The CA API Gateway must protect audit tools from unauthorized access.
V-237359 Medium The CA API Gateway must not have unnecessary services and functions enabled.
V-237360 Medium The CA API Gateway must be configured to remove or disable unrelated or unneeded application proxy services.
V-237361 Medium The CA API Gateway must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the PPSM CAL and vulnerability assessments.
V-237362 Medium The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
V-237363 Medium The CA API Gateway providing user access control intermediary services must be configured with a pre-established trust relationship and mechanisms with appropriate authorities (e.g., Active Directory or AAA server) that validate user account access authorizations and privileges.
V-237364 Medium The CA API Gateway providing user authentication intermediary services must restrict user authentication traffic to specific authentication server(s).
V-237365 Medium The ALG providing user authentication intermediary services must use multifactor authentication for network access to non-privileged accounts.
V-237366 Medium The CA API Gateway providing user authentication intermediary services must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.
V-237367 Medium The CA API Gateway providing PKI-based user authentication intermediary services must map authenticated identities to the user account.
V-237368 Medium The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
V-237369 Medium The CA API Gateway providing content filtering must block outbound traffic containing known and unknown Denial of Service (DoS) attacks to protect against the use of internal information systems to launch any DoS attacks against other networks or endpoints.
V-237370 Medium The CA API Gateway must terminate all network connections associated with a Policy Manager session at the end of the session or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity within the Policy Manager, and for user sessions simply viewing the contents of Policy Manager or viewing Audit Logs for tracking purposes (non-privileged session), the session must be terminated after 15 minutes of inactivity.
V-237371 Medium The CA API Gateway must detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment.
V-237372 Medium The CA API Gateway must protect the authenticity of communications sessions.
V-237373 Medium The CA API Gateway must invalidate session identifiers upon user logout or other session termination.
V-237374 Medium The CA API Gateway must generate unique session identifiers using a FIPS 140-2 approved random number generator.
V-237375 Medium The CA API Gateway providing content filtering must integrate with an ICAP-enabled Intrusion Detection System that updates malicious code protection mechanisms and signature definitions whenever new releases are available in accordance with organizational configuration management policy and procedures.
V-237376 Medium The CA API Gateway providing content filtering must be configured to perform real-time scans of files from external sources at network entry/exit points as they are downloaded and prior to being opened or executed.
V-237377 Medium The CA API Gateway providing content filtering must block malicious code upon detection.
V-237378 Medium The CA API Gateway providing content filtering must delete or quarantine malicious code in response to malicious code detection.
V-237379 Medium The CA API Gateway providing content filtering must send an immediate (within seconds) alert to the system administrator, at a minimum, in response to malicious code detection.
V-237380 Medium The CA API Gateway providing content filtering must automatically update malicious code protection mechanisms.
V-237381 Medium The CA API Gateway must generate error messages that provide the information necessary for corrective actions without revealing information that could be exploited by adversaries.
V-237382 Medium The CA API Gateway providing content filtering must block or restrict detected prohibited mobile code.
V-237383 Medium The CA API Gateway providing content filtering must prevent the download of prohibited mobile code.
V-237384 Medium The CA API Gateway providing intermediary services for remote access communications traffic must control remote access methods.
V-237385 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-237386 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-237387 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-237388 Medium To protect against data mining, the CA API Gateway providing content filtering must detect code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-237389 Medium To protect against data mining, the CA API Gateway providing content filtering must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-237390 Medium To protect against data mining, the CA API Gateway providing content filtering as part of its intermediary services must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-237391 Medium The CA API Gateway must off-load audit records onto a centralized log server.
V-237392 Medium The CA API Gateway providing user authentication intermediary services must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.
V-237393 Medium The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
V-237394 Medium The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
V-237395 Medium The CA API Gateway must prohibit the use of cached authenticators after an organization-defined time period.
V-237396 Medium The CA API Gateway providing user authentication intermediary services using PKI-based user 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.
V-237397 Medium The CA API Gateway providing user authentication intermediary services must conform to Federal Identity, Credential, and Access Management (FICAM) issued profiles.
V-237398 Medium The CA API Gateway providing user authentication intermediary services using PKI-based user authentication must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of protected sessions.
V-237399 Medium The CA API Gateway providing content filtering must protect against known and unknown types of Denial of Service (DoS) attacks by employing rate-based attack prevention behavior analysis.
V-237400 Medium The CA API Gateway must implement load balancing to limit the effects of known and unknown types of Denial of Service (DoS) attacks.
V-237401 Medium The CA API Gateway must only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.
V-237402 Medium The CA API Gateway must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.
V-237403 Medium The CA API Gateway providing content filtering must be configured to integrate with a system-wide intrusion detection system.
V-237404 Medium The CA API Gateway providing content filtering must send an alert to, at a minimum, the ISSO and ISSM when detection events occur.
V-237405 Medium The CA API Gateway providing content filtering must generate a notification on the console when root-level intrusion events that attempt to provide unauthorized privileged access are detected.
V-237406 Low The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when user-level intrusions that provide non-privileged access are detected.
V-237407 Low The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when Denial of Service (DoS) incidents are detected.
V-237408 Medium The ALG providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected.
V-237409 Medium The CA API Gateway providing user authentication intermediary services must transmit only encrypted representations of passwords.
V-237410 Medium The CA API Gateway must check the validity of all data inputs except those specifically identified by the organization.
V-237411 Medium The CA API Gateway must reveal error messages only to the ISSO, ISSM, and SCA.
V-237412 Medium The CA API Gateway providing user access control intermediary services must generate audit records when successful/unsuccessful logon attempts occur.
V-237413 Medium The CA API Gateway providing user access control intermediary services must generate audit records showing starting and ending time for user access to the system.
V-237414 Medium The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography to generate cryptographic hashes.
V-237415 Medium The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography for digital signatures.
V-237416 Medium The CA API Gateway providing encryption intermediary services must use NIST FIPS-validated cryptography to implement encryption services.
V-237417 Medium The CA API Gateway must off-load audit records onto a centralized log server in real time.
V-237418 Medium The CA API Gateway that provides intermediary services for FTP must inspect inbound and outbound FTP communications traffic for protocol compliance and protocol anomalies.
V-237419 Medium The CA API Gateway that provides intermediary services for HTTP must inspect inbound and outbound HTTP traffic for protocol compliance and protocol anomalies.
V-237420 Medium The CA API Gateway providing user access control intermediary services must automatically terminate a user session when organization-defined conditions or trigger events that require a session disconnect occur.
V-237421 Medium The CA API Gateway providing user access control intermediary services must provide a logoff capability for user-initiated communications sessions.
V-237422 Medium The CA API Gateway providing user access control intermediary services must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions.
V-264434 High The CA API ALG must be using a version supported by the vendor.

Removed rules 81

V-71283 Medium The CA API Gateway must enforce approved authorizations for logical access to information and system resources by employing identity-based, role-based, and/or attribute-based security policies.
V-71285 Medium The CA API Gateway must enforce approved authorizations for controlling the flow of information within the network based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.
V-71287 Medium The CA API Gateway must restrict or block harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.
V-71289 Medium The CA API Gateway providing user access control intermediary services must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the network.
V-71291 Medium The CA API Gateway providing user access control intermediary services must retain the Standard Mandatory DoD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.
V-71293 Medium The CA API Gateway providing user access control intermediary services for publicly accessible applications must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the system.
V-71295 Medium The CA API Gateway providing user access control intermediary services must limit users to two concurrent sessions.
V-71299 Medium The CA API Gateway providing intermediary services for remote access communications traffic must use encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions.
V-71307 Medium The CA API Gateway that stores secret or private keys must use FIPS-approved key management technology and processes in the production and control of private/secret cryptographic keys.
V-71315 Medium The CA API Gateway that provides intermediary services for TLS must be configured to comply with the required TLS settings in NIST SP 800-52.
V-71325 Medium The CA API Gateway providing intermediary services for remote access communications traffic must use NIST FIPS-validated cryptography to protect the integrity of remote access sessions.
V-71329 Medium The CA API Gateway must produce audit records containing information to establish the source of the events.
V-71333 Medium The CA API Gateway must produce audit records containing information to establish the outcome of the events.
V-71335 Medium The CA API Gateway must generate audit records containing information to establish the identity of any individual or process associated with the event.
V-71337 Medium The CA API Gateway must protect audit information from unauthorized read access.
V-71339 Medium The CA API Gateway must protect audit information from unauthorized deletion.
V-71341 Medium The CA API Gateway must protect audit tools from unauthorized access.
V-71343 Medium The CA API Gateway must not have unnecessary services and functions enabled.
V-71345 Medium The CA API Gateway must be configured to remove or disable unrelated or unneeded application proxy services.
V-71347 Medium The CA API Gateway must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the PPSM CAL and vulnerability assessments.
V-71349 Medium The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).
V-71351 Medium The CA API Gateway providing user access control intermediary services must be configured with a pre-established trust relationship and mechanisms with appropriate authorities (e.g., Active Directory or AAA server) that validate user account access authorizations and privileges.
V-71353 Medium The CA API Gateway providing user authentication intermediary services must restrict user authentication traffic to specific authentication server(s).
V-71355 Medium The ALG providing user authentication intermediary services must use multifactor authentication for network access to non-privileged accounts.
V-71357 Medium The CA API Gateway providing user authentication intermediary services must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.
V-71359 Medium The CA API Gateway providing PKI-based user authentication intermediary services must map authenticated identities to the user account.
V-71361 Medium The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).
V-71363 Medium The CA API Gateway providing content filtering must block outbound traffic containing known and unknown Denial of Service (DoS) attacks to protect against the use of internal information systems to launch any DoS attacks against other networks or endpoints.
V-71365 Medium The CA API Gateway must terminate all network connections associated with a Policy Manager session at the end of the session or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity within the Policy Manager, and for user sessions simply viewing the contents of Policy Manager or viewing Audit Logs for tracking purposes (non-privileged session), the session must be terminated after 15 minutes of inactivity.
V-71367 Medium The CA API Gateway must detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment.
V-71369 Medium The CA API Gateway must protect the authenticity of communications sessions.
V-71371 Medium The CA API Gateway must invalidate session identifiers upon user logout or other session termination.
V-71373 Medium The CA API Gateway must generate unique session identifiers using a FIPS 140-2 approved random number generator.
V-71375 Medium The CA API Gateway providing content filtering must integrate with an ICAP-enabled Intrusion Detection System that updates malicious code protection mechanisms and signature definitions whenever new releases are available in accordance with organizational configuration management policy and procedures.
V-71377 Medium The CA API Gateway providing content filtering must be configured to perform real-time scans of files from external sources at network entry/exit points as they are downloaded and prior to being opened or executed.
V-71379 Medium The CA API Gateway providing content filtering must block malicious code upon detection.
V-71381 Medium The CA API Gateway providing content filtering must delete or quarantine malicious code in response to malicious code detection.
V-71383 Medium The CA API Gateway providing content filtering must send an immediate (within seconds) alert to the system administrator, at a minimum, in response to malicious code detection.
V-71385 Medium The CA API Gateway providing content filtering must automatically update malicious code protection mechanisms.
V-71387 Medium The CA API Gateway must generate error messages that provide the information necessary for corrective actions without revealing information that could be exploited by adversaries.
V-71389 Medium The CA API Gateway providing content filtering must block or restrict detected prohibited mobile code.
V-71391 Medium The CA API Gateway providing content filtering must prevent the download of prohibited mobile code.
V-71393 Medium The CA API Gateway providing intermediary services for remote access communications traffic must control remote access methods.
V-71395 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-71397 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-71399 Medium To protect against data mining, the CA API Gateway providing content filtering must prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-71421 Medium To protect against data mining, the CA API Gateway providing content filtering must detect code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.
V-71423 Medium To protect against data mining, the CA API Gateway providing content filtering must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.
V-71425 Medium To protect against data mining, the CA API Gateway providing content filtering as part of its intermediary services must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.
V-71427 Medium The CA API Gateway must off-load audit records onto a centralized log server.
V-71429 Medium The CA API Gateway providing user authentication intermediary services must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.
V-71431 Medium The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
V-71433 Medium The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to privileged accounts such that one of the factors is provided by a device separate from the system gaining access.
V-71435 Medium The CA API Gateway must prohibit the use of cached authenticators after an organization-defined time period.
V-71437 Medium The CA API Gateway providing user authentication intermediary services using PKI-based user 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.
V-71439 Medium The CA API Gateway providing user authentication intermediary services must conform to Federal Identity, Credential, and Access Management (FICAM) issued profiles.
V-71441 Medium The CA API Gateway providing user authentication intermediary services using PKI-based user authentication must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of protected sessions.
V-71443 Medium The CA API Gateway providing content filtering must protect against known and unknown types of Denial of Service (DoS) attacks by employing rate-based attack prevention behavior analysis.
V-71445 Medium The CA API Gateway must implement load balancing to limit the effects of known and unknown types of Denial of Service (DoS) attacks.
V-71447 Medium The CA API Gateway must only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.
V-71449 Medium The CA API Gateway must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.
V-71451 Medium The CA API Gateway providing content filtering must be configured to integrate with a system-wide intrusion detection system.
V-71453 Medium The CA API Gateway providing content filtering must send an alert to, at a minimum, the ISSO and ISSM when detection events occur.
V-71455 Medium The CA API Gateway providing content filtering must generate a notification on the console when root-level intrusion events that attempt to provide unauthorized privileged access are detected.
V-71457 Low The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when user-level intrusions that provide non-privileged access are detected.
V-71459 Low The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when Denial of Service (DoS) incidents are detected.
V-71461 Medium The ALG providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected.
V-71463 Medium The CA API Gateway providing user authentication intermediary services must transmit only encrypted representations of passwords.
V-71465 Medium The CA API Gateway must check the validity of all data inputs except those specifically identified by the organization.
V-71467 Medium The CA API Gateway must reveal error messages only to the ISSO, ISSM, and SCA.
V-71469 Medium The CA API Gateway providing user access control intermediary services must generate audit records when successful/unsuccessful logon attempts occur.
V-71471 Medium The CA API Gateway providing user access control intermediary services must generate audit records showing starting and ending time for user access to the system.
V-71473 Medium The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography to generate cryptographic hashes.
V-71475 Medium The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography for digital signatures.
V-71477 Medium The CA API Gateway that provides intermediary services for FTP must inspect inbound and outbound FTP communications traffic for protocol compliance and protocol anomalies.
V-71479 Medium The CA API Gateway that provides intermediary services for HTTP must inspect inbound and outbound HTTP traffic for protocol compliance and protocol anomalies.
V-71481 Medium The CA API Gateway providing user access control intermediary services must automatically terminate a user session when organization-defined conditions or trigger events that require a session disconnect occur.
V-71483 Medium The CA API Gateway providing user access control intermediary services must provide a logoff capability for user-initiated communications sessions.
V-71485 Medium The CA API Gateway providing user access control intermediary services must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions.
V-71487 Medium The CA API Gateway providing encryption intermediary services must use NIST FIPS-validated cryptography to implement encryption services.
V-71489 Medium The CA API Gateway must off-load audit records onto a centralized log server in real time.

Sort by

Expand all

The CA API Gateway must enforce approved authorizations for logical access to information and system resources by employing identity-based, role-based, and/or attribute-based security policies.

AC-3 - Medium - CCI-000213 - V-237342 - SV-237342r643576_rule

RMF Control

AC-3

Severity

CCI

CCI-000213

Version

CAGW-GW-000100

Vuln IDs

V-237342
V-71283

Rule IDs

SV-237342r643576_rule
SV-85907

Successful authentication must not automatically give an entity access to an asset or security boundary. The lack of authorization-based access control could result in the immediate compromise and unauthorized access to sensitive information. All DoD systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access. 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. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. The CA API Gateway has the ability to integrate with third-party identity providers such as Active Directory. Users within the identity providers should be granted access to the Registered Services as needed through the use of policies within the Registered Services. 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. ALGs must use these policies and mechanisms to control access on behalf of the application for which it is acting as intermediary.

Checks: C-40561r643574_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services and verify the "Request: Authenticate User or Group" assertion has been added and enabled within the Services in accordance with organizational requirements. If it has not, this is a finding.

Fix: F-40524r643575_fix

Open the CA API Gateway - Policy Manager. Double-click all Registered Services and add the "Authenticate User or Group" assertion. Select from a list of Identity providers in the drop-down list and click "Search". Chose from the list of users and groups to grant/authorize access to the Registered Service and click "Select".

The CA API Gateway must enforce approved authorizations for controlling the flow of information within the network based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

AC-4 - Medium - CCI-001368 - V-237343 - SV-237343r643579_rule

RMF Control

AC-4

Severity

CCI

CCI-001368

Version

CAGW-GW-000110

Vuln IDs

V-237343
V-71285

Rule IDs

SV-237343r643579_rule
SV-85909

Information flow control regulates where information is allowed to travel within a network. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, devices) within information systems. Examples of information flow control restrictions include keeping export-controlled information from being transmitted in the clear to the Internet or blocking information marked as classified but being transported to an unapproved destination. Using the CA API Gateway - Policy Manager, when creating polices to meet this requirement, the policies should be configured to leverage attributes from the ${request} variable, which contains information about the requesting client's IP address and identity, as well as message headers and body (content) that make up the request. The CA API Gateway request message headers and content should be parsed and matched against regular expressions (regex) patterns for any text content, XPath expressions for XML content, and JSON path for JSON content relevant to the required flow of information.

Checks: C-40562r643577_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services requiring enforced authorization for controlling the flow of information. Verify the policies include the proper logic and flow based on the information derived from parsing the attributes of the message request. The policy should be configured to do comparisons and provide logical groupings of assertions using the "At least one..." and "All..." assertions so multiple checks can be performed on various attributes to control access to resources. If it has not, this is a finding.

Fix: F-40525r643578_fix

Open the CA API Gateway - Policy Manager. Double-click all Registered Services requiring enforced authorization for controlling the flow of information. Add/update the policy with the appropriate Assertions and include the proper logic and flow based on the information derived from parsing the attributes of a message request to the API in accordance with organizational requirements. The policy should be configured to do comparisons and provide logical groupings of assertions using the "At least one..." and "All..." assertions so multiple checks can be performed on various attributes to control access to resources.

The CA API Gateway must restrict or block harmful or suspicious communications traffic by controlling the flow of information between interconnected networks based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic.

AC-4 - Medium - CCI-001414 - V-237344 - SV-237344r643582_rule

RMF Control

AC-4

Severity

CCI

CCI-001414

Version

CAGW-GW-000120

Vuln IDs

V-237344
V-71287

Rule IDs

SV-237344r643582_rule
SV-85911

Information flow control regulates where information is allowed to travel within a network and between interconnected networks. Blocking or restricting detected harmful or suspicious communications between interconnected networks enforces approved authorizations for controlling the flow of traffic. This requirement applies to the flow of information between the CA API Gateway when used as a gateway or boundary device that allows traffic flow between interconnected networks of differing security policies. The CA API Gateway should be installed and configured to restrict or block information flows based on guidance in the Ports, Protocols, and Services Management (PPSM) regarding restrictions for boundary crossing for ports, protocols, and services. Information flow restrictions may be implemented based on attribute- and content-based inspection of the source, destination, headers, and/or content of the communications traffic. The CA API Gateway policies securing the Registered Services should include rules to control the flow of information between systems and networks with policy filters (e.g., rules that parse the Request Message attributes and/or signatures) that restrict or block information system services; provide a packet-filtering capability based on header information; and/or perform message filtering based on message content.

Checks: C-40563r643580_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services required to restrict or block harmful or suspicious traffic. Verify the policies include the proper logic and flow based on the information derived from parsing the attributes of the message request. The policy should be configured to do comparisons and provide logical groupings of assertions using the "At least one..." and "All..." assertions so multiple checks can be performed on various attributes to control access to resources. If it has not, this is a finding.

Fix: F-40526r643581_fix

Open the CA API Gateway - Policy Manager. Double-click all Registered Services required to restrict or block harmful or suspicious traffic. Add /update the policy with the appropriate Assertions and include the proper logic and flow based on the information derived from parsing the attributes of a message request to the API in accordance with organizational requirements. The policy should be configured to do comparisons and provide logical groupings of assertions using the "At least one..." and "All..." assertions so multiple checks can be performed on various attributes to control access to resources.

The CA API Gateway providing user access control intermediary services must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the network.

AC-8 - Medium - CCI-000048 - V-237345 - SV-237345r643585_rule

RMF Control

AC-8

Severity

CCI

CCI-000048

Version

CAGW-GW-000130

Vuln IDs

V-237345
V-71289

Rule IDs

SV-237345r643585_rule
SV-85913

Display of a standardized and approved use notification before granting access to the network ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." The CA API Gateway should return a custom template response upon first use of an application before routing to a back-end service with the above DoD Banner. An application should be set up to call a CA API Gateway Service with the custom response included, which before logon of an application, displays the Standard Mandatory DoD-approved Notice and Consent Banner.

Checks: C-40564r643583_chk

Open the CA API GW - Policy Manager and verify that a Registered Service is present for displaying the Standard Mandatory DoD-approved Notice and Consent Banner. If the Registered Service is not present, this is a finding.

Fix: F-40527r643584_fix

Open the CA API GW - Policy Manager and create a Registered Service that includes a "Return Template Response" Assertion displaying the Standard Mandatory DoD-approved Notice and Consent Banner. For more details, refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing user access control intermediary services must retain the Standard Mandatory DoD-approved Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access.

AC-8 - Medium - CCI-000050 - V-237346 - SV-237346r643588_rule

RMF Control

AC-8

Severity

CCI

CCI-000050

Version

CAGW-GW-000140

Vuln IDs

V-237346
V-71291

Rule IDs

SV-237346r643588_rule
SV-85915

The banner must be acknowledged by the user prior to allowing the user access to the network. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The network element must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK". The CA API Gateway should return a custom template response before routing to a back-end service with the above DoD Banner and must wait for acceptance of the Banner by the requesting user. An application should be set up to call a CA API Gateway Service with the custom response included that, before logon of an application, displays the Standard Mandatory DoD-approved Notice and Consent Banner.

Checks: C-40565r643586_chk

Open the CA API Gateway - Policy Manager and verify a Registered Service is present for displaying the Standard Mandatory DoD-approved Notice and Consent Banner. If the Registered Service is not present, this is a finding.

Fix: F-40528r643587_fix

Open the CA API Gateway - Policy Manager and create a Registered Service that includes a "Return Template Response" Assertion displaying the Standard Mandatory DoD-approved Notice and Consent Banner. Add additional policy Assertions to check for whether the banner was acknowledged or not and grant access accordingly to the logon page. For more details, refer to the "Layer 7 Policy Authoring User Manual".

The CA API Gateway providing user access control intermediary services for publicly accessible applications must display the Standard Mandatory DoD-approved Notice and Consent Banner before granting access to the system.

AC-8 - Medium - CCI-001384 - V-237347 - SV-237347r643591_rule

RMF Control

AC-8

Severity

CCI

CCI-001384

Version

CAGW-GW-000150

Vuln IDs

V-237347
V-71293

Rule IDs

SV-237347r643591_rule
SV-85917

Display of a standardized and approved use notification before granting access to the publicly accessible network element ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. This requirement applies to network elements that have the concept of a user account and have the logon function residing on the network element. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for network elements that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." The CA API Gateway should return a custom template response before routing to a back-end service with the above DoD Banner and must wait for acceptance of the Banner by the requesting user. An Application should be set up to call a CA API Gateway Service with the custom response included that, before logon of an application, displays the Standard Mandatory DoD-approved Notice and Consent Banner.

Checks: C-40566r643589_chk

Fix: F-40529r643590_fix

Open the CA API Gateway - Policy Manager and create a Registered Service that includes a "Return Template Response" Assertion displaying the Standard Mandatory DoD-approved Notice and Consent Banner. For more details, refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing user access control intermediary services must limit users to two concurrent sessions.

AC-10 - Medium - CCI-000054 - V-237348 - SV-237348r643594_rule

RMF Control

AC-10

Severity

CCI

CCI-000054

Version

CAGW-GW-000160

Vuln IDs

V-237348
V-71295

Rule IDs

SV-237348r643594_rule
SV-85919

Network element management includes the ability to control the number of users and user sessions that utilize a network element. Limiting the number of current sessions per user is helpful in limiting risks related to Denial of Service (DoS) attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions must be the same as the requirements specified for the application for which it serves as intermediary. The CA API Gateway must have Global Policies that enable rate limits that throttle the number of concurrent sessions for Registered Services/APIs in accordance with organizational requirements.

Checks: C-40567r643592_chk

Log on to the CA API Gateway - Policy Manager. By default, the Gateway has no limit set on the number of concurrent sessions. However, this is configurable in Global Policy. Check the lower-left corner of the CA API Gateway - Policy Manager to see if a Global Policy for concurrent sessions has been previously configured by an administrator. (Global policies are displayed with a green icon beside their name.) If the policy does not exist, this is a finding. If the policy does exist, verify the Rate Limits are set to meet the organization's security requirements. If the Rate Limits are not set to meet the organization's security requirements, this is a finding.

Fix: F-40530r643593_fix

The CA API Gateway providing intermediary services for remote access communications traffic must use encryption services that implement NIST FIPS-validated cryptography to protect the confidentiality of remote access sessions.

AC-17 - Medium - CCI-000068 - V-237349 - SV-237349r643597_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

CAGW-GW-000170

Vuln IDs

V-237349
V-71299

Rule IDs

SV-237349r643597_rule
SV-85923

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 broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). 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 the mechanism is selected based on the security categorization of the information. The CA API Gateway uses the RSA BSAFE Crypto-J Software Module for cryptography, which is validated to FIPS 140-2 Overall Level 1 when operated in FIPS mode. FIPS mode is not enabled by default and must be enabled to meet this requirement.

Checks: C-40568r643595_chk

Open the CA API Gateway - Policy Manager. Select Tasks >> Manage Listen Ports and double-click on each SSL listen port. Verify that no SSL versions are selected, TLS 1.0 is not selected, and only TLS 1.1, 1.2, and above are selected. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable). If it is not, this is a finding.

Fix: F-40531r643596_fix

Open the CA API Gateway - Policy Manager. Select Tasks >> Manage Listen Ports, double-click on each SSL listen port, select the SSL/TLS settings, deselect TLS 1.0, and select TLS 1.1 and TLS 1.2. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable).

The CA API Gateway that stores secret or private keys must use FIPS-approved key management technology and processes in the production and control of private/secret cryptographic keys.

AC-17 - Medium - CCI-000068 - V-237350 - SV-237350r643600_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

CAGW-GW-000180

Vuln IDs

V-237350
V-71307

Rule IDs

SV-237350r643600_rule
SV-85931

Private key data is used to prove the entity presenting a public key certificate is the certificate's rightful owner. Compromise of private key data allows an adversary to impersonate the key holder. Private key data associated with software certificates, including those issued to an ALG, is required to be generated and protected in at least a FIPS 140-2 Level 1 validated cryptographic module. By default, the CA API Gateway uses the SunJSSE PKCS#12 for key storage, which is not approved at FIPS 140-2. The Gateway must be configured to use a SafeNet Luna Hardware Security Module (HSM) that is approved at FIPS-140-2 Level 3.

Checks: C-40569r643598_chk

Verify an HSM, such as the SafeNet Luna HSM, is currently storing Private Keys. If an HSM is not present, this is a finding.

Fix: F-40532r643599_fix

Refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home for directions on configuring the CA API Gateway to use a SafeNet Luna HSM for secure private key storage.

The CA API Gateway that provides intermediary services for TLS must be configured to comply with the required TLS settings in NIST SP 800-52.

AC-17 - Medium - CCI-000068 - V-237351 - SV-237351r643603_rule

RMF Control

AC-17

Severity

CCI

CCI-000068

Version

CAGW-GW-000190

Vuln IDs

V-237351
V-71315

Rule IDs

SV-237351r643603_rule
SV-85939

SP 800-52 provides guidance on using the most secure version and configuration of the TLS/SSL protocol. Using older unauthorized versions or incorrectly configuring protocol negotiation makes the Gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. SP 800-52 sets TLS version 1.1 as a minimum version; thus, all versions of SSL are not allowed (including for client negotiation) on either DoD-only or public-facing servers. The CA API Gateway must be configured to use FIPS-140 cryptographic algorithms to meet the NIST SP 800-52 TLS settings.

Checks: C-40570r643601_chk

Open the CA API Gateway - Policy Manager. Select "Manage Cluster-Wide Properties" from the "Tasks" menu. If the "security.fips.enabled" property is not listed or is set to false, this is a finding.

Fix: F-40533r643602_fix

The CA API Gateway providing intermediary services for remote access communications traffic must use NIST FIPS-validated cryptography to protect the integrity of remote access sessions.

AC-17 - Medium - CCI-001453 - V-237352 - SV-237352r643606_rule

RMF Control

AC-17

Severity

CCI

CCI-001453

Version

CAGW-GW-000200

Vuln IDs

V-237352
V-71325

Rule IDs

SV-237352r643606_rule
SV-85949

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. 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 broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. The CA API Gateway uses the RSA BSAFE Crypto-J Software Module, which is validated to FIPS 140-2 Overall Level 1 when operated in FIPS mode. FIPS mode is not enabled by default and must be enabled.

Checks: C-40571r643604_chk

Open the CA API Gateway - Policy Manager. Select "Manage Cluster-Wide Properties" from the "Tasks" menu. If the "security.fips.enabled" property is not listed or is set to false, this is a finding. Additionally, select Tasks >> Manage Listen Ports and double-click on each SSL listen port. Verify that no SSL versions are selected, TLS 1.0 is not selected, and only TLS 1.1, 1.2, and above are selected. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable). If it is not, this is a finding.

Fix: F-40534r643605_fix

Open the CA API Gateway - Policy Manager. Select "Manage Cluster-Wide Properties" from the "Tasks" menu. Click "Add" and select "security.fips.enabled" from the Key: drop-down list. Set the value to "true" and click "OK". API Gateway version 8.3 and later will automatically deselect TLS 1.0. For version 8.2 and prior, select Tasks >> Manage Listen Ports, double-click on each SSL listen port, select the SSL/TLS settings, deselect TLS 1.0, and select TLS 1.1 and TLS 1.2. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable).

The CA API Gateway must produce audit records containing information to establish the source of the events.

AU-3 - Medium - CCI-000133 - V-237353 - SV-237353r643609_rule

RMF Control

AU-3

Severity

CCI

CCI-000133

Version

CAGW-GW-000210

Vuln IDs

V-237353
V-71329

Rule IDs

SV-237353r643609_rule
SV-85953

Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event. In addition to logging where events occur within the network, the audit records must also identify sources of events such as IP addresses, processes, and node or device names. The CA API Gateway policies must be configured to provide the required level of auditing in accordance with organizational requirements.

Checks: C-40572r643607_chk

Open the CA API Gateway - Policy Manager. Select "Gateway Audit Events" from the "View" menu. Execute a logon failure of one of the Registered Services using an approved testing tool or an Application that accesses the service. View the Audit logs to notice the logging of the Authentication failure as well as the source of the failure showing the individual client ID's IP address. If the failure is not logged or the source is not properly displayed, this is a finding.

Fix: F-40535r643608_fix

If a logon failure is not recorded, check the Registered Service for the existence of an Authentication Mechanism using an Access Control Assertion such as "Authenticate Against Identity Provider". Also verify a Credential Source is added from the Access Control Assertions, such as "Require HTTP Basic Credentials" or "Require WS-Security Username Token Profile Credentials". Other attacks on a Registered Service, such as SQL Injection or PHP Evaluation Injections, will be automatically logged when the Assertion checking for the attack is added to a Registered Service or set in Global Policy. The event will include the source of the attack indicated by the client ID.

The CA API Gateway must produce audit records containing information to establish the outcome of the events.

AU-3 - Medium - CCI-000134 - V-237354 - SV-237354r643612_rule

RMF Control

AU-3

Severity

CCI

CCI-000134

Version

CAGW-GW-000220

Vuln IDs

V-237354
V-71333

Rule IDs

SV-237354r643612_rule
SV-85957

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 network. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the network after the event occurred). They also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. The CA API Gateway policies must be configured to provide the required level of auditing in accordance with organizational requirements.

Checks: C-40573r643610_chk

Open the CA API Gateway - Policy Manager. Select "Gateway Audit Events" from the "View" menu. Execute a logon failure of one of the Registered Services using an approved testing tool or an application that accesses the service. View the audit logs to notice the logging of the authentication failure showing the outcome of the logon failure event. If the outcome of the event is not shown, this is a finding.

Fix: F-40536r643611_fix

If a logon failure is not recorded, check the Registered Service for the existence of an authentication mechanism using an Access Control Assertion such as "Authenticate Against Identity Provider". Also verify that a Credential Source is added from the Access Control Assertions, such as "Require HTTP Basic Credentials" or "Require WS -Security Username Token Profile Credentials". Other outcomes of events occurring on a Registered Service, such as SQL Injection or PHP Evaluation Injections, will be automatically logged when the Assertion checking for the attack is added to a Registered Service or set in Global Policy. The event will include the outcome displaying its results.

The CA API Gateway must generate audit records containing information to establish the identity of any individual or process associated with the event.

AU-3 - Medium - CCI-001487 - V-237355 - SV-237355r643615_rule

RMF Control

AU-3

Severity

CCI

CCI-001487

Version

CAGW-GW-000230

Vuln IDs

V-237355
V-71335

Rule IDs

SV-237355r643615_rule
SV-85959

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. Associating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured network element. The CA API Gateway must have the "Audit Messages in Policy" Assertion added to all policies.

Checks: C-40574r643613_chk

Open the CA API Gateway - Policy Manager and verify all of the Registered Services have the "Audit Messages in Policy" Assertion added to the Service. If any of the Registered Services do not have the "Audit Messages in Policy" Assertion added, this is a finding.

Fix: F-40537r643614_fix

Open the CA API Gateway - Policy Manager. Open the Registered Services that do not have the "Audit Messages in Policy" Assertion and add it to the top of the Registered Services policies.

The CA API Gateway must protect audit information from unauthorized read access.

AU-9 - Medium - CCI-000162 - V-237356 - SV-237356r643618_rule

RMF Control

AU-9

Severity

CCI

CCI-000162

Version

CAGW-GW-000240

Vuln IDs

V-237356
V-71337

Rule IDs

SV-237356r643618_rule
SV-85961

Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or simply identify an improperly configured network element. Thus, it is imperative that the collected log data from the various network elements, as well as the auditing tools, be secured and can only be accessed by authorized personnel. Audited events are protected by default by only allowing access to the audited events to authorized users of the CA API Gateway - Policy Manager. Any user requiring access to the audit Information must be explicitly granted access to the Policy Manager auditing tool as per organizational requirements.

Checks: C-40575r643616_chk

Open the CA API Gateway - Policy Manager. Select "Tasks" from the main menu and chose "Manage Roles". Verify that only authorized users have been given the "View Audit Records" role. If unauthorized users are granted this role, this is a finding.

Fix: F-40538r643617_fix

Open the CA API Gateway - Policy Manager as an administrator. Select "Tasks" from the main menu and chose "Manage Roles". Remove the unauthorized user from any role they should not be a member of, including the "View Audit Records" role. Additionally, consider removing the user completely or removing the user from any groups within the identity provider that may be assigned to a role for which the user may not be authorized.

The CA API Gateway must protect audit information from unauthorized deletion.

AU-9 - Medium - CCI-000164 - V-237357 - SV-237357r643621_rule

RMF Control

AU-9

Severity

CCI

CCI-000164

Version

CAGW-GW-000250

Vuln IDs

V-237357
V-71339

Rule IDs

SV-237357r643621_rule
SV-85963

If audit data becomes compromised, 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 on system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audited events are protected by default by only allowing access to the audited events to authorized users of the CA API Gateway - Policy Manager assigned to the role of "View Audit Records". Those users must be granted access by an administrator and must be approved for access to the audited events by the organization. Users needing access to the deletion of audited events must be explicitly granted the privileges to do so.

Checks: C-40576r643619_chk

Open the CA API Gateway - Policy Manager. Select "Tasks" from the main menu and choose "Manage Roles". Verify that only authorized users have been given the "View Audit Records" role. If unauthorized users are granted this role, this is a finding.

Fix: F-40539r643620_fix

Open the CA API Gateway - Policy Manager as an administrator. Select "Tasks" from the main menu and chose "Manage Roles". Select the "View Audit Records" Role and Add/Assign the users that are authorized to view the audited events as per organizational policy.

The CA API Gateway must protect audit tools from unauthorized access.

AU-9 - Medium - CCI-001493 - V-237358 - SV-237358r643624_rule

RMF Control

AU-9

Severity

CCI

CCI-001493

Version

CAGW-GW-000260

Vuln IDs

V-237358
V-71341

Rule IDs

SV-237358r643624_rule
SV-85965

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. Network elements 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 to make decisions regarding access to audit tools. There is only one tool used to view audited events within the CA API Gateway. That tool is the CA API Gateway - Policy Manager. Use of this tool must be granted and policed by the organization, only allowing individuals access as needed in accordance with the organizational requirements.

Checks: C-40577r643622_chk

Open the CA API Gateway - Policy Manager as an administrative user. Select "Tasks" from the main menu and chose "Manage Roles". Verify that only the authorized users of the tool have been granted their respective roles. If any user has not been granted the proper role(s), this is a finding.

Fix: F-40540r643623_fix

The CA API Gateway must not have unnecessary services and functions enabled.

CM-7 - Medium - CCI-000381 - V-237359 - SV-237359r643627_rule

RMF Control

CM-7

Severity

CCI

CCI-000381

Version

CAGW-GW-000270

Vuln IDs

V-237359
V-71343

Rule IDs

SV-237359r643627_rule
SV-85967

Information systems are capable of providing a wide variety of functions (capabilities or processes) and services. Some of these functions and services are installed and enabled by default. The organization must determine which functions and services are required to perform the content filtering and other necessary core functionality for each component of the ALG. 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. The primary function of an ALG is to provide application-specific content filtering and/or proxy services. The ALG application suite may integrate related content filtering and analysis services and tools (e.g., IPS, proxy, malware inspection, black/white lists). Some gateways may also include email scanning, decryption, caching, and DLP services. However, services and capabilities that are unrelated to this primary functionality must not be installed (e.g., DNS, email client or server, FTP server, or web server). Next Generation ALGs (NGFW) and Unified Threat Management (UTM) ALGs integrate functions that have traditionally been separated. These products integrate content filtering features to provide more granular policy filtering. There may be operational drawbacks to combining these services into one device. Another issue is that NGFW and UTM products vary greatly, with no current definitive industry standard. The CA API Gateway must not enable unnecessary services unless required by a Registered Service to be used in accordance with organizational requirements.

Checks: C-40578r643625_chk

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu, and chose "Manage Listen Ports". If the Listen ports or firewall rules are not configured in accordance with organizational requirements for disabling unnecessary services, this is a finding.

Fix: F-40541r643626_fix

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu, and chose "Manage Listen Ports". Update the Listen ports and firewall rules in accordance with organizational requirements for disabling unnecessary services.

The CA API Gateway must be configured to remove or disable unrelated or unneeded application proxy services.

CM-7 - Medium - CCI-000381 - V-237360 - SV-237360r643630_rule

RMF Control

CM-7

Severity

CCI

CCI-000381

Version

CAGW-GW-000280

Vuln IDs

V-237360
V-71345

Rule IDs

SV-237360r643630_rule
SV-85969

Unrelated or unneeded proxy services increase the attack vector and add excessive complexity to the securing of the ALG. Multiple application proxies can be installed on many ALGs. However, proxy types must be limited to related functions. At a minimum, the web and email gateway represent different security domains/trust levels. Organizations should also consider separation of gateways that service the DMZ and the trusted network. The CA API Gateway allows administrators to register only the necessary services that require reverse proxy to the internal organization’s network. All other services must not be enabled on the CA API Gateway until registered and assigned the appropriate amount of security policy to meet the organization's requirements.

Checks: C-40579r643628_chk

Open the CA API Gateway - Policy Manager and verify the Registered Services installed on the Gateway are only the Registered Services required by the Gateway to manage proxy services in accordance with organizational requirements. If there are other services not required by the organization or that the organization is not responsible for managing, this is a finding.

Fix: F-40542r643629_fix

Open the CA API Gateway - Policy Manager and delete all unrelated or not needed Registered Services that are not required by the organization's CA API Gateway to manage proxy services.

The CA API Gateway must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the PPSM CAL and vulnerability assessments.

CM-7 - Medium - CCI-000382 - V-237361 - SV-237361r643633_rule

RMF Control

CM-7

Severity

CCI

CCI-000382

Version

CAGW-GW-000290

Vuln IDs

V-237361
V-71347

Rule IDs

SV-237361r643633_rule
SV-85971

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. ALGs 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. DoD continually assesses the ports, protocols, and services that can be used for network communications. Some ports, protocols, or services have known exploits or security weaknesses. Network traffic using these ports, protocols, and services must be prohibited or restricted in accordance with DoD policy. The ALG is a key network element for preventing these non-compliant ports, protocols, and services from causing harm to DoD information systems. The CA API Gateway must be configured to prevent or restrict the use of prohibited ports, protocols, and services throughout the network by filtering the network traffic and disallowing or redirecting traffic as necessary. Default and updated policy filters from the vendors will disallow older version of protocols and applications and will address most known non-secure ports, protocols, and/or services. However, sources for further policy filters are the IAVMs and the PPSM requirements.

Checks: C-40580r643631_chk

Open the CA API Gateway - Policy Manager. Select "Tasks" from the main menu and chose "Manage Listen Ports". Verify on the ports necessary to meet organizational requirements are listed. If there are ports in violation of organizational requirements, this is a finding.

Fix: F-40543r643632_fix

Open the CA API Gateway - Policy Manager. Select “Tasks" from the main menu and chose "Manage Listen Ports". Select any port in violation and then press the "Remove" button to remove that port in accordance with organizational requirements.

The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users).

IA-2 - Medium - CCI-000764 - V-237362 - SV-237362r643636_rule

RMF Control

IA-2

Severity

CCI

CCI-000764

Version

CAGW-GW-000300

Vuln IDs

V-237362
V-71349

Rule IDs

SV-237362r643636_rule
SV-85973

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: 1) 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. 2) 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. The CA API Gateway must have an Identity Provider registered/enabled on the Gateway in accordance with organizational requirements and must ensure authentication mechanisms are included with all Registered Services on the Gateway through the use of "Access Control" Assertions added to Registered Services policies.

Checks: C-40581r643634_chk

Open the CA API Gateway - Policy Manager and double-click each of the Registered Services that require authentication of organizational users. Check the Registered Services for the existence of an Authentication Mechanism using an Access Control Assertion such as "Authenticate Against Identity Provider". Also validate that a Credential Source is added from the Access Control Assertions, such as "Require HTTP Basic Credentials" or "Require WS - Security Username Token Profile Credentials". If it is not, this is a finding.

Fix: F-40544r643635_fix

Open the CA API Gateway - Policy Manager and double-click each of the Registered Services that require authentication of organizational users that do not have the required "Access Control" Assertions. Add the "Authenticate Against Identity Provider" as well as a Credential Source such as "Require HTTP Basic Credentials" or "Require WS - Security Username Token Profile Credentials" from the list of "Access Control" Assertions. Click "Save and Activate" to activate the updated policy for the Registered Services.

The CA API Gateway providing user access control intermediary services must be configured with a pre-established trust relationship and mechanisms with appropriate authorities (e.g., Active Directory or AAA server) that validate user account access authorizations and privileges.

IA-2 - Medium - CCI-000764 - V-237363 - SV-237363r643639_rule

RMF Control

IA-2

Severity

CCI

CCI-000764

Version

CAGW-GW-000310

Vuln IDs

V-237363
V-71351

Rule IDs

SV-237363r643639_rule
SV-85975

User account and privilege validation must be centralized in order to prevent unauthorized access using changed or revoked privileges. ALGs can implement functions such as traffic filtering, authentication, access, and authorization functions based on computer and user privileges. However, the directory service (e.g., Active Directory or LDAP) must not be installed on the ALG, particularly if the Gateway resides on the untrusted zone of the enclave. The CA API Gateway must have registered identity providers in a central location on the Gateway that provides a pre-established trust for use in authentication and authorization to Registered Services.

Checks: C-40582r643637_chk

Open the CA API Gateway - Policy Manager. Select the "Identity Providers" tab and verify all appropriate Identity Providers are listed in accordance with organizational requirements. If they are not, this is a finding.

Fix: F-40545r643638_fix

Open the CA API Gateway - Policy Manager. Select the "Identity Providers" tab, right-click "Identity Providers", and register the appropriate Identity Providers to establish the trust on the Gateway in accordance with organizational requirements.

The CA API Gateway providing user authentication intermediary services must restrict user authentication traffic to specific authentication server(s).

IA-2 - Medium - CCI-000764 - V-237364 - SV-237364r643642_rule

RMF Control

IA-2

Severity

CCI

CCI-000764

Version

CAGW-GW-000320

Vuln IDs

V-237364
V-71353

Rule IDs

SV-237364r643642_rule
SV-85977

User authentication can be used as part of the policy filtering rule sets. Some URLs or network resources can be restricted to authenticated users only. Users are prompted by the application or browser for credentials. Authentication service may be provided by the ALG as an intermediary for the application; however, the authentication credential must be stored in the site's directory services server. The CA API Gateway must be configured to direct authentication traffic to specific authentication servers/URLs.

Checks: C-40583r643640_chk

Open the CA API Gateway - Policy Manager. Select the "Identity Providers" tab, right-click a Registered Identity Provider, such as an LDAP Identity Provider, and select "Properties". Verify that a list of "LDAP Host URLs" is provided for use in authentication against this provider. If all of the servers needed for authentication are not listed in accordance with organizational requirements, this is a finding.

Fix: F-40546r643641_fix

Open the CA API Gateway - Policy Manager. Select the "Identity Providers" tab, right-click a Registered Identity Provider such as an LDAP Identity Provider, and select "Properties". Add the additional "LDAP Host URLs" to the list in accordance with organizational requirements and click "Finish".

The ALG providing user authentication intermediary services must use multifactor authentication for network access to non-privileged accounts.

IA-2 - Medium - CCI-000766 - V-237365 - SV-237365r954210_rule

RMF Control

IA-2

Severity

CCI

CCI-000766

Version

CAGW-GW-000330

Vuln IDs

V-237365
V-71355

Rule IDs

SV-237365r954210_rule
SV-85979

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: 1) Something you know (e.g., password/PIN), 2) Something you have (e.g., cryptographic, identification device, token), and 3) Something you are (e.g., biometric). Non-privileged accounts are not authorized access to the network element regardless of access method. 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. Authenticating with a PKI credential and entering the associated PIN is an example of multifactor authentication. The CA API Gateway supports X.509, username/password, SAML, Kerberos, and RADIUS authentication. To provide multifactor authentication, the CA API Gateway must include a policy that uses multiple authentication assertions and include a route assertion that routes to a biometric back-end service and then evaluate the response to allow/disallow access to the Registered Service.

Checks: C-40584r643643_chk

Open the CA API Gateway - Policy Manager. Double-click the Registered Services requiring multifactor authentication. For example, within the policy that leverages an RSA SecurID hardware token along with X.509, verify the policy includes a "Require SSL/TLS with Client Certificate" Assertion, which will validate the certificate according to organizational requirements, then use that certificate to authenticate against LDAP or Active Directory using the "Authenticate Against Identity Provider" Assertion, and then include the value from the hardware token in a request to the RSA SecurID RADIUS service via the" Authenticate Against RADIUS Server" Assertion. If the policy is not configured with multiple factors for authentication in a similar fashion, this is a finding. Additionally, to meet the biometric requirement, check for the existence of an "HTTP(S) Route" assertion, which routes to a back-end biometric validation web service. If the biometric route assertion is not present, this is also a finding.

Fix: F-40547r643644_fix

Open the CA API Gateway - Policy Manager. Double-click the Registered Services requiring multifactor authentication that were not properly configured. For example, within the policy that leverages an RSA SecurID hardware token along with X.509, verify/add the "Require SSL/TLS with Client Certificate" Assertion, which will validate the certificate according to organizational requirements, then using that certificate to authenticate against LDAP or Active Directory, verify/add the "Authenticate Against Identity Provider" Assertion, and then verify/include the value from the hardware token in a request to the RSA SecurID RADIUS service via the "Authenticate Against RADIUS Server" Assertion. Additionally, to meet the biometric requirement, verify/add an "HTTP(S) Route" Assertion configured to route to a back-end biometric validation web service.

The CA API Gateway providing user authentication intermediary services must implement replay-resistant authentication mechanisms for network access to non-privileged accounts.

IA-2 - Medium - CCI-001942 - V-237366 - SV-237366r981631_rule

RMF Control

IA-2

Severity

CCI

CCI-001942

Version

CAGW-GW-000340

Vuln IDs

V-237366
V-71357

Rule IDs

SV-237366r981631_rule
SV-85981

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 non-privileged account is any account with the authorizations of a non-privileged user. Privileged roles are organization-defined roles assigned to individuals that allow those individuals to perform certain security-relevant functions that ordinary users are not authorized to perform. Security-relevant roles include key management, account management, network and system administration, database administration, and web administration. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS). Additional techniques include time-synchronous or challenge-response one-time authenticators. The CA API Gateway registered services requiring replay-resistance must include an out-of-the-box "Protect Against Message Replay" Assertion that will assist with preventing the replay of authenticated sessions accessing network resources.

Checks: C-40585r643646_chk

Open the CA API Gateway - Policy Manager and open each of the Registered Services that requires the replay-resistant authentication mechanisms. Verify the "Protect Against Message Replay" Assertion is present after the "Authenticate User or Group" or "Authenticate Against Identity Provider" Assertion. If the Assertion is not present, this is a finding.

Fix: F-40548r643647_fix

Open the CA API Gateway - Policy Manager and open each of the Registered Services that require the replay-resistant authentication mechanisms. Add the "Protect Against Message Replay" Assertion after the "Authenticate User or Group" or "Authenticate Against Identity Provider" Assertion.

The CA API Gateway providing PKI-based user authentication intermediary services must map authenticated identities to the user account.

IA-5 - Medium - CCI-000187 - V-237367 - SV-237367r643651_rule

RMF Control

IA-5

Severity

CCI

CCI-000187

Version

CAGW-GW-000350

Vuln IDs

V-237367
V-71359

Rule IDs

SV-237367r643651_rule
SV-85983

Authorization for access to any network element requires an approved and assigned individual account identifier. To ensure only the assigned individual is using the account, the account must be bound to a user certificate when PKI-based authentication is implemented. This requirement applies to ALGs that provide user authentication intermediary services (e.g., authentication gateway or TLS gateway). This does not apply to authentication for the purpose of configuring the device itself (device management). When a user is authenticated using PKI, the CA API Gateway must map attributes associated with their certificate in order to query an identity provider mapping the PKI certificate to a user account.

Checks: C-40586r643649_chk

Open the CA API Gateway - Policy Manager and double-click the Registered Services requiring certificate mapping to user accounts. Verify that the "Require SSL/TLS with Client Certificate Authentication" Assertion is present, that "Extract Attributes from Certificate" is present, and that one of the "Authenticate Against..." Assertions is also present. In addition, verify the logic necessary to provide access to the Registered Service's resources is properly enabled using the required policy logic after extracting the proper attributes from the certificate using the "Extract Attributes from Certificate" Assertion. If these requirements have not been met within the policy, this is a finding.

Fix: F-40549r643650_fix

Open the CA API Gateway - Policy Manager and double-click the Registered Services requiring certificate mapping to user accounts. Update the policy with the "Require SSL/TLS with Client Certificate Authentication", the "Extract Attributes from Certificate", and one of the "Authenticate Against..." Assertions. In addition, create the policy logic necessary to provide access to the Registered Service's resources after extracting the proper attributes from the certificate using the "Extract Attributes from Certificate" Assertion in accordance with organizational requirements.

The CA API Gateway providing user authentication intermediary services must uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users).

IA-8 - Medium - CCI-000804 - V-237368 - SV-237368r643654_rule

RMF Control

IA-8

Severity

CCI

CCI-000804

Version

CAGW-GW-000360

Vuln IDs

V-237368
V-71361

Rule IDs

SV-237368r643654_rule
SV-85985

Lack of authentication enables anyone to gain access to the network or possibly a network element that provides opportunity for intruders to compromise resources within the network infrastructure. By identifying and authenticating non-organizational users, their access to network resources can be restricted accordingly. Non-organizational users will 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. Authorization requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Authentication of user identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor authentication, some combination thereof. This control applies to application layer gateways that provide content filtering and proxy services on network segments (e.g., DMZ) that allow access by non-organizational users. This requirement focuses on authentication requests to the proxied application for access to destination resources and policy filtering decisions, rather than administrator and management functions. The CA API Gateway must provide for the use of an internal identity provider that can be used in conjunction with organizational directories such as Active Directory. The internal identity provider can be used for those users not explicitly defined within the organization or for users that exist outside of the organization.

Checks: C-40587r643652_chk

Open the CA API GW - Policy manager and click the "Identity Providers" tab. Verify a provider is listed and designated as the Identity Provider for non-organizational users in accordance with organizational requirements. Verify that non-organizational users are present within this provider. Open the CA API GW - Policy Manager and double-click the Registered Services requiring Certificate mapping to User Accounts. Verify that the "Require SSL/TLS with Client Certificate Authentication" Assertion is present, that "Extract Attributes from Certificate" is present, and that one of the "Authenticate Against..." Assertions is also present. In addition, verify that the logic necessary to provide access to the Registered Service's resources is properly enabled using the required Policy Logic after extracting the proper attributes from the certificate using the "Extract Attributes from Certificate" Assertion. If these requirements have not been met within the policy, this is a finding.

Fix: F-40550r643653_fix

Open the CA API GW - Policy manager and click the "Identity Providers" tab. Right-click "Identity Providers" and create the provider/s utilized for non-organizational users in accordance with organizational requirements. Add non-organizational users to the provider as necessary. Open the CA API GW - Policy Manager and double-click the Registered Services requiring Certificate mapping to User Accounts. Update the policy with the "Require SSL/TLS with Client Certificate Authentication", the "Extract Attributes from Certificate", and one of the "Authenticate Against..." Assertions. In addition, create the Policy Logic necessary to provide access to the Registered Service's resources after extracting the proper attributes from the certificate using the "Extract Attributes from Certificate" Assertion in accordance with organizational requirements.

The CA API Gateway providing content filtering must block outbound traffic containing known and unknown Denial of Service (DoS) attacks to protect against the use of internal information systems to launch any DoS attacks against other networks or endpoints.

SC-5 - Medium - CCI-001094 - V-237369 - SV-237369r643657_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

CAGW-GW-000370

Vuln IDs

V-237369
V-71363

Rule IDs

SV-237369r643657_rule
SV-85987

DoS attacks can take multiple forms but have the common objective of overloading or blocking a network or host to deny or seriously degrade performance. If the network does not provide safeguards against DoS attack, network resources will be unavailable to users. Installation of an ALG at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. The ALG must include protection against DoS attacks that originate from inside the enclave, which can affect either internal or external systems. These attacks may use legitimate or rogue endpoints from inside the enclave. These attacks can be simple "floods" of traffic to saturate circuits or devices, malware that consumes CPU and memory on a device or causes it to crash, or a configuration issue that disables or impairs the proper function of a device. For example, an accidental or deliberate misconfiguration of a routing table can misdirect traffic for multiple networks. To comply with this requirement, the ALG must monitor outbound traffic for indications of known and unknown DoS attacks. Audit log capacity management, along with techniques that prevent the logging of redundant information during an attack, also guard against DoS attacks. The CA API Gateway must enable an inbound rate limit in an effort to provide safeguards against DoS attacks. By default, this is not turned on and will need to be enabled either in Global Policy or within each Registered Service. Additionally, a quota can be inserted within a Registered Service's policy to verify that any request exceeding the quota for an authenticated user, client IP, etc. will be denied access to the Registered Service. Furthermore, a message size limiter can be inserted into a policy to limit the size of any request being received or response being sent.

Checks: C-40588r643655_chk

Open the CA API Gateway - Policy Manager. Check the lower-left corner of the CA API Gateway - Policy Manager to see if a Global Policy is set that includes an "Apply Rate Limit" Assertion. (Global policies are displayed with a green icon beside their name.) If the policy does not exist, this is a finding. If it does exist, verify the Rate Limits are set to meet the organization's security requirements for DoS attacks. Also check each Registered Service requiring additional safeguards such as quota limits and message size limitation to verify the "Apply Throughput Quota" and "Limit Message Size" Assertions have been added and configured to meet organizational requirements. If they have not, this is also a finding.

Fix: F-40551r643656_fix

Open the CA API Gateway - Policy Manager. Select "Tasks" from the main menu and choose "Create Policy". Give the policy a name and select "Global Policy Fragment" from the Policy Type drop-down menu. Select "message-received" from the Policy Tag drop-down menu and click "OK". Drag the "Apply Rate Limit" Assertion into the newly created Global Policy Fragment. Set the "Maximum requests per second" and/or "Maximum concurrent requests" and/or "Limit each:" values to meet the organization's requirements to protect against DoS attacks. Click "Save and Activate”. Also double-click each Registered Service requiring additional safeguards, such as quota limits message size limitations, to verify/add the "Apply Throughput Quota" and "Limit Message Size" Assertions and configure their settings in accordance with organizational requirements.

The CA API Gateway must terminate all network connections associated with a Policy Manager session at the end of the session or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity within the Policy Manager, and for user sessions simply viewing the contents of Policy Manager or viewing Audit Logs for tracking purposes (non-privileged session), the session must be terminated after 15 minutes of inactivity.

SC-10 - Medium - CCI-001133 - V-237370 - SV-237370r971530_rule

RMF Control

SC-10

Severity

CCI

CCI-001133

Version

CAGW-GW-000380

Vuln IDs

V-237370
V-71365

Rule IDs

SV-237370r971530_rule
SV-85989

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with Policy Manager sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. The CA API Gateway must be configured to terminate any management session after an inactivity time via the Policy Manager. The default value for the Policy Manager is 30 minutes and must be configured for 10 minutes for administration sessions and 15 minutes for all other sessions, such as users viewing logs.

Checks: C-40589r643658_chk

Open the CA API Gateway - Policy Manager and select "Preferences" from the main menu. Verify the inactivity timeout is set in accordance with organizational requirements. If it is not, this is a finding.

Fix: F-40552r643659_fix

Open the CA API Gateway - Policy Manager and select "Preferences" from the main menu. Update the inactivity timeout in accordance with organizational requirements.

The CA API Gateway must detect, at a minimum, mobile code that is unsigned or exhibiting unusual behavior, has not undergone a risk assessment, or is prohibited for use based on a risk assessment.

SC-18 - Medium - CCI-001166 - V-237371 - SV-237371r643663_rule

RMF Control

SC-18

Severity

CCI

CCI-001166

Version

CAGW-GW-000390

Vuln IDs

V-237371
V-71367

Rule IDs

SV-237371r643663_rule
SV-85991

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Examples of mobile code include JavaScript, VBScript, Java applets, ActiveX controls, Flash animations, Shockwave videos, and macros embedded within Microsoft Office documents. Mobile code can be exploited to attack a host. It can be sent as an email attachment or embedded in other file formats not traditionally associated with executable code. While the ALG cannot replace the network IDS or the antivirus and host-based IDS (HIDS) protection installed on the network's endpoints, vendor or locally created sensor rules can be implemented that provide pre-emptive defense against both known and zero-day vulnerabilities. Many of the protections may provide defenses before vulnerabilities are discovered and rules or blacklist updates are distributed by antivirus or malicious code solution vendors. To monitor for and detect known prohibited mobile code or approved mobile code that violates permitted usage requirements, the ALG must implement policy filters, rules, signatures, and anomaly analysis. The CA API Gateway must block against code injection and SQL injection attacks, helping to prevent and detect any mobile code that is exhibiting unusual behavior through the injection of incorrect code or wrongly formatted SQL statements within all registered services policies as per organizational requirements.

Checks: C-40590r643661_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services that require protection from unusual mobile code activity and verify the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions are included as part of the policies. If they are not included, this is a finding.

Fix: F-40553r643662_fix

Open the CA API Gateway - Policy Manager. Double-click on the Registered Services that did not have the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions added to their policies and add them from the list of Assertions. Chose from the list of available protections for the Assertions to meet the appropriate organizational requirement for protection against unusual mobile code activity.

The CA API Gateway must protect the authenticity of communications sessions.

SC-23 - Medium - CCI-001184 - V-237372 - SV-237372r643666_rule

RMF Control

SC-23

Severity

CCI

CCI-001184

Version

CAGW-GW-000400

Vuln IDs

V-237372
V-71369

Rule IDs

SV-237372r643666_rule
SV-85993

Authenticity protection provides protection against man-in-the-middle attacks/session hijacking and the insertion of false information into sessions. This requirement focuses on communications protection for the application session, rather than for 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/SOAP will require the use of mutual authentication (two-way/bidirectional). To protect authenticity of communications sessions, the CA API Gateway includes the "Require SSL or TLS Transport with Client Certificate Authentication" Assertion which includes options for Mutual Authentication such as requiring the client initiating the communication to authenticate with a trusted certificate. The CA API Gateway must utilize this assertion within Registered services or within Global policy to help create protection against man-in-the-middle attacks/session hijacking and the insertion of false information into a session allowing both the client and destination server to trust and authenticate against each other before communications can occur.

Checks: C-40591r643664_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require the protection of communications sessions or mutual authentication. Optionally, if a Global Policy has been set, double-click that policy to inspect the contents. If the "Require SSL or TLS Transport with Client Certificate Authentication" Assertion is not present, this is a finding.

Fix: F-40554r643665_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that do not have the "Require SSL or TLS Transport with Client Certificate Authentication" Assertion. Optionally, if a Global Policy has been set, double-click that policy to inspect the contents. Add the "Require SSL or TLS Transport with Client Certificate Authentication" Assertion to the policy and click "Save and Activate".

The CA API Gateway must invalidate session identifiers upon user logout or other session termination.

SC-23 - Medium - CCI-001185 - V-237373 - SV-237373r643669_rule

RMF Control

SC-23

Severity

CCI

CCI-001185

Version

CAGW-GW-000410

Vuln IDs

V-237373
V-71371

Rule IDs

SV-237373r643669_rule
SV-85995

Captured sessions can be reused in "replay" attacks. This requirement limits the ability of adversaries from capturing and continuing to employ previously valid session IDs. Session IDs are tokens generated by web applications to uniquely identify an application user's session. Unique session identifiers or IDs are the opposite of sequentially generated session IDs, which can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. When a user logs out, or when any other session termination event occurs, the network element must terminate the user session to minimize the potential for an attacker to hijack that particular user session. ALGs act as an intermediary for applications; therefore, session control is part of the function provided. This requirement focuses on communications protection at the application session, rather than at the network packet level. The CA API Gateway must protect against replay attacks by using an out-of-the-box "Protect Against Message Replay" Assertion within the registered services that will assist with validating and invalidating sessions as per organizational requirements.

Checks: C-40592r643667_chk

Open the CA API Gateway - Policy Manager and open each of the Registered Services that require the invalidation of session identifiers in order to protect against replay attacks. Verify the "Protect Against Message Replay" Assertion is present after the "Authenticate User or Group" or "Authenticate Against Identity Provider" Assertion. If the Assertion is not present, this is a finding.

Fix: F-40555r643668_fix

Open the CA API Gateway - Policy Manager and open each of the Registered Services that did not include the "Protect Against Message Replay" Assertion but that require the protection. Add the "Protect Against Message Replay" Assertion to the policies, configure the Assertion in accordance with organizational requirements, and click "Save and Activate".

The CA API Gateway must generate unique session identifiers using a FIPS 140-2 approved random number generator.

SC-23 - Medium - CCI-001188 - V-237374 - SV-237374r643672_rule

RMF Control

SC-23

Severity

CCI

CCI-001188

Version

CAGW-GW-000420

Vuln IDs

V-237374
V-71373

Rule IDs

SV-237374r643672_rule
SV-85997

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. The CA API Gateway uses random numbers for session IDs. Random number generation, out of the box, uses the FIPS 140-2 validated RSA BSAFE Crypto-J Software Module for random number generation for all cryptographic algorithms. By default, JsafeJCE FIPS 186 PRNG algorithm is used in all crypto operations. This can be overridden as per organizational requirements when configured to use a SafeNet Luna HSM, whereupon all cryptographic algorithms performed within the HSM will use its FIPS 140-2 validated random number generation.

Checks: C-40593r643670_chk

Verify the CA API Gateway is configured to use a SafeNet Luna HSM, whereupon all cryptographic algorithms performed within the HSM will use its FIPS 140-2 validated random number generation. If the CA API Gateway is not configured to use the SafeNet Luna HSM, this is a finding.

Fix: F-40556r643671_fix

Refer to the “CA API Management Documentation Wiki" at the link below for directions on installing and configuring the CA API Gateway to use a SafeNet Luna HSM. https://docops.ca.com/ca-api-gateway/9-0/en/install-and-configure-the-gateway/configure-the-appliance-gateway/configure-hardware-security-modules-hsm/configure-the-safenet-luna-sa-hsm

The CA API Gateway providing content filtering must integrate with an ICAP-enabled Intrusion Detection System that updates malicious code protection mechanisms and signature definitions whenever new releases are available in accordance with organizational configuration management policy and procedures.

SI-3 - Medium - CCI-001240 - V-237375 - SV-237375r981632_rule

RMF Control

SI-3

Severity

CCI

CCI-001240

Version

CAGW-GW-000430

Vuln IDs

V-237375
V-71375

Rule IDs

SV-237375r981632_rule
SV-85999

Malicious code protection mechanisms include, but are not limited to, antivirus and malware detection software. In order to minimize any potential negative impact to the organization caused by malicious code, malicious code must be identified and eradicated. Malicious code includes viruses, worms, trojan horses, and spyware. The CA API Gateway must be configured to integrate with an ICAP-enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must then be configured to update their protection mechanisms and signature definitions in accordance with organizational requirements.

Checks: C-40594r643673_chk

Open the CA API GW - Policy Manager and double-click any of the Registered Services that require updating of malicious code mechanisms and signatures. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. Check that the list of ICAP Servers has been configured to include servers listed in the following format: "icap://<servername:port/avscan". Also, verify all other options have been configured in accordance with organizational requirements. If not, check to see if the assertion has been added to a Global Policy and configured properly. If the "Scan Using ICAP-Enabled Antivirus" Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40557r643674_fix

Open the CA API GW - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the list of ICAP Scanning servers to the Server list in the following format: "icap://<servername:port/avscan", and configure the additional parameters for the Assertion in accordance with organizational requirements. Click the "Save and Activate" button. If the organization requires that all Registered Services require this ability, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway providing content filtering must be configured to perform real-time scans of files from external sources at network entry/exit points as they are downloaded and prior to being opened or executed.

SI-3 - Medium - CCI-001242 - V-237376 - SV-237376r981633_rule

RMF Control

SI-3

Severity

CCI

CCI-001242

Version

CAGW-GW-000440

Vuln IDs

V-237376
V-71377

Rule IDs

SV-237376r981633_rule
SV-86001

Malicious code includes viruses, worms, trojan horses, and spyware. The code provides the ability for a malicious user to read from and write to files and folders on a computer's hard drive. Malicious code may also be able to run and attach programs, which may allow the unauthorized distribution of malicious mobile code. Once this code is installed on endpoints within the network, unauthorized users may be able to breach firewalls and gain access to sensitive data. To guard against malicious code, real-time scans must be performed on files from external sources as they are downloaded and prior to being opened or executed. The CA API Gateway must be configured to integrate with an ICAP-enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must be configured in accordance with organizational requirements, which must include the real-time scanning of files from external sources.

Checks: C-40595r643676_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require real-time scanning. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. If it is not, check to see if it has been added to a Global Policy. If the Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40558r643677_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion, configure the parameters for the Assertion in accordance with organizational requirements, and click the "Save and Activate" button. If the organization requires that all Registered Services require the ability to scan files in real time, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway providing content filtering must block malicious code upon detection.

SI-3 - Medium - CCI-001243 - V-237377 - SV-237377r643681_rule

RMF Control

SI-3

Severity

CCI

CCI-001243

Version

CAGW-GW-000450

Vuln IDs

V-237377
V-71379

Rule IDs

SV-237377r643681_rule
SV-86003

Taking an appropriate action based on local organizational incident handling procedures minimizes the impact of malicious code on the network. The CA API Gateway must be configured to integrate with an ICAP enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must be configured in accordance with organizational requirements, which must include the blocking of malicious code once detected.

Checks: C-40596r643679_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require the blocking of malicious code once detected. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. If it is not, check to see if it has been added to a Global Policy. If the Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40559r643680_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion, configure the parameters for the Assertion in accordance with organizational requirements, and click the "Save and Activate" button. If the organization requires that all Registered Services require the ability to block malicious code upon detection, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway providing content filtering must delete or quarantine malicious code in response to malicious code detection.

SI-3 - Medium - CCI-001243 - V-237378 - SV-237378r643684_rule

RMF Control

SI-3

Severity

CCI

CCI-001243

Version

CAGW-GW-000460

Vuln IDs

V-237378
V-71381

Rule IDs

SV-237378r643684_rule
SV-86005

Taking an appropriate action based on local organizational incident handling procedures minimizes the impact of malicious code on the network. The ALG must be configured to block all detected malicious code. It is sometimes acceptable/necessary to generate a log event and then automatically delete the malicious code; however, for critical attacks or where forensic evidence is deemed necessary, the file should be quarantined for further investigation. The CA API Gateway must be configured to integrate with an ICAP-enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must be configured in accordance with organizational requirements, which must include the deletion of malicious code once detected.

Checks: C-40597r643682_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require the deletion of malicious code once detected. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. If it is not, check to see if it has been added to a Global Policy. If the Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40560r643683_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion, configure the parameters for the Assertion in accordance with organizational requirements, and click the "Save and Activate" button. If the organization requires that all Registered Services require the ability to delete malicious code upon detection, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway providing content filtering must send an immediate (within seconds) alert to the system administrator, at a minimum, in response to malicious code detection.

SI-3 - Medium - CCI-001243 - V-237379 - SV-237379r643687_rule

RMF Control

SI-3

Severity

CCI

CCI-001243

Version

CAGW-GW-000470

Vuln IDs

V-237379
V-71383

Rule IDs

SV-237379r643687_rule
SV-86007

Without an alert, security personnel may be unaware of an impending failure of the audit capability, which will impede the ability to perform forensic analysis and detect rate-based and other anomalies. The ALG generates an immediate (within seconds) alert that notifies designated personnel of the incident. Sending a message to an unattended log or console does not meet this requirement since it will not be seen immediately. These messages should include a severity level indicator or code as an indicator of the criticality of the incident. The CA API Gateway must be configured to integrate with an ICAP-enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must be configured in accordance with organizational requirements, including the detection of malicious code. The CA API Gateway must then evaluate the response of the scanning from the ICAP-enabled Intrusion Detection System and send an email to the system administrator.

Checks: C-40598r643685_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require an alert to be sent when malicious code is detected. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy and the "Send Email Alert" Assertion is included after the "ICAP-Enabled Antivirus" Assertion with the results of the response variable set in the "ICAP-Enabled Antivirus" Assertion included in the message body of the Assertion. Additionally, to avoid receiving emails on all items scanned, the policy should be configured to only send an email alert upon detection of malicious code within the response of the "ICAP-Enabled AntiVirus" Assertion. If neither Assertion is present, check to see if it has been added to a Global Policy. If the Assertions are not present in either Global or Registered Services policy, this is a finding.

Fix: F-40561r643686_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require an alert to be sent when malicious code is detected. Verify/add the "Scan Using ICAP-Enabled Antivirus" Assertion and the "Send Email Alert". Configure the "Scan Using ICAP-Enabled Antivirus" Assertion as per organizational requirements. Position the "Send Email Alert" Assertion after the "ICAP-Enabled Antivirus" Assertion with the results of the response variable set in the "ICAP-Enabled Antivirus" Assertion included in the message body of the "Send Email Alert" Assertion. Additionally, to avoid receiving emails on all items scanned, configure the policy to only send an email alert upon detection of malicious code within the response of the "ICAP-Enabled AntiVirus" Assertion.

The CA API Gateway providing content filtering must automatically update malicious code protection mechanisms.

SI-3 - Medium - CCI-001247 - V-237380 - SV-237380r981634_rule

RMF Control

SI-3

Severity

CCI

CCI-001247

Version

CAGW-GW-000480

Vuln IDs

V-237380
V-71385

Rule IDs

SV-237380r981634_rule
SV-86009

The malicious software detection functionality on network elements needs to be constantly updated in order to identify new threats as they are discovered. All malicious software detection functions must come with an update mechanism that automatically updates the application and any associated signature definitions. The organization (including any contractor to the organization) is required to promptly install security-relevant malicious code protection updates. Examples of relevant updates include antivirus signatures, detection heuristic rule sets, and/or file reputation data employed to identify and/or block malicious software from executing. Malicious code includes viruses, worms, trojan horses, and spyware. The CA API Gateway must be configured to integrate with an ICA- enabled Intrusion Detection System such as McAfee, Sophos, or Symantec. These systems must then be configured to update their protection mechanisms and signature definitions in accordance with organizational requirements. The CA API Gateway does not offer this feature beyond the integration with the third-party systems.

Checks: C-40599r643688_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require updating of malicious code mechanisms. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. If it is not, check to see if it has been added to a Global Policy. If the Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40562r643689_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion, configure the parameters for the Assertion in accordance with organizational requirements, and click the "Save and Activate" button. If the organization requires that all Registered Services require this ability, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway must generate error messages that provide the information necessary for corrective actions without revealing information that could be exploited by adversaries.

SI-11 - Medium - CCI-001312 - V-237381 - SV-237381r643693_rule

RMF Control

SI-11

Severity

CCI

CCI-001312

Version

CAGW-GW-000490

Vuln IDs

V-237381
V-71387

Rule IDs

SV-237381r643693_rule
SV-86011

Providing too much information in error messages risks compromising the data and security of the application and system. Organizations must carefully consider the structure/content of error messages. The required information within error messages will vary based on the protocol and error condition. Information that could be exploited by adversaries includes, for example, ICMP messages that reveal the use of firewalls or access-control lists. The CA API Gateway must include within the Registered Services Policies customized error responses revealing only the necessary information as required by the organization.

Checks: C-40600r643691_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services that require a customized error response, revealing only the necessary information about an error. Verify the "Customize Error Response" Assertion is included in the policy and placed in accordance with organizational requirements. If it is not, this is a finding.

Fix: F-40563r643692_fix

Open the CA API Gateway - Policy Manager and double-click each of the Registered Services that require a customized error response and did not include a "Customize Error Response" Assertion. Add the "Customize Error Response" Assertion to the policy, placing and configuring it in accordance with organizational requirements.

The CA API Gateway providing content filtering must block or restrict detected prohibited mobile code.

SC-18 - Medium - CCI-001695 - V-237382 - SV-237382r643696_rule

RMF Control

SC-18

Severity

CCI

CCI-001695

Version

CAGW-GW-000500

Vuln IDs

V-237382
V-71389

Rule IDs

SV-237382r643696_rule
SV-86013

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. This applies to mobile code that may originate either internal to or external from the enclave. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Mobile code that must be blocked or restricted is identified in CCI-001166. The CA API Gateway must block against code injection and SQL injection attacks, helping to block any mobile code that is exhibiting unusual behavior, such as the injection of incorrect code or wrongly formatted SQL statements, and that may be prohibited from use due to these anomalies.

Checks: C-40601r643694_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services that require protection from prohibited mobile code and verify the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions are included as part of the policies. If they are not included, this is a finding.

Fix: F-40564r643695_fix

The CA API Gateway providing content filtering must prevent the download of prohibited mobile code.

SC-18 - Medium - CCI-001169 - V-237383 - SV-237383r643699_rule

RMF Control

SC-18

Severity

CCI

CCI-001169

Version

CAGW-GW-000510

Vuln IDs

V-237383
V-71391

Rule IDs

SV-237383r643699_rule
SV-86015

Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. This applies to mobile code that may originate either internal to or external from the enclave. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Mobile code that must be prevented from downloading is identified in CCI-001166. The CA API Gateway must block against code injection and SQL injection attacks, helping to prevent/deny any mobile code that is exhibiting unusual behavior by preventing the injection of prohibited code or incorrectly formatted SQL statements.

Checks: C-40602r643697_chk

Open the CA API GW - Policy Manager. Double-click all Registered Services that require protection from downloading prohibited mobile code and verify the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions are included as part of the policies and that the target message is the response. If the Threat Protection Assertions are not included, this is a finding.

Fix: F-40565r643698_fix

Open the CA API GW - Policy Manager. Double-click on the Registered Services that did not have the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions added to their policies and add them from the list of Assertions after a "Route via..." Assertion in order to protect the downloaded response from malicious intent, such as code injections. Choose from the list of available protections for the Assertions to meet the appropriate organizational requirement for protection against prohibited mobile code.

The CA API Gateway providing intermediary services for remote access communications traffic must control remote access methods.

AC-17 - Medium - CCI-002314 - V-237384 - SV-237384r831409_rule

RMF Control

AC-17

Severity

CCI

CCI-002314

Version

CAGW-GW-000520

Vuln IDs

V-237384
V-71393

Rule IDs

SV-237384r831409_rule
SV-86017

Remote access devices, such as those providing remote access to network devices and information systems, that lack automated control capabilities increase risk and makes remote user access management difficult at best. 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 broadband and wireless connections. Remote access methods include, for example, proxied remote encrypted traffic (e.g., TLS gateways, web content filters, and webmail proxies). The CA API Gateway must control access to Remote Services accessible over broadband and wireless connections using customizable policies and communications protocol Assertions.

Checks: C-40603r643700_chk

Open the CA API GW - Policy Manager. Verify the Services requiring remote access controls are registered on the Gateway. Check each Service's policy and verify the required communications protocols' Assertions have been added as per organizational requirements. Additionally, select Tasks >> Manage Listen Ports and verify listen ports have been created for each type of Remote Access, such as HTTP, HTTPS, FTP, etc. If the required communication protocols have not been set in the policies or the listen ports have not been configured, this is a finding.

Fix: F-40566r643701_fix

Open the CA API GW - Policy Manager. Select the Registered Services that do not have controls for Access Methods that are responsible for remote access communications traffic, such as FTP, HTTP, HTTPS, etc. Using the Message Routing Policy Assertions, customize the security policies for the Services to include the various types of communications protocols, such as FTP, HTTP, HTTPS, etc. Include only the required organizational remote access protocols. Additionally, select Tasks >> Manage Listen Ports and create the required listen ports for the remote access methods needed. If policies are required to be attached to the port, as is the case with an FTP Listen port, assign the policy to the listen port in accordance with organizational requirements for managing and monitoring the remote access protocol and communication traffic. All other communications protocols and methods will be rejected.

To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.

AC-23 - Medium - CCI-002346 - V-237385 - SV-237385r831410_rule

RMF Control

AC-23

Severity

CCI

CCI-002346

Version

CAGW-GW-000530

Vuln IDs

V-237385
V-71395

Rule IDs

SV-237385r831410_rule
SV-86019

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. Compliance requires the CA API Gateway to have the capability to prevent code injections. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as "Protect Against SQL Attack" and/or "Protect Against Code Injection" Assertions configured in accordance with organizational requirements and used in a Registered Service's policy requiring protection to help prevent attacks against data storage objects.

Checks: C-40604r643703_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services that access a protected database and verify the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions are included as part of the policies. If they are not included, this is a finding.

Fix: F-40567r643704_fix

Open the CA API Gateway - Policy Manager. Double-click on the Registered Services that do not have the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions added to their policies and add them from the list of Assertions. Chose from the list of available protections for the Assertions to meet the appropriate organizational requirement.

To protect against data mining, the CA API Gateway providing content filtering must prevent code injection attacks launched against application objects including, at a minimum, application URLs and application code.

AC-23 - Medium - CCI-002346 - V-237386 - SV-237386r831411_rule

RMF Control

AC-23

Severity

CCI

CCI-002346

Version

CAGW-GW-000540

Vuln IDs

V-237386
V-71397

Rule IDs

SV-237386r831411_rule
SV-86021

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. Compliance requires the CA API Gateway to have the capability to prevent code injections. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as "Protect Against SQL Attack" and/or "Protect Against Code Injection" Assertions configured in accordance with organizational requirements and used in a Registered Service's policy requiring protection to help prevent code injection attacks launched against data storage objects.

Checks: C-40605r643706_chk

Fix: F-40568r643707_fix

To protect against data mining, the CA API Gateway providing content filtering must prevent SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.

AC-23 - Medium - CCI-002346 - V-237387 - SV-237387r831412_rule

RMF Control

AC-23

Severity

CCI

CCI-002346

Version

CAGW-GW-000550

Vuln IDs

V-237387
V-71399

Rule IDs

SV-237387r831412_rule
SV-86023

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to prevent attacks launched against organizational information from unauthorized data mining may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. Compliance requires the CA API Gateway to have the capability to prevent SQL code injections. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as a "Protect Against SQL Attack" Assertion configured in accordance with organizational requirements and used in a Registered Service's policy requiring data mining protection to help prevent SQL injection attacks launched against data storage objects.

Checks: C-40606r643709_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services that access a protected database and verify the "Protect Against SQL Attacks" Threat Protection Assertion is included as part of the policies. If it is not included, this is a finding.

Fix: F-40569r643710_fix

Open the CA API Gateway - Policy Manager. Double-click on the Registered Services that do not have the "Protect Against SQL Attacks" Threat Protection Assertion added to their policy and add it from the list of Assertions. Choose from the list of available protections for the Assertion to meet the appropriate organizational requirement.

To protect against data mining, the CA API Gateway providing content filtering must detect code injection attacks from being launched against data storage objects, including, at a minimum, databases, database records, queries, and fields.

AC-23 - Medium - CCI-002347 - V-237388 - SV-237388r831413_rule

RMF Control

AC-23

Severity

CCI

CCI-002347

Version

CAGW-GW-000560

Vuln IDs

V-237388
V-71421

Rule IDs

SV-237388r831413_rule
SV-86045

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational databases may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database or change data on a website. Web applications frequently access databases to store, retrieve, and update information. An attacker can construct inputs that the database will execute. This is most commonly referred to as a code injection attack. This type of attack includes XPath and LDAP injections. CA API Gateways with anomaly detection must be configured to protect against unauthorized code injections. These devices must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as a "Protect Against Code Injection" Assertion configured in accordance with organizational requirements and used in a Registered Service's policy requiring data mining protection to help detect code injection attacks.

Checks: C-40607r643712_chk

Open the CA API Gateway - Policy Manager. Double-click all Registered Services that access a protected database and verify the "Protect Against Code Injection Attacks" Threat Protection Assertion is included as part of the policies. If it is not included, this is a finding.

Fix: F-40570r643713_fix

Open the CA API GW - Policy Manager. Double-click on the Registered Services that do not have the "Protect Against SQL Attacks" and "Protect Against Code Injection" Threat Protection Assertions added to their policies and add them from the list of Assertions. Chose from the list of available protections for the Assertions to meet the appropriate organizational requirement.

To protect against data mining, the CA API Gateway providing content filtering must detect SQL injection attacks launched against data storage objects, including, at a minimum, databases, database records, and database fields.

AC-23 - Medium - CCI-002347 - V-237389 - SV-237389r831414_rule

RMF Control

AC-23

Severity

CCI

CCI-002347

Version

CAGW-GW-000570

Vuln IDs

V-237389
V-71423

Rule IDs

SV-237389r831414_rule
SV-86047

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational databases may result in the compromise of information. SQL injection attacks are the most prevalent attacks against web applications and databases. These attacks inject SQL commands that can read, modify, or compromise the meaning of the original SQL query. An attacker can spoof identity; expose, tamper, destroy, or make existing data unavailable; or gain unauthorized privileges on the database server. CA API Gateways with anomaly detection must be configured to protect against unauthorized data mining attacks. These devices must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as a "Protect Against SQL Attack" Assertion configured in accordance with organizational requirements and used in a Registered Service's policy requiring data mining protection to help detect SQL Injection attacks.

Checks: C-40608r643715_chk

Fix: F-40571r643716_fix

Open the CA API Gateway - Policy Manager. Double-click on the Registered Services that do not have the "Protect Against SQL Attacks" Threat Protection Assertion added to their policy and add it from the list of Assertions. Chose from the list of available protections for the Assertion to meet the appropriate organizational requirement.

To protect against data mining, the CA API Gateway providing content filtering as part of its intermediary services must detect code injection attacks launched against application objects including, at a minimum, application URLs and application code.

AC-23 - Medium - CCI-002347 - V-237390 - SV-237390r831415_rule

RMF Control

AC-23

Severity

CCI

CCI-002347

Version

CAGW-GW-000580

Vuln IDs

V-237390
V-71425

Rule IDs

SV-237390r831415_rule
SV-86049

Data mining is the analysis of large quantities of data to discover patterns and is used in intelligence gathering. Failure to detect attacks launched against organizational applications may result in the compromise of information. Injection attacks allow an attacker to inject code into a program or query or inject malware onto a computer to execute remote commands that can read or modify a database or change data on a website. These attacks include buffer overrun, XML, JavaScript, and HTML injections. CA API Gateways with anomaly detection must be configured to protect against unauthorized code injections. These devices must include rules and anomaly detection algorithms to monitor for atypical database queries or accesses. Examples include Web Application Firewalls (WAFs) or database application gateways. The CA API Gateway must include threat protection mechanisms such as a "Protect Against Code Injection" Assertion configured in accordance with organizational requirements and used in a Registered Service's policy requiring data mining protection to help detect code injection attacks launched against application objects.

Checks: C-40609r643718_chk

Fix: F-40572r643719_fix

The CA API Gateway must off-load audit records onto a centralized log server.

AU-4 - Medium - CCI-001851 - V-237391 - SV-237391r831416_rule

RMF Control

AU-4

Severity

CCI

CCI-001851

Version

CAGW-GW-000590

Vuln IDs

V-237391
V-71427

Rule IDs

SV-237391r831416_rule
SV-86051

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. The CA API Gateway must include a method for off-loading audit records onto a centralized log server, including External Audit Stores and Centralized Syslog Servers.

Checks: C-40610r643721_chk

By default, audit records are created locally on the CA API Gateway Server and will need to be configured for off-loading using the External Audit Store Wizard or by specifying to send them to a Syslog server via TCP, UDP, or SSL. If they are not, this is a finding.

Fix: F-40573r643722_fix

Open the CA API Gateway - Policy Manager. Select "Tasks" and chose "Manage Log/Audit Sinks". Double-click the "ssg" log and change the "Type:" to "Syslog". Click "Syslog Settings" and specify the settings for the Centralized Syslog Server as defined by the organization.

The CA API Gateway providing user authentication intermediary services must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.

IA-11 - Medium - CCI-002038 - V-237392 - SV-237392r987783_rule

RMF Control

IA-11

Severity

CCI

CCI-002038

Version

CAGW-GW-000600

Vuln IDs

V-237392
V-71429

Rule IDs

SV-237392r987783_rule
SV-86053

Without reauthentication, users may access resources or perform tasks for which they do not have authorization. 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: 1) When authenticators change 2) When roles change 3) When security categories of information systems change 4) When the execution of privileged functions occurs 5) After a fixed period of time 6) Periodically Within the DoD, the minimum circumstances requiring reauthentication are privilege escalation and role changes. This requirement only applies to components where this is specific to the function of the device or has the concept of user authentication (e.g., VPN or ALG capability). This does not apply to authentication for the purpose of configuring the device itself (i.e., device management). The CA API Gateway must include in policies requiring users to reauthenticate logic to check the session token used by the client for expiration on each request and check if the session has expired, and if so, redirect them to the authentication provider.

Checks: C-40611r643724_chk

Open the CA API Gateway - Policy Manager and verify the Registered Services installed on the Gateway that require re-authentication mechanisms are configured to check for session token expiration. If they are not, this is a finding.

Fix: F-40574r643725_fix

Open the CA API Gateway - Policy Manager and update the Registered Services installed on the CA API Gateway that require reauthentication mechanisms with logic to check for session token expiration. For more details, refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to non-privileged accounts such that one of the factors is provided by a device separate from the system gaining access.

IA-2 - Medium - CCI-001951 - V-237393 - SV-237393r981642_rule

RMF Control

IA-2

Severity

CCI

CCI-001951

Version

CAGW-GW-000610

Vuln IDs

V-237393
V-71431

Rule IDs

SV-237393r981642_rule
SV-86055

For remote access to non-privileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card. A privileged account is defined as an information system account with authorizations of a privileged user. 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. An example of compliance with this requirement is the use of a one-time password token and PIN coupled with a password or the use of a CAC/PIV card and PIN coupled with a password. The CA API Gateway supports X.509, username/password, SAML, Kerberos, and RADIUS authentication. To provide multifactor authentication (MFA), the registered services requiring MFA must include multiple authentication assertions.

Checks: C-40612r643727_chk

Open the CA API Gateway - Policy Manager. Double-click the Registered Services requiring multifactor authentication. For example, within the policy that leverages an RSA SecurID hardware token along with X.509, verify the policy includes a "Require SSL/TLS with Client Certificate" Assertion, which will validate the certificate according to organizational requirements, then use that certificate to authenticate against LDAP or Active Directory using the "Authenticate Against Identity Provider" Assertion, and then include the value from the hardware token in a request to the RSA SecurID RADIUS service via the "Authenticate Against RADIUS Server" Assertion. If the policy is not configured with multiple factors for authentication in a similar fashion, this is a finding.

Fix: F-40575r643728_fix

Open the CA API Gateway - Policy Manager. Double-click the Registered Services requiring multifactor authentication. For example, within the policy, configure the policy to leverage an RSA SecurID hardware token along with X.509 by adding a "Require SSL/TLS with Client Certificate" Assertion, which will validate the certificate according to organizational requirements, then using that certificate to authenticate against LDAP or Active Directory, add an "Authenticate Against Identity Provider" Assertion, and then include the value from the hardware token in a request to the RSA SecurID RADIUS service by adding the "Authenticate Against RADIUS Server" Assertion. Configure additional Registered Services in a similar fashion in accordance with organizational requirements.

The CA API Gateway providing user authentication intermediary services must implement multifactor authentication for remote access to privileged accounts such that one of the factors is provided by a device separate from the system gaining access.

IA-2 - Medium - CCI-001948 - V-237394 - SV-237394r981643_rule

RMF Control

IA-2

Severity

CCI

CCI-001948

Version

CAGW-GW-000620

Vuln IDs

V-237394
V-71433

Rule IDs

SV-237394r981643_rule
SV-86057

For remote access to privileged accounts, the purpose of requiring a device that is separate from the information system gaining access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authentication credentials stored on the system. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card. A privileged account is defined as an information system account with authorizations of a privileged user. 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. The CA API Gateway supports X.509, username/password, SAML, Kerberos, and RADIUS authentication. To provide multifactor authentication (MFA), the registered services requiring MFA must include multiple authentication assertions.

Checks: C-40613r643730_chk

Fix: F-40576r643731_fix

The CA API Gateway must prohibit the use of cached authenticators after an organization-defined time period.

IA-5 - Medium - CCI-002007 - V-237395 - SV-237395r831420_rule

RMF Control

IA-5

Severity

CCI

CCI-002007

Version

CAGW-GW-000630

Vuln IDs

V-237395
V-71435

Rule IDs

SV-237395r831420_rule
SV-86059

If the cached authenticator information is out of date, the validity of the authentication information may be questionable. This requirement applies to all ALGs that may cache user authenticators for use throughout a session. This requirement also applies to ALGs that provide user authentication intermediary services (e.g., authentication gateway or TLS gateway). This does not apply to authentication for the purpose of configuring the device itself (device management). The CA API Gateway must be configured to use an organization-defined value for determining the expiration of cached data from an identity provider or third party, such as a SAML Token Service.

Checks: C-40614r643733_chk

Open the CA API Gateway - Policy Manager and select the "Identity Provider" tab. Verify the "Cache Size" and "Cache Maximum Age" are set in accordance with organization-defined requirements. If the values are not set or are not set in accordance with organizational requirements, this is a finding.

Fix: F-40577r643734_fix

Open the CA API Gateway - Policy Manager and select the "Identity Provider" tab. Update the "Cache Size" and "Cache Maximum Age" in accordance with organization-defined requirements.

The CA API Gateway providing user authentication intermediary services using PKI-based user 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.

IA-5 - Medium - CCI-001991 - V-237396 - SV-237396r981644_rule

RMF Control

IA-5

Severity

CCI

CCI-001991

Version

CAGW-GW-000640

Vuln IDs

V-237396
V-71437

Rule IDs

SV-237396r981644_rule
SV-86061

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). The intent of this requirement is to require support for a secondary certificate validation method using a locally cached revocation data, such as Certificate Revocation List (CRL), in case access to OCSP (required by CCI-000185) is not available. Based on a risk assessment, an alternate mitigation is to configure the system to deny access when revocation data is unavailable. This requirement applies to ALGs that provide user authentication intermediary services (e.g., authentication gateway or TLS gateway). This does not apply to authentication for the purpose of configuring the device itself (device management). The CA API Gateway must implement a local cache of revocation data to support certificate validation in the event network access to the revocation server is unavailable. This cache must be created using a "Revocation Checking Policy" and be configurable to meet organizational requirements.

Checks: C-40615r643736_chk

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu and chose "Manage Certificates". Click the "Certificate Validation" button and verify there is at least one Policy in the list of Revocation Checking Policies. Double-click one of the listed policies and verify the "Continue processing if server is unavailable" check box is checked. If there is no policy listed or the "Continue processing if server is unavailable" check box is not selected within the revocation policy, this is a finding.

Fix: F-40578r643737_fix

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu, and chose "Manage Certificates". Click the "Certificate Validation" button and add a Revocation Check Policy in accordance with organizational requirements, making sure to select the "Continue processing if server is unavailable" check box within the policy. If a policy has already been added, open an existing policy and select the "Continue processing if server is unavailable" check box.

The CA API Gateway providing user authentication intermediary services must conform to Federal Identity, Credential, and Access Management (FICAM) issued profiles.

IA-8 - Medium - CCI-002014 - V-237397 - SV-237397r981646_rule

RMF Control

IA-8

Severity

CCI

CCI-002014

Version

CAGW-GW-000650

Vuln IDs

V-237397
V-71439

Rule IDs

SV-237397r981646_rule
SV-86063

Without conforming to FICAM-issued profiles, the information system may not be interoperable with FICAM authentication protocols, such as SAML 2.0 and OpenID 2.0. Use of FICAM-issued profiles addresses open identity management standards. This requirement only applies to components where this is specific to the function of the device or has the concept of a non-organizational user, (e.g., ALG capability that is the front end for an application in a DMZ). CA API Gateway must be capable of producing and validating FICAM-compliant SAML.

Checks: C-40616r643739_chk

Open the CA API GW - Policy Manager and double-click all Registered Services required to conform to FICAM-issued profiles. Verify the "Evaluate SAML Protocol Response" Assertion is included in the policy and set to evaluate only SAML 2.0 responses. Validate all additional parameters within the Assertion are set in accordance with organizational requirements for FICAM-issued profiles. If the "Evaluate SAML Protocol Response" Assertion is not included in the policy and set to evaluate only SAML 2.0 responses, this is a finding.

Fix: F-40579r643740_fix

Open the CA API GW - Policy Manager and double-click all Registered Services required to conform to FICAM issued profiles. Add the "Evaluate SAML Protocol Response" Assertion to the policy and set the SAML Version to 2.0. Set all other configuration parameters within the Assertion to meet organizational requirements for FICAM-issued profiles.

The CA API Gateway providing user authentication intermediary services using PKI-based user authentication must only accept end entity certificates issued by DoD PKI or DoD-approved PKI Certification Authorities (CAs) for the establishment of protected sessions.

SC-23 - Medium - CCI-002470 - V-237398 - SV-237398r878063_rule

RMF Control

SC-23

Severity

CCI

CCI-002470

Version

CAGW-GW-000660

Vuln IDs

V-237398
V-71441

Rule IDs

SV-237398r878063_rule
SV-86065

Non-DoD-approved PKIs have not been evaluated to ensure that they have security controls and identity vetting procedures in place that are sufficient for DoD systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DoD-approved PKIs is published at http://iase.disa.mil/pki-pke/interoperability. DoD-approved PKI CAs may include Category I, II, and III certificates. Category I DoD-Approved External PKIs are PIV issuers. Category II DoD-Approved External PKIs are Non-Federal Agency PKIs cross-certified with the Federal Bridge Certification Authority (FBCA). Category III DoD-Approved External PKIs are Foreign, Allied, or Coalition Partner PKIs. Deploying the ALG with TLS enabled will require the installation of DoD and/or DoD-approved CA certificates in the trusted root certificate store of each proxy to be used for TLS traffic. This requirement focuses on communications protection for the application session, rather than for the network packet. The CA API Gateway must import the DoD PKI CA certificate(s) as trusted by using the "Manage Certificates" task. If the certificate(s) are also intended to be used for user authentication, the configuration of a "Federated Identity Provider" that extends trust to valid certificates that are signed by the DoD PKI CA certificate(s) must be configured.

Checks: C-40617r643742_chk

Log on to the CA API Gateway - Policy Manager. Click "Task" from the main menu and select "Manage Certificates". If the DoD-approved PKI CA certificates are not listed or non-approved certificates are shown, this is a finding.

Fix: F-40580r643743_fix

Log on to the CA API Gateway - Policy Manager. Click "Task" from the main menu and select "Manage Certificates". Remove all non-approved certificates and click "Add". Select the proper options to import the approved certificates and complete the Certificate Import Wizard, selecting the values and options defined by the organization for approved certificates.

The CA API Gateway providing content filtering must protect against known and unknown types of Denial of Service (DoS) attacks by employing rate-based attack prevention behavior analysis.

SC-5 - Medium - CCI-002385 - V-237399 - SV-237399r831424_rule

RMF Control

SC-5

Severity

CCI

CCI-002385

Version

CAGW-GW-000670

Vuln IDs

V-237399
V-71443

Rule IDs

SV-237399r831424_rule
SV-86067

If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Installation of content filtering gateways and application layer firewalls at key boundaries in the architecture mitigates the risk of DoS attacks. These attacks can be detected by matching observed communications traffic with patterns of known attacks and monitoring for anomalies in traffic volume/type. Detection components that use rate-based behavior analysis can detect attacks when signatures for the attack do not exist or are not installed. These attacks include zero-day attacks, which are new attacks for which vendors have not yet developed signatures. Rate-based behavior analysis can detect sophisticated, Distributed DoS (DDoS) attacks by correlating traffic information from multiple network segments or components. This requirement applies to the communications traffic functionality of the ALG as it pertains to handling communications traffic, rather than to the ALG device itself. The CA API Gateway must enable a rate limit in an effort to provide safeguards against DoS attacks.

Checks: C-40618r643745_chk

Open the CA API Gateway - Policy Manager. Check the lower-left corner of the CA API Gateway - Policy Manager to see if a Global Policy is set that includes an "Apply Rate Limit" Assertion. (Global policies are displayed with a green icon beside their name.) If the policy does not exist, this is a finding. If it does exist, verify the Rate Limits are set to meet the organization's security requirements for DoS Attacks. If the Rate Limits are not set to meet the organization's security requirements for DoS attacks, this is a finding.

Fix: F-40581r643746_fix

The CA API Gateway must implement load balancing to limit the effects of known and unknown types of Denial of Service (DoS) attacks.

SC-5 - Medium - CCI-002385 - V-237400 - SV-237400r831425_rule

RMF Control

SC-5

Severity

CCI

CCI-002385

Version

CAGW-GW-000680

Vuln IDs

V-237400
V-71445

Rule IDs

SV-237400r831425_rule
SV-86069

If the network does not provide safeguards against DoS attacks, network resources will be unavailable to users. Load balancing provides service redundancy, which reduces the susceptibility of the ALG to many DoS attacks. The ALG must be configured to prevent or mitigate the impact on network availability and traffic flow of DoS attacks that have occurred or are ongoing. This requirement applies to the network traffic functionality of the device as it pertains to handling network traffic. Some types of attacks may be specialized to certain network technologies, functions, or services. For each technology, known and potential DoS attacks must be identified and solutions for each type implemented. The CA API Gateway is designed to run as a cluster behind any industry standard load balancer. When routing to back-end services, the Gateway itself can also provide load balancing across back ends as described in the Check and Fix content if needed to support additional protection against DoS attacks.

Checks: C-40619r643748_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring load balancing. Verify there is a "Route via HTTP(S)" Assertion included in the policy and double-click it. Click the "Connection" button and verify either the "Use the following IP addresses:" or "Use multiple URLs:" radio button is selected and that multiple URLs/IP addresses are listed in the box. If the assertion is not included within the policies or multiple URLs/IP addresses are not being used, this is a finding.

Fix: F-40582r643749_fix

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring load balancing. Verify/add a "Route via HTTP(s)" Assertion within the policy and double-click it. Click the "Connection" button and chose either the "Use the following IP addresses:" or "Use multiple URLs:" radio button. Configure multiple IP addresses/URLs and set the Failover strategy in accordance with organizational requirements.

The CA API Gateway must only allow incoming communications from organization-defined authorized sources routed to organization-defined authorized destinations.

SC-7 - Medium - CCI-002403 - V-237401 - SV-237401r831426_rule

RMF Control

SC-7

Severity

CCI

CCI-002403

Version

CAGW-GW-000700

Vuln IDs

V-237401
V-71447

Rule IDs

SV-237401r831426_rule
SV-86071

Unrestricted traffic may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources. Access control policies and access control lists implemented on devices that control the flow of network traffic (e.g., application-level firewalls and Web content filters), ensure the flow of traffic is only allowed from authorized sources to authorized destinations. Networks with different levels of trust (e.g., the Internet or CDS) must be kept separate. CA API Gateway must use services, policy, and iptable configurations to enforce flows only to/from authorized sources and destinations.

Checks: C-40620r643751_chk

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu, and chose "Manage Listen Ports". Click the "Manage Firewall Rules" button and verify the proper Firewall Rules have been configured in accordance with organizational requirements for routing communications between authorized sources and destinations. Additionally, double-click each of the Registered Services and verify their policies have the proper logic to route the communications traffic to and from authorized sources and destinations. If either the firewall rules or the policy logic is not configured properly, this is a finding.

Fix: F-40583r643752_fix

Open the CA API Gateway - Policy Manager, select "Tasks" from the main menu, and chose "Manage Listen Ports". Click the "Manage Firewall Rules" button and add the proper Firewall Rules in accordance with organizational requirements for routing communications between authorized sources and destinations. Additionally, double-click each of the Registered Services and add the proper logic to route the communications traffic to and from authorized sources and destinations within their policies in accordance with organizational requirements.

The CA API Gateway must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

SI-10 - Medium - CCI-002754 - V-237402 - SV-237402r831427_rule

RMF Control

SI-10

Severity

CCI

CCI-002754

Version

CAGW-GW-000710

Vuln IDs

V-237402
V-71449

Rule IDs

SV-237402r831427_rule
SV-86073

A common vulnerability of network elements is unpredictable behavior when invalid inputs are received. 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. The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input. The CA API Gateway must validate both XML and JSON schemas to verify valid inputs from a client requesting Registered Services. This helps to prevent XDoS attacks and parameter tampering, which in turn helps to prevent the injection of malicious scripts or content into the request.

Checks: C-40621r643754_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services required to validate inputs. Verify that either the "Validate XML Schema" or "Validate JSON Schema" Assertions have been added to the policies and that they have been configured in accordance with organizational requirements. If they have not, this is a finding.

Fix: F-40584r643755_fix

Open the CA API Gateway - Policy Manager and double-click each of the Registered Services required to validate inputs that do not include a "Validate XML Schema" or Validate JSON Schema" Assertion. Add either the "Validate XML Schema" or "Validate JSON Schema" Assertion and configure in accordance with organizational requirements.

The CA API Gateway providing content filtering must be configured to integrate with a system-wide intrusion detection system.

SI-4 - Medium - CCI-002656 - V-237403 - SV-237403r831428_rule

RMF Control

SI-4

Severity

CCI

CCI-002656

Version

CAGW-GW-000720

Vuln IDs

V-237403
V-71451

Rule IDs

SV-237403r831428_rule
SV-86075

Without coordinated reporting between separate devices, it is not possible to identify the true scale and possible target of an attack. Integration of the ALG with a system-wide intrusion detection system supports continuous monitoring and incident response programs. This requirement applies to monitoring at internal boundaries using TLS gateways, web content filters, email gateways, and other types of ALGs. ALGs can work as part of the network monitoring capabilities to off-load inspection functions from the external boundary Intrusion Detection and Prevention System (IDPS) by performing more granular content inspection of protocols at the upper layers of the Open Systems Interconnection (OSI) reference model. The CA API Gateway must be configured to integrate with an ICAP enabled Intrusion Detection System such as McAfee, Sophos, or Symantec.

Checks: C-40622r643757_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require scanning for intrusion detection. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy. If it is not, check to see if it has been added to a Global Policy. If the Assertion is not present in either Global or Registered Services policy, this is a finding.

Fix: F-40585r643758_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not have the "Scan Using ICAP-Enabled Antivirus" Assertion. Add the "Scan Using ICAP-Enabled Antivirus" Assertion, configure the parameters for the Assertion in accordance with organizational requirements, and click the "Save and Activate" button. If the organization requires that all Registered Services require integration with an intrusion detection system, consider adding the "Scan Using ICAP-Enabled Antivirus" Assertion to a Global Policy to meet this requirement.

The CA API Gateway providing content filtering must send an alert to, at a minimum, the ISSO and ISSM when detection events occur.

SI-4 - Medium - CCI-002664 - V-237404 - SV-237404r971533_rule

RMF Control

SI-4

Severity

CCI

CCI-002664

Version

CAGW-GW-000770

Vuln IDs

V-237404
V-71453

Rule IDs

SV-237404r971533_rule
SV-86077

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. The CA API Gateway provides content inspection services in real time. These systems generate alerts when detection events from real-time monitoring occur. Alerts may be transmitted, for example, telephonically, by electronic mail messages or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The CA API Gateway must send an email upon detection of an event though the use of a "Send Email Alert" Assertion added to the Registered Services requiring email notifications.

Checks: C-40623r643760_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services requiring email notifications. Verify the "Send Email Alert" Assertion has been included in the policy at the required decision points within the policy as per organizational requirements. If it is not present, this is a finding.

Fix: F-40586r643761_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that did not include the "Send Email Alert" Assertion. Add the "Send Email Alert" Assertion to the policy and configure the parameters for the Assertion to meet organizational requirements. Note that the Assertion should be added after a detection event occurs, such as a threat detection event detecting a SQL injection, and will most likely be included as part of either an "At least one assertion must evaluate to true" or "All Assertions must evaluate to true" policy logic folder.

The CA API Gateway providing content filtering must generate a notification on the console when root-level intrusion events that attempt to provide unauthorized privileged access are detected.

SI-4 - Medium - CCI-002664 - V-237405 - SV-237405r971533_rule

RMF Control

SI-4

Severity

CCI

CCI-002664

Version

CAGW-GW-000790

Vuln IDs

V-237405
V-71455

Rule IDs

SV-237405r971533_rule
SV-86079

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) that require real-time alerts. These messages should include a severity-level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The CA API Gateway is configured by default to only allow 5 failed attempts to log on to the Gateway console. After 5 attempts, all accounts will be locked for 20 minutes. Upon the next successful logon as a privileged administrator, such as root on the console, a message will appear stating "there were x failed logon attempts since the last successful login".

Checks: C-40624r643763_chk

Using an SSH client, attempt to log on to the CA API Gateway using the root user. The attempt will fail as root logons from a remote SSH client are disabled by default. On the main console of the CA API Gateway, log on with the root user and notice the message stating "There were 'x' failed login attempts..." and "Last failed login: date time from address on ssh:notty". If the logon is allowed or the message does not appear, this is a finding.

Fix: F-40587r643764_fix

There should be no fix for this, as by default the CA API Gateway is configured to disallow remote logons by the root user and detect when an attempt to logon as root has occurred.

The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when user-level intrusions that provide non-privileged access are detected.

SI-4 - Low - CCI-002664 - V-237406 - SV-237406r971533_rule

RMF Control

SI-4

Severity

CCI

CCI-002664

Version

CAGW-GW-000800

Vuln IDs

V-237406
V-71457

Rule IDs

SV-237406r971533_rule
SV-86081

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) that require real-time alerts. These messages should include a severity-level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The CA API Gateway must be configured to send an email upon detection of an event such as a user trying to gain privileged access to a back-end service through the use of a "Send Email Alert" Assertion within all Registered Services requiring email notifications for events such as user-level intrusions.

Checks: C-40625r643766_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services requiring email notifications for user-level intrusions. Verify the "Send Email Alert" Assertion has been included in the policy as per organizational requirements. If it is not present, this is a finding.

Fix: F-40588r643767_fix

Open the CA API Gateway - Policy Manager and double-click the Registered Services requiring email notifications for user-level intrusions that did not have the "Send Email Alert" Assertion included. Add the "Send Email Alert" Assertion to the policy and configure as per organizational requirements.

The CA API Gateway providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when Denial of Service (DoS) incidents are detected.

SI-4 - Low - CCI-002664 - V-237407 - SV-237407r971533_rule

RMF Control

SI-4

Severity

CCI

CCI-002664

Version

CAGW-GW-000810

Vuln IDs

V-237407
V-71459

Rule IDs

SV-237407r971533_rule
SV-86083

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) that require real-time alerts. These messages should include a severity-level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel. The CA API Gateway must be configured to send an email upon detection of an event such as a denial of service after exceeding a rate limit defined by an administrator in accordance with organizational requirements through the use of a "Send Email Alert" Assertion that can be added to all Registered Services requiring email notifications or to a global policy defining a rate limit.

Checks: C-40626r643769_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services requiring email notifications for denial of service attacks. Verify the "Send Email Alert" Assertion has been included in the policy at the required decision points, usually after an "Apply Rate Limit" or "Apply Throughput Quota" Assertion within the policy as per organizational requirements. If it is not present, this is a finding.

Fix: F-40589r643770_fix

Open the CA API Gateway - Policy Manager and double-click the Registered Services requiring email notifications for DoS attacks that did not have the "Send Email Alert" Assertion included. Add the "Send Email Alert" Assertion to the policy at the required decision points, usually after an "Apply Rate Limit" or "Apply Throughput Quota" Assertion within the policy as per organizational requirements. Optionally, the "Send Email Alert" Assertion can be added to a Global Policy detecting DoS attacks.

The ALG providing content filtering must generate an alert to, at a minimum, the ISSO and ISSM when new active propagation of malware infecting DoD systems or malicious code adversely affecting the operations and/or security of DoD systems is detected.

SI-4 - Medium - CCI-002664 - V-237408 - SV-237408r971533_rule

RMF Control

SI-4

Severity

CCI

CCI-002664

Version

CAGW-GW-000820

Vuln IDs

V-237408
V-71461

Rule IDs

SV-237408r971533_rule
SV-86085

Without an alert, security personnel may be unaware of major detection incidents that require immediate action, and this delay may result in the loss or compromise of information. The ALG generates an alert that notifies designated personnel of the Indicators of Compromise (IOCs) that require real-time alerts. These messages should include a severity-level indicator or code as an indicator of the criticality of the incident. These indicators reflect the occurrence of a compromise or a potential compromise. Since these incidents require immediate action, these messages are assigned a critical or level 1 priority/severity, depending on the system's priority schema. CJCSM 6510.01B, "Cyber Incident Handling Program", lists nine Cyber Incident and Reportable Event Categories. DoD has determined that categories identified by CJCSM 6510.01B Major Indicators (category 1, 2, 4, or 7 detection events) will require an alert when an event is detected. Alerts may be transmitted, for example, telephonically, by electronic mail messages, or by text messaging. The ALG must either send the alert to a management console that is actively monitored by authorized personnel or use a messaging capability to send the alert directly to designated personnel.

Checks: C-40627r643772_chk

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require an alert to be sent when malicious code/malware is detected. Verify the "Scan Using ICAP-Enabled Antivirus" Assertion is included in the policy and that the "Send Email Alert" Assertion is included after the "ICAP-Enabled Antivirus" Assertion, with the results of the response variable set in the "ICAP-Enabled Antivirus" Assertion included in the message body of the Assertion. Additionally, to avoid receiving emails on all items scanned, the policy should be configured to only send an email alert upon detection of malicious code/malware within the response of the "ICAP-Enabled AntiVirus" Assertion. If neither Assertion is present, check to see if it has been added to a Global Policy. If the Assertions are not present in either Global or Registered Services policy, this is a finding.

Fix: F-40590r643773_fix

Open the CA API Gateway - Policy Manager and double-click any of the Registered Services that require an alert to be sent when malicious code/malware is detected. Verify/add the "Scan Using ICAP-Enabled Antivirus" Assertion and the "Send Email Alert". Configure the "Scan Using ICAP-Enabled Antivirus" Assertion as per organizational requirements and position the "Send Email Alert Assertion after the "ICAP-Enabled Antivirus" Assertion, with the results of the response variable set in the "ICAP-Enabled Antivirus" Assertion included in the message body of the "Send Email Alert" Assertion. Additionally, to avoid receiving emails on all items scanned, the policy should be configured to only send an email alert upon detection of malicious code within the response of the "ICAP-Enabled AntiVirus" Assertion. If desired, these Assertions can be added to a Global Policy.

The CA API Gateway providing user authentication intermediary services must transmit only encrypted representations of passwords.

IA-5 - Medium - CCI-000197 - V-237409 - SV-237409r643777_rule

RMF Control

IA-5

Severity

CCI

CCI-000197

Version

CAGW-GW-000830

Vuln IDs

V-237409
V-71463

Rule IDs

SV-237409r643777_rule
SV-86087

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. This requirement applies to ALGs that provide user authentication intermediary services. This does not apply to authentication for the purpose of configuring the device itself (device management). The CA API Gateway must require SSL or TLS when accessing a Registered Service. By requiring SSL or TLS to access a Registered Service, passwords will be encrypted by the CA API Gateway even if the back-end server does not require passwords to be encrypted or have SSL enabled.

Checks: C-40628r643775_chk

Open the CA API Gateway - Policy Manager and open each of the Registered Services that requires the authentication passwords to be protected. Verify the "Require SSL or TLS Transport" Assertion is present. If it is not, this is a finding.

Fix: F-40591r643776_fix

Open the CA API Gateway - Policy Manager and open each of the Registered Services that requires authentication passwords to be protected and that does not include the "Require SSL or TLS Transport" Assertion. Add the "Require SSL or TLS Transport" Assertion and click the "Save and Activate" button to activate the changes to the policy.

The CA API Gateway must check the validity of all data inputs except those specifically identified by the organization.

SI-10 - Medium - CCI-001310 - V-237410 - SV-237410r643780_rule

RMF Control

SI-10

Severity

CCI

CCI-001310

Version

CAGW-GW-000840

Vuln IDs

V-237410
V-71465

Rule IDs

SV-237410r643780_rule
SV-86089

Invalid user input occurs when a user inserts data or characters into an application's data entry fields and the application is unprepared to process that data. This results in unanticipated application behavior, potentially leading to an application or information system compromise. Invalid input is one of the primary methods employed when attempting to compromise an application. Network devices with the functionality to perform application layer inspection may be leveraged to validate data content of network communications. 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 typically follows 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 network elements use attacker-supplied inputs to construct structured messages without properly encoding such messages, 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. Pre-screening 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. The CA API Gateway must validate both XML and JSON schemas to verify valid inputs from a client requesting Registered Services. This helps to prevent against XDoS attacks and parameter tampering, which in turn helps to prevent the injection of malicious scripts or content into the request.

Checks: C-40629r643778_chk

Fix: F-40592r643779_fix

Open the CA API Gateway - Policy Manager and double-click each of the Registered Services required to validate inputs that do not include a "Validate XML Schema" or Validate JSON Schema" Assertion. Add either the "Validate XML Schema" or "Validate JSON Schema" Assertions and configure in accordance with organizational requirements.

The CA API Gateway must reveal error messages only to the ISSO, ISSM, and SCA.

SI-11 - Medium - CCI-001314 - V-237411 - SV-237411r643783_rule

RMF Control

SI-11

Severity

CCI

CCI-001314

Version

CAGW-GW-000850

Vuln IDs

V-237411
V-71467

Rule IDs

SV-237411r643783_rule
SV-86091

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 give configuration details about the network element. Limiting access to system logs and administrative consoles to authorized personnel will help to mitigate this risk. However, user feedback and error messages should also be restricted by type and content in accordance with security best practices (e.g., ICMP messages). The CA API Gateway must be configured within the policies of a Registered Service to only pass limited error messaging to the end user of a Registered Service. Additional error messages will be recorded in audit logs, and the audit logs are controlled via role-based access.

Checks: C-40630r643781_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring limited error messaging feedback to end users. Verify that the policy is configured to deliver limited error feedback to the user via the "Customize Error Response" and/or "Customize Soap Fault Response" Assertion in accordance with organizational requirements. If it is not, this is a finding.

Fix: F-40593r643782_fix

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring limited error messaging feedback to end users that were not configured properly. Add the "Customize Error Response" and/or "Customize Soap Fault Response" Assertion and configure in accordance with organizational requirements.

The CA API Gateway providing user access control intermediary services must generate audit records when successful/unsuccessful logon attempts occur.

AU-12 - Medium - CCI-000172 - V-237412 - SV-237412r643786_rule

RMF Control

AU-12

Severity

CCI

CCI-000172

Version

CAGW-GW-000860

Vuln IDs

V-237412
V-71469

Rule IDs

SV-237412r643786_rule
SV-86093

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). This requirement applies to the ALG traffic management functions, such as content filtering or intermediary services. This does not apply to audit logs generated on behalf of the device (device management). The CA API Gateway by default audits when unsuccessful attempts to log on to a Registered Service or the Gateway occur. To enable the auditing of successful events, the log level on the Gateway must be increased to INFO, as by default it is set to WARNING, which only audits events that may be considered an issue.

Checks: C-40631r643784_chk

Open the CA API Gateway - Policy Manager. Locate the Global Policy created for "message-received". Open the policy and verify the "Audit Messages in Policy" Assertion has been added. If the Global policy does not exist or the "Audit Messages in Policy" Assertion is not present, this is a finding.

Fix: F-40594r643785_fix

Open the CA API Gateway - Policy Manager. If a Global Policy is not set for the system, create one by selecting "Tasks" from the main menu and choosing "Create Policy". Give the policy a name and select "Global Policy Fragment" from the Policy Type drop-down menu. Select "message-received" from the Policy Tag drop-down menu and click "OK". Locate the Global Policy created for "message-received". Open the policy and add the "Audit Messages in Policy" Assertion. Set the Level to "WARNING" to verify the normally successful logons are recorded as WARNINGS and not INFO.

The CA API Gateway providing user access control intermediary services must generate audit records showing starting and ending time for user access to the system.

AU-12 - Medium - CCI-000172 - V-237413 - SV-237413r643789_rule

RMF Control

AU-12

Severity

CCI

CCI-000172

Version

CAGW-GW-000870

Vuln IDs

V-237413
V-71471

Rule IDs

SV-237413r643789_rule
SV-86095

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). This requirement applies to the ALG traffic management functions, such as content filtering or intermediary services. This does not apply to audit logs generated on behalf of the device (device management). By default, the CA API Gateway audits all starting events for each Registered Service. An ending event can be generated through the use of a "logout service/API", which is called by the user's application at the time of logout or session termination. If the Registered Service/API already has the logout capability included, the ending event will be generated automatically at logout without the need for an additional logout service.

Checks: C-40632r643787_chk

Open the CA API Gateway - Policy Manager. Verify that each Registered Service requiring starting and ending event auditing includes the logout/terminate session capability as part of the Registered Service/API. If it does not, this is a finding.

Fix: F-40595r643788_fix

If any of the Registered Services/API's do not provide a logout/terminate session capability as part of the API, create and register a "Logoff" Registered Service and call this service from the user's application upon ending a session. This will automatically generate the ending event as required and be audited on the Gateway. For more details on registering and authoring services, refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography to generate cryptographic hashes.

SC-13 - Medium - CCI-002450 - V-237414 - SV-237414r831434_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

CAGW-GW-000880

Vuln IDs

V-237414
V-71473

Rule IDs

SV-237414r831434_rule
SV-86097

Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. This requirement applies only to ALGs that provide encryption intermediary services (e.g., HTTPS, TLS, or DNSSEC). The CA API Gateway uses the RSA BSAFE Crypto-J Software Module for cryptographic hashing, which is validated to FIPS 140-2 overall Level 1 when operated in FIPS mode. FIPS mode is not enabled by default and must be enabled on the CA API Gateway. Hashing algorithms used in signature operations are configured as per the assertion in the policy.

Checks: C-40633r643790_chk

Open the CA API Gateway - Policy Manager. Select "Manage Cluster-Wide Properties" from the "Tasks" menu. If the "security.fips.enabled" property is not listed or set to "True", this is a finding. Additionally, select Tasks >> Manage Listen Ports and double-click on each SSL listen port. Verify that no SSL versions are selected, TLS 1.0 is not selected, and only TLS 1.1, 1.2, and above are selected. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable). When using the following Assertions in the policy, verify only the approved secure hashes are selected: "Sign XML Element", "Sign Element", "Generate Security Hash". Verify that SHA-1 and below are not selected wherever appropriate. If not, this is also a finding.

Fix: F-40596r643791_fix

Open the CA API Gateway - Policy Manager. Select "Manage Cluster-Wide Properties" from the "Tasks" menu. Click "Add" and select "security.fips.enabled" from the "Key:" drop-down list. Set the value to "True" and click "OK". API Gateway version 8.3 and later will automatically deselect TLS 1.0. For version 8.2 and prior, select Tasks >> Manage Listen Ports, double-click on each SSL listen port, select the SSL/TLS settings, deselect TLS 1.0, and select TLS 1.1 and TLS 1.2. Verify that each Enabled Cipher Suites with a checkmark is included in NIST SP 800-52 section 3.3.2 Cipher Suites (or Appendix C if applicable). Within each Registered Service using the following Assertions in the policy, enable only the approved secure hashes are selected: "Sign XML Element", "Sign Element", "Generate Security Hash". Also verify SHA-1 and below are not selected wherever appropriate.

The CA API Gateway providing encryption intermediary services must implement NIST FIPS-validated cryptography for digital signatures.

SC-13 - Medium - CCI-002450 - V-237415 - SV-237415r831435_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

CAGW-GW-000890

Vuln IDs

V-237415
V-71475

Rule IDs

SV-237415r831435_rule
SV-86099

Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. This requirement applies only to ALGs that provide encryption intermediary services (e.g., HTTPS, TLS, or DNSSEC). The CA API Gateway meets NIST FIPS-validated cryptography for digital signatures by using the built-in "Sign XML Element" and "Sign Element" Assertions within Registered Services policies, along with registered keypairs configured in accordance with organizational requirements.

Checks: C-40634r643793_chk

Open the CA API GW - Policy Manager. Double-click each of the Registered Services that has the "Sign XML Element” or “Sign Element” Assertions, or require NIST-FIPS-validated cryptography for digital signatures be enabled. Verify that the Signature Digest Algorithm is SHA-256 or above to meet organizational requirements. Verify that an approved public-private keypair exists in Tasks >> Manage Private Keys. Right-click on the aforementioned Assertions; whenever used, chose "Select Private Key" and verify the appropriate private key is assigned to be used for the signature. Additionally verify that the "security.fips.enabled" Cluster Wide Property is enabled. If any of the above steps are not met, this is a finding.

Fix: F-40597r643794_fix

Open the CA API Gateway - Policy Manager. Double-click each of the Registered Services that requires NIST-FIPS-validated cryptography for digital signatures to be enabled. Add the following Assertion(s) in accordance with organizational need: "Sign XML Element" and/or "Sign Element". Verify that the Signature Digest Algorithm is set to SHA-256 or above to meet organizational requirements. Verify/install an approved public-private keypair in Tasks >> Manage Private Keys. Also, right-click on the aforementioned Assertions, whenever used, chose "Select Private Key", and verify the appropriate private key is assigned to be used for the signature. If the "security.fips.enabled" Cluster-Wide Property is not enabled, select "Manage Cluster-Wide Properties" from the "Tasks" menu. Click "Add" and select "security.fips.enabled" from the "Key:" drop-down list. Set the value to "True" and click "OK".

The CA API Gateway providing encryption intermediary services must use NIST FIPS-validated cryptography to implement encryption services.

SC-13 - Medium - CCI-002450 - V-237416 - SV-237416r831436_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

CAGW-GW-000900

Vuln IDs

V-237416
V-71487

Rule IDs

SV-237416r831436_rule
SV-86111

Use of weak or untested encryption algorithms undermines the purposes of using encryption to protect data. The network element must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. This requirement applies only to ALGs that provide encryption intermediary services (e.g., HTTPS, TLS, or DNSSEC). Encryption operations are performed in the following assertions: "Encrypt XML Element" and "Encrypt Element". Any of the listed encryption methods (AES 128 CBC, AES 192 CBC, AES 128 GCM, AES 256 GCM, Triple DES) included with the Assertions are NIST-FIPS validated. The FIPS-140-2 Certified RSA BSAFE Crypto-J Module is used for encryption operations. All CA API Gateway references to Triple-DES directly imply three-key and NOT two-key.

Checks: C-40635r643796_chk

Open the CA API Gateway - Policy Manager. Double-click each of the Registered Services that requires NIST-FIPS validated encryption services. Verify that the "Encrypt XML Element" or "Encrypt Element" Assertion has/have been added to the policy in accordance with organizational requirements. If the Assertion(s) is/are not present, this is a finding.

Fix: F-40598r643797_fix

Open the CA API Gateway - Policy Manager. Double-click each of the Registered Services that require NIST-FIPS validated encryption services. Add the "Encrypt XML Element" and/or "Encrypt Element" to the policy and configure in accordance with organizational requirements.

The CA API Gateway must off-load audit records onto a centralized log server in real time.

AU-4 - Medium - CCI-001851 - V-237417 - SV-237417r831437_rule

RMF Control

AU-4

Severity

CCI

CCI-001851

Version

CAGW-GW-000910

Vuln IDs

V-237417
V-71489

Rule IDs

SV-237417r831437_rule
SV-86113

Off-loading ensures audit information does not get overwritten if the limited audit storage capacity is reached and also protects the audit record in case the system/component being audited is compromised. Off-loading is a common process in information systems with limited audit storage capacity. The audit storage on the ALG is used only in a transitory fashion until the system can communicate with the centralized log server designated for storing the audit records, at which point the information is transferred. However, DoD requires that the log be transferred in real time, which indicates that the time from event detection to off-loading is seconds or less. This does not apply to audit logs generated on behalf of the device itself (management). By default, when the CA API Gateway Server is configured to off-load audit records, they are offloaded in real time. No additional configuration is needed.

Checks: C-40636r643799_chk

Open the CA API Gateway - Policy Manager. Select "Tasks" and chose "Manage Log/Audit Sinks". Confirm the "ssg" log type is "Syslog". Click "Syslog Settings" and verify the settings for the Centralized Syslog Server are set as defined by the organization. If the log type is not "Syslog", this is a finding. If the centralized syslog server settings are not set as defined by the organization, this is a finding.

Fix: F-40599r643800_fix

The CA API Gateway that provides intermediary services for FTP must inspect inbound and outbound FTP communications traffic for protocol compliance and protocol anomalies.

CM-6 - Medium - CCI-000366 - V-237418 - SV-237418r643804_rule

RMF Control

CM-6

Severity

CCI

CCI-000366

Version

CAGW-GW-000930

Vuln IDs

V-237418
V-71477

Rule IDs

SV-237418r643804_rule
SV-86101

Application protocol anomaly detection examines application layer protocols such as FTP to identify attacks based on observed deviations in the normal RFC behavior of a protocol or service. This type of monitoring allows for the detection of known and unknown exploits, which exploit weaknesses of commonly used protocols. Since protocol anomaly analysis examines the application payload for patterns or anomalies, an FTP proxy must be included in the ALG. This ALG will be configured to inspect inbound and outbound FTP communications traffic to detect protocol anomalies such as malformed message and command insertion attacks. The CA API Gateway must be configured to inspect incoming and outgoing FTP traffic for protocol compliance and anomalies such as limiting message size, protecting against code injection cross-site request forgery, SQL attacks, and XML and JSON document structure validation; validate content; and/or use third-party antivirus scanning. Also, regular expressions can be used to detect any known attack patterns within policies.

Checks: C-40637r643802_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring the inspection of FTP traffic for anomalies. Verify the "Route via FTP(s)" Assertion is included within the policies. Also, verify the FTP Listen Port exists and the settings are configured in accordance with organizational requirements by selecting "Tasks" from the main menu, choosing "Manage Listen Ports", and validating that an FTP/FTPS Protocol Listen Port has been added/configured properly including setting the maximum message size property. If the "Route via FTP(s)" Assertion is not included in the policies or the Listen port has not been added/configured in accordance with organizational requirements, this is a finding.

Fix: F-40600r643803_fix

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring the inspection of FTP traffic for anomalies that did not include a "Route via FTP(s)" Assertion. Add the "Route via FTP(s)" Assertion and configure in accordance with organizational requirements. Also, if the FTP Listen Port was not present or configured properly, verify/add the FTP Listen Port by selecting "Tasks" from the main menu, choosing "Manage Listen Ports", and updating/adding the FTP/FTPS Protocol Listen Port in accordance with organizational requirements, including setting the maximum message size property.

The CA API Gateway that provides intermediary services for HTTP must inspect inbound and outbound HTTP traffic for protocol compliance and protocol anomalies.

CM-6 - Medium - CCI-000366 - V-237419 - SV-237419r643807_rule

RMF Control

CM-6

Severity

CCI

CCI-000366

Version

CAGW-GW-000940

Vuln IDs

V-237419
V-71479

Rule IDs

SV-237419r643807_rule
SV-86103

Application protocol anomaly detection examines application layer protocols such as HTTP to identify attacks based on observed deviations in the normal RFC behavior of a protocol or service. This type of monitoring allows for the detection of known and unknown exploits, which exploit weaknesses of commonly used protocols. Since protocol anomaly analysis examines the application payload for patterns or anomalies, an HTTP proxy must be included in the ALG. This ALG will be configured to inspect inbound and outbound HTTP communications traffic to detect protocol anomalies such as malformed message and command insertion attacks. All inbound and outbound traffic, including HTTPS, must be inspected. However, the intention of this policy is not to mandate HTTPS inspection by the ALG. Typically, HTTPS traffic is inspected either at the source or destination and/or is directed for inspection by organizationally-defined network termination point. The CA API Gateway must be configured to inspect incoming and outgoing HTTP traffic for protocol compliance and anomalies such as limiting message size, protecting against code injection cross-site request forgery, SQL attacks, and XML and JSON document structure validation; validate content; and/or use third-party anti-virus scanning. Also, regular expressions can be used to detect any known attack patterns within policies.

Checks: C-40638r643805_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring the inspection of HTTP traffic for anomalies. Verify the "Route via HTTP(s)" Assertion is included within the policies. Also, verify the HTTP Listen Port exists and the settings are configured in accordance with organizational requirements by selecting "Tasks" from the main menu, choosing "Manage Listen Ports", and validating that an HTTP/HTTPS Protocol Listen Port has been added/configured properly, including setting the maximum message size property. If the "Route via HTTP(s):" Assertion is not included in the policies or the Listen Port has not been added/configured in accordance with organizational requirements, this is a finding.

Fix: F-40601r643806_fix

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring the inspection of HTTP traffic for anomalies that did not include a "Route via HTTP(s)" Assertion. Add the "Route via HTTP(s)" Assertion and configure in accordance with organizational requirements. Also, if the HTTP Listen Port was not present or configured properly, verify/add the HTTP Listen Port by selecting "Tasks" from the main menu choosing "Manage Listen Ports", and updating/adding the HTTP/HTTPS Protocol Listen Port in accordance with organizational requirements, including setting the maximum message size property. Additionally, the policy can be updated to add other threat protections, such as the "Protect Against Code Injection" or other Assertions listed in the "Threat Protection" Folder Assertion list. For more details, refer to the “CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing user access control intermediary services must automatically terminate a user session when organization-defined conditions or trigger events that require a session disconnect occur.

AC-12 - Medium - CCI-002361 - V-237420 - SV-237420r831438_rule

RMF Control

AC-12

Severity

CCI

CCI-002361

Version

CAGW-GW-000950

Vuln IDs

V-237420
V-71481

Rule IDs

SV-237420r831438_rule
SV-86105

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session, except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. This capability is typically reserved for specific system functionality where the system owner, data owner, or organization requires additional trigger events based on specific mission needs. Conditions or trigger events requiring automatic session termination can include, for example, targeted responses to certain types of incidents and time-of-day restrictions on information system use. This policy only applies to gateways (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services. The CA API Gateway must place restrictions on Registered Services, such as time/day restrictions, and generate targeted responses to certain types of incidents based on organizational requirements for disconnecting sessions.

Checks: C-40639r643808_chk

Open the CA API Gateway - Policy Manager and double-click all Registered Services requiring organization-defined conditions for session disconnects. Verify the Registered Services' policies are configured in accordance with organizational requirements for time-of-day restrictions or other incidents causing the need for a session disconnect and targeted responses. If they are not, this is a finding.

Fix: F-40602r643809_fix

Open the CA API Gateway - Policy Manager and double-click all Registered Services that did not meet the organization-defined conditions for session disconnects. Configure the policies in accordance with organizational requirements for time-of-day restriction or other events requiring session disconnects and targeted responses. For more details, refer to the "CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API Gateway providing user access control intermediary services must provide a logoff capability for user-initiated communications sessions.

AC-12 - Medium - CCI-002363 - V-237421 - SV-237421r831439_rule

RMF Control

AC-12

Severity

CCI

CCI-002363

Version

CAGW-GW-000960

Vuln IDs

V-237421
V-71483

Rule IDs

SV-237421r831439_rule
SV-86107

If a user cannot explicitly end a session, the session may remain open and be exploited by an attacker. However, for some types of interactive sessions, including, for example, remote logon, information systems typically send logoff messages as final messages prior to terminating sessions. This policy only applies to gateways (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services. The CA API Gateway must register, protect, and expose the API responsible for logoff capability. Policy can then be configured to allow the Logoff Registered Service to be initiated through the application requiring the user logoff capability.

Checks: C-40640r643811_chk

Open the CA API Gateway - Policy Manager. Verify that all services/applications requiring user-initiated logoff are registered on the Gateway and that the Logoff API is included and exposed to the users requiring user-initiated logoff capability. If not, this is a finding.

Fix: F-40603r643812_fix

Open the CA API Gateway - Policy Manager and register the Logoff APIs as Registered Services. Assign the proper policy to the Registered Service in accordance with organizational requirements for securing/protecting Registered Services/APIs. For more details, refer to the "Layer 7 Policy Authoring User Manual". Additionally, update all applications developed within the organization to call the newly added Registered Service in accordance with organizational requirements.

The CA API Gateway providing user access control intermediary services must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions.

AC-12 - Medium - CCI-002364 - V-237422 - SV-237422r831440_rule

RMF Control

AC-12

Severity

CCI

CCI-002364

Version

CAGW-GW-000970

Vuln IDs

V-237422
V-71485

Rule IDs

SV-237422r831440_rule
SV-86109

If a user cannot explicitly end a session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Logoff messages for access, for example, can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions including, for example, remote logon, information systems typically send logoff messages as final messages prior to terminating sessions. This policy only applies to ALGs (e.g., identity management or authentication gateways) that provide user account services as part of the intermediary services. The CA API Gateway must return a custom template response upon calling a service. All developed applications protected by the CA API Gateway must be set up to call a CA API Gateway Service, which upon selecting "logoff" within the application, terminates the authenticated session and displays an explicit logoff message.

Checks: C-40641r643814_chk

Open the CA API Gateway - Policy Manager. Verify that a Registered Service is present for displaying an explicit logoff message using a "Return Template Response" Assertion. If the Registered Service is not present, this is a finding.

Fix: F-40604r643815_fix

Open the CA API Gateway - Policy Manager and create a Registered Service that includes a "Return Template Response" Assertion in accordance with organizational requirements for an explicit logoff message. For more details, refer to the "CA API Management Documentation Wiki" at https://wiki.ca.com/display/GATEWAY90/CA+API+Gateway+Home.

The CA API ALG must be using a version supported by the vendor.

CM-6 - High - CCI-000366 - V-264434 - SV-264434r992099_rule

RMF Control

CM-6

Severity

CCI

CCI-000366

Version

CAGW-GW-000920

Vuln IDs

V-264434

Rule IDs

SV-264434r992099_rule

Systems running an unsupported software/firmware version lack current security fixes required to mitigate the risks associated with recent vulnerabilities.

Checks: C-68348r992097_chk

This STIG is sunset and no longer updated. Compare the version running to the supported version by the vendor. If the system is using an unsupported version from the vendor, this is a finding.

Fix: F-68256r992098_fix

Upgrade to a version supported by the vendor.

Added rules 82

Removed rules 81

Checks: C-40561r643574_chk

Fix: F-40524r643575_fix

Generate Mitigation Statement:

Checks: C-40562r643577_chk

Fix: F-40525r643578_fix

Generate Mitigation Statement:

Checks: C-40563r643580_chk

Fix: F-40526r643581_fix

Generate Mitigation Statement:

Checks: C-40564r643583_chk

Fix: F-40527r643584_fix

Generate Mitigation Statement:

Checks: C-40565r643586_chk

Fix: F-40528r643587_fix

Generate Mitigation Statement:

Checks: C-40566r643589_chk

Fix: F-40529r643590_fix

Generate Mitigation Statement:

Checks: C-40567r643592_chk

Fix: F-40530r643593_fix

Generate Mitigation Statement:

Checks: C-40568r643595_chk

Fix: F-40531r643596_fix

Generate Mitigation Statement:

Checks: C-40569r643598_chk

Fix: F-40532r643599_fix

Generate Mitigation Statement:

Checks: C-40570r643601_chk

Fix: F-40533r643602_fix

Generate Mitigation Statement:

Checks: C-40571r643604_chk

Fix: F-40534r643605_fix

Generate Mitigation Statement:

Checks: C-40572r643607_chk

Fix: F-40535r643608_fix

Generate Mitigation Statement:

Checks: C-40573r643610_chk

Fix: F-40536r643611_fix

Generate Mitigation Statement:

Checks: C-40574r643613_chk

Fix: F-40537r643614_fix

Generate Mitigation Statement:

Checks: C-40575r643616_chk

Fix: F-40538r643617_fix

Generate Mitigation Statement:

Checks: C-40576r643619_chk

Fix: F-40539r643620_fix

Generate Mitigation Statement:

Checks: C-40577r643622_chk

Fix: F-40540r643623_fix

Generate Mitigation Statement:

Checks: C-40578r643625_chk

Fix: F-40541r643626_fix

Generate Mitigation Statement:

Checks: C-40579r643628_chk

Fix: F-40542r643629_fix

Generate Mitigation Statement:

Checks: C-40580r643631_chk

Fix: F-40543r643632_fix

Generate Mitigation Statement:

Checks: C-40581r643634_chk

Fix: F-40544r643635_fix

Generate Mitigation Statement:

Checks: C-40582r643637_chk

Fix: F-40545r643638_fix

Generate Mitigation Statement:

Checks: C-40583r643640_chk

Fix: F-40546r643641_fix

Generate Mitigation Statement:

Checks: C-40584r643643_chk

Fix: F-40547r643644_fix

Generate Mitigation Statement:

Checks: C-40585r643646_chk

Fix: F-40548r643647_fix

Generate Mitigation Statement:

Checks: C-40586r643649_chk

Fix: F-40549r643650_fix

Generate Mitigation Statement: