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 network element configuration to determine if administrative access to the device requires some form of authentication—at a minimum a password is required.
Configure the network element so it will require a password to gain administrative access to the device.
Review the device configuration or request that the administrator login to the device and observe the terminal. Verify either Option A or Option B (for systems with character limitations) of the Standard Mandatory DoD Notice and Consent Banner is displayed at logon. The required banner verbiage follows and must be displayed verbatim: Option A 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. Option B If the system is incapable of displaying the required banner verbiage due to its size, a smaller banner must be used. The mandatory verbiage follows: “I've read & consent to terms in IS user agreem't.”
Configure all management interfaces to the network device to display the DoD mandated warning banner verbiage at login regardless of the means of connection or communication. The required banner verbiage that must be displayed verbatim is as follows: Option A 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. Option B If the system is incapable of displaying the required banner verbiage due to its size, a smaller banner must be used. The mandatory verbiage follows: “I've read & consent to terms in IS user agreem't.”
Review the management connection for administrative access and verify the network element is configured to time-out the connection after 10 minutes or less of inactivity.
Configure the network element to ensure the timeout for unattended administrative access connections is no longer than 10 minutes.
Review the network device configuration and validate there are no group accounts configured for access.
Configure individual user accounts for each authorized person then remove any group accounts.
Review the accounts authorized for access to the network device. Determine if the accounts are assigned the lowest privilege level necessary to perform assigned duties. User accounts must be set to a specific privilege level which can be mapped to specific commands or a group of commands. Authorized accounts should have the greatest privilege level unless deemed necessary for assigned duties. If it is determined that authorized accounts are assigned to greater privileges than necessary, this is a finding.
Configure authorized accounts with the least privilege rule. Each user will have access to only the privileges they require to perform their assigned duties.
Review the organization's responsibilities list and reconcile the list of authorized account with those accounts defined for access to the network device. If an unauthorized account is configured for access to the device, this is a finding.
Remove any account configured for access to the network device that is not defined in the organization's responsibilities list.
Review the network device configuration to verify only secure protocols using FIPS 140-2 validated cryptographic modules are used for any administrative access. Some of the secure protocols used for administrative and management access are listed below. This list is not all inclusive and represents a sample selection of secure protocols. -SSHv2 -SCP -HTTPS -SSL -TLS If management connections are established using protocols without FIPS 140-2 validated cryptographic modules, this is a finding.
Configure the network device to use secure protocols with FIPS 140-2 validated cryptographic modules.
Review the configuration to verify all attempts to access the device via management connection are logged.
Configure the device to log all access attempts to the device to establish a management connection for administrative access.
Review the network element configuration to determine if the vendor default password is active.
Remove any vendor default passwords from the network element configuration.
Have the administrator display the OS version in operation. The OS must be current with related IAVMs addressed.
Update operating system and address all related IAVMs.
Review the network device configuration to verify all management connections for administrative access require authentication.
Configure authentication for all management connections.
The SA shall define clipping levels / thresholds as a baseline to display alert messages on specific attacks identifying the potential security violation or attack. Review the IDS or firewall configuration to determine what alerts have been defined and how the notifications are performed.
Configure the IDS or firewall to alarm the SA of potential attacks or system failure.
Verify the mechanism controlling the spooling of IDPS data is in place to move the data to the Network Management network.
Configure the IDPS sensor to spool the IDS data before data overflow occurs.
Review the device configuration to verify it is configured to use SNMPv3 with both SHA authentication and privacy using AES encryption. If the site is using Version 1 or Version 2 with all of the appropriate patches and has developed a migration plan to implement the Version 3 Security Model, this finding can be downgraded to a Category II. To verify the appropriate patches on CISCO devices: Check the following IAVMs associated with SNMPv1: 1. 2001-B-0001 (V0005809) Cisco IOS Software SNMP Read-Write ILMI Community String Vulnerability 2. 2002-A-SNMP-001 (V0005835) Multiple Simple Network Management Protocol Vulnerabilities in Perimeter Devices (Cisco Security Advisory: Malformed SNMP Message-Handling Vulnerabilities) To verify the appropriate patches on other vendors refer to this web site: http://www.cert.org/advisories/CA-2002-03.html. If the targeted asset is running SNMPv3 and does not support SHA or AES, but the device is configured to use MD5 authentication and DES or 3DES encryption, then the finding can be downgraded to a Category III. If the site is using Version 1 or Version 2 and has installed all of the appropriate patches or upgrades to mitigate any known security vulnerabilities, this finding can be downgraded to a Category II. In addition, if the device does not support SNMPv3, this finding can be downgraded to a Category III provided all of the appropriate patches to mitigate any known security vulnerabilities have been applied and has developed a migration plan that includes the device upgrade to support Version 3 and the implementation of the Version 3 Security Model.
If SNMP is enabled, configure the network element to use SNMP Version 3 Security Model with FIPS 140-2 validated cryptography (i.e., SHA authentication and AES encryption).
Review the network element configuration and verify if either of the SNMP community strings “public” or “private” is being used.
Configure unique SNMP community strings replacing the default community strings.
Review the configuration and verify a session using the console port will time out after 10 minutes or less of inactivity.
Configure the timeout for idle console connection to 10 minutes or less.
Review the network device's configuration and verify authentication is required for console access.
Configure authentication for console access on the network device.
Review the configuration and verify management access to the device is allowed only from hosts within the management network.
Configure an ACL or filter to restrict management access to the device from only the management network.
Review the configuration and verify the timeout is set for 60 seconds or less. The SSH service terminates the connection if protocol negotiation (that includes user authentication) is not complete within this timeout period.
Configure the network element so it will require a secure shell timeout of 60 seconds or less.
Review the configuration and verify the number of unsuccessful SSH login attempts is set at 3.
Configure the network element to require a maximum number of unsuccessful SSH login attempts at 3.
Review the device configuration to determine if threshold filters or timeout periods are set for dropping excessive half-open TCP connections. For timeout periods, the time should be set to 10 seconds or less. If the device can not be configured for 10 seconds or less, it should be set to the least amount of time allowable in the configuration. Threshold filters will need to be determined by the organization for optimal filtering.
Configure the device to drop half-open TCP connections through threshold filtering or timeout periods.
Review the configuration and verify the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected.
Disable the auxiliary port. If used for out-of-band administrative access, the port must be connected to a secured modem providing encryption and authentication.
Review the network device or syslog server to determine whether alerts are configured to automatically generate and notify the administrator when seventy-five percent or more of the storage capacity has been reached with log data.
Configure the network device or syslog server to automatically generate and notify the administrator when seventy-five percent or more of the storage capacity has been reached with log data.
Review the device configuration and verify it is authenticating the NTP messages received from the NTP server or peer. Authentication must be performed using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by both the NTP client and server, then MD5 can be used.
Configure the device to authenticate all received NTP messages using either PKI (supported in NTP v4) or SHA-1 hashing algorithm. If SHA-1 is not supported by this client or the NTP peer or server, then MD5 can be used.
Review the configuration and verify SSH Version 1 is not being used for administrative access.
Configure the network element to use SSH version 2.
The managed network element’s OOBM interface must be configured with an IP address from the address space belonging to the OOBM network. After determining which interface is connected to the OOBM access switch, review the managed device configuration and verify the interface has been assigned an address from the local management address block.
Configure the managed network element’s OOBM interface with an IP address from the address space belonging to the OOBM network.
Verify the IP address assigned to IDPS consoles and servers are designated for the management network.
Configure all IDPS consoles and servers with IP addresses designated for the management network.
Review the configuration and ensure the interfaces with data flow do not have an IP address.
Remove the IP addresses from all interfaces monitoring data flow.
Check the thresholds to ensure a message is sent when data overflow has occurred.
Configure the device to send messages to indicate data overflow is occurring.
Review the Whitelists and Blacklists used by the IDPS and interview the SA to determine when the last update occurred. These lists are updated frequently by the vendor.
Create a periodic update schedule to review the Whitelists and Blacklist.
Have the IDPS SA display the configuration settings. Verify all http ports are defined and have the SA identify the signatures that will review applications using port redirection. Review and tune as necessary the signatures that are specific to vulnerabilities in Web servers.
Configure the IDPS to protect the Web components.
Signatures are usually defined for each FTP command. Verify all FTP commands are being monitored by the IDPS.
Add all signatures for FTP commands to the IDPS that monitors file servers.
Review the IDPS configuration and ensure the device is protecting the Network Management subnet. Protocols going to the Management network should be known by the SA. Alarms should be generated for unexpected traffic types.
Implement or modify the sensor to protect the Management Network. Expected traffic to this network should be known by the SA.
Ask the SA to identify the signature that protects against IP hijacking of TCP sessions. Ensure the signature is current.
Implement the latest signature from vendor that protects against IP hijacking of TCP sessions.
If DHCP is not being used in the network, drop inbound and outbound TCP and UDP packets with the following port numbers: 67, 68, 546, 547, 647, 847, and 2490 on the IDPS.
Apply inspection on IDPS.
Review the IDPS configuration and verify the signatures are defined to protect against TCP SYN Flood attacks. If the server farm is being monitored by an IDS as opposed to an IPS that can block traffic inline, the following alternatives can be implemented: Upon detection of a SYN flood attack, the IDS can dynamically push (or remotely configure) an ACL unto the upstream router or multi-layer switch that can serve as the blocking device for the TCP SYN flood attack. Configure TCP Intercept on the server farm's first hop router, MLS, or firewall that is controlling access to the server farm sub-net (VLAN).
Apply current signatures to protect against SYN Flood attacks. If the server farm is being monitored by an IDS as opposed to an IPS that can block traffic inline, the following alternatives can be implemented: Upon detection of a SYN flood attack, the IDS can dynamically push (or remotely configure) an ACL unto the upstream router or multi-layer switch that can serve as the blocking device for the TCP SYN flood attack. Configure TCP Intercept on the server farm's first hop router, MLS, or firewall that is controlling access to the server farm sub-net (VLAN).
Have the SA identify the signature and policy established that forges TCP Resets at the perimeter and in front of DMZ server segments when malware and unexpected traffic is identified in the network. If an IPS is not in place to provide this safeguard, verify there is a firewall at the described locations providing the safeguard.
Implement TCP Reset protections to protect the enclave from malware and other unexpected network traffic.
Verify the IDPS protects against DoS LAND attacks. An effective implementation is the use of an Atomic attack signature that looks at a single packet, because State information ( tracking established connections) is not necessary in identifying this attack.
Implement IDPS signatures that protect against LAND attacks.
Identify the IDPS product and discuss the atomic signature installation with the SA. As defined above, regardless of the product type there are signatures that require state and those that do not. Ensure the atomic signatures are applied to all IDPS within the enclave. As a result of no statefulness, the implementation of atomic signatures do not degrade product performance significantly. Validate the signatures are current.
Apply Atomic Signatures to all IDPS components in the enclave. Create a Change management process to receive Atomic signatures daily from the vendor if available, else as frequently as available by vendor.
Review the configuration and verify two NTP servers have been defined.
Specify two NTP server IP addresses on the device to be used to request time from.
Verify the call home service or feature is disabled on the device.
Configure the network device to disable the call home service or feature.