Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Review the switch configuration to determine if concurrent management sessions are limited as show in the example below: line vty session-limit 2 If the switch is not configured to limit the number of concurrent management sessions, this is a finding.
Configure the switch to limit the number of concurrent management sessions to an organization-defined number as shown in the example below: SW4(config)# line vty SW4(config)# session-limit 2
Review the switch configuration to determine if it automatically audits account creation. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If account creation is not automatically audited, this is a finding.
Configure the switch to log account creation using the following steps: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the switch configuration to determine if it automatically audits account modification. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If account modification is not automatically audited, this is a finding.
Configure the switch to log account modification using the following steps: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the switch configuration to determine if it automatically audits account disabling. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If account disabling is not automatically audited, this is a finding.
Configure the switch to log account disabling using the following steps: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the switch configuration to determine if it automatically audits account removal. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If account removal is not automatically audited, this is a finding.
Configure the switch to log account removal using the following steps: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement. Step 1: Verify that the line vty has an ACL inbound applied as shown in the example below: line vty access-class MGMT_NET in Step 2: Verify that the ACL permits only hosts from the management network to access the switch. ip access-list MGMT_NET 10 permit ip 10.1.48.0/24 any 20 deny ip any any log NX-OS v8 and later example Step 1: Verify that an ACL has been applied to the management interface inbound as shown in the example below: interface mgmt0 ip access-group MGMT_NET in Step 2: Verify that the ACL permits only hosts from the management network to access the switch. ip access-list MGMT_NET 10 permit ip 10.1.48.0/24 any 20 deny ip any any log If the Cisco switch is not configured to enforce approved authorizations for controlling the flow of management information within the device based on control policies, this is a finding.
Configure the Cisco switch to restrict management access to specific IP addresses as shown in the example below: SW1(config)# ip access-list MGMT_NET SW1(config-acl)# permit ip 10.1.48.0/24 any SW1(config-acl)# deny ip any any log SW1(config-acl)# exit SW1(config)# line vty SW1(config-line)# access-class MGMT_NET in SW1(config-acl)# end NX-OS v8 and later example SW1(config)# ip access-list MGMT_NET SW1(config-acl)# permit ip 10.1.48.0/24 any SW1(config-acl)# deny ip any any log SW1(config-acl)# exit SW1(config)# interface mgmt0 SW1(config-if)# ip access-group MGMT_NET in SW1(config-acl)# end
Review the Cisco switch configuration to verify that it enforces the limit of three consecutive invalid logon attempts as shown in the example below: ssh login-attempts 3 If the Cisco switch is not configured to enforce the limit of three consecutive invalid logon attempts, this is a finding. NOTE: The NX-OS switch does not lock out the account, it disconnects the session. The AAA server will lock out the user account on three failed attempts.
Configure the Cisco switch to enforce the limit of three consecutive invalid logon attempts as shown in the example below: SW2(config)# ssh login-attempts 3
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: banner motd # You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. # If the Cisco switch is not configured to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the device, this is a finding.
Configure the Cisco switch to display the Standard Mandatory DoD Notice and Consent Banner before granting access as shown in the following example: SW1(config)# banner motd # Enter TEXT message. End with the character '#'. > You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. > > By using this IS (which includes any device attached to this IS), you consent to the following conditions: > > -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, > penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law > enforcement (LE), and counterintelligence (CI) investigations. > > -At any time, the USG may inspect and seize data stored on this IS. > > -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and > search, and may be disclosed or used for any USG-authorized purpose. > > -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your > personal benefit or privacy. > > -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or > monitoring of the content of privileged communications, or work product, related to personal representation or services > by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and > confidential. See User Agreement for details. > # SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in steps below: Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If logging of administrator activity is not configured, this is a finding.
Configure the switch to log administrator activity as shown in the steps below: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement. The configuration example below will log all logon attempts. logging logfile LOG_FILE 6 logging level authpri 6 If the Cisco switch is not configured to generate audit records when successful/unsuccessful attempts to logon, this is a finding.
Configure the Cisco switch to log all logon attempts as shown in the example below: Step 1: Lower the authpriv level to 6. SW1(config)# logging level authpriv 6 Step 2: Configure a logfile to record log messages at level 6. SW1(config)# logging logfile LOG_FILE 6
Step 1: Review the deny statements in all interface ACLs to determine if the log parameter has been configured as shown in the example below: ip access-list extended BLOCK_INBOUND deny icmp any any log Step 2: Verify that the Optimized Access-list Logging (OAL) has been configured. logging ip access-list cache entries nnnn Note: Once OAL has been enabled, the logged ACL hits can be viewed via the show log ip access-list cache command. If the switch is not configured with the log-input parameter after any deny statements to note where packets have been dropped via an ACL, this is a finding.
Enable OAL as shown in the example below: SW1(config)# logging ip access-list cache entries nnnn Set the ‘log’ parameter after any ‘deny’ entries in the ACL as referenced in the check text above.
Review the Cisco switch configuration to verify that it is compliant with this requirement. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If the Cisco switch is not configured to generate audit records of configuration changes, this is a finding.
Configure the Cisco switch to log all configuration changes as shown in the example below: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Verify that the switch does not have any unnecessary or non-secure ports, protocols and services enabled. For example, the following features such as telnet should never be enabled, while other features should only be enabled if required for operations. feature telnet feature dhcp feature wccp feature nxapi feature imp If any unnecessary or non-secure ports, protocols, or services are enabled, this is a finding.
Disable features that should not be enabled unless required for operations. SW2(config)# no feature telnet SW2(config)# no feature dhcp SW2(config)# no feature wccp SW2(config)# no feature nxapi SW2(config)# no feature imp Note: Telnet must always be disabled.
Step 1: Review the Cisco switch configuration to verify that a local account for last resort has been configured with a privilege level that will enable the administrator to troubleshoot connectivity to the authentication server. username xxxxxxxxxxxxx password 5 $5$88SPgpAn$Q6/17o5U/5lz4dNL1iQZuj/1a0wcKdrk29ZH1HJsnF. role priv-9 Step 2: Verify that the fallback to use local account has not been disabled as shown in the example below: no aaa authentication login default fallback error local Note: The fallback is enabled by default; hence the above command should not be seen in the configuration. If the Cisco switch is not configured with only one local account to be used as the account of last resort in the event the authentication server is unavailable, this is a finding.
Step 1: Configure a local account with the necessary privilege level to troubleshoot network outage and restore operations as shown in the following example: SW2(config)# switch(config)# username xxxxxxx password xxxxxx role priv-9 Step 2: Configure the authentication to use an AAA server with the fallback to use the local account if the authentication server is not reachable as shown in the following example: SW2(config)# aaa authentication login default group RADIUS_SERVERS SW2(config)# aaa authentication login default fallback error local SW2(config)# end
Verify that FIPS mode is enabled as shown in the example below: fips mode enable Note: Cisco NX-OS software supports only SSH version 2 (SSHv2). Beginning in Cisco NX-OS Release 5.1, SSH runs in FIPS mode. Source: Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 6.x If the switch is not configured to implement cryptographic mechanisms to protect the confidentiality of remote maintenance sessions, this is a finding.
Enable fips mode via the command fips mode enable.
Password complexity is enabled by default. Review the Cisco switch configuration to verify that it is compliant with this requirement. The following command should not be found in the configuration: no password strength-check If the Cisco switch is not configured to enforce password complexity by requiring that at least one upper-case character be used, this is a finding.
Configure the Cisco switch to enforce password complexity by requiring that at least one upper-case character be used as shown in the example below: SW1(config)# password strength-check
Password complexity is enabled by default. Review the Cisco switch configuration to verify that it is compliant with this requirement. The following command should not be found in the configuration: no password strength-check If the Cisco switch is not configured to enforce password complexity by requiring that at least one lower-case character be used, this is a finding.
Configure the Cisco switch to enforce password complexity by requiring that at least one lower-case character be used as shown in the example below: SW1(config)# password strength-check
Password complexity is enabled by default. Review the Cisco switch configuration to verify that it is compliant with this requirement. The following command should not be found in the configuration: no password strength-check If the Cisco switch is not configured to enforce password complexity by requiring that at least one numeric character be used, this is a finding.
Configure the Cisco switch to enforce password complexity by requiring that at least one numeric character be used as shown in the example below: SW1(config)# password strength-check
Password complexity is enabled by default. Review the Cisco switch configuration to verify that it is compliant with this requirement. The following command should not be found in the configuration: no password strength-check If the Cisco switch is not configured to enforce password complexity by requiring that at least one special character be used, this is a finding.
Configure the Cisco switch to enforce password complexity by requiring that at least one special character be used as shown in the example below: SW1(config)# password strength-check
Review the Cisco switch configuration to verify that all network connections associated with a device management have an idle timeout value set to 10 minutes or less as shown in the following example: line console exec-timeout 10 line vty exec-timeout 10 If the Cisco switch is not configured to terminate all network connections associated with a device management after 10 minutes of inactivity, this is a finding.
Set the idle timeout value to 10 minutes or less on all configured login classes as shown in the example below: SW1(config)# line console SW1(config-console)# exec-timeout 10 SW1(config-console)# exit SW1(config)# line vty SW1(config-line)# exec-timeout 10
Review the switch configuration to determine if it automatically audits account enabling. The configuration should look similar to the example below: Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If account enabling is not automatically audited, this is a finding.
Configure the switch to log account enabling using the following steps: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement. The configuration example below will log all configuration changes. Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If the Cisco switch is not configured to log all configuration changes, this is a finding.
Configure the Cisco switch to log all configuration changes as shown in the following example: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Verify that the Cisco switch is configured with a logfile size. The configuration should look like the example below: logging logfile LOGFILE1 6 size nnnnn If the Cisco switch is not configured to allocate audit record storage capacity in accordance with organization-defined audit record storage requirements, this is a finding.
Configure the buffer size for logging as shown in the example below: SW2(config)# logging logfile LOGFILE1 6 size nnnnn
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: logging server 10.1.48.10 2 Note: The parameter 2 (critical) can replaced with a lesser severity level 3 through 6 (i.e. error, warning, notice, informational). Informational is the default severity level; hence, if the severity level is configured to informational, the parameter 7 will not be shown in the configuration. If the Cisco switch is not configured to generate an alert for all audit failure events, this is a finding.
Configure the Cisco switch to send critical to emergency log messages to the syslog server as shown in the example below: SW4(config)# logging server 10.1.48.10 2 Note: The parameter 2 (critical) can replaced with a lesser severity level 3 through 6 (i.e. error, warning, notice, informational).
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the configuration example below: ntp distribute ntp server 10.1.12.10 ntp server 10.1.22.13 ntp commit If the Cisco switch is not configured to synchronize its clock with redundant authoritative time sources, this is a finding.
Configure the Cisco switch to synchronize its clock with redundant authoritative time sources as shown in the example below: SW1(config)# feature ntp SW1(config)# ntp distribute SW1(config)# ntp server 10.1.12.10 SW1(config)# ntp server 10.1.22.13 SW1(config)# ntp commit SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: clock timezone EST -5 0 Note: UTC is the default; hence, the command set time-zone may not be seen in the configuration. This can be verified using the show system uptime command. If the switch is not configured to record time stamps for log records that can be mapped to UTC or GMT, this is a finding.
Configure the Cisco switch to record time stamps for audit records that can be mapped to UTC or GMT as shown in the example below: SW1(config)# clock timezone EST -5 0
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: snmp-server user NETOPS network-operator auth sha 0xb40efa3f311006de39b9d0725e663277d84ca332 localizedkey snmp-server host 10.1.48.10 traps version 3 auth NETOPS Authentication used by the SNMP users can be viewed via the show snmp user command as shown in the example below: SW1# show snmp user ______________________________________________________________ SNMP USERS ______________________________________________________________ User Auth Priv(enforce) Groups acl_filter ____ ____ ___________ ______ __________ NETOPS sha no network-operator If the Cisco switch is not configured to authenticate SNMP messages using a FIPS-validated HMAC, this is a finding.
Configure the Cisco switch to authenticate SNMP messages as shown in the example below: SW1(config)# snmp-server user NETOPS auth sha xxxxxxxxxxxxxxxxx SW1(config)# snmp-server host 10.1.48.10 traps version 3 auth NETOPS
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: snmp-server user NETOPS auth sha 5Er23@#as178 priv aes-128 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Encryption used by the SNMP users can be viewed via the show snmp user command as shown in the example below: SW1# show snmp user ______________________________________________________________ SNMP USERS ______________________________________________________________ User Auth Priv(enforce) Groups acl_filter ____ ____ ___________ ______ __________ NETOPS sha aes-128 network-operator If the Cisco switch is not configured to encrypt SNMP messages using a FIPS 140-2 approved algorithm, this is a finding.
Configure the Cisco switch to encrypt SNMP messages using a FIPS 140-2 approved algorithm as shown in the example below: SW1(config)# snmp-server user NETOPS auth sha xxxxxxxxxxxxx priv aes-128 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the configuration example below: ntp distribute ntp server 10.1.12.10 key 1 ntp server 10.1.22.13 key 1 ntp authenticate ntp authentication-key 1 md5 xxxxxxxxxx 7 ntp trusted-key 1 ntp commit If the Cisco switch is not configured to authenticate NTP sources using authentication that is cryptographically based, this is a finding.
Configure the Cisco switch to authenticate NTP sources using authentication that is cryptographically based as shown in the example below: SW1(config)# ntp authenticate SW1(config)# ntp authentication-key 1 md5 xxxxxxxxxxxxx SW1(config)# ntp trusted-key 1 SW1(config)# ntp server 10.1.12.10 key 1 SW1(config)# ntp server 10.1.22.13 key 1 SW1(config)# ntp commit SW1(config)# end
Verify that FIPS mode is enabled as shown in the example below: fips mode enable Note: Cisco NX-OS software supports only SSH version 2 (SSHv2). Beginning in Cisco NX-OS Release 5.1, SSH runs in FIPS mode. Source: Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 6.x If the switch is not configured to use FIPS-validated HMAC to protect the integrity of remote maintenance sessions, this is a finding.
Enable fips mode via the command fips mode enable.
Verify that FIPS mode is enabled as shown in the example below: fips mode enable Note: Cisco NX-OS software supports only SSH version 2 (SSHv2). Beginning in Cisco NX-OS Release 5.1, SSH runs in FIPS mode. Source: Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 6.x If the switch is not configured to implement cryptographic mechanisms to protect the confidentiality of remote maintenance sessions, this is a finding.
Enable fips mode via the command fips mode enable.
Review the Cisco switch configuration to verify that it is compliant with this requirement. Step 1: Verify traffic types have been classified based on importance levels. The following is an example configuration: class-map match-all CoPP_CRITICAL match access-group name CoPP_CRITICAL class-map match-any CoPP_IMPORTANT match access-group name CoPP_IMPORTANT match protocol arp class-map match-all CoPP_NORMAL match access-group name CoPP_NORMAL class-map match-any CoPP_UNDESIRABLE match access-group name CoPP_UNDESIRABLE class-map match-all CoPP_DEFAULT match access-group name CoPP_DEFAULT Step 2: Review the ACLs referenced by the class maps to determine if the traffic is being classified appropriately. The following is an example configuration: ip access-list extended CoPP_CRITICAL remark our control plane adjacencies are critical permit ospf host [OSPF neighbor A] any permit ospf host [OSPF neighbor B] any permit pim host [PIM neighbor A] any permit pim host [PIM neighbor B] any permit pim host [RP addr] any permit igmp any 224.0.0.0 15.255.255.255 permit tcp host [BGP neighbor] eq bgp host [local BGP addr] permit tcp host [BGP neighbor] host [local BGP addr] eq bgp deny ip any any ip access-list extended CoPP_IMPORTANT permit tcp host [TACACS server] eq tacacs any permit tcp [management subnet] 0.0.0.255 any eq 22 permit udp host [SNMP manager] any eq snmp permit udp host [NTP server] eq ntp any deny ip any any ip access-list extended CoPP_NORMAL remark we will want to rate limit ICMP traffic permit icmp any any echo permit icmp any any echo-reply permit icmp any any time-exceeded permit icmp any any unreachable deny ip any any ip access-list extended CoPP_UNDESIRABLE remark other management plane traffic that should not be received permit udp any any eq ntp permit udp any any eq snmp permit tcp any any eq 22 permit tcp any any eq 23 remark other control plane traffic not configured on switch permit eigrp any any permit udp any any eq rip deny ip any any ip access-list extended CoPP_DEFAULT permit ip any any Note: Explicitly defining undesirable traffic with ACL entries enables the network operator to collect statistics. Excessive ARP packets can potentially monopolize Route Processor resources, starving other important processes. Currently, ARP is the only Layer 2 protocol that can be specifically classified using the match protocol command. Step 3: Review the policy-map to determine if the traffic is being policed appropriately for each classification. The following is an example configuration: policy-map CONTROL_PLANE_POLICY class CoPP_CRITICAL police 512000 8000 conform-action transmit exceed-action transmit class CoPP_IMPORTANT police 256000 4000 conform-action transmit exceed-action drop class CoPP_NORMAL police 128000 2000 conform-action transmit exceed-action drop class CoPP_UNDESIRABLE police 8000 1000 conform-action drop exceed-action drop class CoPP_DEFAULT police 64000 1000 conform-action transmit exceed-action drop Step 4: Verify that the CoPP policy is enabled. The following is an example configuration: control-plane service-policy input CONTROL_PLANE_POLICY If the Cisco switch is not configured to protect against known types of DoS attacks by employing organization-defined security safeguards, this is a finding.
Configure the Cisco switch protect against known types of DoS attacks on the route processor. Implementing a CoPP policy as shown in the example below is a best practice method. Step 1: Configure ACLs' specific traffic types. SW1(config)# ip access-list CoPP_CRITICAL SW1(config-acl)# remark our control plane adjacencies are critical SW1(config-acl)# permit ospf host 10.1.12.1 any SW1(config-acl)# permit ospf host 10.1.22.1 any SW1(config-acl)# permit pim host 10.1.12.1 any SW1(config-acl)# permit pim host 10.1.22.1 any SW1(config-acl)# permit pim host 10.1.33.4 any SW1(config-acl)# permit igmp any 224.0.0.0 15.255.255.255 SW1(config-acl)# permit tcp host 10.2.33.3 eq bgp host 10.2.33.4 SW1(config-acl)# permit tcp host 10.2.33.3 host 10.2.33.4 eq bgp SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_IMPORTANT SW1(config-acl)# permit tcp host 10.1.33.5 eq tacacs any SW1(config-acl)# permit tcp 10.1.33.0 0.0.0.255 any eq 22 SW1(config-acl)# permit udp host 10.1.33.7 any eq snmp SW1(config-acl)# permit udp host 10.1.33.9 eq ntp any SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_NORMAL SW1(config-acl)# remark we will want to rate limit ICMP traffic SW1(config-acl)# permit icmp any any echo SW1(config-acl)# permit icmp any any echo-reply SW1(config-acl)# permit icmp any any time-exceeded SW1(config-acl)# permit icmp any any unreachable SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_UNDESIRABLE SW1(config-acl)# remark other management plane traffic that should not be received SW1(config-acl)# permit udp any any eq ntp SW1(config-acl)# permit udp any any eq snmp SW1(config-acl)# permit tcp any any eq 22 SW1(config-acl)# permit tcp any any eq 23 SW1(config-acl)# remark other control plane traffic not configured on switch SW1(config-acl)# permit eigrp any any SW1(config-acl)# permit udp any any eq rip SW1(config-acl)# deny ip any any SW1(config-acl)# exit SW1(config)# ip access-list CoPP_DEFAULT SW1(config-acl)# permit ip any any SW1(config-acl)# exit Step 2: Configure class maps referencing each of the ACLs. SW1(config)# class-map match-all CoPP_CRITICAL SW1(config-cmap)# match access-group name CoPP_CRITICAL SW1(config-cmap)# class-map match-any CoPP_IMPORTANT SW1(config-cmap)# match access-group name CoPP_IMPORTANT SW1(config-cmap)# match protocol arp SW1(config-cmap)# class-map match-all CoPP_NORMAL SW1(config-cmap)# match access-group name CoPP_NORMAL SW1(config-cmap)# class-map match-any CoPP_UNDESIRABLE SW1(config-cmap)# match access-group name CoPP_UNDESIRABLE SW1(config-cmap)# class-map match-all CoPP_DEFAULT SW1(config-cmap)# match access-group name CoPP_DEFAULT SW1(config-cmap)# exit Step 3: Configure a policy map referencing the configured class maps and apply appropriate bandwidth allowance and policing attributes. SW1(config)# policy-map CONTROL_PLANE_POLICY SW1(config-pmap)# class CoPP_CRITICAL SW1(config-pmap-c)# police 512000 8000 conform-action transmit exceed-action transmit SW1(config-pmap-c-police)# class CoPP_IMPORTANT SW1(config-pmap-c)# police 256000 4000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# class CoPP_NORMAL SW1(config-pmap-c)# police 128000 2000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# class CoPP_UNDESIRABLE SW1(config-pmap-c)# police 8000 1000 conform-action drop exceed-action drop SW1(config-pmap-c-police)# class CoPP_DEFAULT SW1(config-pmap-c)# police 64000 1000 conform-action transmit exceed-action drop SW1(config-pmap-c-police)# exit SW1(config-pmap-c)# exit SW1(config-pmap)# exit Step 4: Apply the policy map to the control plane. SW1(config)# control-plane SW1(config-cp)# service-policy input CONTROL_PLANE_POLICY SW1(config-cp)# end
Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If the Cisco switch is not configured to generate log records when administrator privileges are modified, this is a finding.
Configure the Cisco switch to generate log records when account privileges are modified as shown in the example below: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If the Cisco switch is not configured to generate log records when administrator privileges are deleted, this is a finding.
Configure the Cisco switch to generate log records when administrator privileges are deleted as shown in the example below: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the examples below: logging logfile LOG_FILE 6 logging level authpri 6 If the Cisco switch is not configured to generate audit records when successful/unsuccessful logon attempts occur, this is a finding.
Configure the Cisco switch to generate audit records when successful/unsuccessful logon attempts occur as shown in the example below: Step 1: Lower the authpriv level to 6. SW1(config)# logging level authpriv 6 Step 2: Configure a logfile to record log messages at level 6. SW1(config)# logging logfile LOG_FILE 6
Step 1: Verify that account records will be sent to an AAA server as shown in the example below: aaa accounting default group RADIUS_SERVERS Step 2: Verify that the referenced group name has defined AAA servers that are online. aaa group server radius RADIUS_SERVERS server 10.1.48.10 server 10.1.48.12 Note: Cisco NX-OS devices report configuration activity to TACACS+ or RADIUS servers in the form of accounting records. Each accounting record contains accounting attribute-value (AV) pairs and is stored on the AAA server. If the Cisco switch is not configured to generate log records for privileged activities, this is a finding.
Configure the Cisco switch to generate log records for privileged activities as shown in the example below: Step 1: Configure the AAA servers as shown in the example below: SW1(config)# radius-server host 10.1.48.10 SW1(config)# radius-server host 10.1.48.12 Step 2: Configure an AAA server group as shown in the example below: SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 SW1(config-radius)# server 10.1.48.12 SW1(config-radius)# exit Step 3: Enable AAA accounting as shown in the example below: SW1(config)# aaa accounting default group RADIUS_SERVERS SW1(config)# end
Verify that the switch is configured to generate log records showing starting and ending time for administrator access as shown in the example below: logging level authpri 6 If the switch is not configured to generate log records showing starting and ending time for administrator access, this is a finding.
Configure the switch to log session start and ending per admin session as shown in the example below: SW1(config)# logging level authpriv 6
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the examples below: logging logfile LOG_FILE 6 logging level authpri 6 If the Cisco switch is not configured to generate log records when concurrent logons from different workstations occur, this is a finding.
Configure the Cisco switch to log all logon attempts as shown in the example below: Step 1: Lower the authpriv level to 6. SW1(config)# logging level authpriv 6 Step 2: Configure a logfile to record log messages at level 6. SW1(config)# logging logfile LOG_FILE 6
Review the Cisco switch configuration to verify that it is compliant with this requirement as shown in the example below: logging server 10.1.48.10 6 If the Cisco switch is not configured to off-load log records onto a different system than the system being audited, this is a finding.
Configure the Cisco switch to send log records to a syslog server as shown in the example below: SW4(config)# logging server 10.1.48.10 6
Review the Cisco switch configuration to verify that the device is configured to use an authentication server as primary source for authentication. Step 1: Verify that an AAA server group is configured for login authentication for both in-band and console access methods. aaa authentication login default group RADIUS_SERVERS aaa authentication login console group RADIUS_SERVERS Step 2: Verify that an AAA server has been defined for the server group as shown in the example below: radius-server host 10.1.48.10 key 7 "xxxxxx" authentication accounting aaa group server radius RADIUS_SERVERS server 10.1.48.10 If the Cisco switch is not configured to use an authentication server for the purpose of authenticating users prior to granting administrative access, this is a finding.
Configure the Cisco switch to use an authentication server as shown in the following example: Step 1: Define the authentication server. SW1(config)# radius-server host 10.1.48.10 key xxxxxx Step 2: Configure the AAA group. SW1(config)# aaa group server radius RADIUS_SERVERS SW1(config-radius)# server 10.1.48.10 Step 3: Use the AAA server for login authentication for both in-band and console access methods. SW1(config)# aaa authentication login default group RADIUS_SERVERS SW1(config)# aaa authentication login console group RADIUS_SERVERS
Review the Cisco switch configuration to verify that it is compliant with this requirement. The example configuration below will send the configuration to a TFTP server when a configuration change occurs. event manager applet BACKUP_CONFIG event syslog pattern "SYSLOG_CONFIG_I" action 1 cli command "copy startup-config tftp://10.1.48.10/nx-config vrf default" action 2 syslog priority informational msg "Configuration backup was executed" If the Cisco switch is not configured to conduct backups of the configuration when changes occur, this is a finding.
Configure the Cisco switch to send the configuration to an TFTP or FTP server when a configuration change occurs as shown in the example below: SW4(config)# event manager applet BACKUP_CONFIG SW4(config-applet)# event syslog pattern "SYSLOG_CONFIG_I" SW4(config-applet)# action 1 cli command "copy startup-config tftp://10.1.48.10/nx-config vrf default” SW4(config-applet)# action 2 syslog priority informational msg "Configuration backup was executed" SW4(config-applet)# end
If PKI certificates are not implemented on the switch, this requirement is not applicable. Step 1: Review the switch configuration to determine if a CA trust point has been configured as shown in the example below: crypto ca trustpoint CA_X enrollment terminal Step 2: Verify the CA is a DoD or DoD-approved service provider by entering the following command: show crypto ca certificates The output will list the following information for each certificate: Trustpoint (will map to a configured trustpoint from step 1) Common Name (CN) of the issuer Organization (O) of the issuer Organization Unit (OU) of the issuer Note: Cisco NX-OS software supports only the manual cut-and-paste method for certificate enrollment If the switch is not configured to obtain its public key certificates from a DoD or DoD-approved service provider, this is a finding.
Ensure that certificate requests are only sent to DoD or DoD-approved service providers.
Verify that the switch is configured to send logs to a syslog server. The configuration should look similar to the example below: logging server 10.1.48.10 6 If the switch is not configured to send log data to the syslog server, this is a finding.
Configure the switch to send log messages to the syslog server as shown in the example below: SW4(config)# logging server 10.1.48.10 6
Verify that the switch is in compliance with this requirement by having the switch administrator enter the following command: show version Verify that the release is still supported by Cisco. All releases supported by Cisco can be found on the following URL: www.cisco.com/c/en/us/support/ios-nx-os-software If the switch is not running a supported release, this is a finding.
Upgrade the switch to a supported release.