{"stig":{"title":"Cisco ACI NDM Security Technical Implementation Guide","version":"1","release":"2"},"checks":[{"vulnId":"V-271916","ruleId":"SV-271916r1168349_rule","severity":"medium","ruleTitle":"The Cisco ACI must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC).","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 UTC or local time with an offset from UTC.","checkContent":"1. Navigate to System >> Settings.\n2. In the Navigation pane, click \"Date and Time\".\n3. Verify UTC is selected.\n\nIf the Cisco ACI is not configured to use the UTC time zone, this is a finding.","fixText":"Configure NTP servers to provide UTC time.\n\n1. Navigate to System >> Settings.\n2. In the Navigation pane, click \"Date and Time\".\n3. In the Work pane, choose \"Display Format, then click \"UTC\".\n4. Click \"Update\".","ccis":["CCI-001890"]},{"vulnId":"V-271917","ruleId":"SV-271917r1114333_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to authenticate SNMP messages using a FIPS-validated Keyed-Hash Message Authentication Code (HMAC).","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.","checkContent":"To show the current FIPS mode setting, use the show command from the CLI configuration mode.\n\napic1(config) show fips status\n\nIf FIPS mode is not set to \"Enable\", this is a finding.","fixText":"From the CLI configuration mode, enable FIPS mode on all nodes and then reboot all nodes to activate FIPS compliance. \n\napic1(config)# fips mode enable","ccis":["CCI-001967"]},{"vulnId":"V-271918","ruleId":"SV-271918r1168426_rule","severity":"medium","ruleTitle":"The Cisco ACI must display the Standard Mandatory DOD Notice and Consent Banner before granting access to the device.","description":"Display of the DOD-approved use notification before granting access to the Cisco ACI ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.\n\nSystem use notifications are required only for access via logon interfaces with human users.","checkContent":"1. Navigate to System >> System Alias and Banners.\n2. In the \"Work\" pane, verify the Controller CLI Banner and Switch CLI Banner are configured to display the text below.\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"\n\nIf the banner is not presented when the system administrators log in, this is a finding.","fixText":"The CLI banner is a simple text string to be printed at the terminal before the password prompt. A banner can be defined for the APIC CLI and a separate banner for the switch CLI. \n\n1. In the GUI menu bar, navigate to System >> System Alias and Banners.\n2. In the \"Work\" pane, copy and paste the banner below in the exact format for each banner type, and then click \"Submit\".\n\nThe banner must read exactly as follows:\n\n\"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.\"","ccis":["CCI-000048"]},{"vulnId":"V-271919","ruleId":"SV-271919r1168355_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to enforce the limit of three consecutive invalid logon attempts, after which time it must block any login attempt for 15 minutes.","description":"By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. \n\nFor Cisco ACI, when a user is in a locked-out state, the lockout is enforced in all nodes that are part of the fabric, including controllers and switches.","checkContent":"1. On the GUI menu bar, choose Admin >> AAA.\n2. In the Navigation pane, choose \"Security\".\n3. In the Work pane, choose the Default Settings >> Policy tab.\n4. Under Properties, verify the fields as follows:\n- For \"Lockout User after multiple failed login attempts\", choose \"Enable\".\n- For \"Number of failed attempts before user is locked out\", enter \"3\".\n- For \"Time period in which consecutive attempts were failed (m)\", enter \"15\" or an organization-defined value.\n- For \"Duration of lockout (m)\", enter \"15\".\n\nIf the Cisco ACI fabric is not configured to enforce the limit of three consecutive invalid logon attempts and lock out users for 15 minutes, this is a finding.","fixText":"1. On the GUI menu bar, choose Admin >> AAA.\n2. In the Navigation pane, choose \"Security\".\n3. In the Work pane, choose Default Settings >> Edit\n4. Under Properties, complete the fields as follows:\n- For \"Lockout User after multiple failed login attempts\", choose \"Enable\".\n- For \"Number of failed attempts before user is locked out\", enter \"3\".\n- For \"Time period in which consecutive attempts were failed (m)\", enter \"15\" (or an organization-defined value).\n- For \"Duration of lockout (m)\", enter \"15\".\n5. Click \"Submit\".","ccis":["CCI-000044"]},{"vulnId":"V-271920","ruleId":"SV-271920r1168358_rule","severity":"high","ruleTitle":"The Cisco ACI must be configured to prohibit the use of all unnecessary and/or nonsecure functions, ports, protocols, and/or services.","description":"To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable unused or unnecessary physical and logical ports/protocols on information systems.\n\nBy default, Cisco ACI only exposes two ports from the outside:\n- HTTPS (TCP 443) for GUI access and REST API access, on both the APIC and switches.\n- SSH (TCP 22) for CLI access, on both the APIC and switches.\n\nCisco ACI enables Link Layer Discovery Protocol (LLDP) by default to support zero-touch fabric provisioning. DOD sites may keep LLDP enabled on trusted interfaces for loop prevention and VMM integration. Sites must disable LLDP on interfaces facing untrusted networks.\n\nCisco ACI is designed not to run nonrequired services by default, as well as to limit remote management services or protocols that are active by default. Hence, there is no action required from an administrator standpoint to disable them. If any other protocol is required, such as SNMP, administrators must explicitly configure it.","checkContent":"From the APIC GUI:\n1. Navigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access. \n2. Navigate to Tenants >> mgmt >> Node Management EPGs >> Out-Of-Band EPG - Default.\n\nVerify insecure or unnecessary ports/protocols, services, and ciphers are disabled. This is the default.\n\nIf the Cisco ACI is configured to listen or run unnecessary and/or nonsecure functions, ports, protocols, and/or services, this is a finding.","fixText":"From the APIC GUI:\nNavigate to Fabric >> Fabric Policies >> Policies >> Pod >> Management Access. This will limit the ports the management plane is listening on. \n\nAdd an OOB contract to limit the mgmt interfaces to only accept the required port traffic.\nNavigate to Tenants >> mgmt >> Node Management EPGs >> Out-Of-Band EPG - Default.\n\nDisable insecure or unnecessary ports/protocols, services, and ciphers that have been enabled, such as HTTP, FTP, unauthorized TLS versions, and TELNET.","ccis":["CCI-000382"]},{"vulnId":"V-271921","ruleId":"SV-271921r1113817_rule","severity":"medium","ruleTitle":"The Cisco ACI must conduct backups of the configuration weekly or at an organization-defined frequency and store on a separate device.","description":"Information system backup is a critical step in maintaining data assurance and availability. Information system and security-related documentation contains information pertaining to system configuration and security settings. If this information were not backed up, and a system failure were to occur, the security settings would be difficult to reconfigure quickly and accurately. Maintaining a backup of information system and security-related documentation provides for a quicker recovery time when system outages occur. This control requires the Cisco ACI to support the organizational central backup process for user account information associated with the Cisco ACI. This function may be provided by the Cisco ACI itself; however, the preferred best practice is a centralized backup rather than each Cisco ACI performing discrete backups.\n\nWith ACI, all components of the ACI Fabric are treated as one entity (leaves, spines, APIC controllers). The ACI Fabric configuration, while made up of different managed objects, is combined into one tar/gz zipfile, which greatly improves the configuration backup process, as well as the configuration restoration process. Finally, the backups can be configured as one-time backup jobs, or they can be scheduled in a daily or weekly scheduler to export the entire Fabric configuration to a remote location (i.e., external server) using SCP, FTP, or SFTP. Cisco ACI allows administrators to perform on-demand and periodic snapshots. Those snapshots can be saved either locally or in a remote location. Cisco ACI configuration contains many sensitive details, including passwords and secrets. Therefore, backup configuration must be properly secured and stored in a secure remote location, ensuring that sensitive information on the configuration files is not disclosed. Set the AES passphrase immediately after fabric bring-up and store the passphrase in a safe location external to the APIC. This passphrase must be provided by the administrator to unencrypt the configuration backup needed to restore the fabric should a disaster happen.","checkContent":"From the APIC GUI, verify backups are being performed as required:\n1. Navigate to Admin >> Import/Export >> Export Policies >> Configuration >> Create Configuration Export Policy. \n2. Fill out the rest of the form and click \"Submit\".\n\nIf the Cisco ACI is not configured to conduct backups of the configuration weekly or at an organization-defined frequency and stored on a separate device, this is a finding.","fixText":"From the APIC GUI, create a remote location where the configuration will be stored:\n1. Navigate to Admin >> Import/Export >> Remote Locations >> Create Remote Location. \n2. Enable the global AES encryption setting and save the password in a secure location.\n3. Fill out the rest of the form and click \"Submit\".\n\nCreate a Scheduler policy for weekly backups:\n1. Navigate to Admin >> Schedulers >> Fabric >> Create Scheduler >> Create Trigger Scheduler.\n2. Fill out the rest of the form and click \"Submit\".\n\nCreate a Configuration Export Policy:  \n1. Navigate to Admin >> Import/Export >> Export Policies >> Configuration >> Create Configuration Export Policy. \n2. Fill out the rest of the form and click \"Submit\".","ccis":["CCI-000539"]},{"vulnId":"V-271922","ruleId":"SV-271922r1168360_rule","severity":"medium","ruleTitle":"The Cisco ACI must obtain its public key certificates from an appropriate certificate policy through an approved service provider.","description":"After the Cisco ACI is initialized, it uses the self-signed certificate as the SSL certificate for HTTPS. This self-signed certificate is neither appropriate nor approved for use in DOD.","checkContent":"From the GUI menu bar:\n1. Navigate to Admin >> AAA >> Security >> Certificate Authorities.\n2. Verify the Issuer is an approved CA.\n\nIf the Cisco ACI does not obtain its public key certificates from an approved certificate policy through an approved service provider, this is a finding.","fixText":"From the GUI menu bar:\n1. Navigate to Admin >> AAA >> Security >> Certificate Authorities.\n2. Complete the form to configure CA root certificate. \n3. Click \"Submit\".","ccis":["CCI-001159"]},{"vulnId":"V-271923","ruleId":"SV-271923r1114182_rule","severity":"medium","ruleTitle":"The Cisco ACI must use DOD-approved Network Time Protocol (NTP) sources that use authentication that is cryptographically based.","description":"If NTP is not authenticated, an attacker can introduce a rogue NTP server. This rogue server can then be used to send incorrect time information to Cisco ACIs, which will make log timestamps inaccurate and affect scheduled actions. NTP authentication is used to prevent this tampering by authenticating the time source.\n\nTime synchronization plays a critical role in the ACI fabric. From validating certificates, to keeping log files across devices consistent, it is strongly encouraged to sync the ACI fabric to redundant time sources. Simply creating an NTP policy does not apply it to the fabric. This policy will need to be updated to a \"Pod Policy\".\n\nDo not enable the NTP server option that allows the leaf switches to serve time requests to downstream endpoints. Using a Bridge Domain SVI (Subnet IP) as an NTP Source for downstream clients is not recommended. When a leaf switch is enabled as NTP server, it will respond on any interface. Issues can arise when attempting to use the SVI address of a leaf, rather than the management IP.","checkContent":"Review the NTP configuration to verify it is compliant:\n1. Navigate to Fabric >> Fabric Policies >> Fabric Security.\n2. Expand \"Policies\".\n3. Expand \"Pod\".\n4. Expand \"Date and Time\".\n5. Expand each \"Date and Time Policy\".\n6. Verify at least two DOD-approved time sources are configured.\n\nNote: 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.\n\nIf Cisco ACI fabric does not use DOD-approved NTP sources that use authentication that is cryptographically based, this is a finding.","fixText":"Configure NTP servers.\n\nCreate an NTP policy:\n1. Navigate to Fabric >> Quickstart, and then click \"Create an NTP Policy Link\".\n2. Fill out the form. \n- Provide a name for the policy.\n- Set the State to \"Enabled\". \n3. Click \"Next\" to define the NTP Sources. \n4. Define at least two DOD-approved time servers. Leave all the default options and click \"OK\". Refer to the note below.\n5. Navigate to Fabric >> Fabric Policies sub menu >> Pods >> Policy Groups folder to add the NTP Policy to the appropriate Fabric Pod Policy or group to assign to one or more Pods in the fabric.\n6. Right-click on the Policy Groups folder. Select an existing Pod Policy Group or create a new group.\n7. Select the policy for NTP created in the previous step. \n8. Navigate to Fabric >> Fabric Policies sub menu >> Pods >> Profiles >> Pod Profile >> default. If needed, with the default Pod Selector selected in the navigation pane, change the Fabric Policy Group to the one created in the previous step. \n\nNote: 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); USNO time servers; and/or the GPS. The secondary time source must be located in a different geographic region than the primary time source.","ccis":["CCI-001967"]},{"vulnId":"V-271924","ruleId":"SV-271924r1168362_rule","severity":"high","ruleTitle":"The Cisco APIC must be configured to use at least two authentication servers for the purpose of authenticating users prior to granting administrative access.","description":"Centralized management of authentication settings increases the security of remote and nonlocal access methods. This control is particularly important protection against the insider threat. With robust centralized management, audit records for administrator account access to the organization's Cisco ACIs can be more readily analyzed for trends and anomalies. The alternative method of defining administrator accounts on each device exposes the device configuration to remote access authentication attacks and system administrators with multiple authenticators for each Cisco ACI.\n\nAPIC policies manage the authentication, authorization, and accounting (AAA) functions of the Cisco ACI fabric. The combination of user privileges, roles, and domains with access rights inheritance enables administrators to configure AAA functions at the managed object level in a granular fashion. Creating a user and assigning a role to that user does not enable access rights. It is necessary to also assign the user to one or more security domains. By default, the ACI fabric includes two special pre-created domains:\n- \"All\" allows access to the entire MIT.\n- \"Infra\" allows access to fabric infrastructure objects/subtrees, such as fabric access policies.\n\nSatisfies: SRG-APP-000149-NDM-000247, SRG-APP-000001-NDM-000200","checkContent":"Review the AAA configuration:\n1. In the GUI, on the menu bar, choose Admin >> AAA.\n2. In the Navigation pane, click \"Authentication\".\n3. Review the configuration for the configured AAA providers.\n4. Review the configuration of the Login Domain(s) used by the site.\n\nIf the Cisco ACI is not configured to use at least two authentication servers for the purpose of authenticating users prior to granting administrative access, this is a finding.","fixText":"In the APIC, configure redundant RADIUS providers.\n1. On the menu bar, choose Admin >> AAA.\n2. In the Navigation pane, choose \"Authentication\".\n3. In the Work pane, choose \"Providers\",  and then click Actions >> Create Provider.\n4. In the Create Provider screen, enter the Hostname/IP Address, Description, and choose a RADIUS or TACACS+ as the realm from the drop-down list. Provide the configuration details.\n5. Repeat the above steps for at least one other AAA server.\n\nCreate the login domain for RADIUS:\n1. In the Navigation pane, choose AAA Authentication >> Login Domains.\n2. In the Work pane, choose Actions >> Create Login Domain.\n3. Specify the login domain name, description, realm, and provider group as appropriate.\n\nNote: The above configuration is an example using the RADIUS protocol; however, DOD sites may configure the options for RADIUS or TACACS+.","ccis":["CCI-000370","CCI-000765","CCI-000054"]},{"vulnId":"V-271926","ruleId":"SV-271926r1168364_rule","severity":"high","ruleTitle":"The Cisco ACI must be running an operating system release that is currently supported by the vendor.","description":"Cisco ACIs running an unsupported operating system lack current security fixes required to mitigate the risks associated with recent vulnerabilities.","checkContent":"To view the current firmware versions installed on the controllers and switches.\n\nNavigate to Admin >> Firmware.\n\nRefer to the Cisco APIC Upgrade/Downgrade Support Matrix for Cisco APIC upgrade and downgrade paths.\n\nIf the Cisco ACI fabric, leaf switches, or APIC components have an operating system release that is not currently supported by the vendor, this is a finding.","fixText":"Refer to the Cisco APIC Upgrade/Downgrade Support Matrix for Cisco APIC upgrade and downgrade paths.\n\nInstall a Cisco APIC Software Maintenance Upgrade Patch.3t\n\nUse the following procedure to install a software maintenance upgrade (SMU) patch on a Cisco APIC:\n1. Add the firmware image that corresponds to the SMU patch to the Cisco APIC. The patch will be listed along with any other firmware images (SMU patches and otherwise).\n2. Set up a controller firmware update. On the Version Selection screen, for the Update Type, choose \"Software Maintenance Upgrade (Install)\", then choose the SMU patch in the Select Firmware section.\n\nInstalling a Switch Software Maintenance Upgrade Patch.\n\nSMU patch installation or uninstallation uses the same update group as a regular firmware upgrade. Because one node can belong to only one update group, when an SMU patch is applied to a specific node, remove that node from the existing group and create a new group dedicated to the node so that other nodes are not impacted. When performing a regular firmware upgrade for the entire fabric, delete the dedicated update group used for the SMU patch installation and add the node back to one of the original groups. If all the nodes in the existing group need the SMU patch, reuse the same update group without creating a new update group.\n\n1. Add the firmware image that corresponds to the SMU patch to the Cisco APIC. The Cisco APIC lists the patch along with any other firmware images (SMU patches and otherwise).\n2. Set up a node firmware update. On the Version Selection screen, for the Update Type, choose \"Software Maintenance Upgrade (Install)\", then choose the SMU patch in the Select Firmware section. Click \"Begin Download\" in the Confirmation screen to download the patch to the selected switches. \n3. In the Firmware Upgrade Work pane, click the upgrade group that was created. The Node Firmware Update dialog displays with information for the upgrade group.\n4. When the status for the switches is \"Ready to Install\", click \"Actions\".\n\nInstall and Reload: The switches reboot after the SMU patch gets installed. Choose this action to install only one SMU patch, or if installing the final patch of multiple patches.\n\nInstall and Skip Reload: The switches do not reboot after the SMU patch gets installed. Choose this action to install multiple SMU patches and if this patch is not the final patch. In this case, repeat this entire procedure for each additional patch and continue to choose Install and Skip Reload until the final patch is installed. For the final patch, choose Install and Reload. Optionally, choose \"Install and Skip Reload\" and manually reboot the switch after the patch gets installed.","ccis":["CCI-000366"]},{"vulnId":"V-271927","ruleId":"SV-271927r1168428_rule","severity":"high","ruleTitle":"The Cisco ACI must be configured to assign appropriate user roles or access levels to authenticated users.","description":"Successful identification and authentication must not automatically give an entity full access to a Cisco ACI or security domain. The lack of authorization-based access control could result in the immediate compromise of, and unauthorized access to, sensitive information. All DOD systems must be properly configured to incorporate access control methods that do not rely solely on authentication for authorized access. \n\nThere are multiple ways to provide this function so the site should be prepared to demonstrate in the \"Users\" section that different accounts have different AV pairs, domains, or roles. \n\nSatisfies: SRG-APP-000033-NDM-000212, SRG-APP-000329-NDM-000287, SRG-APP-000177-NDM-000263, SRG-APP-000910-NDM-000300","checkContent":"Verify users are assigned roles based on the SSP. This requirement does not apply to the account of last resort.\n\nFrom the GUI, navigate to Admin >> AAA >> Security >> Roles or have the site demonstrate the method used for role and privilege separation.\n\nVerify that the roles are associated with the users in compliance with the SSP required roles and privileges. Read and write access rights must match the level of granularity required by the SSP.\n\nIf any user/group or service account are assigned to roles with privileges that are beyond those required and authorized by the organization, this is a finding.","fixText":"View the SSP to determine the required organization-defined roles and the least privilege policies required for each role. For example, audit administrator, crypto administrator, system administrator, etc. Assign remote users to roles based on SSP and least privileges. Carefully assign capabilities to each role based on SSP role assignments. Remote authentication server is required, but roles can be created, deleted, or associated access privileges to nodes and resources update in the APIC. To create a new role with reduced permissions, do the following:\n\nTo create or modify roles:\n1. From the GUI, navigate to Admin >> AAA >> Security >> Roles.\n2. Create custom roles with appropriate privileges (e.g., read-write access to specific objects).\n3. Associate users with these roles, allowing them to perform specific tasks within the ACI fabric.\n\nNote: This procedure may use preconfigured rules and privileges. Security Domains, Rules, and Custom Roles may also be used depending on the desired architecture and complexity of the implementation. Refer to the vendor documentation to create custom rules, privileges combinations, Rules, and Security domains. These roles are assigned to the remote users in the external authentication server.","ccis":["CCI-000213","CCI-002169","CCI-000187","CCI-000764","CCI-000166","CCI-004909"]},{"vulnId":"V-271929","ruleId":"SV-271929r1113827_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured with only one local account to be used as the account of last resort in the event the authentication server is unavailable.","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 when the authentication server is down or connectivity between the device and the authentication server is not operable. This account is referred to as the account of last resort since it is intended to be used as a last resort and when immediate administrative access is absolutely necessary.\n\nIn the initial configuration script for the Cisco ACI, the admin account is configured and the admin is the only user when the system starts. \n\nThe account of last resort logon credentials must be stored in a sealed envelope and kept in a safe. The safe must be periodically audited to verify the envelope remains sealed. The signature of the auditor and the date of the audit should be added to the envelope as a record. Administrators should secure the credentials and disable the root account (if possible) when not needed for system administration functions.","checkContent":"Verify only the local site designated account of last resort is present:\n1. In the GUI menu bar, navigate to Admin >> AAA.\n2. In the navigation pane, click \"Users\".\n3. In the Work pane, click \"View the Local Users\" tab.\n\nIf local accounts other than the account of last resort are present, this is a finding.","fixText":"Remove accounts that are not the account of last resort:\n1. In the GUI menu bar, navigate to Admin >> AAA.\n2. In the navigation pane, click \"Users\".\n3. In the Work pane, click \"View the Local Users\" tab.\n4. Select any unauthorized user accounts that are not the account of last resort and deactivate the user account by using the Account Status control.","ccis":["CCI-001358","CCI-002111"]},{"vulnId":"V-271931","ruleId":"SV-271931r1168368_rule","severity":"high","ruleTitle":"The Cisco ACI must be configured to send log data to a central log server for log retention and forwarding alerts to the administrators and the information system security officer (ISSO).","description":"The aggregation of log data kept on a syslog server can be used to detect attacks and trigger an alert to the appropriate security personnel. The stored log data can be used to detect weaknesses in security that enable the network IA team to find and address these weaknesses before breaches can occur. Reviewing these logs, whether before or after a security breach, is important in determining whether someone is an internal employee or an outside threat.","checkContent":"Verify the ACI Fabric is configured to send event messages to syslog servers.\n\nNavigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n\nIf the Cisco ACI is not configured to send audit records to at least one central syslog server, this is a finding.","fixText":"Configure the Cisco switch to send log records to a syslog servers.\n\nNavigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n\nProvide the configuration information to create a log server.","ccis":["CCI-001851"]},{"vulnId":"V-271932","ruleId":"SV-271932r1114348_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to alert organization-defined personnel or roles upon detection of unauthorized access, modification, or deletion of audit information.","description":"Audit information includes all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities. Protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by both media protection controls and physical and environmental protection controls.","checkContent":"Verify the remote syslog or SIEM is sending event notifications to personnel based on audit log entries and associating those notifications with specific user roles or groups within the organization through the Authentication, Authorization, and Accounting (AAA) configuration.\n\nIf the ACI is not configured to send audit records to the central audit server, this is a finding.","fixText":"Configure event notifications based on audit log entries and associate those notifications with specific user roles or groups within the organization through the AAA configuration.\n\nPreferred method (required): \n1. Configure the APIC to forward audit log events to a centralized Syslog such as a SIEM platform. (SRG-APP-000515-NDM-000325)\n2. Configure the SIEM's capabilities to aggregate, analyze, and correlate audit events with other system logs for advanced threat detection and incident response. \n\nNote: Although the ACI can perform this function, it leverages the Call Home feature, which must be set to disabled by another STIG requirement.","ccis":["CCI-003831"]},{"vulnId":"V-271933","ruleId":"SV-271933r1114169_rule","severity":"medium","ruleTitle":"The Cisco ACI must audit the enforcement actions used to restrict access associated with changes to the device.","description":"Without auditing the enforcement of access restrictions against changes to the device configuration, it will be difficult to identify attempted attacks, and an audit trail will not be available for forensic investigation for after-the-fact actions. \n\nEnforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.\n\nSatisfies: SRG-APP-000381-NDM-000305, SRG-APP-000080-NDM-000220","checkContent":"Verify the ACI Fabric is configured to send event messages to redundant syslog servers:\n1. Navigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n2. Verify one or more Syslog Monitoring Destinations have been configured.\n3. Verify redundant syslog servers are configured.\n\nIf the ACI is not configured to send audit records to redundant central syslog servers that are separate from the ACI, this is a finding.","fixText":"Configure the ACI Fabric to send messages to redundant external syslog servers.\n\nCreate Syslog Remote Location:\n1. Navigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n2. From the Actions Menu, select \"Create Syslog Monitoring Destination Group\".\n3. Provide a name for the Syslog Group (e.g., syslog servers).\n4. Leave all other options as default and click \"Next\".\n5. Under Create Remote Destinations, click the \"+\" icon.\na. Enter hostname or IP address.\nb. Set the Severity level to \"Information\".\nc. Set the Management EPG as default (Out-of-band).\nd. Click \"OK\".\n6. If necessary, add additional Remove Destinations.\n7. Click \"Finish\".\n\nCreate Fabric Level Syslog Source:\nThe fabric Syslog policy will export alerts for monitoring details including physical ports, switch components (fans, memory, PSUs, etc.), and linecards.\n1. Navigate to Fabric >> Fabric Policies submenu >> Policies >> Monitoring >> Common Policy >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. From the Actions Menu, select \"Create Syslog Source\".\na. Provide a name for the source (e.g., fabric_common_syslog).\nb. Set the Severity level to \"Information\".\nc. Check all Log types.\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n\nCreating Access Level Syslog Policy:\nThe Access Syslog policy will export alerts for monitoring details including VLAN Pools, Domains, Interface Policy Groups, and Interface & Switch Selectors Policies.\n1. Navigate to Fabric >> Access Policies submenu >> Policies >> Monitoring >> default >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. In the Work pane, set the Source Type to \"Syslog\".\n3. Click the \"+\" icon to add a Syslog Source.\na. Provide a name for the source (e.g., access_default_syslog).\nb. Set severity level to \"Information\" unless desired to increase logging details.\nc. Check any additional Log types such as Audit Logs (optional).\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n\nCreating Tenant Level Syslog Policies:\nTenant-level logging includes all tenant-related policies, including Application Profiles, EPGs, Bridge domains, VRFs, external networking, etc. To simplify the syslog configuration across multiple tenants, leverage Common Tenant syslog configuration and share that across other tenants. This would provide a consistent level of logging for all tenants. Alternately, the site may create the respective Syslog policy within each tenant. The following configures a single consistent syslog policy using the Common Tenant:\n1. Navigate to Tenants >> common >> Policies >> Mentoring >> default >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. In the Work pane, set the Source Type to \"Syslog\".\n3. Click the \"+\" icon to add a Syslog Source.\na. Provide a name for the source (e.g., tenant_default_syslog).\nb. Set the severity level as \"Information\".\nc. Check all log types.\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n4. Navigate to Tenants >> Your_Tenant >> Policy tab.\n5. Set the Monitoring Policy drop-down box to be the default policy from the common tenant.","ccis":["CCI-003938","CCI-000166"]},{"vulnId":"V-271935","ruleId":"SV-271935r1114172_rule","severity":"medium","ruleTitle":"The Cisco ACI must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.","description":"To ensure Cisco ACIs have a sufficient storage capacity in which to write the audit logs, they need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial device setup if it is modifiable. \n\nThe value for the organization-defined audit record storage requirement will depend on the amount of storage available on the Cisco ACI, the anticipated volume of logs, the frequency of transfer from the Cisco ACI to centralized log servers, and other factors.","checkContent":"Verify the ACI Fabric is configured to send event messages to redundant syslog servers:\n1. Navigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n2. Verify one or more Syslog Monitoring Destinations have been configured.\n3. Verify redundant syslog servers are configured.\n\nIf the ACI is not configured to send audit records to redundant central syslog server that are separate from the ACI, this is a finding.","fixText":"Configuring the ACI Fabric to send messages to redundant external syslog servers.\n\nCreate Syslog Remote Location:\n1. Navigate to Admin >> External Data Collectors >> Monitoring Destinations >> Syslog.\n2. From the Actions Menu, select \"Create Syslog Monitoring Destination Group\".\n3. Provide a name for the Syslog Group (e.g., syslog servers).\n4. Leave all other options default and click \"Next\".\n5. Under Create Remote Destinations, click the \"+\" icon.\na. Enter hostname or IP address.\nb. Set the Severity level to \"Information\".\nc. Set the Management EPG as default (Out-of-band).\nd. Click \"OK\".\n6. If necessary, add additional Remove Destinations.\n7. Click \"Finish\".\n\nCreate Fabric Level Syslog Source:\nThe fabric Syslog policy will export alerts for monitoring details including physical ports, switch components (fans, memory, PSUs, etc.) and linecards.\n1. Navigate to Fabric >> Fabric Policies submenu >> Policies >> Monitoring >> Common Policy >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. From the Actions Menu, select \"Create Syslog Source\".\na. Provide a name for the source (e.g., fabric_common_syslog).\nb. Set the Severity level to \"Information\". \nc. Check all Log types.\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n\nCreating Access Level Syslog Policy:\nThe Access Syslog policy will export alerts for monitoring details including VLAN Pools, Domains, Interface Policy Groups, and Interface & Switch Selectors Policies.\n1. Navigate to Fabric >> Access Policies submenu >> Policies >> Monitoring >> default >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. In the Work pane, set the Source Type to \"Syslog\".\n3. Click the \"+\" icon to add a Syslog Source.\na. Provide a name for the source (e.g., access_default_syslog).\nb. Set severity level to \"Information\" unless desired to increase logging details.\nc. Check any additional Log types such as Audit Logs (optional).\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n\nCreating Tenant Level Syslog Policies:\nTenant-level logging includes all tenant-related policies, including Application Profiles, EPGs, Bridge domains, VRFs, external networking, etc. To simplify the syslog configuration across multiple tenants, leverage Common Tenant syslog configuration and share that across other tenants. This would provide a consistent level of logging for all tenants. Alternately, the site may create the respective Syslog policy within each tenant. The following configures a single consistent syslog policy using the Common Tenant.\n1. Navigate to Tenants >> common >> Policies >> Mentoring >> default >> Callhome/Smart Callhome/SNMP/Syslog/TACACs.\n2. In the Work pane, set the Source Type to \"Syslog\".\n3. Click the \"+\" icon to add a Syslog Source.\na. Provide a name for the source (e.g., tenant_default_syslog).\nb. Set the severity level as \"Information\".\nc. Check all log types.\nd. Set the Dest Group to the Syslog Destination Group previously created.\ne. Click \"Submit\".\n4. Navigate to Tenants >> Your_Tenant >> Policy tab.\n5. Set the Monitoring Policy drop-down box to be the default policy from the common tenant.","ccis":["CCI-001849"]},{"vulnId":"V-271936","ruleId":"SV-271936r1113837_rule","severity":"medium","ruleTitle":"The Cisco ACI must implement replay-resistant authentication mechanisms for network access to privileged accounts.","description":"A replay attack may enable an unauthorized user to gain access to the application. authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack.\n\nAn authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. \n\nTechniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.","checkContent":"Verify the default fabric TLS Protocol:\n1. On the menu bar, choose Fabric >> Fabric Policies.\n2. In the Navigation pane, select Policies >> Pod >> Management Access >> default.\n3. In the Work pane, find the HTTPS section.\n4. For SSL Protocols, verify the box for TLS 1.2 or higher is checked. Verify other SSL or TLS versions are not checked.\n\nIf the Cisco ACI fabric does not implement TLS 1.2 or higher for authentication for network access to privileged accounts, this is a finding.","fixText":"Configure the default fabric TLS Protocol:\n1. On the menu bar, choose Fabric >> Fabric Policies.\n2. In the Navigation pane, choose Policies >> Pod >> Management Access >> default.\n3. In the Work pane, find the HTTPS section.\n4. For SSL Protocols, check the boxes for TLS 1.2 or higher. Uncheck or leave unchecked for any other SSL or TLS version.","ccis":["CCI-001941"]},{"vulnId":"V-271939","ruleId":"SV-271939r1114173_rule","severity":"medium","ruleTitle":"The Cisco ACI must automatically audit account creation.","description":"Upon gaining access to a Cisco ACI, an attacker will often first attempt to create a persistent method of reestablishing access. One way to accomplish this is to create a new account. Notification of account creation helps to mitigate this risk. Auditing account creation provides the necessary reconciliation that account management procedures are being followed. Without this audit trail, personnel without the proper authorization may gain access to critical network nodes.\n\nSystem messages are created by various sources, such as the Application Policy Infrastructure Controller (APIC) or the spine and leaf switches in the ACI fabric. System messages from the switches can be generated by either of the following processes: the underlying NX-OS operating system of the spine and leaf switches or the ACI-related processes in the switch. This requirement sets the default logging level on the ACI to 7. This information severity level captures normal but significant condition messages and is the level required.\n\nSatisfies: SRG-APP-000026-NDM-000208, SRG-APP-000027-NDM-000209, SRG-APP-000028-NDM-000210, SRG-APP-000029-NDM-000211, SRG-APP-000343-NDM-00028, SRG-APP-000091-NDM-000223, SRG-APP-000091-NDM-000223, SRG-APP-000495-NDM-000318, SRG-APP-000499-NDM-000319, SRG-APP-000503-NDM-000320, SRG-APP-000503-NDM-000320, SRG-APP-000504-NDM-000321, SRG-APP-000101-NDM-000231, SRG-APP-000095-NDM-000225, SRG-APP-000096-NDM-000226, SRG-APP-000097-NDM-000227, SRG-APP-000098-NDM-000228, SRG-APP-000099-NDM-000229, SRG-APP-000100-NDM-000230","checkContent":"View the AAA event types in the local log:\n1. In the menu bar, click \"Admin\".\n2. In the submenu bar, click \"AAA\".\n3. In the Navigation pane, choose \"AAA Authentication\".\n4. In the Work pane, click the \"History\" tab.\n5. Under the History tab, click the \"Events\" subtab to view the event log.\n6. Under the History tab, click the \"Audit Log\" subtab to view the audit log.\n7. Double-click a log entry to view additional details about the event.\n\nIf account change actions are not being logged, this is a finding.","fixText":"To change the logging level to 6:\n1. Select a service from the \"Services\" field in the \"Changing Logging Level\" window.\n2. Choose the new logging level for the service from the \"Logging Level\" field.\n3. Click \"Apply\".","ccis":["CCI-000018","CCI-001403","CCI-001404","CCI-001405","CCI-002234","CCI-000172","CCI-002130","CCI-000172","CCI-000135","CCI-000130","CCI-000131","CCI-000132","CCI-000133","CCI-000134","CCI-001487"]},{"vulnId":"V-271944","ruleId":"SV-271944r1168370_rule","severity":"medium","ruleTitle":"The Cisco ACI must generate log records 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 Cisco ACI. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis.","checkContent":"Configure locally required events for auditing in compliance with the SSP:\n1. Navigate to the \"Contracts\" section within the tenant. \n2. View the existing contracts: Tenants >> {{your_tenant}} >> Contracts >> {{your_contract}} to verify that log is enabled for each filter.\n\nIf log is not enabled for each filter, this is a finding.","fixText":"Configure locally required events for auditing in compliance with the SSP:\n1. Navigate to the \"Contracts\" section within the tenant. \n2. View the existing contracts: Tenants >> {{your_tenant}} >> Contracts >> {{your_contract}}.\n3. Check the directive to enable log is for each filter.","ccis":["CCI-000169"]},{"vulnId":"V-271958","ruleId":"SV-271958r1168373_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to allow user selection of long passwords and passphrases, including spaces and all printable characters, for password-based authentication.","description":"Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.\n\nSatisfies: SRG-APP-000860-NDM-000250, SRG-APP-000865-NDM-000260, SRG-APP-000167-NDM-000255, SRG-APP-000168-NDM-000256, SRG-APP-000169-NDM-000257","checkContent":"1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit.\n3. In the Properties section, verify \"Password Strength Check\" is checked.\n\nIf the Cisco ACI fabric is not configured to allow user selection of long passwords and passphrases, including spaces and all printable characters for password-based authentication, this is a finding.","fixText":"1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit.\n3. In the Properties section, verify \"Password Strength Check\" is checked.","ccis":["CCI-004064","CCI-004065","CCI-004066"]},{"vulnId":"V-271960","ruleId":"SV-271960r1168376_rule","severity":"medium","ruleTitle":"The Cisco ACI 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 must be tested before the password is compromised. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password.","checkContent":"1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit.\n3. In the Properties section, verify \"Password Strength Check\" is checked.\n\nIf the Cisco ACI fabric is not configured to enforce a minimum 15-character password length, this is a finding.","fixText":"1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit\n3. In the Properties section, verify \"Password Strength Check\" is checked.\n4. In the dialog box that opens, verify \"Password Minimum Length\" is set to \"15\".","ccis":["CCI-004066"]},{"vulnId":"V-271966","ruleId":"SV-271966r1114341_rule","severity":"high","ruleTitle":"The Cisco ACI must use FIPS 140-2/140-3 approved algorithms for authentication to a cryptographic module.","description":"Unapproved mechanisms used for authentication to the cryptographic module are not validated and therefore, cannot be relied on to provide confidentiality or integrity, and DOD data may be compromised.\n\nCisco ACIs using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.\n\nFIPS 140-2/140-3 is the current standard for validating that mechanisms used to access cryptographic modules use authentication that meets DOD requirements. However, authentication algorithms must configure security processes to use only FIPS-approved and NIST-recommended authentication algorithms.\n\nSatisfies: SRG-APP-000179-NDM-000265, SRG-APP-000411-NDM-000330, SRG-APP-000412-NDM-000331","checkContent":"1. Navigate to System >> System Settings.\n2. Click \"Fabric Security\".\n3. Click the \"Policy\" tab.\n4. Verify FIPS Mode is set to \"Enable\".\n\nIf FIPS mode is not set to \"Enable\", this is a finding.","fixText":"When FIPS is enabled, it is applied across the Cisco Application Policy Infrastructure Controller (APIC).\n\n1. On the menu bar, select System >> System Settings. \n2. In the Navigation pane, select \"Fabric Security\".\n3. In the Work pane, in the Properties area, select the desired FIPS mode.\n4. Reboot to complete the configuration.","ccis":["CCI-000803","CCI-002890","CCI-003123"]},{"vulnId":"V-271969","ruleId":"SV-271969r1168379_rule","severity":"high","ruleTitle":"Cisco ACI SSH sessions must be terminated after five minutes of inactivity.","description":"Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. Quickly terminating an idle session will also free up resources committed by the managed network element. \n\nTerminating network connections associated with communications sessions includes, for example, deallocating associated TCP/IP address/port pairs at the operating system level or deallocating networking assignments at the application level if multiple application sessions are using a single, operating system-level network connection. This does not mean that the device terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.","checkContent":"Verify the maximum GUI idle duration before requiring login refresh is set to 300 seconds or less:\n\n1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit.\n3. In the Properties section, verify \"Web Token Timeout (s)\" is set to 300 or less.\n\nNote: If not set, then the default values are used, this is a finding.\n\nIf \"Web Token Timeout (s)\" is not set to 300 or less, this is a finding.","fixText":"Set the GUI idle timeout, which affects SSH on both APIC and Switches:\n1. Navigate to Admin >> AAA >> Security.\n2. In the Work pane, choose Default Settings >> Edit.\n3. In the Properties section, set \"Web Token Timeout (s)\" to 300 or less.","ccis":["CCI-001133"]},{"vulnId":"V-271971","ruleId":"SV-271971r1168430_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to synchronize system clocks within and between systems or system components.","description":"Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. 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. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities such as access control and identification and authentication depending on the nature of the mechanisms used to support the capabilities.","checkContent":"1. Navigate to Fabric >> Fabric Policies.\n2. Expand \"Policies\".\n3. Expand \"Pod\".\n4. Expand \"Date and Time\".\n5. Expand each \"Date and Time Policy\".\n6. Verify at least two DOD-approved time sources are configured.\n\nNote: 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.\n\nIf Cisco ACI fabric does not use DOD-approved redundant NTP sources that use authentication that is cryptographically based, this is a finding.","fixText":"Create an NTP policy:\n1. Navigate to Fabric >> Quickstart and click \"Create an NTP Policy Link\".\n2. Complete the form. \n- Provide a name for the policy.\n- Set the State to \"Enabled\". \n3. Click \"Next\" to define the NTP Sources. \n4. Define at least two DOD-approved time servers. Leave all the default options and click \"OK\". Refer to note below.\n5. Navigate to Fabric >> Fabric Policies submenu >> Pods >> Policy Groups folder to add the NTP Policy to the appropriate Fabric Pod Policy or group to assign to one or more Pods in the fabric.\n6. Right-click the Policy Groups folder. Select an existing Pod Policy Group or create a new group.\n7. Select the policy for NTP created in the previous step. \n8. Navigate to Fabric >> Fabric Policies submenu >> Pods >> Profiles >> Pod Profile >> default. If needed, with the default Pod Selector selected in the navigation pane, change the Fabric Policy Group to the one created in the previous step. \n\nNote: 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), USNO time servers, and/or GPS. The secondary time source must be located in a different geographic region than the primary time source.","ccis":["CCI-004922"]},{"vulnId":"V-271972","ruleId":"SV-271972r1114185_rule","severity":"medium","ruleTitle":"The Cisco ACI must be configured to disable the auxiliary USB port.","description":"Disable the USB port in those environments where physical access to the devices is not strictly controlled, or in environments where this extra layer of protection is required.\n\nCisco Nexus 9000 switches running Cisco ACI code have the USB port enabled by default. When the USB port is enabled, switches will try to boot from the USB drive first. This may be a security risk in case a malicious actor has physical access to the switch, given they could power-cycle the device to try to boot the switch from a USB image that contains malicious code.\n\nEven if this is not a common scenario considering that most organizations have physical access security guidelines in place, Cisco ACI release 5.2(3) introduced the option to disable the USB port using a specific switch policy.","checkContent":"Verify the USB port is disabled:\n1. Navigate to Fabric >> Access Policies >> Policies >> Switch >> USB Configuration >> default.\n2. Verify the \"Disable USB Port\" box is checked.\n\nIf the USB port is not disabled, this is a finding.","fixText":"Disable the USB port on all switches within the Cisco ACI fabric:\n1. Navigate to Fabric >> Access Policies >> Policies >> Switch >> USB Configuration >> default.\n2. Check the \"Disable USB Port\" box; this will disable the USB port on all switches within the Cisco ACI fabric.","ccis":["CCI-000382"]},{"vulnId":"V-271975","ruleId":"SV-271975r1168383_rule","severity":"medium","ruleTitle":"The Cisco ACI must limit the number of concurrent sessions to one for each administrator account.","description":"Device management includes the ability to control the number of administrators and management sessions that manage a device. Limiting the number of allowed administrators and sessions per administrator based on account type, role, or access type is helpful in limiting risks related to denial-of-service (DoS) attacks.\n\nThis requirement addresses concurrent sessions for administrative accounts and does not address concurrent sessions by a single administrator via multiple administrative accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system. At a minimum, limits must be set for SSH, HTTPS, account of last resort, and root account sessions.","checkContent":"Review the AAA configuration:\n1. In the GUI, on the menu bar, choose Admin >> AAA.\n2. In the Navigation pane, click \"Authentication\".\n3. Review the configuration for the configured AAA providers.\n4. Review the configuration of the Login Domain(s) used by the site.\n\nIf the Cisco ACI is not configured to use at a AAA provider for the purpose of authenticating users prior to granting administrative access, this is a finding.","fixText":"In the APIC, configure redundant RADIUS providers.\n1. On the menu bar, choose Admin >> AAA.\n2. In the Navigation pane, choose \"Authentication\".\n3. In the Work pane, choose Providers and click Actions >> Create Provider.\n4. In the Create Provider screen, enter the Hostname/IP Address, Description, and choose a RADIUS or TACACS+ as the realm from the drop-down list. Provide the configuration details.\n\nCreate the login domain for RADIUS:\n1. In the Navigation pane, choose AAA Authentication >> Login Domains.\n2. In the Work pane, choose Actions >> Create Login Domain.\n3. Specify the login domain name, description, realm, and provider group as appropriate.\n\nNote: The above configuration is an example using the RADIUS protocol. However, DOD sites may configure the options for RADIUS or TACACS+.","ccis":["CCI-000054"]}]}