{"stig":{"title":"CA API Gateway NDM Security Technical Implementation Guide","version":"1","release":"2"},"checks":[{"vulnId":"V-255500","ruleId":"SV-255500r961863_rule","severity":"high","ruleTitle":"The CA API Gateway must be installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.","description":"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.","checkContent":"Verify the CA API Gateway is installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.\n\nIf the CA API Gateway is not installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher, this is a finding.","fixText":"Configure the CA API Gateway to be installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.","ccis":["CCI-000366"]},{"vulnId":"V-255501","ruleId":"SV-255501r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must employ RADIUS + LDAPS or LDAPS to centrally manage authentication settings.","description":"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.\n\nUse 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.","checkContent":"Review the CA API Gateway configuration to determine if RADIUS + LDAPS or LDAPS is employed to centrally manage authentication settings.\n\n- SSH to SSG as a member of ssgconfig.\n- Select: 1) Configure system settings, 6) Export configuration.\n- Export configuration to \"file\".\n- Go back to main menu, select 3) Use a privileged shell (root).\n- Navigate to /home/ssgconfig, open \"file\".\n- Check \"authenticationType\".\n\nIf \"authenticationType\" is not RADIUS_WITH_LDAP or RADIUS_WITH_LDAPS, this is a finding.","fixText":"Configure the CA API Gateway to employ RADIUS + LDAPS or LDAPS to centrally manage authentication settings.\n\nPrerequisites:\n\n- RADIUS server (for the RADIUS+LDAPS configuration)\n- LDAPS server with posixAccount objects for user logins\n- LDAPS server CA certificate available via HTTP at a specific URL\n- LDAP account for the SSG to bind and lookup info\n- posixUser object within LDAP contain object (OU)\n- 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.\n\nConfigure SSG to use LDAPS.\n\n- SSH to SSG as a member of ssgconfig\n- Select: 1) Configure system settings, 4) Configure authentication method.\n- Select: 2) ldap.\n- Walk through configuration steps, providing requisite information ensuring:\n - Select LDAPS (secure) \"y\".\n - Select the appropriate TLS port (636 is the default).\n - Disable anonymous bind.\n - Specify the URL containing the PEM of the CA certificate to download.\n - Specify that the SSG LDAP client \"demand\" the server's certificate.\n - Set the user filter to use either a specific gidNumber or a group DN.\n - Set the posixAccount attribute to use as login name (uid).\n\nConfirmation configuration should be approximately:\n\nAuthentication Type: LDAP_ONLY\n\nLabel | Value \n---------------------------------------------------------------------------------------------\nSecure | true \nActiveDirectory | false \nServer | smldap.l7tech.com \nBaseDn | dc=l7tech,dc=com \nPort | 636 \nAnonymousBind | false \nBindDn | cn=Manager,dc=l7tech,dc=com \nBindPassword | \nObject for finding the password for users | ou=posixAccounts \nObject class name of users in the LDAP | posixAccount \nServer CaCert File | /etc/openldap/cacerts/ldapcacert \nCertificate Action | DEMAND \nGroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com\nPAM login attribute | uid \n\nFinally, apply configuration and restart the SSG.\n\nConfigure SSG to use RADIUS+LDAPS.\n\n- SSH to SSG as ssgconfig.\n- Select: 1) Configure system settings, 4) Configure authentication method.\n- Select: 4) ldap_radius.\n- Walk through configuration steps, providing requisite information ensuring:\n - Enter the RADIUS server's address and secret.\n - Complete the LDAP questions as for the LDAPS only case (above).\n\nConfirmation configuration should be approximately:\n\nAuthentication Type: RADIUS_WITH_LDAP\n\nLabel | Value \n-------------------------------\nServer | freerad217.l7tech.com\nSecret | \nTimeout | 3 \n\nLabel | Value \n---------------------------------------------------------------------------------------------\nSecure | true \nActiveDirectory | false \nServer | smldap.l7tech.com \nBaseDn | dc=l7tech,dc=com \nPort | 636 \nAnonymousBind | false \nBindDn | cn=Manager,dc=l7tech,dc=com \nBindPassword | \nObject for finding the password for users | ou=posixAccounts \nObject class name of users in the LDAP | posixAccount \nServer CaCert Url | http://localhost:8080/cert \nCertificate Action | DEMAND \nGroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com\nPAM login attribute | uid","ccis":["CCI-000366","CCI-000370"]},{"vulnId":"V-255502","ruleId":"SV-255502r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must shut down by default upon audit failure (unless availability is an overriding concern).","description":"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. \n\nWhen availability is an overriding concern, other approved actions in response to an audit failure are as follows: \n\n(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.\n(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.","checkContent":"Verify the \"/etc/audit/auditd.conf\" file contains the lines: \n\ndisk_full_action = HALT\ndisk_error_action = HALT\n\nIf \"/etc/audit/auditd.conf\" does not contain these lines, this is a finding.","fixText":"Configure the \"auditd\" configuration file \"/etc/audit/auditd.conf\" by adding these lines: \n\ndisk_full_action = HALT\ndisk_error_action = HALT","ccis":["CCI-000140","CCI-000366"]},{"vulnId":"V-255503","ruleId":"SV-255503r961863_rule","severity":"low","ruleTitle":"The CA API Gateway must forward all log audit log messages to the central log server.","description":"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. \n\nThis helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.","checkContent":"Verify the CA API Gateway forwards all log audit log messages to the central log server. \n\nWithin the \"/etc/rsyslog.conf\" file, confirm a rule in the format \"*.* @@loghost.log.com\" is in the ruleset section.\n\nIf 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.","fixText":"Configure the CA API Gateway to forward all audit log messages to the central log server.\n\n- Log in to CA API Gateway as root.\n- Open \"/etc/rsyslog.conf\" for editing.\n- Add a rule \"*.* @@loghost.log.com\" to the ruleset section of the \"rsyslogd.conf\" file.","ccis":["CCI-001348","CCI-000366"]},{"vulnId":"V-255504","ruleId":"SV-255504r984088_rule","severity":"medium","ruleTitle":"The CA API Gateway must not have any default manufacturer passwords when deployed.","description":"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. \n\nMany 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.","checkContent":"Verify login as \"root\" (at the console) and \"ssgconfig\" have non-default passwords. \n\nThe default password for \"root\" is \"7layer\" and the default password for \"ssgconfig\" is \"7layer\".\n\nIf root or ssgconfig use default passwords, this is a finding.","fixText":"Use the \"passwd\" command to set non-default passwords.","ccis":["CCI-002041"]},{"vulnId":"V-255505","ruleId":"SV-255505r960969_rule","severity":"medium","ruleTitle":"In the event the authentication server is unavailable, there must be one local account of last resort.","description":"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.\n\nThe 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.","checkContent":"Verify the \"root\" (or its equivalent, renamed account) is listed in the password configuration files.\n\nIf the \"root\" account is not listed in the password configuration files, this is a finding.","fixText":"Configure the \"root\" account as the local account of last resort. \n\nDisable the \"ssgconfig\" account by destroying its password and making the login shell \"/sbin/nologin\".","ccis":["CCI-001358","CCI-002111"]},{"vulnId":"V-255506","ruleId":"SV-255506r984092_rule","severity":"medium","ruleTitle":"The CA API Gateway must enforce a minimum 15-character password length.","description":"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.\n\nThe 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.","checkContent":"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: \n\nPASS_MIN_LEN 15.\n\nIf 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.","fixText":"In order to change the default setting: \n\n- Log in to Gateway via SSH.\n- Open /etc/login.defs.\n- Change the value for PASS_MIN_LENGTH to desired value.\n\nThen:\n\n- Change the PASS_MIN_LENGTH field to desired value in the following files:\n-- /etc/pam.d/password-auth\n-- /etc/pam.d/password-auth-ac\n-- /etc/pam.d/system-auth\n-- /etc/pam.d/system-auth-ac\n\nNote: Must be a value of \"15\" or greater.","ccis":["CCI-000205"]},{"vulnId":"V-255507","ruleId":"SV-255507r984101_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nThe 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.","checkContent":"Verify the password attribute \"difok\" field is set to \"8\" in the following files: \n\n-- /etc/pam.d/password-auth\n-- /etc/pam.d/password-auth-ac\n\nIf the password attribute \"difok\" field is not set to \"8\" in these files, this is a finding.","fixText":"Set the password attribute \"difok\" field is set to \"8\" in the following files: \n\n-- /etc/pam.d/password-auth\n-- /etc/pam.d/password-auth-ac","ccis":["CCI-000195"]},{"vulnId":"V-255508","ruleId":"SV-255508r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must automatically remove or disable emergency accounts, except the emergency administration account, after 72 hours.","description":"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. \n\nIf 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.\n\nIt 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.","checkContent":"Verify expiry of account with command: \n\nchage -l \"USERNAME\"\n\nand look at the \"Account expires\" line for expiry date.\n\nIf the expiry date is more than \"72\" hours after emergency account creation, this is a finding.","fixText":"For existing accounts, set expiry time of an account using command: \n\nchage -E \"YYYY-MM-DD\" \"USERNAME\n\nFor new accounts, create using command: \n\nuseradd -e USERNAME\n\nwhere the expiry date in YYYY-MM-DD format is when you wish the account to expire.","ccis":["CCI-001682","CCI-000366"]},{"vulnId":"V-255509","ruleId":"SV-255509r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must activate a system alert message, send an alarm, and/or automatically shut down when a component failure is detected.","description":"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.","checkContent":"Verify \"/usr/local/bin/failtest\" script exists and is executable. \n\nVerify crontab runs \"/usr/local/bin/failtest\" every minute by checking cron's logfile \"/var/log/cron\".\n\nIf \"/usr/local/bin/failtest\" does not exist or it is not executable, this is a finding.","fixText":"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","ccis":["CCI-000366","CCI-001328"]},{"vulnId":"V-255510","ruleId":"SV-255510r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must notify System Administrators (SAs) and Information System Security Officers (ISSMs) when accounts are created, or enabled when previously disabled.","description":"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.\n\nIn 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.","checkContent":"Verify \"/usr/local/bin/alerter\" script exists and is executable. \n\nVerify crontab runs \"/usr/local/bin/alerter\" every minute by checking cron's logfile /var/log/cron.\n\nIf the \"/usr/local/bin/alerter\" script does not exist, this is a finding. \n\nIf the \"/usr/local/bin/alerter\" script does not run every minute as a cron job, this is a finding. \n\nAn 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. \n\nThis authentication configuration is placed in \"/etc/snmp/snmp.conf\":\n-----------------------------------\ndefSecurityLevel authPriv\ndefAuthType SHA\ndefPrivType AES\ndefAuthPassphrase {password123}\ndefPrivPassphrase {password123}\n-----------------------------------\n\nThis snmp alerter script is placed in \"/usr/local/bin/alerter script\":\n--------\n#!/bin/bash\n\n#\n# This script implements watching for changes in a system that may indicate unauthorized\n# changes have been made to the system\n#\n# It is designed to be run as \"alerter -w\" to capture the current configuration and\n# then to be run out of cron on a regular basis as \"alerter -c\" which then compares the\n# current configuration to the previously captured configuration. If the configuration\n# has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command.\n# SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security\n# implemented on the SNMP Management Server.\n#\n# The script uses /var/run/alerter as a base directory to capture filesystem timestamps and\n# the installed RPM software list.\n\nSNMPUSER=myuser\nSNMPENGINEID=0x0102030405\nSNMPHOST=rsbfreebsd.ca.com\n\nSNMPENTNUM=\"1.3.6.1.4.1.17304\"\nSNMPNOTIF=\".7.3.128\"\nSNMPBASECMD=\"snmptrap -v 3 -n \\\"\\\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s\"\n\nALERTER_ROOT=/var/run/alerter\n\nACCOUNTFILES=(\"/etc/passwd\" \"/etc/shadow\" \"/etc/group\")\n\nTSFILE=timestamps\nRPMFILE=rpmlist\n\nfunction usage {\n echo \"$0 [-w | -c]\"\n echo \" -w - Write data\"\n echo \" -c - Compare current to data\"\n echo \" (at least one must be selected)\"\n echo\n}\n\nfunction writeTsSummary {\n for file in ${ACCOUNTFILES[*]} \n do\n ts=$(stat -c '%Y' $file)\n echo $file $ts >> $ALERTER_ROOT/$TSFILE\n done\n}\n\nfunction writeRpmSummary {\n rpm -qa >> $ALERTER_ROOT/$RPMFILE\n}\n\nfunction writeSummaries {\n\n if [ ! -d $ALERTER_ROOT ]\n then\n mkdir $ALERTER_ROOT\n fi\n\n rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE\n\n writeTsSummary\n writeRpmSummary\n}","fixText":"Install and configure (setup SNMP trap dest/authentication) alerter script in /usr/local/bin/alerter. \n\nRun \"/usr/local/bin/alerter -w\" to write initial config to filesystem. \n\nConfigure cron to run \"/usr/local/bin/alerter -c\" every minute.\n\nAn 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. \n\nThis authentication configuration is placed in \"/etc/snmp/snmp.conf\":\n-----------------------------------\n\ndefSecurityLevel authPriv\ndefAuthType SHA\ndefPrivType AES\ndefAuthPassphrase {password123}\ndefPrivPassphrase {password123}\n-----------------------------------\n\nThis snmp alerter script is placed in \"/usr/local/bin/alerter script\":\n--------\n\n#!/bin/bash\n\nThis 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. \n\nIf the configuration has changed, an SNMP TRAP is sent using the \"SNMPBASECMD\" variable as the base \"snmptrap\" command. \n# SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security\n# implemented on the SNMP Management Server.\n#\n# The script uses \"/var/run/alerter\" as a base directory to capture filesystem timestamps and\n# the installed RPM software list.\n\nSNMPUSER=myuser\nSNMPENGINEID=0x0102030405\nSNMPHOST=rsbfreebsd.ca.com\n\nSNMPENTNUM=\"1.3.6.1.4.1.17304\"\nSNMPNOTIF=\".7.3.128\"\nSNMPBASECMD=\"snmptrap -v 3 -n \\\"\\\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s\"\n\nALERTER_ROOT=/var/run/alerter\n\nACCOUNTFILES=(\"/etc/passwd\" \"/etc/shadow\" \"/etc/group\")\n\nTSFILE=timestamps\nRPMFILE=rpmlist\n\nfunction usage {\n echo \"$0 [-w | -c]\"\n echo \" -w - Write data\"\n echo \" -c - Compare current to data\"\n echo \" (at least one must be selected)\"\n echo\n}\n\nfunction writeTsSummary {\n for file in ${ACCOUNTFILES[*]} \n do\n ts=$(stat -c '%Y' $file)\n echo $file $ts >> $ALERTER_ROOT/$TSFILE\n done\n}\n\nfunction writeRpmSummary {\n rpm -qa >> $ALERTER_ROOT/$RPMFILE\n}\n\nfunction writeSummaries {\n\n if [ ! -d $ALERTER_ROOT ]\n then\n mkdir $ALERTER_ROOT\n fi\n\n rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE\n\n writeTsSummary\n writeRpmSummary\n}","ccis":["CCI-002132","CCI-000366"]},{"vulnId":"V-255511","ruleId":"SV-255511r961863_rule","severity":"medium","ruleTitle":"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.","description":"Protecting access authorization information (i.e., access control decisions) ensures that authorization information cannot be altered, spoofed, or otherwise compromised during transmission.\n\nIn 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.","checkContent":"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 >> 4) Configure authentication method.\n\nSelect the appropriate ldap/ldap+radius configuration and then verify its settings by continuing the menu process until it completes.\n\nIf LDAP or RADIUS+LDAP is not configured for all administrative accounts, this is a finding.","fixText":"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.\n\nSelect the appropriate ldap/ldap+radius configuration and then set the appropriate settings for your environment by following the menu process until it completes.","ccis":["CCI-000366","CCI-002353"]},{"vulnId":"V-255512","ruleId":"SV-255512r987682_rule","severity":"low","ruleTitle":"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.","description":"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. \n\nMultiple 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.\n\nDoD-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.","checkContent":"Verify the Gateway (using \"ssgconfig\") is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and verify the list of ntp servers is correct.\n\nIf the CA API Gateway is not configured to use multiple ntp sources, this is a finding.","fixText":"Configure the Gateway using \"ssgconfig\" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.","ccis":["CCI-000366","CCI-001893"]},{"vulnId":"V-255513","ruleId":"SV-255513r961443_rule","severity":"low","ruleTitle":"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).","description":"If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.\n\nTime 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.","checkContent":"Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and verify the list of ntp servers is correct.\n\nIf the CA API Gateway is not configured to use multiple ntp sources, this is a finding.","fixText":"Configure the Gateway using \"ssgconfig\" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.","ccis":["CCI-001890"]},{"vulnId":"V-255514","ruleId":"SV-255514r961446_rule","severity":"low","ruleTitle":"The CA API Gateway must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.","description":"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.","checkContent":"Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and verify the list of ntp servers is correct.\n\nIf the CA API Gateway is not configured to use multiple ntp sources, this is a finding.","fixText":"Configure the Gateway using ssgconfig to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. \n\nWalk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.","ccis":["CCI-001889"]},{"vulnId":"V-255515","ruleId":"SV-255515r961863_rule","severity":"medium","ruleTitle":"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.","description":"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.","checkContent":"Verify \"/usr/local/bin/alerter\" script exists and is executable. \n\nVerify crontab runs \"/usr/local/bin/alerter\" every minute by checking cron's logfile /var/log/cron.\n\nIf the \"/usr/local/bin/alerter\" script does not exist, this is a finding. \n\nIf the \"/usr/local/bin/alerter\" script does not run every minute as a cron job, this is a finding. \n\nAn 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. \n\nThis authentication configuration is placed in \"/etc/snmp/snmp.conf\":\n-----------------------------------\ndefSecurityLevel authPriv\ndefAuthType SHA\ndefPrivType AES\ndefAuthPassphrase {password123}\ndefPrivPassphrase {password123}\n-----------------------------------\n\nThis snmp alerter script is placed in \"/usr/local/bin/alerter script\":\n--------\n#!/bin/bash\n\n#\n# This script implements watching for changes in a system that may indicate unauthorized\n# changes have been made to the system\n#\n# It is designed to be run as \"alerter -w\" to capture the current configuration and\n# then to be run out of cron on a regular basis as \"alerter -c\" which then compares the\n# current configuration to the previously captured configuration. If the configuration\n# has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command.\n# SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security\n# implemented on the SNMP Management Server.\n#\n# The script uses /var/run/alerter as a base directory to capture filesystem timestamps and\n# the installed RPM software list.\n\nSNMPUSER=myuser\nSNMPENGINEID=0x0102030405\nSNMPHOST=rsbfreebsd.ca.com\n\nSNMPENTNUM=\"1.3.6.1.4.1.17304\"\nSNMPNOTIF=\".7.3.128\"\nSNMPBASECMD=\"snmptrap -v 3 -n \\\"\\\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s\"\n\nALERTER_ROOT=/var/run/alerter\n\nACCOUNTFILES=(\"/etc/passwd\" \"/etc/shadow\" \"/etc/group\")\n\nTSFILE=timestamps\nRPMFILE=rpmlist\n\nfunction usage {\n echo \"$0 [-w | -c]\"\n echo \" -w - Write data\"\n echo \" -c - Compare current to data\"\n echo \" (at least one must be selected)\"\n echo\n}\n\nfunction writeTsSummary {\n for file in ${ACCOUNTFILES[*]} \n do\n ts=$(stat -c '%Y' $file)\n echo $file $ts >> $ALERTER_ROOT/$TSFILE\n done\n}\n\nfunction writeRpmSummary {\n rpm -qa >> $ALERTER_ROOT/$RPMFILE\n}\n\nfunction writeSummaries {\n\n if [ ! -d $ALERTER_ROOT ]\n then\n mkdir $ALERTER_ROOT\n fi\n\n rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE\n\n writeTsSummary\n writeRpmSummary\n}","fixText":"Install and configure (setup SNMP trap dest/authentication) alerter script in \"/usr/local/bin/alerter\". \n\nRun \"/usr/local/bin/alerter -w\" to write initial config to filesystem. \n\nConfigure cron to run \"/usr/local/bin/alerter -c\" every minute.\n\nAn 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. \n\nThis authentication configuration is placed in \"/etc/snmp/snmp.conf\":\n-----------------------------------\ndefSecurityLevel authPriv\ndefAuthType SHA\ndefPrivType AES\ndefAuthPassphrase {password123}\ndefPrivPassphrase {password123}\n-----------------------------------\n\nThis snmp alerter script is placed in \"/usr/local/bin/alerter script\":\n--------\n#!/bin/bash\n\n#\n# This script implements watching for changes in a system that may indicate unauthorized\n# changes have been made to the system\n#\n# It is designed to be run as \"alerter -w\" to capture the current configuration and\n# then to be run out of cron on a regular basis as \"alerter -c\" which then compares the\n# current configuration to the previously captured configuration. If the configuration\n# has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command.\n# SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security\n# implemented on the SNMP Management Server.\n#\n# The script uses /var/run/alerter as a base directory to capture filesystem timestamps and\n# the installed RPM software list.\n\nSNMPUSER=myuser\nSNMPENGINEID=0x0102030405\nSNMPHOST=rsbfreebsd.ca.com\n\nSNMPENTNUM=\"1.3.6.1.4.1.17304\"\nSNMPNOTIF=\".7.3.128\"\nSNMPBASECMD=\"snmptrap -v 3 -n \\\"\\\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s\"\n\nALERTER_ROOT=/var/run/alerter\n\nACCOUNTFILES=(\"/etc/passwd\" \"/etc/shadow\" \"/etc/group\")\n\nTSFILE=timestamps\nRPMFILE=rpmlist\n\nfunction usage {\n echo \"$0 [-w | -c]\"\n echo \" -w - Write data\"\n echo \" -c - Compare current to data\"\n echo \" (at least one must be selected)\"\n echo\n}\n\nfunction writeTsSummary {\n for file in ${ACCOUNTFILES[*]} \n do\n ts=$(stat -c '%Y' $file)\n echo $file $ts >> $ALERTER_ROOT/$TSFILE\n done\n}\n\nfunction writeRpmSummary {\n rpm -qa >> $ALERTER_ROOT/$RPMFILE\n}\n\nfunction writeSummaries {\n\n if [ ! -d $ALERTER_ROOT ]\n then\n mkdir $ALERTER_ROOT\n fi\n\n rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE\n\n writeTsSummary\n writeRpmSummary\n}","ccis":["CCI-001811","CCI-000366"]},{"vulnId":"V-255516","ruleId":"SV-255516r961506_rule","severity":"low","ruleTitle":"The CA API Gateway must authenticate NTP endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.","description":"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.\n\nA 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).\n\nBecause 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.","checkContent":"Verify \"server\" lines in the \"/etc/ntp.conf\" file are all marked with \"autokey\". Perform the command \"ntpq -p\" to show peer functioning.\n\nIf the \"server\" lines in the \"/etc/ntp.conf\" file are not marked with \"autokey\", this is a finding. \n\nIf the command \"ntpq -p\" does not show peers functioning, this is a finding.","fixText":"Configure Gateway to use public key (autokey in NTP terminology) authentication. See: http://support.ntp.org/bin/view/Support/ConfiguringAutokey","ccis":["CCI-001967"]},{"vulnId":"V-255517","ruleId":"SV-255517r961506_rule","severity":"medium","ruleTitle":"The CA API Gateway must authenticate SNMP endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.","description":"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.\n\nA 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).\n\nBecause 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.","checkContent":"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\"\n\nIf SNMP Version 3 is not being used, this is a finding.","fixText":"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\"","ccis":["CCI-001967"]},{"vulnId":"V-255518","ruleId":"SV-255518r961506_rule","severity":"medium","ruleTitle":"The CA API Gateway must authenticate RADIUS endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.","description":"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.\n\nA 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).\n\nBecause 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.","checkContent":"Using the \"ssgconfig\" menu subsystem, confirm RADIUS has been configured via 1) Configure system settings >> 4) Configure authentication method item 3 or 4. \n\nConfirm password is set to \"Enter the RADIUS shared secret []\".\n\nIf RADIUS is not correctly configured, this is a finding.","fixText":"Using the ssgconfig menu subsystem, confirm RADIUS has been configured via 1) Configure system settings >> 4) Configure authentication method item 3 or 4. \n\nConfigure radius/ladap_radius as required.","ccis":["CCI-001967"]},{"vulnId":"V-255519","ruleId":"SV-255519r961506_rule","severity":"medium","ruleTitle":"The CA API Gateway must authenticate LDAPS endpoint devices before establishing a network connection using bidirectional authentication that is cryptographically based.","description":"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.\n\nA 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).\n\nBecause 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.","checkContent":"Using the \"ssgconfig\" menu subsystem, confirm LDAP (Secure) has been configured via 1) Configure system settings >> 4) Configure authentication method item 2 or 4. \n\nConfirm the answer to the question \"Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:\" is \"y\". \n\nEnsure 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.\n\nIf the LDAP is not correctly configured, this is a finding.","fixText":"Using the \"ssgconfig\" menu subsystem, set LDAP (Secure) by 1) Configure system settings >> 4) Configure authentication method item 2 or 4. \n\nSet the answer to the question \"Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:\" to \"y\". \n\nSet 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.","ccis":["CCI-001967"]},{"vulnId":"V-255520","ruleId":"SV-255520r961506_rule","severity":"medium","ruleTitle":"The CA API Gateway must obtain LDAPS server certificates securely to use bidirectional authentication that is cryptographically based.","description":"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.\n\nA 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).\n\nBecause 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.","checkContent":"Verify the LDAPS server certificate is in \"/etc/openldap/cacerts\". Verify TLS_REQCERT is set to demand in \"/etc/openldap/ldap.conf\".\n\nIf the LDAPS server certificate is not in \"/etc/openldap/cacerts\", this is a finding. \n\nIf \"TLS_REQCERT\" is not set to demand in \"/etc/openldap/ldap.conf\", this is a finding.","fixText":"Configure LDAPS/LDAPS+RADIUS to use LDAPS server certificates for bidirectional authentication that is cryptographically based.\n\nPlace the LDAPS server certificate in \"/etc/openldap/cacerts\". \n\nSet \"TLS_REQCERT\" to demand in \"/etc/openldap/ldap.conf\".","ccis":["CCI-001967"]},{"vulnId":"V-255521","ruleId":"SV-255521r961620_rule","severity":"medium","ruleTitle":"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.","description":"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.\n\nThis 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.\n\nThe 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).","checkContent":"Verify the CA API Gateway drops packets by default and only puts non-Gateway services on trusted interfaces.\n \nCheck for the following lines in \"/etc/sysconfig/iptables\":\n:INPUT DROP [0:0]\n:FORWARD DROP [0:0]\n[0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT\n \nCheck for the following lines in \"/etc/sysconfig/ip6tables\":\n:INPUT DROP [0:0]\n[0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT\n[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT\n \nIf the CA API Gateway does not drop packets by default or puts non-Gateway services on untrusted interfaces, this is a finding.\n \nVerify the CA API Gateway logs and drops TCP packets with bad flags.\n \nCheck for the following lines in \"/etc/sysconfig/iptables\":\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags\n[0:0] -A badflags -m limit --limit 15/min -j LOG --log-prefix \"Badflags:\"\n[0:0] -A badflags -j DROP\n \nCheck for the following lines in \"/etc/sysconfig/ip6tables\":\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags6\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags6\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags6\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags6\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags6\n[0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags6\n[0:0] -A badflags6 -m limit --limit 15/min -j LOG --log-prefix \"Badflags6:\"\n[0:0] -A badflags6 -j DROP\n \nIf the CA API Gateway does not log and drop TCP packets with bad flags, this is a finding.\n \nVerify the CA API Gateway only allows certain ICMPs and rate limits pings.\n \nCheck for the following lines in \"/etc/sysconfig/iptables\":\n[0:0] -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT\n[0:0] -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT\n[0:0] -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT\n[0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT\n[0:0] -A INPUT -p icmp -j badflags\n[0:0] -A OUTPUT -p icmp -m state --state INVALID -j DROP\n \nCheck for the following lines in \"/etc/sysconfig/ip6tables\":\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 1 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 3 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 129 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 128 -m limit --limit 2/sec -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 133 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 134 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 135 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 136 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 137 -j ACCEPT\n[0:0] -A INPUT -p icmpv6 -j badflags6\n \nIf the CA API Gateway does not only allow certain ICMPs and rate limits pings, this is a finding.","fixText":"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.","ccis":["CCI-002385"]},{"vulnId":"V-255522","ruleId":"SV-255522r961824_rule","severity":"medium","ruleTitle":"The CA API Gateway must generate audit records when successful/unsuccessful logon attempts occur.","description":"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.\n\nAudit records can be generated from various components within the network device (e.g., module or policy filter).","checkContent":"Confirm the CA API Gateway file \"/etc/audit/audit.rules\" is the file as distributed using command:\n\nrpm -Vf /etc/audit/audit.rules\n\nIf the string returned contains a \"5\" (ok: .......T., failure: S.5....T.), this is a finding.","fixText":"Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM:\n\nrpm -i \"RPMFILE\"","ccis":["CCI-000172"]},{"vulnId":"V-255523","ruleId":"SV-255523r961830_rule","severity":"medium","ruleTitle":"The CA API Gateway must generate audit records showing starting and ending time for administrator access to the system.","description":"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. \n\nAudit records can be generated from various components within the network device (e.g., module or policy filter).","checkContent":"Confirm the CA API Gateway file \"/etc/audit/audit.rules\" is the file as distributed using command:\n\nrpm -Vf /etc/audit/audit.rules\n\nIf the string returned contains a \"5\" (ok: .......T., failure: S.5....T.), this is a finding.","fixText":"Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM:\n\nrpm -i \"RPMFILE\"","ccis":["CCI-000172"]},{"vulnId":"V-255524","ruleId":"SV-255524r961833_rule","severity":"medium","ruleTitle":"The CA API Gateway must generate audit records when concurrent logons from different workstations occur.","description":"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.\n\nAudit records can be generated from various components within the network device (e.g., module or policy filter).","checkContent":"Confirm the CA API Gateway file \"/etc/audit/audit.rules\" is the file as distributed using command:\nrpm -Vf /etc/audit/audit.rules\n\nIf the string returned contains a \"5\" (ok: .......T., failure: S.5....T.), this is a finding.","fixText":"Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM:\n\nrpm -i \"RPMFILE\"","ccis":["CCI-000172"]},{"vulnId":"V-255525","ruleId":"SV-255525r961860_rule","severity":"low","ruleTitle":"The CA API Gateway must off-load audit records onto a different system or media than the system being audited.","description":"Information stored in one location is vulnerable to accidental or incidental deletion or alteration.\n\nOff-loading is a common process in information systems with limited audit storage capacity.","checkContent":"Verify by confirming the following lines are part of \"rsyslogd.conf\":\n\n# auditd audit.log\n$ModLoad imfile\n$InputFileName /var/log/audit/audit.log\n$InputFileTag tag_audit_log:\n$InputFileStateFile audit_log\n$InputFileSeverity info\n$InputFileFacility local6\n$InputRunFileMonitor\n\nFurther verify that this line is also part of the rsyslogd.conf file:\nlocal6.* @@loghost.ca.com\n\nIf \"rsyslogd.conf\" does not contain the above lines, this is a finding.","fixText":"Setup steps:\n\nConfigure rsyslogd to monitor \"/var/log/auditd/auditd.log\" file for updates by adding stanza:\n\n# auditd audit.log\n$ModLoad imfile\n$InputFileName /var/log/audit/audit.log\n$InputFileTag tag_audit_log:\n$InputFileStateFile audit_log\n$InputFileSeverity info\n$InputFileFacility local6\n$InputRunFileMonitor\n\nto the \"/etc/rsyslogd.conf\" file. \n\nNote: This creates audit log entries for facility \"local6\" and priority \"info.\" This can be changed to suite.\n\nConfigure \"rsyslogd\" to forward this combination (local6.info) to the appropriate loghost by adding logging rule to the rule section of the \"rsyslogd.conf\" file:\n\nlocal6.* @@loghost.ca.com\n\nNote that the syntax \"@@loghost.ca.com\" means that the records are forwarded via TCP.\n\nA single \"@\" before the remote loghost would mean the records are forwarded via UDP.","ccis":["CCI-001851"]},{"vulnId":"V-255526","ruleId":"SV-255526r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must generate audit log events for a locally developed list of auditable events.","description":"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.","checkContent":"Examine \"/etc/audit/audit.rules\" to confirm any custom developed rules are contained within the file.\n\nIf the \"/etc/audit/audit.rules\" does not contain the custom developed rules within the file, this is a finding.","fixText":"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. \n\nSee the Linux man-page for audit.rules(7) for detail about specifying custom rules.","ccis":["CCI-000366"]},{"vulnId":"V-255527","ruleId":"SV-255527r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must employ automated mechanisms to detect the addition of unauthorized components or devices.","description":"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.","checkContent":"Verify \"/etc/modprobe.d/ssg-harden.conf\" contents are:\n\ninstall dccp /bin/false\ninstall sctp /bin/false\ninstall rds /bin/false\ninstall tipc /bin/false\ninstall net-pf-31 /bin/false\ninstall bluetooth /bin/false\ninstall usb-storage /bin/false\noptions ipv6 disable=1\n\nIf the \"/etc/modprobe.d/ssg-harden.conf\" contents do not contain the above, this is a finding.","fixText":"Set contents of \"/etc/modprobe.d/ssg-harden.conf\" file to:\n\ninstall dccp /bin/false\ninstall sctp /bin/false\ninstall rds /bin/false\ninstall tipc /bin/false\ninstall net-pf-31 /bin/false\ninstall bluetooth /bin/false\ninstall usb-storage /bin/false\noptions ipv6 disable=1","ccis":["CCI-000366","CCI-000416"]},{"vulnId":"V-255528","ruleId":"SV-255528r961863_rule","severity":"medium","ruleTitle":"The CA API Gateway must employ automated mechanisms to assist in the tracking of security incidents.","description":"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.\n\nThe 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.","checkContent":"Verify the CA API Gateway forwards all log audit log messages to the central log server. \n\nWithin the \"/etc/rsyslog.conf\" file, confirm a rule in the format \"*.* @@loghost.log.com\" is in the ruleset section.\n\nIf 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.","fixText":"Configure the CA API Gateway to forward all log audit log messages to the central log server.\n\n- Log in to CA API Gateway as root.\n- Open \"/etc/rsyslog.conf\" for editing.\n- Add a rule \"*.* @@loghost.log.com\" to the ruleset section of the rsyslogd.conf file.","ccis":["CCI-000366","CCI-000833"]},{"vulnId":"V-264435","ruleId":"SV-264435r992102_rule","severity":"high","ruleTitle":"The CA API NDM must be using a version supported by the vendor.","description":"Systems running an unsupported software/firmware version lack current security fixes required to mitigate the risks associated with recent vulnerabilities.","checkContent":"This STIG is sunset and no longer updated.\n\nCompare the version running to the supported version by the vendor.\n\nIf the system is using an unsupported version from the vendor, this is a finding.","fixText":"Upgrade to a version supported by the vendor.","ccis":["CCI-000366"]}]}