by David Schwalenberg
October 10, 2016
Maintaining inventories and managing secure configurations are essential to protecting information systems. Default configurations for operating systems, applications, and devices tend to be geared for ease-of-use rather than security. If proper inventories are not maintained, hardware and software could be overlooked and not properly secured. Without change control processes in place, unauthorized changes may weaken network and system protections, and open up security holes. If system configurations are not locked down, attackers likely will find opportunities to exploit them.
The federal government relies heavily on external service providers and contractors to assist in carrying out a wide range of federal missions. Sensitive but unclassified federal information is routinely processed by, stored on, or transmitted through nonfederal information systems. Failing to properly protect this Controlled Unclassified Information (CUI) could impact the ability of the federal government to successfully carry out required missions and functions.
The National Institute of Standards and Technology (NIST) created Special Publication 800-171 "Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations" to provide recommended requirements for protecting the confidentiality of CUI. Federal agencies should use these requirements when establishing contracts and agreements with nonfederal entities that process, store, or transmit CUI.
This Assurance Report Card (ARC) aligns with the Configuration Management family of security requirements in NIST SP 800-171 (section 3.4). These requirements focus on establishing and maintaining inventories and the secure baseline configurations of information systems. Using this ARC, an organization will be better able to monitor inventories and the secure baseline configurations of information systems. This information will assist the organization in managing and securing the configurations of their information systems that process, store, or transmit CUI.
More details on each of the policy statements included in the ARC are given below. Clicking on a policy statement will bring up the analysis screen to display more details related to that policy statement. The ARC policy statement parameters are guides that can be customized as necessary to meet organizational requirements.
This ARC is available in the Tenable.sc Feed, a comprehensive collection of dashboards, reports, Assurance Report Cards, and assets. The ARC can be easily located in the Tenable.sc Feed under the category Compliance. The ARC requirements are:
- Tenable.sc 5.4.0
- Nessus 8.4.0
- LCE 6.0.0
- NNM 5.9.0
- Compliance data
Tenable's Tenable.sc Continuous View (CV) is the market-defining continuous network monitoring solution, and can assist an organization in securing information systems. Tenable.sc CV is continuously updated with information about advanced threats, zero-day vulnerabilities, and new regulatory compliance data. Active scanning periodically examines systems to find vulnerabilities, and can also make use of audit files to assess compliance. Passive listening provides real-time monitoring to collect information about systems and vulnerabilities. Host data and data from other security devices is analyzed to monitor policy and configuration settings activity. Tenable.sc CV provides an organization with the most comprehensive view of the network and the intelligence needed to secure systems and safeguard sensitive information.
ARC Policy Statements
At least 95% of actively and passively detected systems have been scanned for compliance in the past 90 days: This policy statement displays the percentage of detected systems that have been scanned for compliance in the past 90 days. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Systems on the network are detected both passively by the Tenable Nessus Network Monitor (NNM) and actively by Tenable Nessus. Compliance scans are performed by Nessus. Non-compliant systems should be reviewed further by the organization. This policy statement helps an organization measure whether compliance scans are being performed across all systems on a regular basis.
Less than 10% of NIST SP 800-171 Configuration Management compliance checks failed: This policy statement displays the percentage of NIST SP 800-171 Configuration Management compliance checks that failed. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Compliance is measured against those policy checks that reference the Configuration Management family of security requirements in NIST SP 800-171 (section 3.4).
Less than 5% of secure configuration compliance checks failed: This policy statement displays the percentage of secure configuration compliance checks that failed. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Secure configuration settings may include privilege and allowed activity settings, among other things. Compliance is measured against those policy checks that reference standards such as the Cybersecurity Framework, NIST 800-53, the CIS Critical Security Controls, and the PCI Data Security Standard.
Less than 5% of least functionality compliance checks failed: This policy statement displays the percentage of least functionality compliance checks that failed. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Least functionality settings may include requirements to disable unnecessary services and other functionality, among other things. Compliance is measured against those policy checks that reference standards such as the Cybersecurity Framework, NIST 800-53, NIST 800-171, the CIS Critical Security Controls, and the PCI Data Security Standard.
Less than 5% of change control compliance checks failed: This policy statement displays the percentage of secure configuration compliance checks that failed. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Change control settings may include requirements to prevent file changes and software installation, among other things. Compliance is measured against those policy checks that reference standards such as the Cybersecurity Framework, NIST 800-53, and ISO/IEC-27001.
No new hosts detected in the past 7 days: This policy statement displays non-compliant if new hosts have been actively or passively detected within the last seven days. New devices on the network should be identified and evaluated; unauthorized devices should be removed or otherwise restricted.
No hosts with software installed in the past 72 hours: This policy statement displays non-compliant if software install events have been detected on any hosts within the last 72 hours. Software installations on the network should be identified and evaluated; unauthorized software should be removed.
Less than 10% of systems have detected device change events: This policy statement displays the percentage of systems that have reported device change events. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Device change events may include server changes, firewall changes, and router changes, among other things.
Less than 10% of systems have detected software change events: This policy statement displays the percentage of systems that have reported software change events. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Software change events may include software installs and changes, and database changes, among other things.
Less than 5% of systems have detected change spikes: This policy statement displays the percentage of systems that have reported change spikes. If the policy statement requirement is met, the result is displayed in green; otherwise, the result is displayed in red. Change spikes indicate that a large number of network changes were detected compared to previous change event rates. Changes can include new software installations, firewall changes, and more. Organizations can use this information to detect potentially unauthorized changes on the network.