Preface on Sub-Control 5.1

The single metric for sub-control 5.1 Implementation Group 1 (IG1) is:

  • The percentage of the total OS/Software in an enterprise for which security configuration standards are documented and maintained

Specifically, Sub-Control 5.1 checks that the organization maintains documented security configuration standards for all authorized operating systems and software. A passing score on this sub-control is achieved when the organization states that they have established and documented security configuration standards for each endpoint. This is a relatively simple and straightforward check.

Just as with previous sub-controls, the goal of this sub-control is to have a score (or ratio) of zero (all endpoints have documented security standards). However, organizations have an opportunity to easily jump ahead to IG2 or IG3. Active and passive scanning with Tenable products provide the organization with the ability to query a variety of systems. Organizations can verify whether or not endpoints meet established security best practices. Additionally, active scanning can provide organizations with a consistent, repeatable process that can be used to identify endpoints that no longer meet compliance. If all endpoints pass these checks, there are little to no “manual” scoring requirements as part of most of the other sub-control 5.x items in CIS Control 5.

Many products are available that can perform vulnerability scans of endpoint devices and detect missing patches. However, a lack of vulnerabilities does not mean endpoint devices are compliant with any particular standard. By using Nessus and Tenable Security Center, information is aggregated for an entire network or asset class allowing security and risk to be analyzed globally. This allows organizations to spot trends in non-compliant systems and adjust controls to fix these on a larger scale. Nessus can log into Unix and Windows servers, Cisco devices, SCADA systems, IBM iSeries servers, databases, and more, to determine if they have been configured in accordance with the local site security policy. For example:

  • Windows endpoints: Nessus can test for any setting that can be configured as a “policy” under the Microsoft Windows framework. There are several hundred registry settings that can be audited. The permissions of files, directories, and objects can also be analyzed.

  • Unix endpoints: Nessus can broadly be used to test for file permissions, file contents, running processes, and user access control for a variety of Unix-based systems. Currently, checks are available to audit Solaris, Red Hat, AIX, HP-UX, SUSE, Gentoo, and FreeBSD derivatives of Unix.

When using Nessus for compliance scanning, each of the audit file types has a corresponding plugin ID. In Tenable Security Center, however, the audit file plugin ID is not used. In Tenable Security Center when you install an audit file, a new plugin is created for each check with a plugin number greater than ID 1000000. To retain the audit file type, there is a cross reference called “auditFile”. You can view the auditFile value in the Reference Information section of the Vulnerability Detail List tool.

When searching using the Cross Reference field, the XREF TYPE and XREF ID are separated by a pipe (|) character. If the filter should search for more that one XREF TYPE and ID combination, then separate the two phrases with a comma, as shown below.