CA API Gateway NDM Security Technical Implementation Guide

  • Version/Release: V1R2
  • Published: 2024-06-04
  • Released: 2024-07-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

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.
c
The CA API Gateway must be installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.
CM-6 - High - CCI-000366 - V-255500 - SV-255500r961863_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
CAGW-DM-000100
Vuln IDs
  • V-255500
  • V-71519
Rule IDs
  • SV-255500r961863_rule
  • SV-86143
The API Gateway (Appliance version) depends on specific RHEL capabilities for the security, logging, and auditing subsystems. Installation on alternative or older RHEL versions may create vulnerabilities.
Checks: C-59173r872429_chk

Verify the CA API Gateway is installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher. If the CA API Gateway is not installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher, this is a finding.

Fix: F-59116r872430_fix

Configure the CA API Gateway to be installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.

b
The CA API Gateway must employ RADIUS + LDAPS or LDAPS to centrally manage authentication settings.
CM-6 - Medium - CCI-000366 - V-255501 - SV-255501r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000110
Vuln IDs
  • V-255501
  • V-71521
Rule IDs
  • SV-255501r961863_rule
  • SV-86145
The use of authentication servers or other centralized management servers for providing centralized authentication services is required for network device management. Maintaining local administrator accounts for daily usage on each network device without centralized management is not scalable or feasible. Without centralized management, it is likely that credentials for some network devices will be forgotten, leading to delays in administration, which itself leads to delays in remediating production problems and in addressing compromises in a timely fashion. Use of RADIUS + LDAPS or LDAPS for authentication and authorization provides the Gateway with an ability to authenticate credentials against a centralized and secured identity management system. This allows permissions for administration of the Gateway to be governed independently of the Gateway.
Checks: C-59174r872432_chk

Review the CA API Gateway configuration to determine if RADIUS + LDAPS or LDAPS is employed to centrally manage authentication settings. - SSH to SSG as a member of ssgconfig. - Select: 1) Configure system settings, 6) Export configuration. - Export configuration to "file". - Go back to main menu, select 3) Use a privileged shell (root). - Navigate to /home/ssgconfig, open "file". - Check "authenticationType". If "authenticationType" is not RADIUS_WITH_LDAP or RADIUS_WITH_LDAPS, this is a finding.

Fix: F-59117r872433_fix

Configure the CA API Gateway to employ RADIUS + LDAPS or LDAPS to centrally manage authentication settings. Prerequisites: - RADIUS server (for the RADIUS+LDAPS configuration) - LDAPS server with posixAccount objects for user logins - LDAPS server CA certificate available via HTTP at a specific URL - LDAP account for the SSG to bind and lookup info - posixUser object within LDAP contain object (OU) - All SSG LDAP posixAccount objects are filtered either by a fixed gidNumber or by membership in an LDAP group containing a sequence of memberUid attributes, one for each user. Configure SSG to use LDAPS. - SSH to SSG as a member of ssgconfig - Select: 1) Configure system settings, 4) Configure authentication method. - Select: 2) ldap. - Walk through configuration steps, providing requisite information ensuring: - Select LDAPS (secure) "y". - Select the appropriate TLS port (636 is the default). - Disable anonymous bind. - Specify the URL containing the PEM of the CA certificate to download. - Specify that the SSG LDAP client "demand" the server's certificate. - Set the user filter to use either a specific gidNumber or a group DN. - Set the posixAccount attribute to use as login name (uid). Confirmation configuration should be approximately: Authentication Type: LDAP_ONLY Label | Value --------------------------------------------------------------------------------------------- Secure | true ActiveDirectory | false Server | smldap.l7tech.com BaseDn | dc=l7tech,dc=com Port | 636 AnonymousBind | false BindDn | cn=Manager,dc=l7tech,dc=com BindPassword | <Hidden> Object for finding the password for users | ou=posixAccounts Object class name of users in the LDAP | posixAccount Server CaCert File | /etc/openldap/cacerts/ldapcacert Certificate Action | DEMAND GroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com PAM login attribute | uid Finally, apply configuration and restart the SSG. Configure SSG to use RADIUS+LDAPS. - SSH to SSG as ssgconfig. - Select: 1) Configure system settings, 4) Configure authentication method. - Select: 4) ldap_radius. - Walk through configuration steps, providing requisite information ensuring: - Enter the RADIUS server's address and secret. - Complete the LDAP questions as for the LDAPS only case (above). Confirmation configuration should be approximately: Authentication Type: RADIUS_WITH_LDAP Label | Value ------------------------------- Server | freerad217.l7tech.com Secret | <Hidden> Timeout | 3 Label | Value --------------------------------------------------------------------------------------------- Secure | true ActiveDirectory | false Server | smldap.l7tech.com BaseDn | dc=l7tech,dc=com Port | 636 AnonymousBind | false BindDn | cn=Manager,dc=l7tech,dc=com BindPassword | <Hidden> Object for finding the password for users | ou=posixAccounts Object class name of users in the LDAP | posixAccount Server CaCert Url | http://localhost:8080/cert Certificate Action | DEMAND GroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com PAM login attribute | uid

b
The CA API Gateway must shut down by default upon audit failure (unless availability is an overriding concern).
AU-5 - Medium - CCI-000140 - V-255502 - SV-255502r961863_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
CAGW-DM-000120
Vuln IDs
  • V-255502
  • V-71523
Rule IDs
  • SV-255502r961863_rule
  • SV-86147
It is critical that when the network device is at risk of failing to process audit logs as required, it take action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: (i) If the failure was caused by the lack of audit record storage capacity, the network device must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. (ii) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the network device must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.
Checks: C-59175r872435_chk

Verify the "/etc/audit/auditd.conf" file contains the lines: disk_full_action = HALT disk_error_action = HALT If "/etc/audit/auditd.conf" does not contain these lines, this is a finding.

Fix: F-59118r872436_fix

Configure the "auditd" configuration file "/etc/audit/auditd.conf" by adding these lines: disk_full_action = HALT disk_error_action = HALT

a
The CA API Gateway must forward all log audit log messages to the central log server.
AU-9 - Low - CCI-001348 - V-255503 - SV-255503r961863_rule
RMF Control
AU-9
Severity
Low
CCI
CCI-001348
Version
CAGW-DM-000130
Vuln IDs
  • V-255503
  • V-71525
Rule IDs
  • SV-255503r961863_rule
  • SV-86149
Protection of log data includes assuring log data is not accidentally lost or deleted. Regularly backing up audit records to a different system or onto separate media than the system being audited helps to assure, in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.
Checks: C-59176r872438_chk

Verify the CA API Gateway forwards all log audit log messages to the central log server. Within the "/etc/rsyslog.conf" file, confirm a rule in the format "*.* @@loghost.log.com" is in the ruleset section. If the CA API Gateway "/etc/rsyslog.conf" file does not have a rule in the format "*.* @@loghost.log.com" in the ruleset section, this is a finding.

Fix: F-59119r872439_fix

Configure the CA API Gateway to forward all audit log messages to the central log server. - Log in to CA API Gateway as root. - Open "/etc/rsyslog.conf" for editing. - Add a rule "*.* @@loghost.log.com" to the ruleset section of the "rsyslogd.conf" file.

b
The CA API Gateway must not have any default manufacturer passwords when deployed.
IA-5 - Medium - CCI-002041 - V-255504 - SV-255504r984088_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002041
Version
CAGW-DM-000140
Vuln IDs
  • V-255504
  • V-71527
Rule IDs
  • SV-255504r984088_rule
  • SV-86151
Network devices not protected with strong password schemes provide the opportunity for anyone to crack the password and gain access to the device, which can result in loss of availability, confidentiality, or integrity of network traffic. Many default vendor passwords are well known or are easily guessed; therefore, not removing them prior to deploying the network device into production provides an opportunity for a malicious user to gain unauthorized access to the device.
Checks: C-59177r872441_chk

Verify login as "root" (at the console) and "ssgconfig" have non-default passwords. The default password for "root" is "7layer" and the default password for "ssgconfig" is "7layer". If root or ssgconfig use default passwords, this is a finding.

Fix: F-59120r872442_fix

Use the "passwd" command to set non-default passwords.

b
In the event the authentication server is unavailable, there must be one local account of last resort.
AC-2 - Medium - CCI-001358 - V-255505 - SV-255505r960969_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001358
Version
CAGW-DM-000150
Vuln IDs
  • V-255505
  • V-71529
Rule IDs
  • SV-255505r960969_rule
  • SV-86153
Authentication for administrative (privileged-level) access to the device is required at all times. An account can be created on the device's local database for use in an emergency, such as when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is also referred to as the account of last resort since the emergency administration account is strictly intended to be used only as a last resort and immediate administrative access is absolutely necessary. The number of emergency administration accounts is restricted to at least one, but no more than operationally required as determined by the ISSO. The emergency administration account logon credentials must be stored in a sealed envelope and kept in a safe.
Checks: C-59178r872444_chk

Verify the "root" (or its equivalent, renamed account) is listed in the password configuration files. If the "root" account is not listed in the password configuration files, this is a finding.

Fix: F-59121r872445_fix

Configure the "root" account as the local account of last resort. Disable the "ssgconfig" account by destroying its password and making the login shell "/sbin/nologin".

b
The CA API Gateway must enforce a minimum 15-character password length.
IA-5 - Medium - CCI-000205 - V-255506 - SV-255506r984092_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
CAGW-DM-000160
Vuln IDs
  • V-255506
  • V-71531
Rule IDs
  • SV-255506r984092_rule
  • SV-86155
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
Checks: C-59179r872447_chk

Verify the CA API Gateway configuration files for passwords (/etc/login.defs, /etc/pam.d/password, /etc/pam.d/password-auth-ac, /etc/pam.d/system-auth, and /etc/pam.d/system-auth-ac) each have this line: PASS_MIN_LEN 15. If the CA API Gateway configuration files for passwords (/etc/login.defs, /etc/pam.d/password, /etc/pam.d/password-auth-ac, /etc/pam.d/system-auth, and /etc/pam.d/system-auth-ac) do not have the line requiring minimum 15-character password length, this is a finding.

Fix: F-59122r872448_fix

In order to change the default setting: - Log in to Gateway via SSH. - Open /etc/login.defs. - Change the value for PASS_MIN_LENGTH to desired value. Then: - Change the PASS_MIN_LENGTH field to desired value in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac -- /etc/pam.d/system-auth -- /etc/pam.d/system-auth-ac Note: Must be a value of "15" or greater.

b
If multifactor authentication is not supported and passwords must be used, the CA API Gateway must require that when a password is changed, the characters are changed in at least 8 of the positions within the password.
IA-5 - Medium - CCI-000195 - V-255507 - SV-255507r984101_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000195
Version
CAGW-DM-000170
Vuln IDs
  • V-255507
  • V-71533
Rule IDs
  • SV-255507r984101_rule
  • SV-86157
If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.
Checks: C-59180r872450_chk

Verify the password attribute "difok" field is set to "8" in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac If the password attribute "difok" field is not set to "8" in these files, this is a finding.

Fix: F-59123r872451_fix

Set the password attribute "difok" field is set to "8" in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac

b
The CA API Gateway must automatically remove or disable emergency accounts, except the emergency administration account, after 72 hours.
AC-2 - Medium - CCI-001682 - V-255508 - SV-255508r961863_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001682
Version
CAGW-DM-000180
Vuln IDs
  • V-255508
  • V-71535
Rule IDs
  • SV-255508r961863_rule
  • SV-86159
Emergency accounts are administrator accounts which are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If emergency accounts remain active when no longer needed, they may be used to gain unauthorized access. The risk is greater for the network device since these accounts have elevated privileges. To mitigate this risk, automated termination of these accounts must be set upon account creation. It is important to note the difference between emergency accounts and the emergency administration account. The emergency administration account, also known as the account of last resort, is an infrequently used account used by network administrators only when network or normal logon/access is not available. The emergency administration account is not subject to automatic termination dates.
Checks: C-59181r872453_chk

Verify expiry of account with command: chage -l "USERNAME" and look at the "Account expires" line for expiry date. If the expiry date is more than "72" hours after emergency account creation, this is a finding.

Fix: F-59124r872454_fix

For existing accounts, set expiry time of an account using command: chage -E "YYYY-MM-DD" "USERNAME For new accounts, create using command: useradd -e <expiry_date> USERNAME where the expiry date in YYYY-MM-DD format is when you wish the account to expire.

b
The CA API Gateway must activate a system alert message, send an alarm, and/or automatically shut down when a component failure is detected.
CM-6 - Medium - CCI-000366 - V-255509 - SV-255509r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000190
Vuln IDs
  • V-255509
  • V-71537
Rule IDs
  • SV-255509r961863_rule
  • SV-86161
Predictable failure prevention requires organizational planning to address device failure issues. If components key to maintaining the device's security fail to function, the device could continue operating in an insecure state. If appropriate actions are not taken when a network device failure occurs, a denial of service condition may occur which could result in mission failure since the network would be operating without a critical security monitoring and prevention function. Upon detecting a failure of network device security components, the network device must activate a system alert message, send an alarm, or shut down.
Checks: C-59182r872456_chk

Verify "/usr/local/bin/failtest" script exists and is executable. Verify crontab runs "/usr/local/bin/failtest" every minute by checking cron's logfile "/var/log/cron". If "/usr/local/bin/failtest" does not exist or it is not executable, this is a finding.

Fix: F-59125r872457_fix

Install and configure (setup SNMP trap dest/authentication) alerter script in /usr/local/bin/failtest. Configure cron to run "/usr/local/bin/failtest" every minute as indicated by /etc/crontab entry

b
The CA API Gateway must notify System Administrators (SAs) and Information System Security Officers (ISSMs) when accounts are created, or enabled when previously disabled.
AC-2 - Medium - CCI-002132 - V-255510 - SV-255510r961863_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-002132
Version
CAGW-DM-000200
Vuln IDs
  • V-255510
  • V-71539
Rule IDs
  • SV-255510r961863_rule
  • SV-86163
Once an attacker establishes initial access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Notification of account enabling is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of application user accounts and notifies SAs and ISSMs. Such a process greatly reduces the risk that accounts will be surreptitiously enabled and provides logging that can be used for forensic purposes. In order to detect and respond to events that affect network administrator accessibility and device processing, network devices must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event.
Checks: C-59183r872459_chk

Verify "/usr/local/bin/alerter" script exists and is executable. Verify crontab runs "/usr/local/bin/alerter" every minute by checking cron's logfile /var/log/cron. If the "/usr/local/bin/alerter" script does not exist, this is a finding. If the "/usr/local/bin/alerter" script does not run every minute as a cron job, this is a finding. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts &gt;&gt; $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa &gt;&gt; $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }

Fix: F-59126r872460_fix

Install and configure (setup SNMP trap dest/authentication) alerter script in /usr/local/bin/alerter. Run "/usr/local/bin/alerter -w" to write initial config to filesystem. Configure cron to run "/usr/local/bin/alerter -c" every minute. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash This script implements watching for changes in a system that may indicate unauthorized changes have been made to the system. It is designed to be run as "alerter -w" to capture the current configuration and then to be run out of cron on a regular basis as "alerter -c", which then compares the current configuration to the previously captured configuration. If the configuration has changed, an SNMP TRAP is sent using the "SNMPBASECMD" variable as the base "snmptrap" command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses "/var/run/alerter" as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }

b
The CA API Gateway must transmit organization-defined access authorization information using organization-defined security safeguards to organization-defined information systems which enforce access control decisions.
CM-6 - Medium - CCI-000366 - V-255511 - SV-255511r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000210
Vuln IDs
  • V-255511
  • V-71541
Rule IDs
  • SV-255511r961863_rule
  • SV-86165
Protecting access authorization information (i.e., access control decisions) ensures that authorization information cannot be altered, spoofed, or otherwise compromised during transmission. In distributed information systems, authorization processes and access control decisions may occur in separate parts of the systems. In such instances, authorization information is transmitted securely so timely access control decisions can be enforced at the appropriate locations. To support the access control decisions, it may be necessary to transmit, as part of the access authorization information, supporting security attributes. This is because, in distributed information systems, there are various access control decisions that need to be made, and different entities (e.g., services) make these decisions in a serial fashion, each requiring some security attributes to make the decisions.
Checks: C-59184r872462_chk

Verify the CA API Gateway is configured to use LDAP or RADIUS+LDAP for all administrative accounts by using the "ssgconfig" account and using menu: 1) Configure system settings &gt;&gt; 4) Configure authentication method. Select the appropriate ldap/ldap+radius configuration and then verify its settings by continuing the menu process until it completes. If LDAP or RADIUS+LDAP is not configured for all administrative accounts, this is a finding.

Fix: F-59127r872463_fix

Configure the Gateway to use LDAP or RADIUS+LDAP for all administrative accounts by using the "ssgconfig" account and using menu: 1) Configure system settings >> 4) Configure authentication method. Select the appropriate ldap/ldap+radius configuration and then set the appropriate settings for your environment by following the menu process until it completes.

a
The CA API Gateway must be configured to synchronize internal information system clocks with the primary and secondary time sources located in different geographic regions using redundant authoritative time sources.
CM-6 - Low - CCI-000366 - V-255512 - SV-255512r987682_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
CAGW-DM-000220
Vuln IDs
  • V-255512
  • V-71543
Rule IDs
  • SV-255512r987682_rule
  • SV-86167
The loss of connectivity to a particular authoritative time source will result in the loss of time synchronization (free-run mode) and increasingly inaccurate time stamps on audit events and other functions. Multiple time sources provide redundancy by including a secondary source. Time synchronization is usually a hierarchy; clients synchronize time to a local source while that source synchronizes its time to a more accurate source. The network device must utilize an authoritative time server and/or be configured to use redundant authoritative time sources. This requirement is related to the comparison done in CCI-001891. DoD-approved solutions consist of a combination of a primary and secondary time source using a combination or multiple instances of the following: a time server designated for the appropriate DoD network (NIPRNet/SIPRNet); United States Naval Observatory (USNO) time servers; and/or the Global Positioning System (GPS). The secondary time source must be located in a different geographic region than the primary time source.
Checks: C-59185r872465_chk

Verify the Gateway (using "ssgconfig") is configured to use multiple ntp sources using menu: 1) Configure system settings &gt;&gt; 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.

Fix: F-59128r872466_fix

Configure the Gateway using "ssgconfig" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.

a
The CA API Gateway must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).
AU-8 - Low - CCI-001890 - V-255513 - SV-255513r961443_rule
RMF Control
AU-8
Severity
Low
CCI
CCI-001890
Version
CAGW-DM-000230
Vuln IDs
  • V-255513
  • V-71545
Rule IDs
  • SV-255513r961443_rule
  • SV-86169
If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the application include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.
Checks: C-59186r872468_chk

Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings &gt;&gt; 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.

Fix: F-59129r872469_fix

Configure the Gateway using "ssgconfig" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.

a
The CA API Gateway must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.
AU-8 - Low - CCI-001889 - V-255514 - SV-255514r961446_rule
RMF Control
AU-8
Severity
Low
CCI
CCI-001889
Version
CAGW-DM-000240
Vuln IDs
  • V-255514
  • V-71547
Rule IDs
  • SV-255514r961446_rule
  • SV-86171
Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records. Time stamps generated by the application include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.
Checks: C-59187r872471_chk

Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings &gt;&gt; 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.

Fix: F-59130r872472_fix

Configure the Gateway using ssgconfig to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.

b
The CA API Gateway must generate an alert that will then be sent to the ISSO, ISSM, and other designated personnel (deemed appropriate by the local organization) when the unauthorized installation of software is detected.
CM-11 - Medium - CCI-001811 - V-255515 - SV-255515r961863_rule
RMF Control
CM-11
Severity
Medium
CCI
CCI-001811
Version
CAGW-DM-000250
Vuln IDs
  • V-255515
  • V-71549
Rule IDs
  • SV-255515r961863_rule
  • SV-86173
Unauthorized software not only increases risk by increasing the number of potential vulnerabilities, it also can contain malicious code. Sending an alert (in real time) when unauthorized software is detected allows designated personnel to take action on the installation of unauthorized software. Note that while the device must generate the alert, the notification may be done by a management server.
Checks: C-59188r872474_chk

Verify "/usr/local/bin/alerter" script exists and is executable. Verify crontab runs "/usr/local/bin/alerter" every minute by checking cron's logfile /var/log/cron. If the "/usr/local/bin/alerter" script does not exist, this is a finding. If the "/usr/local/bin/alerter" script does not run every minute as a cron job, this is a finding. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts &gt;&gt; $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa &gt;&gt; $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }

Fix: F-59131r872475_fix

Install and configure (setup SNMP trap dest/authentication) alerter script in "/usr/local/bin/alerter". Run "/usr/local/bin/alerter -w" to write initial config to filesystem. Configure cron to run "/usr/local/bin/alerter -c" every minute. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }

a
The CA API Gateway must authenticate NTP endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.
IA-3 - Low - CCI-001967 - V-255516 - SV-255516r961506_rule
RMF Control
IA-3
Severity
Low
CCI
CCI-001967
Version
CAGW-DM-000260
Vuln IDs
  • V-255516
  • V-71551
Rule IDs
  • SV-255516r961506_rule
  • SV-86175
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication.
Checks: C-59189r872477_chk

Verify "server" lines in the "/etc/ntp.conf" file are all marked with "autokey". Perform the command "ntpq -p" to show peer functioning. If the "server" lines in the "/etc/ntp.conf" file are not marked with "autokey", this is a finding. If the command "ntpq -p" does not show peers functioning, this is a finding.

Fix: F-59132r872478_fix

Configure Gateway to use public key (autokey in NTP terminology) authentication. See: http://support.ntp.org/bin/view/Support/ConfiguringAutokey

b
The CA API Gateway must authenticate SNMP endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.
IA-3 - Medium - CCI-001967 - V-255517 - SV-255517r961506_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
CAGW-DM-000270
Vuln IDs
  • V-255517
  • V-71553
Rule IDs
  • SV-255517r961506_rule
  • SV-86177
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication.
Checks: C-59190r872480_chk

Verify the "snmptrap" shell command used to emit SNMP TRAPS to the Network Management Station is using Version 3 with User Authentication for each potential trap source identified in this document. "snmptrap -v 3 -a SHA -A mypassword -x AES -X mypassword -l authPriv -u traptest -e 0x8000000001020304 localhost REQUIRED_TRAP_OID" If SNMP Version 3 is not being used, this is a finding.

Fix: F-59133r872481_fix

Change the "snmptrap" command at each source to use encryption/authentication (Version 3) IE: "snmptrap -v 3 -a SHA -A mypassword -x AES -X mypassword -l authPriv -u traptest -e 0x8000000001020304 localhost REQUIRED_TRAP_OID"

b
The CA API Gateway must authenticate RADIUS endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.
IA-3 - Medium - CCI-001967 - V-255518 - SV-255518r961506_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
CAGW-DM-000280
Vuln IDs
  • V-255518
  • V-71555
Rule IDs
  • SV-255518r961506_rule
  • SV-86179
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication.
Checks: C-59191r872483_chk

Using the "ssgconfig" menu subsystem, confirm RADIUS has been configured via 1) Configure system settings &gt;&gt; 4) Configure authentication method item 3 or 4. Confirm password is set to "Enter the RADIUS shared secret [&lt;Hidden&gt;]". If RADIUS is not correctly configured, this is a finding.

Fix: F-59134r872484_fix

Using the ssgconfig menu subsystem, confirm RADIUS has been configured via 1) Configure system settings >> 4) Configure authentication method item 3 or 4. Configure radius/ladap_radius as required.

b
The CA API Gateway must authenticate LDAPS endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.
IA-3 - Medium - CCI-001967 - V-255519 - SV-255519r961506_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
CAGW-DM-000290
Vuln IDs
  • V-255519
  • V-71557
Rule IDs
  • SV-255519r961506_rule
  • SV-86181
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication.
Checks: C-59192r872486_chk

Using the "ssgconfig" menu subsystem, confirm LDAP (Secure) has been configured via 1) Configure system settings &gt;&gt; 4) Configure authentication method item 2 or 4. Confirm the answer to the question "Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:" is "y". Ensure the answer to question "Specify the URL where the PEM formatted CA certificate can be located [ldaps://smldap.l7tech.com:636]:" is a trusted source of the certificate. If the LDAP is not correctly configured, this is a finding.

Fix: F-59135r872487_fix

Using the "ssgconfig" menu subsystem, set LDAP (Secure) by 1) Configure system settings >> 4) Configure authentication method item 2 or 4. Set the answer to the question "Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:" to "y". Set the answer to the question "Specify the URL where the PEM formatted CA certificate can be located [ldaps://smldap.l7tech.com:636]:" to a trusted source of the certificate.

b
The CA API Gateway must obtain LDAPS server certificates securely to use bidirectional authentication that is cryptographically based.
IA-3 - Medium - CCI-001967 - V-255520 - SV-255520r961506_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001967
Version
CAGW-DM-000300
Vuln IDs
  • V-255520
  • V-71559
Rule IDs
  • SV-255520r961506_rule
  • SV-86183
Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area or wide area network, Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply the requirement to those limited number (and type) of devices that truly need to support this capability. For network device management, this has been determined to be network management device addresses, SNMP authentication, and NTP authentication.
Checks: C-59193r872489_chk

Verify the LDAPS server certificate is in "/etc/openldap/cacerts". Verify TLS_REQCERT is set to demand in "/etc/openldap/ldap.conf". If the LDAPS server certificate is not in "/etc/openldap/cacerts", this is a finding. If "TLS_REQCERT" is not set to demand in "/etc/openldap/ldap.conf", this is a finding.

Fix: F-59136r872490_fix

Configure LDAPS/LDAPS+RADIUS to use LDAPS server certificates for bidirectional authentication that is cryptographically based. Place the LDAPS server certificate in "/etc/openldap/cacerts". Set "TLS_REQCERT" to demand in "/etc/openldap/ldap.conf".

b
The CA API Gateway must protect against or limit the effects of all known types of Denial of Service (DoS) attacks on the CA API Gateway management network by employing organization-defined security safeguards.
SC-5 - Medium - CCI-002385 - V-255521 - SV-255521r961620_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
CAGW-DM-000310
Vuln IDs
  • V-255521
  • V-71561
Rule IDs
  • SV-255521r961620_rule
  • SV-86185
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of network devices to mitigate the impact of DoS attacks that have occurred or are ongoing on device availability. For each network device, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or restricting the number of sessions the device opens at one time). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks. The security safeguards cannot be defined at the DoD level because they vary according to the capabilities of the individual network devices and the security controls applied on the adjacent networks (for example, firewalls performing packet filtering to block DoS attacks).
Checks: C-59194r872492_chk

Verify the CA API Gateway drops packets by default and only puts non-Gateway services on trusted interfaces. Check for the following lines in "/etc/sysconfig/iptables": :INPUT DROP [0:0] :FORWARD DROP [0:0] [0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT Check for the following lines in "/etc/sysconfig/ip6tables": :INPUT DROP [0:0] [0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT If the CA API Gateway does not drop packets by default or puts non-Gateway services on untrusted interfaces, this is a finding. Verify the CA API Gateway logs and drops TCP packets with bad flags. Check for the following lines in "/etc/sysconfig/iptables": [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags [0:0] -A badflags -m limit --limit 15/min -j LOG --log-prefix "Badflags:" [0:0] -A badflags -j DROP Check for the following lines in "/etc/sysconfig/ip6tables": [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags6 [0:0] -A badflags6 -m limit --limit 15/min -j LOG --log-prefix "Badflags6:" [0:0] -A badflags6 -j DROP If the CA API Gateway does not log and drop TCP packets with bad flags, this is a finding. Verify the CA API Gateway only allows certain ICMPs and rate limits pings. Check for the following lines in "/etc/sysconfig/iptables": [0:0] -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT [0:0] -A INPUT -p icmp -j badflags [0:0] -A OUTPUT -p icmp -m state --state INVALID -j DROP Check for the following lines in "/etc/sysconfig/ip6tables": [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 1 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 3 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 129 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 128 -m limit --limit 2/sec -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 133 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 134 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 135 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 136 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 137 -j ACCEPT [0:0] -A INPUT -p icmpv6 -j badflags6 If the CA API Gateway does not only allow certain ICMPs and rate limits pings, this is a finding.

Fix: F-59137r872493_fix

If the "iptables" file is not consistent, replace it with one from the distribution RPM. You may need to add additional permissions if some services are required.

b
The CA API Gateway must generate audit records when successful/unsuccessful logon attempts occur.
AU-12 - Medium - CCI-000172 - V-255522 - SV-255522r961824_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
CAGW-DM-000320
Vuln IDs
  • V-255522
  • V-71563
Rule IDs
  • SV-255522r961824_rule
  • SV-86187
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 network device (e.g., module or policy filter).
Checks: C-59195r872495_chk

Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.

Fix: F-59138r872496_fix

Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"

b
The CA API Gateway must generate audit records showing starting and ending time for administrator access to the system.
AU-12 - Medium - CCI-000172 - V-255523 - SV-255523r961830_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
CAGW-DM-000330
Vuln IDs
  • V-255523
  • V-71565
Rule IDs
  • SV-255523r961830_rule
  • SV-86189
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 network device (e.g., module or policy filter).
Checks: C-59196r872498_chk

Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.

Fix: F-59139r872499_fix

Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"

b
The CA API Gateway must generate audit records when concurrent logons from different workstations occur.
AU-12 - Medium - CCI-000172 - V-255524 - SV-255524r961833_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
CAGW-DM-000340
Vuln IDs
  • V-255524
  • V-71567
Rule IDs
  • SV-255524r961833_rule
  • SV-86191
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 network device (e.g., module or policy filter).
Checks: C-59197r872501_chk

Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.

Fix: F-59140r872502_fix

Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"

a
The CA API Gateway must off-load audit records onto a different system or media than the system being audited.
AU-4 - Low - CCI-001851 - V-255525 - SV-255525r961860_rule
RMF Control
AU-4
Severity
Low
CCI
CCI-001851
Version
CAGW-DM-000350
Vuln IDs
  • V-255525
  • V-71569
Rule IDs
  • SV-255525r961860_rule
  • SV-86193
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.
Checks: C-59198r872504_chk

Verify by confirming the following lines are part of "rsyslogd.conf": # auditd audit.log $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor Further verify that this line is also part of the rsyslogd.conf file: local6.* @@loghost.ca.com If "rsyslogd.conf" does not contain the above lines, this is a finding.

Fix: F-59141r872505_fix

Setup steps: Configure rsyslogd to monitor "/var/log/auditd/auditd.log" file for updates by adding stanza: # auditd audit.log $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor to the "/etc/rsyslogd.conf" file. Note: This creates audit log entries for facility "local6" and priority "info." This can be changed to suite. Configure "rsyslogd" to forward this combination (local6.info) to the appropriate loghost by adding logging rule to the rule section of the "rsyslogd.conf" file: local6.* @@loghost.ca.com Note that the syntax "@@loghost.ca.com" means that the records are forwarded via TCP. A single "@" before the remote loghost would mean the records are forwarded via UDP.

b
The CA API Gateway must generate audit log events for a locally developed list of auditable events.
CM-6 - Medium - CCI-000366 - V-255526 - SV-255526r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000360
Vuln IDs
  • V-255526
  • V-71571
Rule IDs
  • SV-255526r961863_rule
  • SV-86195
Auditing and logging are key components of any security architecture. Logging the actions of specific events provides a means to investigate an attack; to recognize resource utilization or capacity thresholds; or to identify an improperly configured network device. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.
Checks: C-59199r872507_chk

Examine "/etc/audit/audit.rules" to confirm any custom developed rules are contained within the file. If the "/etc/audit/audit.rules" does not contain the custom developed rules within the file, this is a finding.

Fix: F-59142r872508_fix

The Gateway relies on the standard Linux audit subsystem. The subsystem is configurable by modifying /etc/audit/audit.rules. Custom rules can be added to this file. See the Linux man-page for audit.rules(7) for detail about specifying custom rules.

b
The CA API Gateway must employ automated mechanisms to detect the addition of unauthorized components or devices.
CM-6 - Medium - CCI-000366 - V-255527 - SV-255527r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000370
Vuln IDs
  • V-255527
  • V-71575
Rule IDs
  • SV-255527r961863_rule
  • SV-86199
This requirement addresses configuration management of the network device. The network device must automatically detect the installation of unauthorized software or hardware onto the device itself. Monitoring may be accomplished on an ongoing basis or by periodic monitoring. Automated mechanisms can be implemented within the network device and/or in another separate information system or device. If the addition of unauthorized components or devices is not automatically detected, then such components or devices could be used for malicious purposes, such as transferring sensitive data to removable media for compromise.
Checks: C-59200r872510_chk

Verify "/etc/modprobe.d/ssg-harden.conf" contents are: install dccp /bin/false install sctp /bin/false install rds /bin/false install tipc /bin/false install net-pf-31 /bin/false install bluetooth /bin/false install usb-storage /bin/false options ipv6 disable=1 If the "/etc/modprobe.d/ssg-harden.conf" contents do not contain the above, this is a finding.

Fix: F-59143r872511_fix

Set contents of "/etc/modprobe.d/ssg-harden.conf" file to: install dccp /bin/false install sctp /bin/false install rds /bin/false install tipc /bin/false install net-pf-31 /bin/false install bluetooth /bin/false install usb-storage /bin/false options ipv6 disable=1

b
The CA API Gateway must employ automated mechanisms to assist in the tracking of security incidents.
CM-6 - Medium - CCI-000366 - V-255528 - SV-255528r961863_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
CAGW-DM-000400
Vuln IDs
  • V-255528
  • V-71573
Rule IDs
  • SV-255528r961863_rule
  • SV-86197
Despite the investment in perimeter defense technologies, enclaves are still faced with detecting, analyzing, and remediating network breaches and exploits that have made it past the network device. An automated incident response infrastructure allows network operations to immediately react to incidents by identifying, analyzing, and mitigating any network device compromise. Incident response teams can perform root cause analysis, determine how the exploit proliferated, and identify all affected nodes, as well as contain and eliminate the threat. The network device assists in the tracking of security incidents by logging detected security events. The audit log and network device application logs capture different types of events. The audit log tracks audit events occurring on the components of the network device. The application log tracks the results of the network device content filtering function. These logs must be aggregated into a centralized server and can be used as part of the organization's security incident tracking and analysis.
Checks: C-59201r872513_chk

Verify the CA API Gateway forwards all log audit log messages to the central log server. Within the "/etc/rsyslog.conf" file, confirm a rule in the format "*.* @@loghost.log.com" is in the ruleset section. If the CA API Gateway "/etc/rsyslog.conf" file does not have a rule in the format "*.* @@loghost.log.com" in the ruleset section, this is a finding.

Fix: F-59144r872514_fix

Configure the CA API Gateway to forward all log audit log messages to the central log server. - Log in to CA API Gateway as root. - Open "/etc/rsyslog.conf" for editing. - Add a rule "*.* @@loghost.log.com" to the ruleset section of the rsyslogd.conf file.

c
The CA API NDM must be using a version supported by the vendor.
CM-6 - High - CCI-000366 - V-264435 - SV-264435r992102_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
CAGW-DM-000380
Vuln IDs
  • V-264435
Rule IDs
  • SV-264435r992102_rule
Systems running an unsupported software/firmware version lack current security fixes required to mitigate the risks associated with recent vulnerabilities.
Checks: C-68349r992100_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-68257r992101_fix

Upgrade to a version supported by the vendor.