0% found this document useful (0 votes)

55 views

CIS CAS Controls

The document provides specifications for assessing controls from the CIS Controls framework. It outlines sub-controls for 11 basic and foundational controls, including inventory of hardware and software assets, secure configurations, malware defenses, network security, backups, and more. Sub-controls describe specific recommended security configurations and practices.

Uploaded by

gamal abdelaziz

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

55 views

CIS CAS Controls

Uploaded by

gamal abdelaziz

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 191

CIS Controls Assessment Specification

Last Revised: October 27, 2022

Table of Contents

CIS Controls Assessment Specification 6

Basic Controls 9

CIS Control 1: Inventory and Control of Hardware Assets 10

1.4: Maintain Detailed Asset Inventory 14

1.6: Address Unauthorized Assets 22

CIS Control 2: Inventory and Control of Software Assets 26

2.1: Maintain Inventory of Authorized Software 30

2.2: Ensure Software is Supported by Vendor 32

2.6: Address Unapproved Software 37

CIS Control 3: Continuous Vulnerability Management 40

Preface on Sub-Controls 3.4 and 3.5 44

3.4: Deploy Automated Operating System Patch Management Tools 45

3.5: Deploy Automated Software Patch Management Tools 48

CIS Control 4: Controlled Use of Administrative Privileges 50

Preface on Sub-Controls 4.2 and 4.3 53

4.2: Change Default Passwords 57

4.3: Ensure the Use of Dedicated Administrative Accounts 60

CIS Control 5: Secure Configuration for Hardware and Software on Mobile Devices, Laptops,
Workstations and Servers 62

Preface on Sub-Control 5.1 65

5.1: Establish Secure Configurations 67

CIS Control 6: Maintenance, Monitoring and Analysis of Audit Logs 69

6.2: Activate Audit Logging 71

Foundational Controls 73

CIS Control 7: Email and Web Browser Protections 74

Preface on Sub-Controls 7.1 and 7.7 76

7.1: Ensure Use of Only Fully Supported Browsers and Email Clients 78

7.7: Use of DNS Filtering Services 82

CIS Control 8: Malware Defenses 84

Preface on Sub-Controls 8.2, 8.4, and 8.5 86

8.2: Ensure Anti-Malware Software and Signatures Are Updated 89

8.4: Configure Anti-Malware Scanning of Removable Media 92

8.5: Configure Devices to Not Auto-Run Content 94

CIS Control 9: Limitation and Control of Network Ports, Protocols, and Services 96

Preface on Sub-Control 9.4 98

9.4: Apply Host-Based Firewalls or Port-Filtering 102

CIS Control 10: Data Recovery Capabilities 104

10.1: Ensure Regular Automated Backups 107

10.2: Perform Complete System Backups 110

10.4: Protect Backups 112

10.5: Ensure All Backups Have at Least One Offline Backup Destination 114

CIS Control 11: Secure Configuration for Network Devices, such as Firewalls, Routers, and
Switches 116

Preface on Sub-Control 11.4 119

11.4: Install the Latest Stable Version of Any Security-Related Updates on All Network 120

CIS Control 12: Boundary Defense 122

Preface on Sub-Controls 12.1 and 12.4 125

12.1: Maintain an Inventory of Network Boundaries 126

12.4: Deny Communication Over Unauthorized Ports 128

CIS Control 13: Data Protection 130

Preface on Sub-Controls 13.1 and 13.2 133

Preface on Sub-Control 13.6 136

13.1: Maintain an Inventory of Sensitive Information 137

13.2: Remove Sensitive Data or Systems Not Regularly Accessed by Organization 139

13.6: Encrypt Mobile Device Data 141

CIS Control 14: Controlled Access Based on the Need to Know 143

14.6: Protect Information Through Access Control Lists 145

CIS Control 15: Wireless Access Control 147

15.7: Leverage the Advanced Encryption Standard (AES) to Encrypt Wireless Data 149

CIS Control 16: Account Monitoring and Control 151

Preface on Sub-Controls 16.8, 16.9, and 16.11 154

16.8: Disable Any Unassociated Accounts 158

16.9: Disable Dormant Accounts 160

16.11: Lock Workstation Sessions After Inactivity 162

Organizational Controls 164

CIS Control 17: Implement a Security Awareness and Training Program 166

CIS Control 18: Application Software Security 168

CIS Control 19: Incident Response and Management 169

Tenable.sc CAS Dashboard 174

Appendix 180

Audit File Scan Tutorial 181

CIS CAS Audit Requirements 182

Create a New Repository + Scan Zone 183

Create a New Audit File + Policy 185

Create a Scan 186

Run Scan + See the Results 188

CAS Implementation Group 1 Audit Questions 189

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
CIS Controls Assessment Specification
The Center for Internet Security (CIS) and Tenable partnered together to create a guide to help cus-
tomers understand how to implement the CIS Controls. Starting with the SANS Top 20 Controls pub-
lished several years ago, Tenable has continuously helped our customers leverage Tenable.sc
(previously SecurityCenter) to understand their security posture using these controls. CIS Controls ver-
sion 7.1 introduced the concept of Implementation Groups (IGs), which are self-assessed categories for
organizations based on specific cybersecurity attributes. The security community has assessed the
Controls and identified these 20 controls to be reasonable for an organization to implement. Other
standards such as Cybersecurity Maturity Model Certification (CMMC) and Cyber Security Framework
(CSF) also have a tiered approach to deployment. By grouping the controls into three categories, the
implementation is easier to understand and integrate into security operations.

This guide is focused on Implementation Groups 1 (IG1); however, many of the controls have require-
ments for input that come from active or passive network scanning. As Tenable is a Cyber Exposure
and Vulnerability Management company, any guidance provided will best serve the organization with
Tenable.sc Continuous View deployed using active and passive scanning. For controls that Tenable is
not able to directly assist with, suggestions on how to use Tenable products will be provided to aid in
the successful completion of the control.

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
The 20 CIS Controls are broken down into three categories: Basic, Foundational, and Organizational.
The Basic Controls (first six controls) are commonly referred to as the “cyber hygiene” controls. These
controls focus on basic security guidelines; for example, Configuration Management, Vulnerability
Assessment, and Continuous Monitoring. The next group, Foundational Controls (7 - 16), enable an
organization to build a framework for a good security program. The last category, Organizational Con-
trols (final four controls) provide more guidance with respect to people and process.

Tenable assists organizations in taking charge of their cybersecurity program with five steps to suc-
cessful cybersecurity. These five steps are Discover, Assess, Analyze, Fix, and Measure. For IG1 organ-
izations, these five steps align closely with efforts across the Basic and Foundational categories. With
Cyber Hygiene being the focus of the first six controls, these actions align closely with the Discover
step. Starting with controls 1 & 2, organizations begin to discover hardware and software assets. The
remaining steps Assess, Analyze, Fix and Measure are seen throughout the remaining controls. Con-
trols 3, 4, 5, 8, and 11 are all key aspects to Tenable’s core ability to help assess risk. For the other cat-
egories, Tenable can often aid in the understanding of configuration problems or situational context
based on discovered vulnerabilities.

By combining Tenable's Five Steps To Cybersecurity Success and the CIS Controls into a unified pro-
cess, an organization can more easily secure their network. Using the CIS Control Assessment Spe-
cification (CAS) as a detailed guide, the security team can easily align their efforts in vulnerability
management to meet the CIS Control requirements. Using the inputs and measures found in the CAS,
the security team can operationalize the controls and use Tenable.sc as the source of truth for many
controls, and for other controls the data within Tenable.sc will add value.

This guide provides a section for each CIS Control, and sub-sections for each Sub-Control. Examples
of queries and dashboard use cases are provided. The security team can follow the CAS and this guide
for a more successful deployment of the CIS Controls.

l CIS Control 2: Inventory and Control of Software Assets

l CIS Control 3: Continuous Vulnerability Management

l CIS Control 4: Controlled Use of Administrative Privileges

l CIS Control 5: Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Work-
stations and Servers

l CIS Control 6: Maintenance, Monitoring and Analysis of Audit Logs

“Attackers, who can be located anywhere in the world, are continuously scanning the
address space of target organizations, waiting for new and possibly unprotected systems
to be attached to the network. They are particularly interested in devices which come and
go off of the enterprise’s network such as laptops or Bring-Your-Own-Device (BYOD) which
might be out of synchronization with security updates or might already be compromised.
Attacks can take advantage of new hardware that is installed on the network one evening
but not configured and patched with appropriate security updates until the following day.
Even devices that are not visible from the Internet can be used by attackers who have
already gained internal access and are hunting for internal pivot points or victims. Addi-
tional systems that connect to the enterprise’s network (e.g., demonstration systems, tem-
porary test systems, guest networks) should also be managed carefully and/or isolated in
order to prevent adversarial access from affecting the security of enterprise operations.”

Any journey begins with single step, and the journey of implementing the CIS Controls begins with
inventory of hardware assets. A hardware asset is any device that operates at the Datalink layer (Layer
2) or the Network layer (Layer 3). These devices, whether they are connected to the network or not, can
store or provide access to sensitive data. Therefore, their risk must be identified. By discovering
assets within the organization, the CISO can begin to establish an inventory and can then begin assess-
ing and mitigating associated risks to the asset. To accomplish this, though, our first priority is to dis-
cover the assets. The CIS Control 1 Dashboard provides information to assist in identifying assets
collected during a vulnerability scan.

The Discover step helps organizations identify and map every asset across any computing envir-
onment. In this phase, Tenable.sc Continuous View (CV) allows the CISO to detect assets through active
scanning, passive network analysis, and event log discovery. By utilizing these three methods of dis-
covery, the CISO can build a more complete list of hardware assets and begin to understand a clearer
picture of risk on the network.

The CAS provides guidance on how to assess the organization's progress in this journey. This guide
illustrates how the CISO can effectively measure progress. Shown below are the CIS Control 1 IG levels
and requirements.

Active Scanning and passive Scanning, specifically:

l ICMP/TCP/SYN/ACK identification

l OS fingerprinting

l Pulling data from switches and routers regarding connected devices

All devices that have an IP address (whether they are wired/wireless and/or physical/virtual) are to be
included in the asset inventory.

Asset Type Security Function Implementation Groups

Devices Identify 1, 2, 3

Dependencies
l None

Inputs
1. Endpoint Inventory (I1): The organization’s current inventory list (aka the “to be checked” list).

a. This list is a static list of the number of assets the organization currently has or believes
they have. For example, the organization should be aware of the number of laptops,
desktops, servers, routers, switches, wireless Access Points, or other devices that are cap-
able of obtaining an IP address. Use the count, or number of these devices for this input.
The CISO is the resource who has a complete list of devices.

i. If the organization does not have a list of devices for this input, they can created a
list of assets by utilizing DHCP logs, or other similar resources which track assets. In
the example image below, a Windows DHCP Server’s Address Leases are reviewed

2. "Ground Truth” Inventory (I2): A list to compare with input 1 (I1). This list is enhanced by manual
verification. However, a tool-generated or aggregated list can also be substituted. This list
should be an aggregation of the devices detected over a period of time, but preferably not from a
single scan. Scans should be conducted frequently. For example, a scan using plugin 10180 has
very little effect on network performance, and can be conducted daily.

a. Tenable.sc uses Nessus as the active discovery tool, and stores the collected data in a
cumulative database. The database is considered cumulative because all data collected on
the assets using active, passive, and event scanning methods are stored in a single repos-
itory for analysis.

3. Procedural Write-up for Adding or Removing Assets to or from the Inventory: an input only
for manual review. This is a required physical document detailing the procedure for adding or

Assumptions
l Devices belonging to the organization, but not connected to the organization’s network, require
manual discovery in order to be included in the “Ground Truth” inventory.

l Audit File: Questions regarding connected devices.

Operations
l If I1 is not provided, this sub-control is measured at a 0 (complete fail).

l If I2 is not provided, no true accuracy measurement can be made for this sub-control. However,
I2 can be obtained from the CIS Sub-Control 1 on the CAS Control 1 (IG1) Dashboard available
within Tenable.sc. The Tenable.sc component provides a summary of devices found on the net-
work, as identified by Nessus. The following screenshots show the captured plugin output and
the filters used within the component to capture the required data.

l This, or any data contained within a component can be easily exported to a spreadsheet for fur-
ther analysis and processing:

a. Click on the blue arrow in the top right corner of the component.

b. On the Vulnerability Analysis page, click Options.

c. Choose the method by which you want to export the data.

Optionally, you can also send the entire dashboard to a report:

a. On the Dashboards page, click Options.

b. Select Send to Report.

Many of the tasks associated with this control are manual. However, active and passive discovery tools
are available to assist you. In addition, using active and passive discovery tools to detect and inventory
assets can help organizations meet the other Sub-Control CAS IG2 and IG3 requirements for Control 1.
Tenable.sc allows organizations at all IG’s to collect unique information about each asset scanned via
an active scanning tool. Using Nessus, Tenable.sc initially port scans each asset and collects any open
ports grabbing service banners where applicable. Next, when scanned with credentials, Nessus logs in
to the system and collects a multitude of system configuration data. While Tenable.sc is known for vul-
nerability data collected, it also collects a wide range of asset identification attributes such as MAC
address, and CPU GUIDs. CIS Control 1 (Inventory of Hardware Assets Dashboard) contains actively col-
lected attributes for further analysis by the operations teams. For more information, see
https://www.tenable.com/sc-dashboards/cis-control-1-inventory-of-hardware-assets.

Tenable.sc Continuous View includes Nessus Network Monitor (NNM). Using NNM, Tenable.sc can dis-
cover assets on the network using a Switch Port Analyzer (SPAN) port. SPAN ports are also commonly
referred to as Mirrored ports. These ports provide copies of traffic to a Network Interface Card (NIC)
for analysis.

NNM is a network discovery and vulnerability analysis software solution that delivers continuous net-
work listening, profiling, and monitoring in a non-intrusive manner. NNM monitors network traffic at
the packet layer to determine topology, services, and vulnerabilities. It is tightly integrated with Ten-
able.sc and Log Correlation Engine (LCE) to centralize both event analysis and vulnerability man-
agement for a complete view of your security and compliance posture.

Measures
Measure Definition

M1 = List of items in the inter- A list of items that are either: in I2 but not in I1, or items that
section of Input 1 and Input 2. M1 are in I1 but not in I2. The creation of this list is a manual task
is derived from the Operations that requires reviewing all the assets from each of those lists.
section of this document.

M2 = Count of items in M1 A count of the total number of items identified in M1.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of items in I1 and not in A list of devices that the organization believes they have, but
I2 that have not been found on the network.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of items in I2 and not A list of items that were identified from scanning but that are
in I1 unknown to the organization.

M8 = Count of items in M7 A count of the total number of items in M7.

Metrics
Accuracy Score

Metric Calculation

The percentage of the “Ground Truth” inventory that is accoun- M2 / M4

ted for in the organization’s current asset inventory.
M2 is a count of the items from
the intersection of I1 and I2.

M4 is the count of the items

that have been identified.

Procedure Review

After the accuracy score is calculated, there must be a manual review/rating of the inventory pro-
cedures. This includes adding and removing assets and the time allowable or expected for the acquis-
ition or disposal of assets.

Reconcile I1 with any new devices that have been identified that should be part of the asset inventory.
In many cases, devices can be added to an organization over time and not be properly accounted for.

Asset Type Security Function Implementation Groups

Devices Respond 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

Inputs
1. Unauthorized Assets: A list of discovered assets not currently present in the asset inventory.
This can be pulled from sub-control 1.4, Measure M3. This is a list of any found asset that was not
previously known to the organization. The information from M3 must be brought into this sub-
control as Input 1.

2. Endpoint Inventory: The current hardware inventory. This can be pulled from I2 sub-control 1.4,
Inventory I1. This is a complete and accurate inventory of all the devices within the organization.

3. Definition of "Timely": An organizationally defined time frame for the term “timely”. The CIS
recommends a turnaround of 24 hours or less.

4. (Optional) Disposition of Items: Measurement results are more useful if the status (removed,
added to inventory, quarantined, etc.) is provided and verified. This is not, however, required.
Verification can be easily achieved with continued use of active and passive scanning tech-
niques which determine if a device is still on the network. Assets/devices that are removed from
the network can be validated as removed by a subsequent scan at a specified time period.

Operations
If the optional disposition list is provided, the checks would be tailored to those dispositions. For the
following, assume no disposition list is available:

2. For those I1 items that are not in I2, scan the network to determine if the item is still reachable on
the network.

Assumptions

If the item is not reachable, it may be reasonable to assume it has been removed from the network.

Measures
Measure Definition

M1 = List of M1 can be copied from sub-control 1.4, Measure M7. A list of items that were
items not in the identified from scanning but that are unknown to the organization. This is also
inventory the number of items from Input 1 NOT passing either Operation 1 or Operation
2.

M2 = Count of A count of the total number of items in M1. This can also be copied from sub-
items in M1 control 1.4, Measure M8.

M3 = List of A list of items that are considered unreachable. This can be curated by using a
items not reach- Tenable.sc component that displays a list of assets/devices by Class C address
able space that are unreachable. The component works by utilizing the output of
plugin 10180 to ping the remote host. The plugin output of “is considered dead”
uses a timeframe of the last 7 days to determine which assets/devices have
been removed from the network over the last 7 days. This timeframe can be
changed to what the organization deems appropriate. This component
accepts custom values. .

This measure is aided by Tenable.sc CV using Nessus. The following screen-

shots show the captured plugin output and the filters used within the com-
ponent to capture the required data.

M5 = List of A list of items that are considered missing from the inventory or that are
items not in the unreachable. The inventory must first be reconciled, at which point you can
inventory or determine which items are rogue and should be removed.
that are
unreachable

M6 = Count of A count of the total number of items in M5.

items in M5

M7 = List of A list of items that are in the current inventory. This can be derived from sub-
items in the control 1.4, Input 1.
inventory

M8 = Count of A count of the total number of items in M7.

items in M7

Metrics
Unauthorized Asset Remediation

The ratio of unaccounted for, unauthorized assets as If the value of M6 is 0, there are no unau-
compared to the total number of assets in the asset thorized assets that remain unac-
inventory. counted for.

In this case, the value of the metric is 1.

Otherwise, the value is:

(M8 - M6) / M8

The CIS states this control is critical:

“Attackers continuously scan target organizations looking for vulnerable versions of soft-
ware that can be remotely exploited. Some attackers also distribute hostile web pages,
document files, media files, and other content via their own web pages or otherwise trust-
worthy third-party sites. When unsuspecting victims access this content with a vulnerable
browser or other client-side program, attackers compromise their machines, often
installing backdoor programs and bots that give the attacker long-term control of the sys-
tem. Some sophisticated attackers may use zero-day exploits, which take advantage of
previously unknown vulnerabilities for which no patch has yet been released by the soft-
ware vendor. Without proper knowledge or control of the software deployed in an organ-
ization, defenders cannot properly secure their assets.

Poorly controlled machines are more likely to be either running software that is unneeded
for business purposes (introducing potential security flaws), or running malware intro-
duced by an attacker after a system is compromised. Once a single machine has been
exploited, attackers often use the compromised system as a staging point for collecting
sensitive information from the compromised system and from other accessible systems
connected to it. In addition, compromised machines are used as a launching point for
movement throughout the network and partnering networks. In this way, attackers may
quickly turn one compromised machine into many. Organizations that do not have com-
plete software inventories are unable to find systems running vulnerable or malicious soft-
ware to mitigate problems or root out attackers.

Managed control of all software also plays a critical role in planning and executing system
backup, incident response, and recovery.”

For more information about the CIS Control 2 dashboard, see CIS Control 2: Inventory and Control of
Software Assets.

In the discovery phase Tenable.sc Continuous View (CV) provides the CISO with the ability to detect
assets through active scanning and passive network analysis. Utilizing these methods, the CISO is
already transitioning from the IG1 to IG2, and is building a more complete list of software assets, and is
able to better understand the current risk in the network. The CAS provides guidance on how to assess
the organization's progress in this journey. Shown below is the CIS Control 1 IG levels and require-
ments.

Active Scanning and passive Scanning, specifically:

l Identify software/applications that are installed on hosts

l Identify patching/version information on detected software/applications

Asset Type Security Function Implementation Groups

Applications Identify 1, 2, 3

Dependencies
l None

Inputs
1. Authorized Software List: The authorized software list that contains a timestamp indicating
both the last updated and last verified values. The organization should have a list of all approved
applications. Reviewers should identify organizational artifacts such as a “Gold” image that is
used to provision servers and/or desktops/laptops, purchase orders, and license agreements to
create a master list of approved software.

2. Definition of “Up-to-Date”: An organizationally defined time frame for the term “up-to-date".
This time frame includes remediating issues, such as removing unapproved software or patching
unsupported/out-of-date software. The CIS recommends this be at least monthly.

Operations
1. Test for the presence of the list. This is a TRUE/FALSE value (M1).

2. (Optional) If specific attributes of the software are deemed required, test for those (vendor,
product name, version, business case, etc.)

a. We highly recommended that software versions be checked when evaluating installed soft-
ware. Reviewing software versions information ensures all software components are
patched and up to date. Patching remains a critical concern for organizations to protect
themselves.

Measures
l M1:
o TRUE if the authorized software list is present and in the proper format.
o FALSE if the authorized software list is not present or is in the incorrect format.

l M2:
o TRUE if the most recent update/verification is within the “up-to-date” threshold
o FALSE if the most recent update/verification is not within the “up-to-date” threshold

Metrics
Update Quality

Metric Calculation

Is the authorized software list present and up-to-date? M1 AND M2

Asset Type Security Function Implementation Groups

Applications Identify 1, 2, 3

Dependencies
l Sub-control 2.1: Maintain Inventory of Authorized Software

Inputs
1. Authorized Software List: An authorized software list with a notation of “supported” or “unsup-
ported” for each entry (sub-control 2.1). This can be pulled from sub-control 2.1, I1, however, each
piece of software must then be marked as "supported" or "unsupported".

2. Authoritative Source of Information: Access to an authoritative source of information indic-

ating supported/unsupported details per product.

a. There are many active and passive scanning options for the identification of applications
and identification of unsupported applications. For example, selected Plugin Families
along with a Vulnerability Text of ‘unsupported” can be used to identify detected unsup-
ported applications and operating systems.

c. Common Platform Enumeration (CPE) Strings can also be used, and are a common method
for the identification of specific applications. For example, if Apache Tomcat is an author-
ized application, you can use the CPE string to retrieve information for that specific applic-
ation. As shown below, Apache Tomcat is displayed in the fourth row of CPE strings.

l For Linux: Nessus Plugin ID 22869 Software Enumeration (SSH)

l For Windows: Nessus Plugin ID 20811 Microsoft Windows Installed Software Enu-
meration (credentialed check)

l For MacOS: Nessus Plugin ID 83991 List Installed Mac OS X Software

Operations

a. Using the organizations list of known approved software I1, compare the list of software
that has been found to exist within the organization I2 using active and passive detection
and the methods outlined above for each of the following operations.

2. For each entry in I1 labeled “supported”, perform a lookup in I2.

a. From these lookups, note the list of authorized software labeled “supported” but that is
actually not supported based on the authoritative source lookup.

3. For each entry in I1 labeled “unsupported”, perform a lookup in I2.

a. From these lookups, note the list of authorized software labeled “unsupported” but that is
actually supported based on the authoritative source lookup.

Measures
Measure Definition

M1 = List of items in the authorized A combination of Operation 1 and those initially marked as
software list that are unsupported unsupported in I1, resulting in a complete list of unsup-
ported applications.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of authorized software A full list of the applications the organization is authorized
to have.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of items in the authorized A list of applications that the organization believes to be
software list that are mislabeled as supported, but are actually found to be unsupported.
supported

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of items in the authorized A list of applications that are believed to be unsupported
software list that are mislabeled as but that are actually supported.
unsupported

M8 = Count of items in M7 A count of the total number of items in M7.

Metric Calculation

The percentage of authorized software in use is that is unsupported. (M4 - M2) / M4

Rate of False Positives

Metric Calculation

The percentage of software listed as supported that is actually unsupported. (M4 - M5) / M4

Percentage of Unsupported Software in Use

Metric Calculation

The percentage of software listed as unsupported that is actually supported. (M4 - M8) / M4

Asset Type Security Function Implementation Groups

Applications Respond 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 2.1: Maintain Inventory of Authorized Software

Inputs
1. Authorized Software List: The previous list of authorized software (sub-control 2.1, I1).

2. Definition of "Resolved": An organizationally defined allowable time frame for the resolution of
discovered unauthorized software. The CIS recommends this occure at least monthly.

3. Software-Capable Endpoints: The list of endpoints to be checked (sub-control 1.4). This should
include all the organizations devices.

4. Authorized Software List: The updated authorized software list, following the time frame
defined in I2.

5. “Scanning Threshold”: The time period between scan 1 and scan 2.

Assumptions
l For I4, the authorized software list may have been updated after a manual review of unau-
thorized software based on user requests, etc.

l For I5, the scanning threshold time period is greater than the resolution time frame defined in I2.

Operations

a. Perform an active credentialed scan against each device on the network. There are two plu-
gins when conducting credentialed scans that enumerate installed software on the host.

i. For Linux: Nessus Plugin ID 22869 Software Enumeration (SSH)

ii. For Windows: Nessus Plugin ID 20811 Microsoft Windows Installed Software Enu-
meration (credentialed check)

2. Compare the installed software list for each endpoint (M1) to the authorized software list (I1) to
generate the unauthorized software list for that endpoint (M2). This list is the software that is
found/identified on any host that the organization does not have a license to use, or policy pro-
hibits its installation. For example, the application and protocol analyzer Wireshark may be con-
sidered free to use, but organization policy may not authorize its installation.

3. Wait the defined “scanning threshold” period (I5) and re-scan the endpoints specified by I3.

4. For each piece of software listed in M2, determine if scan from Operation 3 still shows that soft-
ware as present.

5. For those that are still present, check I4 to determine if the software is now present on the
updated authorized software list. Software that remains installed on the machine, but that does
not appear on the updated authorized software list, is added to the unaddressed software list for
that endpoint (M3).

Measures
Measure Definition

M1 = Installed software on a given A list of all installed software/applications. This is derived

endpoint from the scan defined in Operation 1.

M2 = Unauthorized software A list of unauthorized software/applications. This is

installed on a given endpoint. derived from comparing M1 to I1.

M3 = Unaddressed software A list of any unauthorized software/applications still

installed on a given endpoint, iden- present on the endpoint after a follow-up scan (Operation
tified by follow-up scan. 3) at a specified interval.

M5 = Count of items in M3 A count of the total number of items in M3.

Metrics
Unauthorized Software (Per Endpoint)

Metric Calculation

Ensure unauthorized software installations are addressed. (M4 - M5) / M4

Unauthorized Software (Organizational)

The organizational metric is calculated by averaging the results of the Per Endpoint metric above.

l Security configurations of systems

l Misconfigurations

l Unauthorized changes

l Patch levels of systems

Vulnerability assessment tools should follow industry recognized vulnerability, configuration, and plat-
form classification schemes such as:

l Vulnerability Priority Rating (VPR)

l Common Vulnerabilities and Exposures (CVE)

l Common Configuration Enumeration (CCE)

l Open Vulnerability and Assessment Language (OVAL)

l Common Platform Enumeration (CPE)

l Common Vulnerability Scoring System (CVSS)

l Extensible Configuration Checklist Description Format (XCCDF)

In addition, identified concerns should be reconciled/mitigated in a timely manner, using follow up vul-
nerability scanning as validation. For CIS Control 3, Tenable products allow organizations to effectively
address, report, and follow up on these industry standards via active, credentialed scanning, across all
three Implementation Groups. A number of dashboards, reports, and Assurance Report Cards (ARC) are
readily available to provide organizations with real time continuous vulnerability monitoring and report-
ing, such as the CIS Control 3/18 Continuous Vulnerability Management and Application Security Dash-
board.

The CIS states this Control is critical:

“Cyber defenders must operate in a constant stream of new information: software

updates, patches, security advisories, threat bulletins, etc. Understanding and managing
vulnerabilities has become a continuous activity, requiring significant time, attention, and
resources. Attackers have access to the same information and can take advantage of
gaps between the appearance of new knowledge and remediation. For example, when
researchers report new vulnerabilities, a race starts among all parties, including: attackers
(to “weaponize,” deploy an attack, exploit), vendors (to develop, deploy patches or sig-
natures and updates), and defenders (to assess risk, regression-test patches, install).

Organizations that do not scan for vulnerabilities and proactively address discovered flaws
face a significant likelihood of having their computer systems compromised. Defenders
face particular challenges in scaling remediation across an entire enterprise, and pri-
oritizing actions with conflicting priorities, and sometimes uncertain side effects.”

The CAS provides guidance on how to assess the organization's progress in this journey. This guide
illustrates how the CISO can effectively measure cybersecurity success. Shown below are the CIS Con-
trol 3 IG levels and requirements.

Credentialed Active Scanning, specifically:

l Identify operating systems/software/applications that are installed on hosts

l Identify patching/version information on detected operating systems/software/applications

The ultimate goal of these sub-controls is to have a score (or ratio) of zero (The number of patches
applied to each end point is the same as the number of patches that are available from the vendor for
the OS or Software, i.e., there are no missing patches). Automated patch management tools can help
organizations ensure that critical security concerns are patched as soon as a fix is available. However,
there will always be patches that require manual updates. Completely relying on automated patch man-
agement as the only option results in poor patch management practice. This leads us to question: how
do we make it better?

Tenable products are able to query a variety of patch management solutions and verify whether or not
patches are installed on managed systems. Additionally, Nessus can also report on unmanaged hosts,
hosts that have fallen out of management, or hosts that aren’t functioning properly. Implementing a
comprehensive patch management policy can provide organizations with a consistent, repeatable pro-
cess that can keep systems up to date. If all systems are up to date, there is little to no “manual” scor-
ing requirements as all ratios would be zero. Any systems out of patching compliance would be easily
identified. The effort to capture and calculate the Inputs, Operations, and Measurements of the fol-
lowing sub-controls would greatly be reduced.

At the same time, we must also consider that if an organization has specific separate devices, such as
database servers, web servers, mail servers, etc., each server type may have a different subset of
applications installed. Or, in some cases, those applications may be combined onto a single server.
Organizations must also be able to identify what software is appropriate for each endpoint device,
removing inappropriate software in addition to patching.

Asset Type Security Function Implementation Groups

Applications Protect 1, 2, 3

Dependencies
l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Required OS auto-update configuration: This could vary by organization, by product, by secur-
ity tool, etc. This could be 1 setting or multiple settings. You must also determine if partial set-
tings are creditable, the potential weighting of settings, dependencies, etc.

2. List of required updates: This could be pulled from the vendor’s website, or could be an organ-
ization’s selected subset of updates.

l Optional Field: If time metrics are desired, this list also needs to show the date when each
update was released by the vendor.

l Continuous vulnerability scanning and integration with patch management systems can
often lessen the burden on organizations to visit vendor sites and pull lists of updates. Ten-
able.sc Continuous View (CV) supports a wide variety of patch management solutions
including SCCM, WSUS, HCL BigFix, Dell KACE K1000, and Symantec Altiris.

3. List of endpoints to be checked: Ideally, this includes all assets. While some hardware devices
exist that rarely receive patches, all endpoints should be monitored on a regular basis. The list of
endpoints can be pulled from the "Ground Truth" devices of Sub-Control 1.4, because this list
includes all known devices on the network as identified by continuous scanning.

4. Optional: Time metrics: The allowable time frame for installation of an update after its release.
CIS recommends this be at least 30 days.

2. For each endpoint in I3, retrieve a list of installed OS updates (M2) and compare that endpoint’s
installed updates to the required updates provided by I2. The list of matching updates is M3.

3. (Optional) If timing metrics are desired, for each endpoint, also determine the elapsed time
between the update release date provided in I2 and the install date for each of the corresponding
updates on the endpoint. This information could be added as another field attached to each
update entry in M3.

Measures
Measure Definition

M1 = Auto- The endpoint-specific auto-update configuration score as determined by

update con- Operation 1.
figuration score

M2 = List of An endpoint-specific list of installed updates as determined by Operation 2.

installed updates

M3 = List of An endpoint-specific list of required updates that are installed, as determ-

required updates ined in Operation 2. This is a full list of updates that are installed for each end-
point.

M4 = Number of The number of required OS updates per I2. This is a count of any updates that
required updates are required to be installed.

M5 = Count of A count of the total number of items in M3.

items in M3

Metrics
Update Effectiveness (Per Endpoint)

For a given endpoint, the calculated ratio of If M4 = 0, this indicates the endpoint requires
installed OS updates compared to the total num- no OS updates. Otherwise, this metric is cal-
ber of OS updates required. culated as M5 / M4

Update Effectiveness (Organizational)

The organizational metric is calculated by averaging the results of the Per Endpoint metric above.

Asset Type Security Function Implementation Groups

Applications Protect 1, 2, 3

Dependencies
l Sub-control 2.1: Maintain Inventory of Authorized Software

Inputs
l Authorized Software List: An authorized software list (ASL; sub-control 2.1) and information on
the current authorized version.

l Authoritative Source of Information: Access to an authoritative source of information indic-

ating version details by product.

l List of Approved Exceptions: A list of approved exceptions that notes any reasons that an
authorized software package does not match the latest version.

Operations
1. For each software in I1, list the software products that do not match the latest version as
described by I2.

2. For each endpoint, obtain the current software load (the list of installed software). This inform-
ation can be retrieved from sub-control 2.1.

3. For each endpoint, list the installed software that does not match the current authorized version
from I1.

4. For each software product listed in Operation 3, list any that exist in the approved exceptions list
(I3).

M1 = List of authorized soft- A list of authorized software products installed on the endpoint
ware products at wrong ver- that are not at the latest version.
sion

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of all authorized A list of all authorized software products installed on the end-
software products point.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of authorized soft- A list of authorized software products installed on the endpoint
ware with exceptions that are not at the latest version, but have approved exceptions.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Update Effectiveness (Per Endpoint)

Metric Calculation

For a given endpoint, the If M2 == 0, this indicates the endpoint requires no software
ratio of installed software updates. If (M2 - M5) == 0, this indicates the endpoint
updates compared to the requires software updates, but the out-of-date software has an
total number of required soft- approved exception. Otherwise, this metric is calculated as (M2
ware updates. - M5) / M4

Update Effectiveness (Organizational)

The organizational metric is calculated by averaging the results of the Per Endpoint metric above.

The CIS states this Control is critical:

“The misuse of administrative privileges is a primary method for attackers to spread inside
a target enterprise. Two very common attacker techniques take advantage of uncontrolled
administrative privileges. In the first, a workstation user running as a privileged user is
fooled into opening a malicious email attachment, downloading and opening a file from a
malicious website, or simply surfing to a website hosting attacker content that can auto-
matically exploit browsers. The file or exploit contains executable code that runs on the
victim’s machine either automatically or by tricking the user into executing the attacker’s
content. If the victim user’s account has administrative privileges, the attacker can take
over the victim’s machine completely and install keystroke loggers, sniffers, and remote
control software to find administrative passwords and other sensitive data. Similar
attacks occur with email. An administrator inadvertently opens an email that contains an
infected attachment and this is used to obtain a pivot point within the network that is
used to attack other systems.

The second common technique used by attackers is elevation of privileges by guessing or

cracking a password for an administrative user to gain access to a target machine. If
administrative privileges are loosely and widely distributed, or identical to passwords used
on less critical systems, the attacker has a much easier time gaining full control of sys-
tems, because there are many more accounts that can act as avenues for the attacker to
compromise administrative privileges.”

The journey of implementing the CIS Controls continues with controlled use of administrative priv-
ileges. Organizations are directed to verify that users with high-privileged accounts are not using priv-
ileged accounts for non-administrative activities such as web surfing and email. The two specific sub-
controls that are part of Implementation Group 1 (IG1) are:

l 4.2: Change Default Passwords

l 4.3: Ensure the Use of Dedicated Administrative Accounts

A vital step in vulnerability management is assessing the configuration of systems within the network.
The CIS Control 4/5 Secure Configurations and Group Memberships Dashboard provides useful inform-
ation to assist organizations with this control.

For more information about the CIS Control 3 dashboard, see CIS Control 4/5: Secure Configurations &
Group Memberships.

NIST also provides helpful information directly related to this CIS Control under the NIST Digital Identity
Guidelines.

The CAS provides guidance on how to assess the organization's progress in this journey. This guide
illustrates how the CISO can effectively measure progress through the vulnerability management pro-
gram. Shown below are the CIS Control 4 IG levels and requirements:

l What percentage of credentials have been changed from the default value?

l What percentage of collected password policies comply with the organization’s password
policies?

Sub-control 4.3 specifically checks that each user has a separate Administrator account to perform
those functions. While there is no method for determining if each user is assigned a separate Admin-
istrator level account, the methods of enumerating user accounts for sub-control 4.2 help organ-
izations to meet the requirements of sub-control 4.3.

Sub-control 4.2 has inputs and processes that dive deep into calculating a score around the number of
default account credentials per endpoint. Steps include manually creating a database of known default
passwords, hashing these passwords, and comparing them to hashes on each endpoint for each
account. Then, you can calculate a score for each endpoint. Manually locating a trusted database of
default credentials, creating hashed passwords, and comparing them to existing password hashes is a
time consuming endeavor for any organization.

The ultimate goal of these sub-controls is to have a score (or ratio) of zero (The number of default
accounts on each end point is zero, there are no default credentials). Active and passive scanning with
Tenable products allow the organization to query a variety of systems. Organizations can verify
whether or not default credentials exist and are installed on managed systems. Additionally, active
scanning can provide organizations with a consistent, repeatable process that can be used to identify
credentials that have fallen out of policy guidelines (password complexity and password age). If all end-
points meet defined password guidelines, there is little to no “manual” scoring requirements as part of
sub-control 4.2 as all ratios would be zero. Any systems found with default credentials, or credentials
out of policy compliance, would be easily identified. The effort to capture and calculate the Inputs,
Operations, and Measurements of the following sub-control would greatly be reduced, reducing overall
cost and workload.

Helpful plugins for this subcontrol are:

l 95928 Linux User List Enumeration

l 95929 macOS and Mac OS X User List Enumeration

Nessus uses these plugins to enumerate all the users on a Windows, Linux, or MacOS endpoint, provid-
ing the following plugin output. Follow the guidance if you need to alter the ID range.

l 10900/10914 Microsoft Windows - User Information: Passwords Never Expire

l 10898 Microsoft Windows - User Information: Never Changed Password

l 83303 Unix/Linux - Local Users Information: Passwords Never Expire

Additionally, Nessus has compliance checks for password length, and min/max password age for
Linux, Solaris, HP-UX, Mac OS X. Windows systems can be audited against password history, and
forced logoff.

Asset Type Security Function Implementation Groups

Users Protect 1, 2, 3

Dependencies
l Sub-control 2.4: Track Software Inventory Information

Inputs
1. Inventory of Endpoints: The organization’s inventory of endpoints which utilize credentials,
either at the OS level or at the application software level. Ideally, this includes software inventory
from sub-control 2.4.

2. Authoritative Source of Default Passwords: An authoritative source of known default pass-

words. Tenable has thousands of checks for known default passwords. Active and passive scan-
ning can identify and report on the use/existence of default credentials.

3. Password Policy Configuration: The organization’s defined password policy configuration.

Operations
1. For each endpoint in I1, enumerate the available logins, including hashed credentials (M1). For
each endpoint that was previously identified, create a list of user ids.

2. For each endpoint in I1, generate password hashes for all relevant default passwords provided in
I2 in accordance with the corresponding hashing procedures for the appropriate OS, application,
etc. (including any applicable salting). The organization must identify a trusted resource that can
provide a list of default passwords for each device on the organizations network.

3. For each login, compare the password hash for that login to the default password hashes gen-
erated in the previous operation. Create a list containing any logins that have hashes that match

4. For each endpoint, collect the applied password policy configuration (M5).

5. For each endpoint, compare the password policy configuration to the organizationally defined
password policy recommendations (including password length, complexity requirements, etc.).
Create a list of endpoint password policies that adhere to the organizational policy (M7) and a list
of endpoint password policies that deviate from the organizational policy (M9). Note where the
deviations occur.

Measures
Measure Definition

M1 = List of logins for cre- A list of available logins for endpoints which utilized credentialed
dentialed accounts accounts. This can be derived from Operation 1.

M2 = Count of items in M1 A count of the total number of items identified in M1.

M3 = List of logins with a A list of enumerated logins with a password hash that matches a
hash matching a default known default password hash. This can be derived from Oper-
hash ation 3.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of collected end- A list of the collected endpoint password policy configurations.
point password policy con- This can be derived from Operation 4.
figurations

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of matching pass- A list of collected password policy configurations that match
word policy configurations organizationally defined recommendations.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of unatching pass- A list of collected password policy configurations that do not
word policy configurations match organizationally defined recommendations.

Metric Calculation

The percentage of credentials that have been changed from the default (M2 - M4) /
value. M2

Password Policy Compliance

Metric Calculation

The percentage of collected password If M6 = 0, then no endpoint password policy con-

policies that comply with the organ- figurations were collected. Otherwise, the value of
ization’s password policies. this metric is M8 / M6

Asset Type Security Function Implementation Groups

Users Protect 1, 2, 3

Dependencies
l None

Inputs
1. The list of users defined as Administrators: All users who are Administrators.

2. The list of user accounts for the users defined in Input 1: A list of all user accounts for I1.

3. The list of users NOT defined as Administrators: All users who are not administrators.

4. The list of user accounts for the users defined in Input 3: A list of all user accounts for I3.

5. The list of all user accounts.: A list of all user accounts.

6. The list of all Administrative user accounts: A list of all Administrative user accounts.

7. The list of non-Administrative user accounts: Aa list of user accounts that do not have admin-
istrator access.

Operations
1. For each user defined in I1, collect the Administrative user account for that user from I6 and the
non-Administrative user account from I7.

2. For each user defined in I3, collect any Administrative user account for that user from I6 and the
non-Administrative user account from I7.

Measures

M1 = List of Admin users A list of all administrative users.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of users from Operation 1 A list of all users identified from Operation 1.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of users from Operation 2 A list of all users identified from Operation 2.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Administrative User Accounts

Metric Calculation

Determines whether those users The mapping performed by Operation 1 must show that,
identified as Administrative-level for each Administrative-level user, at least 1 Admin-
have at least one Administrative- istrative-level user account and at least 1 non-Admin-
level and one non-Administrative istrative-level user account are available. Otherwise, this
level user account. metric is a FAIL

Unauthorized User Accounts

Metric Calculation

Illustrates any non-Administrative-level users that have been assigned If M6 > 0, then FAIL;
an Administrative-level user account. otherwise PASS

l Mobile devices

l Laptops

l Servers

l Workstations

The CIS states this Control is critical:

“As delivered by manufacturers and resellers, the default configurations for operating sys-
tems and applications are normally geared towards ease-of-deployment and ease-of-use –
not security. Basic controls, open services and ports, default accounts or passwords, older
(vulnerable) protocols, and pre-installation of unneeded software can be exploitable in
their default state.

Developing configuration settings with good security properties is a complex task beyond
the ability of individual users, requiring analysis of potentially hundreds or thousands of
options in order to make good choices (the Procedures and Tools section below provides
resources for secure configurations). Even if a strong initial configuration is developed and
installed, it must be continually managed to avoid security “decay” as software is updated
or patched, new security vulnerabilities are reported, and configurations are “tweaked” to
allow the installation of new software or support new operational requirements. If not,
attackers will find opportunities to exploit both network accessible services and client soft-
ware.”

The journey of implementing the CIS Controls continues with the Secure Configuration for Hardware
and Software on Mobile Devices, Laptops, Workstations, and Servers. Organizations are directed to
develop strong, secure baseline configurations for each deployed software system. Organizations are
also directed to maintain documented security configuration standards for all authorized operating sys-
tems and software. The specific sub-controls that are part of Implementation Group 1 (IG1) are:

Oftentimes organizations struggle to get started. Small organizations purchase devices that arrive pre-
configured or pre-loaded with an operating system and applications. Large organizations typically
struggle with large numbers of devices which become harder to manage over time. Creating a secure
baseline is challenging at best, and involves a great deal of resources and expertise. Why recreate the
wheel developing a secure baseline? CIS and NIST have developed publicly available security bench-
marks, security guides, and checklists that have been thoroughly vetted. Excellent resources include:

l The CIS Benchmarks™ Program

l The NIST National Checklist Program

Organizations can save a great deal of time and effort by starting with these publicly available
resources, then augmenting or adjusting these baselines to satisfy local policies and requirements.
Because these resources are trusted industry standards, any deviations should be documented to facil-
itate later reviews or audits. For example, complex enterprises may find that a single security baseline
configuration is impractical. Many organizations may find they need to support different con-
figurations, such as those for web servers, database servers, etc,. If this is the case, the number of
baseline variations should be kept to a minimum and should be well documented.

For CIS Control 5, Tenable products allow security operations teams to use Tenable.sc Continuous View
(CV) to analyze endpoint operating systems and software configurations. Using the CIS Benchmarks
and Tenable.sc, the organization can verify that established configuration policies are followed.

l The percentage of the total OS/Software in an enterprise for which security configuration stand-
ards are documented and maintained

Specifically, Sub-Control 5.1 checks that the organization maintains documented security con-
figuration 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 con-
sistent, 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 miss-
ing patches. However, a lack of vulnerabilities does not mean endpoint devices are compliant with any
particular standard. By using Nessus and Tenable.sc, 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:

l 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.

l 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 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 sep-
arate the two phrases with a comma, as shown below.

Asset Type Security Function Implementation Groups

Applications Protect 1, 2, 3

Dependencies
l Sub-control 2.1: Maintain Inventory of Authorized Software

Inputs
1. Authorized Software List: The list of authorized software. This can be pulled from sub-control
2.1.

2. Security Configuration Standards: The list of enterprise security configuration standards.

Assumptions
l Documentation of secure configuration standards should include any approved devi-
ations/exceptions from industry-standard security baselines such as CIS benchmarks, DISA
Security Technical Implementation Guides (STIGs), or U.S. government configuration baselines
(USGCB).

Operations
1. Perform a calculation to compute the intersection (M1) of I1 and I2.

Measures
Measure Definition

M1 = List of authorized soft- A list of all the software/applications the organization has, includ-
ware with security con- ing operating systems, that have associated enterprise security
figuration standards configuration standards.

M3 = List of authorized soft- A list of all the software/applications the organization has, includ-
ware with security con- ing operating systems, that do not have associated enterprise
figuration standards security configuration standards.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of security con- A list of all the enterprise security configuration standards that do
figuration standards without not have installed applications/software or operating systems
associated software within the organization.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of authorized soft- A list of authorized applications/software and operating systems.

ware

M8 = Count of items in M7 A count of the total number of items in M7.

Metrics
Security Configuration Standards Coverage

Metric Calculation

The percentage of the total OS/Software in an enterprise that have security con- (M8 - M4) /
figuration standards documented and maintained. M8

The CIS states this Control is critical:

“Deficiencies in security logging and analysis allow attackers to hide their location, mali-
cious software, and activities on victim machines. Even if the victims know that their sys-
tems have been compromised, without protected and complete logging records they are
blind to the details of the attack and to subsequent actions taken by the attackers.
Without solid audit logs, an attack may go unnoticed indefinitely and the particular dam-
ages done may be irreversible. Sometimes logging records are the only evidence of a suc-
cessful attack. Many organizations keep audit records for compliance purposes, but
attackers rely on the fact that such organizations rarely look at the audit logs, and they do
not know that their systems have been compromised.

Because of poor or nonexistent log analysis processes, attackers sometimes control vic-
tim machines for months or years without anyone in the target organization knowing, even
though the evidence of the attack has been recorded in unexamined log files.”

The journey of implementing the CIS Controls continues with the Maintenance, Monitoring and Analysis
of Audit Logs. Organizations are directed to ensure that local logging has been enabled on all systems
and networking devices. The specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 6.2: Activate Audit Logging

l Ensure that local logging has been enabled on all systems and networking devices.

Specifically, Sub-Control 6.2 checks that the organization maintains an event logging policy, and that
endpoints are appropriately configured. A passing score on this sub-control is achieved by the organ-
ization stating that they have an established, documented logging policy for each endpoint, and that
each endpoint has been checked and validated as appropriately configured. As with previous sub-con-
trols, the goal of this sub-control is to have a score (or ratio) of zero (all endpoints have documented
security standards).

Using Tenable.sc, organizations are able to verify configuration settings on a wide variety of systems.
In Control 5, we discussed how to establish baseline configuration settings. Using the CIS Benchmarks
and the corresponding audit file, organizations can use Tenable.sc to verify that logging is enabled.
This illustrates the connection between controls 5 & 6. Listed below are two examples, however a
majority of the CIS Benchmarks and Tenable Audit files have recommendations for establishing a
baseline along with detail on how to configure & audit the settings.

l CIS Microsoft Windows Server 2008 R2 Benchmark v3.2.0

o https://workbench.cisecurity.org/files/2696
o CIS_MS_Windows_Server_2008_R2_MS_Level_1_v3.2.0.audit
o 9.3.10 Ensure 'Windows Firewall: Public: Logging: Log successful connections' is set to
'Yes'

l CIS Benchmark for Cisco IOS 16 Benchmark v1.0.0

o https://workbench.cisecurity.org/files/2657
o CIS_Cisco_IOS_16_v1.0.0_Level_1.audit
o 2.2.1 Set 'logging on'

Asset Type Security Function Implementation Groups

Network Detect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: The list of endpoints from the endpoint inventory

2. Event Logging Inventory: The list of events that should be logged (aka an event logging policy).

Assumptions
l There could potentially be numerous events that should be logged.

l A checklist verifying the logging policy can be examined per endpoint.

Operations
1. For each endpoint, determine if the configured event logging policy matches the policy defined
by I2. Note the appropriately and inappropriately configured endpoints.

Measures
Measure Definition

M1 = List of Endpoints A list of all endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of inappropriately configured end- A list of all inappropriately configured end-

points points.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics

Logging Policy Coverage

Metric Calculation

The ratio of endpoints implementing the prescribed event logging policy com- (M4 / M6)
pared to the total number of endpoints.

l CIS Control 8: Malware Defenses

l CIS Control 9: Limitation and Control of Network Ports, Protocols, and Services

l CIS Control 10: Data Recovery Capabilities

l CIS Control 11: Secure Configuration for Network Devices, such as Firewalls, Routers, and
Switches

l CIS Control 12: Boundary Defense

l CIS Control 13: Data Protection

l CIS Control 14: Controlled Access Based on the Need to Know

l CIS Control 15: Wireless Access Control

l CIS Control 16: Account Monitoring and Control

The CIS states this Control is critical:

“Web browsers and email clients are very common points of entry and attack because of
their technical complexity, flexibility, and their direct interaction with users and with other
systems and websites. Content can be crafted to entice or spoof users into taking actions
that greatly increase risk and allow introduction of malicious code, loss of valuable data,
and other attacks. Since these applications are the main means that users interact with
untrusted environments, these are potential targets for both code exploitation and social
engineering.”

The journey of implementing the CIS Controls with CIS Control 7 moves from Basic to Foundational con-
trols, and begins with Email and Web Browser Protections. Organizations are directed to ensure that
only fully supported web browsers and email clients are used. Ideally, only the latest version of these
fully supported web browsers and email clients should be used. Organizations are also directed to use
Domain Name System (DNS) filtering services to assist in the identification and blocking of malicious
domains. The specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 7.1 Ensure Use of Only Fully Supported Browsers and Email Clients Software

l 7.7: Use of DNS Filtering Services

For CIS Control 7, Tenable products allow security operations teams to use Tenable.sc Continuous View
(CV) to analyze endpoint browser and email client configurations. Using a variety of active and passive
plugins paired with Tenable.sc, the organization can verify established configuration policies are fol-
lowed. Tenable.sc provides an on-premise solution for organizations to better understand vulnerability
management. As an example, Nessus Network Monitor can passively detect and enumerate web
browsers that are being utilized, as well as any potential vulnerabilities present in the versions detec-
ted. Active credentialed scanning by Nessus can provide detailed information on web browsers that
are installed via the same methods of software enumeration described in CIS Control 2. Analysts can
easily produce tables and matrices utilizing this information, such as the sample matrix below, which
presents Chrome vulnerabilities. Many other browser clients such as Firefox, Internet Explorer, and
Safari, are part of the Browser Vulnerabilities Dashboard located in the Tenable.sc feed.

In most environments that use the Microsoft Office system, Outlook is often already the default pro-
gram for email, contacts, and calendaring. Compliance checks exist to ensure that group policies are
set which make Outlook the default program for email. Installed web browsers and email clients which
were enumerated in Control 2, can easily be searched for vulnerabilities using vulnerability text filters
within the Analysis tab of Tenable.sc.

Just as with previous sub-controls, the goal of this sub-control is to have a score (or ratio) of zero (all
endpoints having up to date/supported web browsers and email clients).

Asset Type Security Function Implementation Groups

Application Protect 1, 2, 3

Dependencies
l Sub-control 2.1: Maintain Inventory of Authorized Software

Inputs
1. Software Inventory: From the authorized software list (ASL: sub-control 2.1), the inventory of
web browser and email client software. Each entry should have a notation indicating whether the
software is “supported” or “unsupported”.

2. Authoritative source of information: Access to an authoritative source of information indic-

ating supported/unsupported details by product.

Operations
1. For each entry in I1, perform a lookup in I2 to verify.

2. For each entry in I1 labeled “supported”, perform a lookup in I2. From these lookups, note the list
of authorized software labeled “supported” but are actually not supported based on the author-
itative source lookup.

3. For each entry in I1 labeled “unsupported”, perform a lookup in I2. From these lookups, note the
list of authorized software labeled “unsupported” but are actually supported based on the author-
itative source lookup.

4. (Optional) Organizations can utilize Tenable.sc to identify specific details about applications util-
izing the same techniques that were previously used in sub-control 2. For example, If we wanted

If we wanted to drill down into these results further, and specifically identify Firefox vul-
nerabilities, we could simply use a filter of Vulnerability Text = Firefox and set either No Severity,
or chose a specific Severity to filter on as shown in the example below.

Measures

M1 = List of unsupported A combination of Operation 1 results and the software initially

items in I1 marked as unsupported in I1. This can be pulled from the list of
applications/software in sub-control 2.1 that are identified as email
or web browsers.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of authorized An organizational list of supported/authorized web browsers/email

web browser/email client clients.
software

M4 = Count of items in A count of the total number of items in M3.

M5 = List of items from I1 A list of items from I1 labeled as “supported” but that are not actually
labeled as “supported” supported. This can be pulled from sub-control 2.1.
that are not actually sup-
ported

M6 = Count of items in A count of the total number of items in M5.

M7 = List of items from A list of items from I1 labeled as “unsupported” but that are actually
Input 1 labeled as “unsup- supported. This can be pulled from sub-control 2.1.
ported” but are actually
supported

M8 = Count of items in A count of the total number of items in M7.

Metrics
Percentage of Unsupported Web Browser/Email Client Software in Use

Metric Calculation

The calculation of this metric is determined by the ratio of unsupported web (M4 - M2) /

Rate of False Positives

Metric Calculation

The calculation of this metric is determined by the ratio of web browser/email (M4 - M6) /
client software labeled “supported” but found to be unsupported, to the total M4
authorized web browser/email client software in use.

Rate of False Negatives

Metric Calculation

The calculation of this metric is determined by the ratio of web browser/email (M4 - M8) /
client software labeled “unsupported” but found to be supported, to the total M4
authorized web browser/email client software in use.

Asset Type Security Function Implementation Groups

Network Protect 1, 2, 3

Dependencies
l Sub-control 1.5: Maintain Asset Inventory Information

Inputs
1. Endpoint Inventory: The list of endpoints to be audited. This can pulled sub-control 1.5.

2. Accepted DNS services: The list of accepted DNS filtering services, such as Quad-9.

Operations
1. For each endpoint in I1, collect its DNS configuration setting. Note appropriately and inap-
propriately configured endpoints.

Measures
Measure Definition

M1 = List of audited endpoints A list of endpoints to be audited.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of appropriately configured end- A list of endpoints that are configured cor-
points rectly.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of inappropriately configured end- A list of endpoints that are configured incor-
points rectly.

Metrics
DNS Filtering Coverage

Metric Calculation

The ratio of endpoints configured to use accepted DNS filtering service com- M4 / M2
pared to the total number of endpoints which utilize DNS.

Traffic Analysis

Note: A second measurement could utilize traffic analysis to determine if any traffic is not being sent through
the prescribed DNS services.

The CIS states this Control is critical:

“Malicious software is an integral and dangerous aspect of Internet threats, as it is

designed to attack your systems, devices, and your data. It is fast-moving, fast-changing,
and enters through any number of points like end-user devices, email attachments, web
pages, cloud services, user actions, and removable media. Modern malware is designed to
avoid defenses, and attack or disable them. Malware defenses must be able to operate in
this dynamic environment through large-scale automation, rapid updating, and integration
with processes like incident response. They must also be deployed at multiple possible
points of attack to detect, stop the movement of, or control the execution of malicious
software. Enterprise endpoint security suites provide administrative features to verify that
all defenses are active and current on every managed system.”

The journey of implementing the Foundational CIS Controls continues with CIS Control 8 Malware
Defenses. Organizations are directed to ensure that the scanning engine and signature database are
updated on a regular basis for all anti-malware software. Ideally, only the latest version should be
used. Organizations are also directed to configure devices so that they automatically conduct an anti-
malware scan of removable media when inserted or connected. Finally, as part of the IG1 set of con-
trols, organizations are advised to configure devices to not auto-run content from removable media.
The specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 8.2 Ensure Anti-Malware Software and Signatures are Updated

l 8.4 Configure Anti-Malware Scanning of Removable Media

l 8.5 Configure Devices to Not Auto-Run Content

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Preface on Sub-Controls 8.2, 8.4, and 8.5
Malicious software, commonly known as malware, is any software that can attack your systems or
data. The majority of malware is designed to be fast moving, and is typically identified by general
terms such as worms, viruses, trojans, adware, rootkits, and spyware. Malware can be something
simple and annoying, like adware, or can be a complex application that steals data, deletes documents,
or installs unwanted software without the user's knowledge.

For CIS Control 8, Tenable products allow the security operations teams to use Tenable.sc Continuous
View (CV) to analyze endpoints for malicious file detection. As an example, Nessus detects potentially
unwanted files on a remote host utilizing the built in malicious file detection ability. Using a cre-
dentialed Nessus scan, hash files are compared against known malware signatures cataloged by major
antivirus vendors. A report then shows which anti-virus vendor considers the file to be malicious.
Security teams may find this information, along with data derived from the following plugins, useful in
detecting malicious applications:

l 88963 Malicious File Detection

l 59275 Malicious Process Detection

l 59641 Unwanted Software Detection

Additionally, Tenable.sc has the CIS Control 8: Malware Defenses dashboard, which contains com-
ponents that provide information and report on enforcing anti-virus (AV) deployments, disabling Auto
Run, and automating AV scans. In this dashboard, Tenable.sc shows all systems with Auto Run settings
enabled, the AV status, and many other parameters described throughout all sub controls. Using Ten-
able.sc, customers from all IG’s can effectively track and report on sub controls 8.1, 8.2, and 8.5.

Solely relying on software enumeration does not always indicate that an antivirus solution is installed.
Not having a functioning antivirus application installed on endpoints could pose a danger to the organ-
ization. Tenable has a number of plugins that check for antivirus solutions:

l 24232 BitDefender Check

l 20284 Kaspersky Anti-Virus Check

l 12107 McAfee Anti Virus Check

l And more

Additionally, plugin 16193 Antivirus Software Check aggregates the results from other plugins if mul-
tiple applications are installed. Plugin 16193 also reports hosts that do not have an antivirus solution
installed. Output from the plugin shows anti-malware products, versions of the signature files, and
information regarding if the signatures are out of date. This helps organizations meet sub-control 8.2.

Asset Type Security Function Implementation Groups

Devices Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Integrate Software and Hardware Asset Inventories

l Sub-control 2.1: Maintain Inventory of Authorized Software

l Sub-control 2.4: Track Software Inventory Information

Inputs
1. Endpoint Inventory: The endpoint inventory. Update the record for each endpoint to indicate
whether that endpoint can support anti-malware software or not (sub-control 1.4).

2. Anti-malware software version information: A list of acceptable versions for the scanning
engines and the signature databases for any anti-malware products in use on endpoints in I1.
This version information needs to be updated frequently to reflect current version information
and age off outdated versions. Reference the ASL per sub-control 2.1. and ideally leverage the
software inventory in sub-control 2.4)

3. Software update time limit: The maximum time allowed for anti-malware software updates to
be applied to endpoints.

Assumptions
l Some endpoints, such as network devices, may not support anti-malware software. Whether an
endpoint supports anti-malware software is provided as part of I1. Devices that cannot support
anti-malware software are removed from the list of endpoints to be checked during Operation 1,
and these devices are not counted in the metric below.

Operations

2. For each endpoint in M1, generate a list of those endpoints that have an acceptable version of
anti-malware software installed and enabled (both scanning engine and signature database)
according to the information provided in I2 (M2). Then, generate a list of those endpoints that do
not have an acceptable version of anti-malware software installed and enabled (M3).

3. For each endpoint in M1, generate a list of those endpoints that have been updated within the
time frame specified by I3 (M4), and a list of those endpoints that have not been updated within
that time-frame (M5).

Measures
Measure Definition

M1 = List of enpoints capable of supporting anti- A list of all endpoints that have anti-mal-
malware software ware software installed.

M2 = List of endpoints with an acceptable version A list of endpoints that have supported ver-
of anti-malware software installed and enabled sions of anti-malware (and definitions) that
(version compliant list) are installed and current.

M3 = List of endpoints that do not have an accept- A list of endpoints that do not have sup-
able version of anti-malware software installed ported versions of anti-malware (and defin-
and enabled (version non-compliant list) itions) that are installed and current.

M4 = List of endpoints that have had their anti-mal- A list of endpoints that have had their anti-
ware software updated within the specified time- malware software updated within the spe-
frame (time compliant list) cified time-frame.

M5 = List of endpoints that have not had their anti- A list of endpoints that have not had their
malware software updated within the specified anti-malware software updated within the
time-frame (time compliant list) specified time-frame.

M6 = Count of items in M1 A count of the total number of items in M1.

M7 = Count of items in M2 A count of the total number of items in M2.

M9 = Count of items in M4 A count of the total number of items in M4.

M10 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The ratio of anti-malware software version compliant endpoints compared to M7 / M9

the total number of endpoints capable of supporting anti-malware software.

Freshness

Metric Calculation

The ratio of endpoints whose anti-malware software has been updated within M9 / M6
the specified timeframe.

Note: Comparing the coverage metric to the freshness metric can serve as a useful check - for instance, if the
coverage metric tends to be high, while the freshness metric is low, that would suggest that I2 might not have
been updated recently enough (that is, outdated versions are being considered acceptable).

Asset Type Security Function Implementation Groups

Devices Detect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: The endpoint inventory with an entry for each endpoint indicating whether
or not that endpoint can support anti-malware software or not.

2. Desired anti-malware configuration: The desired configuration to automatically scan remov-

able media when inserted/connected.

Operations
1. Refine the endpoint inventory (I1) to only contain endpoints that can support anti-malware soft-
ware endpoint inventory. This reduced list of endpoints becomes M1.

2. Of the set of endpoints that can support anti-malware software (M1), generate a list of those end-
points that actually have anti-malware software installed, enabled, and adhere to the con-
figuration specified in I2 (M2). Then, generate a list of the endpoints that do not adhere to the

Measures
Measure Definition

M1 = List of endpoints capable of supporting anti- A list of all endpoints that have anti-mal-
malware software ware software installed.

M2 = List of endpoints with an acceptable version A list of endpoints that have supported ver-
of anti-malware software installed, enabled, and sions of anti-malware that are installed,
properly configured to scan removable media enabled, and properly configured to scan
(compliant list) removable media.

M3 = List of endpoints not adhering to the spe- A list of endpoints that do not adhere to the
cified configuration (non-compliant list) specified configuration.

M4 = Count of items in M1 A count of the total number of items in M1.

M5 = Count of items in M2 A count of the total number of items in M2.

M6 = Count of items in M3 A count of the total number of items in M3.

Metrics
Coverage

Metric Calculation

The ratio of endpoints that are compliant with the desired anti-malware con- M5 / M4
figuration compared to the total number of endpoints capable of supporting
anti-malware software.

Asset Type Security Function Implementation Groups

Devices Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: The endpoint inventory.

2. Desired configuration(s) to disable auto-run: The desired configuration to use to disable auto-
running content.There may be multiple configurations targeted at different types of endpoints
(for instance, a different configuration might be provided for each type of operating system used
on the endpoints in the provided inventory). If the endpoints are capable of performing multiple
types of auto-run behavior (i.e., auto-run vs. auto-play), appropriate configurations should be
provided for each type.

Operations
1. For each endpoint in I1, compare the endpoint’s configuration to the appropriate configuration
from I2. Generate a list of endpoints that adhere to the specified configuration (M1) and a list of
the endpoints that do not adhere to the specified configuration (M2).

Assumptions
l Endpoints that are not capable of performing any type of auto-run behavior are included in the
compliant list (M1).

Measures

M1 = List of endpoints adhering to the specified con- A list of all endpoints that adhere to the
figuration (compliant list) specified configuration.

M2 = List of endpoints not adhering to the specified A list of endpoints that do not adhere to
configuration (non-compliant list) the specified configuration.

M3 = Count of items in M1 A count of the total number of items in

M1.

M4 = Count of items in M2 A count of the total number of items in

M2.

M5 = Count of items in I1 A count of the total number of items in I1.

Metrics
Coverage

Metric Calculation

The ratio of endpoints properly disabling auto-run compared to the total num- M3 / M5
ber of endpoints.

The CIS states this Control is critical:

“Attackers search for remotely accessible network services that are vulnerable to exploit-
ation. Common examples include poorly configured web servers, mail servers, file and print
services, and DNS servers installed by default on a variety of different device types, often
without a business need for the given service. Many software packages automatically
install services and turn them on as part of the installation of the main software package
without informing a user or administrator that the services have been enabled. Attackers
scan for such services and attempt to exploit these services, often attempting to exploit
default user IDs and passwords or widely available exploitation code.”

The journey of implementing the Foundational CIS Controls continues with CIS Control 9 Limitation and
Control of Network Ports, Protocols, and Services. The full CIS 9 Control evolves around organizations
ensuring that only those ports, protocols, and services with a validated business requirement are
open/running on each system. Organizations are also directed to perform automated scans on a reg-
ular basis against all systems to ensure that unauthorized ports/services are detected. The specific
sub-controls that are part of Implementation Group 1 (IG1) are:

l 9.4 Apply Host-Based Firewalls or Port-Filtering

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Preface on Sub-Control 9.4
The CIS recommends that to meet the requirements for IG1, organizations should at a minimum apply
host-based firewalls or port-filtering tools on end systems, with a default-deny rule that drops all
traffic except those services and ports that are explicitly allowed. For CIS Control 9, Tenable products
allow security operations teams to use Tenable.sc Continuous View (CV) to analyze endpoints and
check firewall configurations, as well as track open ports and services.

To further assist organizations the CIS Control 9/12, the "Monitoring Ports, Services and Network Bound-
aries" dashboard focuses on the tracking of active ports, services, and protocols. Tenable.sc is able to
routinely scan the network for open ports and services. Nessus scanners are capable of scanning
internal and external assets on the network. Tenable.sc can also use passive detection to find systems
that are communicating with the internal network from external or untrusted devices.

For more information about the CIS Control 9 dashboard, see CIS Control 9/12: Monitoring Ports, Ser-
vices and Network Boundaries.

There are a variety of methods that can be employed to assist organizations with port filtering, or
determining if host-based firewalls are in use. Nessus has a variety of scanning methods to detect
open ports and services. The Nessus SYN scanner, plugin ID 11219, is less intrusive and behaves dif-
ferently by simplifying the scanning process. The scanner sends packets and waits for a response, but

Organizations can benefit from also using the following plugins, such as plugin 34220, which uses the
WMI interface to run ‘netstat’ on the remote host to enumerate the open ports.

Asset Type Security Function Implementation Groups

Devices Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

Inputs
1. Endpoint Inventory: The endpoints that are able to scan, and therefore assumed capable of host-
ing firewall/port-filtering software.

2. Policy: A policy (or set of policies, potentially individually per endpoint) indicating which ports
are allowed to be open.

Operations
1. For each endpoint, retrieve the firewall policy.

2. For each firewall policy, enumerate both the ports which allow communication, and any con-
figuration of a default deny rule (could that be a default?), noting along the way which policies
are configured appropriately or inappropriately.

Measures
Measure Definition

M1 = List of endpoints A list of all endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of endpoints with inappropriately A list of endpoints that do not have an appro-
configured firewall ports policy priately configured firewall ports policy.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of endpoints with appropriately A list of endpoints that have an appropriately con-
configured default deny rule figured default deny rule.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of endpoints with inappropriately A list of endpoints that do not have an appro-
configured default deny rule priately configured default deny rule.

M10 = Count of items in M9 A count of the total number of items in M9.

M11 = List of endpoints with both appro- A list of endpoints with both an appropriately con-
priately configured firewall policy figured firewall policy.

M12 = Count of items in M11 A count of the total number of items in M11.

M13 = List of endpoints with at least one inap- A list of all endpoints with at least one inap-
propriate firewall configuration propriate firewall configuration.

M14 = Count of items in M13 A count of the total number of items in M13.

Metrics
Coverage

Metric Calculation

The ratio of correctly configured endpoints compared to the total number of M14 / M2
endpoints.

The CIS states this Control is critical:

“When attackers compromise machines, they often make significant changes to con-
figurations and software. Sometimes attackers also make subtle alterations of data stored
on compromised machines, potentially jeopardizing organizational effectiveness with pol-
luted information. When the attackers are discovered, it can be extremely difficult for
organizations without a trustworthy data recovery capability to remove all aspects of the
attacker’s presence on the machine.”

The journey of implementing the CIS Controls continues with data recovery capabilities. This control
addresses the importance of backing-up and protecting an organization's system data. Organizations
which implement sound data backup strategies ensure their ability to recover lost data or data that
has been tampered-with quickly and efficiently. Properly archiving key system data, periodic integrity
testing, and having at least one offline backup destination are all crucial in restoring systems and
resuming service with the least amount of downtime. This control helps to guide the organization
through this review process. The four specific sub-controls that are part of Implementation Group 1
(IG1) are:

l 10.1: Ensure Regular Automated Backups

l 10.2: Perform Complete System Backups

l 10.4: Protect Backups

l 10.5: Ensure All Backups Have at Least One Offline Backup Destination

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: Inventory of all endpoints.

2. Backup configuration policy: Show the backup configuration policy is available.

3. Backup software: Show the backup software (either OS or 3d party) configuration is available
and able to be queried.

4. Backup logs: Show the backup software logs are available and can be queried

5. Backup staleness threshold: A successful backup staleness threshold is defined. This indicates
the maximum time period allowed between backups. The CIS recommends this occur at least
weekly.

Operations
1. For each endpoint, examine its backup configuration with the available configuration policy.
Note appropriately configured and inappropriately configured endpoints. Then, examine its logs
to determine the most recent successful backup completion time. Note whether it was run
within the enterprise-defined staleness threshold.

3. Compare an endpoint's backup configuration with available configuration policy.

4. Interrogate logs to determine most recent successful backup completion time.

Measures
Measure Definition

M1 = List of endpoints A list of all endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of appropriately configured end- A list of endpoints that are configured correctly.
points

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of inappropriately configured end- A list of endpoints that are configured incorrectly.
points

M6 = Count of items in M5 A count of the total number of items in M5.

M7= List of endpoints both appropriately A list of all endpoints that are both configured cor-
configured and without stale backups rectly and also do not have any stale backups.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of endpoints either inap- A list of endpoints that are configured incorrectly
propriately configured or without stale or that do not have any stale backups.
backups

M10 = Count of items in M9 A count of the total number of items in M9.

Metrics
Coverage

The percentage of endpoints that are successfully backing up system data on a M8 / M2

regular basis.

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Key Systems: The list of “key systems” identified by the organization, as derived from the end-
point inventory (sub-control 1.4).

2. Backup configuration policy: The organization’s backup/imaging configuration policy.

Assumptions
l Backup software (either OS or 3d party) is installed and appropriately configured on the “key sys-
tems” identified in I1.

Operations
1. For each endpoint in the list of “key systems”, examine its backup configuration against the avail-
able backup configuration policy. Note which endpoints are configured appropriately and inap-
propriately.

Measures

M1 = List of "key system" endpoints A list of "key system" endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of appropriately configured “key sys- A list of “key systems” that are configured cor-
tems” rectly.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of inappropriately configured “key A list of “key systems” that are configured incor-
systems” rectly.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The percentage of key systems that are successfully backed up as a complete M4 / M2

system.

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint inventory: The list of endpoints configured for periodic backup, derived from the end-
point inventory (sub-control 1.4).

2. Backup configuration policy: The organization’s backup configuration policy.

Assumptions
l Backup software (either OS or 3d party) is installed and appropriately configured on endpoints
identified in I1.

Operations
1. Interrogate the organization’s backup configuration policy to determine if backups are con-
figured to be encrypted.

2. For each endpoint, examine its backup configuration policy to ensure that encrypted backups
are configured. Note which endpoints are configured appropriately and inappropriately.

Measures

M1 = List of endpoints A list of endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of appropriately configured end- A list of endpoints that are configured cor-
points rectly.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of inappropriately configured end- A list of endpoints that are configured incor-
points rectly.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The percentage of backups that are protected via physical security/encryption. M6 / M2

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: A list of endpoints.

2. Backup configuration policy: The backup configuration policy, assuming the inclusion of “off-
line” backup destinations.

Operations
1. Collect a list of endpoints that do/do not matchthe policy specified in I2.

Measures
Measure Definition

M1 = List of endpoints A list of endpoints.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of endpoints matching policy A list of endpoints that match the policy.

M5 = List of endpoints not matching policy A list of endpoints that do not match the policy.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The ratio of endpoints matching the backup configuration policy compared to M4 / M2

the total number of endpoints.

Lack of Coverage

Metric Calculation

The ratio of endpoints not matching the backup configuration policy compared M5 / M2
to the total number of endpoints.

The CIS states this Control is critical:

“As delivered from manufacturers and resellers, the default configurations for network
infrastructure devices are geared for ease-of-deployment and ease-of-use – not security.
Open services and ports, default accounts (including service accounts) or passwords, sup-
port for older (vulnerable) protocols, pre-installation of unneeded software; all can be
exploitable in their default state. The management of the secure configurations for net-
working devices is not a one-time event, but a process that involves regularly re-eval-
uating not only the configuration items but also the allowed traffic flows. Attackers take
advantage of network devices becoming less securely configured over time as users
demand exceptions for specific business needs. Sometimes the exceptions are deployed
and then left undone when they are no longer applicable to the business needs. In some
cases, the security risk of the exception is neither properly analyzed nor measured against
the associated business need and can change over time.

Attackers search for vulnerable default settings, gaps or inconsistencies in firewall rule
sets, routers, and switches and use those holes to penetrate defenses. They exploit flaws
in these devices to gain access to networks, redirect traffic on a network, and intercept
information while in transmission. Through such actions, the attacker gains access to
sensitive data, alters important information, or even uses a compromised machine to pose
as another trusted system on the network.”

The journey of implementing the CIS Controls, continues with CIS Control 11: Secure Configuration for
network devices, such as Firewalls, Routers, and Switches. Organizations are directed to review the
configuration of all network devices against approved configurations. Organizations should record and
mitigate any deviation. Organizations are also directed to establish a rigorous configuration man-
agement program and change control process in order to prevent attackers from exploiting network
device vulnerabilities.

l 11.4 Install the latest stable version of any security-related updates on all network devices

For CIS Control 11, Tenable products allow the organization to actively and passively discover network
devices and software. Using the same methods as discussed in Control 1 and Control 2, active scan-
ning allows for network device mapping and software enumeration. Devices identified in Control 1 as
network devices, firewalls, routers, and switches must be used as a reference for this control. Software
versions that were enumerated in Control 2 are also required. Both of these efforts contribute greatly
to this control.

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Preface on Sub-Control 11.4
Tenable.sc provides innovative ways to find vulnerabilities for network devices using different attrib-
utes, such as the Common Platform Enumeration (CPE). Tenable.sc uses CPE strings “bluecoat, bro-
cade, check_point, checkpoint, cisco, citrix, dell, f5, fortinet, hp, huawei, juniper, netapp, netgear,
paloaltonetworks, pfsense, sonicwall, ssh, veritas, vmware, websense” to locate vulnerabilities that are
likely related to network devices. These vulnerabilities help support CIS sub control 11.4: Install the
Latest Stable Version of Any Security Related Updates on All Network Devices. Components include
trend lines which are calculated over 3 months, and that use the Last Observed Filter set to “Within the
Last Day”. This allows analysts to track changes from one day to the next, showing a more accurate
change. If scans are run weekly, then a user should modify the field to 7 days, so the change from scan
to scan is accurately measured.

The ultimate goal of this sub-control is to have a score (or ratio) of zero (The number of network
devices all have up to date software versions, i.e., there are no missing patches/updates). Using this
method, we can easily identify unsupported versions of software on network devices. The following
example from pluginID 55933 Juniper Junos Unsupported Version Detection uses the above listed fil-
ters as a base query.

Asset Type Security Function Implementation Groups

Network Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

Inputs
1. Network device inventory: The network device inventory, derived from the endpoint inventory
(sub-control 1.4).

2. Network device version information: A list of acceptable versions for each model of network
device in I1. This version information needs to be updated frequently to reflect current version
information and age off outdated versions.

Operations
1. For each network device in I1, compare the network device’s version to the allowable versions
from I2.

2. Generate a list of those network devices that match an allowable version (M1).

3. Generate a list of those network devices that do not match an allowable version (M2).

Measures
Measure Definition

M2 = Count of items in M1 A count of the total number of items in

M1.

M3 = List of network devices that match an allowable A list of network devices that match an
version (compliant list) allowable version.

M4 = Count of items in M3 A count of the total number of items in

M3.

M5 = List of network devices that do not match an A list of network devices that do not
allowable version (non-compliant list) match an allowable version.

M6 = Count of items in M5 A count of the total number of items in

M5.

Metrics
Coverage

Metric Calculation

The percentage of inventoried network devices that match the If M2 > 0, then M4 /
allowable version for that device/OS. M2; otherwise 0

The CIS states this Control is critical:

“Attackers focus on exploiting systems that they can reach across the Internet, including
not only DMZ systems but also workstations and laptop computers that pull content from
the Internet through network boundaries. Threats such as organized crime groups and
nation-states use configuration and architectural weaknesses found on perimeter sys-
tems, network devices, and Internet-accessing client machines to gain initial access into
an organization. Then, with a base of operations on these machines, attackers often pivot
to get deeper inside the boundary to steal or change information or to set up a persistent
presence for later attacks against internal hosts. Additionally, many attacks occur
between business partner networks, sometimes referred to as extranets, as attackers hop
from one organization’s network to another, exploiting vulnerable systems on extranet peri-
meters.”

The journey of implementing the CIS Controls continues with understanding the boundaries of a the
network and defining how access should be controlled. Organizations are directed to deny com-
munication over unauthorized TCP or UDP ports or application traffic to ensure that only authorized
protocols are allowed. The two specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 12.1: Maintain an Inventory of Network Boundaries

l 12.4: Deny Communication Over Unauthorized Ports

For CIS Control 12, Tenable products allow the organization to actively and passively discover net-
works. Using the same methods as discussed in Control 9, active scanning allows for TCP port enu-
meration and network mapping efforts. Along with Control 1, network addresses can be discovered and
documented. A valuable aid in this process is to use passive scanning around the network to identify

To further assist organizations the CIS Control 9/12: Monitoring Ports, the "Services and Network
Boundaries" dashboard focuses on the tracking of active ports, services, and protocols. Tenable.sc is
able to routinely scan the network for open ports and services. Nessus scanners are capable of scan-
ning internal and external assets to map out subnets that are in use on the network. Tenable.sc can
also use passive detection to discover subnets that are not being scanned.

https://www.tenable.com/sc-dashboards/cis-control-912-monitoring-ports-services-and-network-
boundaries

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Preface on Sub-Controls 12.1 and 12.4
Both of these sub controls are supported by first having a good network discovery process. Tenable.sc
helps customers gain a more accurate understanding of the systems active within their environment.
As the systems are identified and the security team moves from the Discover to the Access phase, the
team begins to understand what normal is, and gains an understanding of the traffic authorized. At the
completion of these two steps, the security team is ready to start progressing in sub control 12.1 and
begin taking inventory of all the networks, establishing a baseline of traffic patterns. As the team Ana-
lyzes (the third step in the life cycle) the previously collected data, a fundamental pattern should
emerge and documentation of authorized traffic will reveal itself.

When documenting the inventory, the organization should consider the follow key items for traffic clas-
sification:

l What Classless Inter-Domain Routing (CIDR) boundaries are used, and how do they map to
VLAN’s?

l Who are the primary users or operators in the subnet or network segment.

l What is the traffic that is normal traffic?

l Are there services running in the network segment?

l Where are the network access controls in relation to the network segment?

As the security team defines each of these questions for each network segment, a network traffic
policy will develop. From these set up policies, a clear set of access controls can be defined.

Asset Type Security Function Implementation Groups

Network Identify 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

Inputs
1. Device inventory: An inventory of expected boundary devices (M1) as derived from the endpoint
inventory (sub-control 1.4).

Operations
1. Utilize a discovery tool or process to examine the network topology. Then, collect the list of
devices that are considered boundary devices (M2).

2. Evaluate the difference between I1 and Operation 1 to get the list of non-inventoried boundary
devices (M3).

Measures
Measure Definition

M1 = List of expected network boundary devices A list of expected network boundary devices.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of discovered network boundary A list of discovered network boundary

devices devices.

M5 = List of non-inventoried boundary devices A list of non-inventoried boundary devices.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The ratio of non-inventoried boundary devices compared to expected bound- M6 / M2

ary devices. If the calculated value is greater than zero, the inventory is not cur-
rent.

Asset Type Security Function Implementation Groups

Network Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 2.4: Track Software Inventory Information

Inputs
1. List of endpoints to scan: The list of endpoints to scan that are assumed capable of hosting fire-
wall/port-filtering software as derived from the endpoint inventory (.sub-control 1.4) Additionally,
this could potentially be informed by the software inventory (sub-control 2.4)

2. Open policies: A policy (or set of policies, potentially individually per endpoint) indicating the
ports that are allowed to be open.

Operations
1. For each endpoint, retrieve its firewall policy.

2. For each endpoint/firewall policy pair, examine the endpoint’s configuration to enumerate the
ports that allow communication. Also, examine any configuration of a default deny rule. Note
which endpoints are configured appropriately or inappropriately.

Measures
Measure Definition

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of endpoints with appropriate port con- A list of endpoints with appropriate port con-
figuration figuration.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of endpoints with inappropriate port A list of endpoints with inappropriate port con-
configuration figuration.

M6 = Count of items in M5 A count of the total number of items in M5.

M7= List of endpoints with appropriately con- A list of all endpoints with an appropriately
figured default deny rule configured default deny rule.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of endpoints within appropriately con- A list of endpoints with an inappropriately con-
figured default deny rule figured default deny rule.

M10 = Count of items in M9 A count of the total number of items in M9.

M11 = List of endpoints with both appropriately A list of endpoints with both appropriately con-
configured ports and default deny rules figured ports and default deny rules.

M12 = Count of items in M11 A count of the total number of items in M11.

Metrics
Coverage

Metric Calculation

The ratio of correctly configured endpoints compared to the total number of M12 / M2
endpoints.

The CIS states this Control is critical:

“Data resides in many places. Protection of that data is best achieved through the applic-
ation of a combination of encryption, integrity protection, and data loss prevention tech-
niques. As organizations continue their move towards cloud computing and mobile access,
it is important that proper care be taken to limit and report on data exfiltration while also
mitigating the effects of data compromise.

Some organizations do not carefully identify and separate their most sensitive and critical
assets from less sensitive, publicly accessible information on their internal networks. In
many environments, internal users have access to all or most of the critical assets. Sens-
itive assets may also include systems that provide management and control of physical
systems, such as Supervisory Control and Data Acquisition (SCADA). Once attackers have
penetrated such a network, they can easily find and exfiltrate important information,
cause physical damage, or disrupt operations with little resistance. For example, in several
high-profile breaches over the past few years, attackers were able to gain access to sens-
itive data stored on the same servers with the same level of access as far less important
data. There are also examples of using access to the corporate network to gain access to,
then control over, physical assets and cause damage.”

The journey of implementing the CIS Controls continues with the prevention of data exfiltration, mit-
igating the effects of exfiltrated data, and ensuring the privacy and integrity of sensitive information.
As with many of the CIS controls, the first step is establishing an asset inventory. With data files, this
can feel like an insurmountable task. This is where knowing what is stored on the network, and where,
is extremely important. Properly storing the data at rest or on mobile systems is critical to the security
and tracking of the data. This control helps guide the organization through this review process. The
three specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 13.2: Remove Sensitive Data or Systems Not Regularly Accessed by Organization

l 13.6: Encrypt Mobile Device Data

For CIS Control 13, Tenable products allow security operations teams to use Tenable.sc Continuous
View (CV) to analyze and search large amounts of data files for sensitive data. Located on the Tenable
download portal and in Tenable.sc feed, the security team can download and install audit files for sens-
itive data. Using these audit templates, file systems can be scanned and checked for sensitive data.
For many organizations, these files need to be customized for optimum effectiveness. The Tenable Pro-
fessional Services team can help with customization.

There are 4 existing dashboards that are designed to work with these audit files. These templates can
be used to get started in using Tenable.sc to assist IG1 organizations with Control 13.

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Preface on Sub-Controls 13.1 and 13.2
As with previous controls, Control 13.1 requires an initial inventory be collected. Using the data from
previous controls, the security team can formulate a plan to create the inventory of Data assets. Ten-
able.sc is often associated with multiple scans per-week (for example, discovery, mitigation, and vul-
nerability scans). Scanning systems using the Content audit files can be very disk intensive, and
Nessus reads the first part of many files. You can plan these scans more strategically, and store this
data in a separate repository. The data should not be mixed with other vulnerability or compliance
data. After the data is collected, the security team can begin to identify the best approach to managing
the classification and data leakage prevention task. Listed below are descriptions of the current dash-
board templates, all of which present the data differently and can help in understanding the where
data is located.

Sensitive Data: Sensitive data includes, but is not limited to, personal and financial data, credit cards,
Social Security numbers, and any other data that can facilitate identity theft, or identify an individual.
Other forms of sensitive data may include copy-written data. Sensitive data can also be customer
data, contact information, memberships, or political opinions. With the increasing amount of data
being generated by businesses and individuals across the Internet, locating and protecting sensitive
data has become crucial. Intruders and malicious organizations attempt to gain access to sensitive
data through weakness and vulnerabilities in computer systems and networks. Identifying these weak-
nesses and keeping systems updated is solid first step to protecting sensitive data. This dashboard
summarizes for the analyst a variety of checks from sensitive data audits, and checks for the presence
of items that may contain sensitive data. Compliance failures could potentially lead to the loss of sens-
itive data.

Windows or Unix File Contents Audit Results: Governance, Risk Management, and Compliance (GRC)
is a substantial part of any information assurance program. A GRC requires information systems to be
audited, regardless of the standard to which the audit is performed. Tenable.sc CV using Nessus can
perform Unix Content .audit checks. The content audit checks differ from Unix Configuration .audit
checks in that they are designed to search a Unix file system for specific file types containing sensitive
data rather than enumerate system configuration settings. The Content .audit checks include a range
of options to help the auditor narrow down the search parameters and more efficiently locate and dis-
play noncompliant data. An example of non-compliant content is PII (Personally Identifiable Inform-
ation) or PHI (Protected Health Information). This dashboard provides the audit results for Windows or
Unix File Contents.

l https://www.tenable.com/sc-dashboards/windows-audit-check-dashboards

l https://www.tenable.com/sc-dashboards/linux-audit-check-dashboards

Removable Media and Content Audits: Data loss can occur through several methods. This dashboard
focuses on tracking usage of USB devices, CD-ROMs, DVD-ROMs, and other removable media auditable
events. Security analysts should also be concerned about the classification of data stored on local com-
puters. In conjunction with scans using Nessus content audit files, systems containing classified data
are easily identified. This dashboard focuses on auditing the use of removable media and storage of
sensitive documents on local storage devices. The first step in monitoring sensitive data is to have an

To audit for the storage of classified data, the organization should download the appropriate content
audit files and modify the files accordingly. There are two modifications that may be required: the file_
extension and max_size values. The file_extention [file_extension: 'pdf' | 'doc'] value contains the
extension of the files that will be searched. The max_size value is the amount of data in the file that
will be searched. For example, if the max-size is set to 20k, then the first 20k of the file will be
searched. Other fields that might need adjusting are the regex and expect fields. However, these
changes require extensive testing.

l https://www.tenable.com/sc-dashboards/removable-media-and-content-audits

Asset Type Security Function Implementation Groups

Data Identify 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

Inputs
1. Classification Scheme: The organizationally-defined classification scheme.

2. Sensitive information data set: The data set of sensitive information for which the organization
is responsible, mapped to the classification scheme defined by I1.

a. Review the available Tenable Audit files to see if an existing audit file is available.

3. Endpoint/system mapping: A mapping of an organization’s endpoints/systems containing sens-

itive information classified by I2. Ideally, this uses the endpoint inventory (sub-control 1.4).

a. This can be the output of any matches found using audit scans with content audit file tem-
plates.

Operations
1. Create the mappings of information deemed “sensitive” to the organization’s classification
scheme.

2. Create the mappings of classified, sensitive information to the endpoints/systems on which that
information is stored.

Measures

l M2:
o 1 if the mappings of classified, sensitive information to the endpoints/systems on which it
resides is provided.
o 0 if the mappings of classified, sensitive information to the endpoints/systems on which it
resides is not provided.

Metrics
Existence

Metric Calculation

The inventory of all sensitive information, cross-referenced with the systems M1 AND M2
on which that information is kept.

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

Sub-control 13.1: Maintain an Inventory of Sensitive Information

Inputs
1. List of sensitive systems: A list of sensitive systems. Ideally, this uses the endpoint inventory
(sub-control 1.4).

a. The list of systems from 13.1 scanning with Content Audit files can identify the systems
with sensitive data.

2. Access frequency: The access frequency for any sensitive systems.

3. Access frequency threshold: An organizationally-defined access frequency threshold.

Assumptions
l Access to sensitive data takes place through some system. Therefore the system, when pro-
cessing, storing, or transmitting sensitive data, is a sensitive system.

l Isolation/exposure score of zero is assumed ideal.

Operations

2. For each infrequently used sensitive system, calculate the system's isolation/exposure.

Measures
Measure Definition

M1 = List of all systems used to process sens- A list all systems used to process sensitive
itive information information.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = Set of infrequently used sensitive systems A list of infrequently used sensitive systems.

M4 = Count of infrequently used sensitive sys- A count of infrequently used sensitive sys-
tems tems.

M5 = List of infrequently used sensitive systems A list of infrequently used sensitive systems
with isolation/exposure scores greater than 0 with isolation/exposure scores greater than 0.

M6 = Count of items in M4 A count of the total number of items in M4.

Metrics
Coverage

Metric Calculation

The percentage of infrequently used sensitive systems that are not properly M6 / M4
isolated.

Asset Type Security Function Implementation Groups

Data Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 2.1: Maintain an Inventory of Authorized Software

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Approved mobile devices: The list of approved mobile devices. This is derived from the end-
point inventory (sub-control 1.4).

2. Approved mobile device encryption software: The list of approved mobile device encryption
software. Ideally, this is derived from the authorized software list (sub-control 2.1).

3. Approved software configuration policy: For each software in I2, the approved software con-
figuration policy.

Operations
1. For each mobile device in I1, determine if any of the approved encryption software from Input 2
is installed.

2. For each mobile device with installed approved encryption software, collect the software con-
figuration information and compare it to the approved configuration policy (I3).

Measures

M1 = List of approved mobile devices A list of approved mobile devices.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of approved mobile devices with A list of approved mobile devices with
approved encryption software installed approved encryption software installed.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of approved mobile devices without A list of approved mobile devices without
approved encryption software installed approved encryption software installed.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of appropriately configured mobile A list of appropriately configured mobile

devices devices.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of inappropriately configured mobile A list of inappropriately configured mobile

devices devices.

M10 = Count of items in M9 A count of the total number of items in M9.

Metrics
Installed Software Coverage

Metric Calculation

The percentage of approved mobile devices that are equipped with approved M4 / M2
encryption software.

Appropriately Configured Devices

Metric Calculation

The percentage of approved mobile devices equipped with approved encryp- M8 / M2

tion software that meet or exceed the approved configuration policy.

The CIS states this Control is critical:

“Encrypting data provides a level of assurance that even if data is compromised, it is

impractical to access the plaintext without significant resources; however, controls should
also be put in place to mitigate the threat of data exfiltration in the first place. Many
attacks occurred across the network, while others involved physical theft of laptops and
other equipment holding sensitive information. Yet, in many cases, the victims were not
aware that the sensitive data were leaving their systems because they were not mon-
itoring data outflows. The movement of data across network boundaries both elec-
tronically and physically must be carefully scrutinized to minimize its exposure to
attackers.”

The journey of implementing the CIS Controls continues with controlling access using Access Control
Lists (ACL). Organizations are directed to protect all information stored on systems using native ACL
methods. These methods include network layer access controls, file level permissions, and other
application centric controls. The specific sub-controls that are part of Implementation Group 1 (IG1)
are:

l 14.6: Protect Information Through Access Control Lists

Managing ACL or Dynamic ACL (DACL) is a complicated task at all levels of IT operations. The best
approach is to have a clearly defined access policy and to conduct repeated internal audits. Some
organizations take an approach to deny all access, and then open up access as needed. This approach
is good for file systems or databases, but is harder when looking at network based ACL. To automate
the audit process, Tenable.sc can be configured with custom audit files to review configurations and
report on the status. This customization is a very advanced process, and should be done with aid of
professional services.

The organization should take their time during this process and review all the access requirements at
each level. In some cases, several controls come together to create the completed security control. For
example, access to a database system starts at the network layer, but restricts access based on IP and
TCP ports. User and services accounts are needed, which may lead to file level permissions. Finally,

Asset Type Security Function Implementation Groups

Date Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. Endpoint Inventory: The list of all endpoints.

2. Access control configuration policy: The organizationally defined access control configuration
policy.

Operations
1. For each endpoint in I1, collect the “ground truth” access policy for that endpoint and compare it
to the access control configuration policy in I2. Generate a list of endpoints which comply with
the specified access control configuration policy (M1) and a list of endpoints that do not comply
with the specified policy (M2).

Measures
Measure Definition

M1 = List of endpoints that comply with access con- A list of endpoints that comply with the
trol configuration policy (compliant list) access control configuration policy.

M2 = List of endpoints that do not comply with A list of endpoints that do not comply

M3 = Count of items in M1 A count of the total number of items in M1.

M4 = Count of items in M2 A count of the total number of items in

M2.

M5 = Count of endpoints in I1 (total number of end- A count of all the endpoints in I1.
points to check)

Metrics
Coverage

Metric Calculation

The percentage of endpoints which are compliant with the organization’s M3 / M5

access control policy.

l Who has access?

l What is being accessed?

l Why wireless access is required?

l Where from which locations is access required?

l When is access appropriate?

The CIS states this Control is critical:

“Major thefts of data have been initiated by attackers who have gained wireless access to
organizations from outside the physical building, bypassing organizations’ security peri-
meters by connecting wirelessly to access points inside the organization. Wireless clients
accompanying travelers are infected on a regular basis through remote exploitation while
on public wireless networks found in airports and cafes. Such exploited systems are then
used as backdoors when they are reconnected to the network of a target organization.
Other organizations have reported the discovery of unauthorized wireless access points on
their networks, planted and sometimes hidden for unrestricted access to an internal net-
work. Because they do not require direct physical connections, wireless devices are a con-
venient vector for attackers to maintain long-term access into a target environment.”

The journey of implementing the CIS Controls continues with controlled use of wireless networking.
Organizations are directed to verify that Advanced Encryption Standard (AES) is configured for all wire-
less technology. The sub-control that is part of Implementation Group 1 (IG1) is:

l 15.7: Leverage the Advanced Encryption Standard (AES) to Encrypt Wireless Data

Asset Type Security Function Implementation Groups

Network Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

Inputs
1. List of wireless devices: A list of wireless devices. This is derived from the Endpoint Inventory
(sub-control 1.4).

2. List of AES-capable wireless devices: A list of all AES-capable wireless devices (sub-control
1.5).

Operations
1. For each AES-capable wireless device, collect the cipher suite configuration.

Measures
Measure Definition

M1 = List of wireless devices A list of wireless devices.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of AES-capable A list of AES-capable wireless devices. Using the regex provided
wireless devices above, the organization can get a count of systems with AES con-
figured.

M5 = List of non-AES-cap- A list of non-AES-capable wireless devices. Using the regex

able wireless devices provided above, the organization can get a count of systems
without AES configured.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of appropriately A list of appropriately configured AES-capable wireless devices.

configured AES-capable Using the regex above, the organization can find the systems with
wireless devices only AES enabled.

M8 = Count of items in M7 A count of the total number of items in M7.

M9 = List of inappropriately A list of inappropriately configured AES-capable wireless

configured AES-capable devices. Using the regex above, the organization can find the sys-
wireless devices tems with only AES enabled.

M10 = Count of items in M9 A count of the total number of items in M9.

Metrics
Coverage

Metric Calculation

The percentage of AES-capable devices that are configured to use cipher M8 / M4

suites leveraging AES.

The CIS states this Control is critical:

“Attackers frequently discover and exploit legitimate but inactive user accounts to imper-
sonate legitimate users, thereby making discovery of attacker behavior difficult for secur-
ity personnel watchers. Accounts of contractors and employees who have been terminated
and accounts formerly set up for Red Team testing (but not deleted afterwards) have often
been misused in this way. Additionally, some malicious insiders or former employees have
gained access to accounts left behind in a system long after contract expiration, main-
taining their access to an organization’s computing system, and sensitive data for unau-
thorized and sometimes malicious purposes.”

The journey of implementing the CIS Controls continues with practicing good user account hygiene
and maintenance. Many systems (operating systems and application systems) may have the ability to
set controls and policies on user accounts. The centralized management of these types of accounts
can often be neglected or fall out of scope of normal business processes. Organizations are directed to
disable any unassociated or dormant accounts. These accounts are often overlooked or set up with a
default password, both of which are undesirable for more than a short period of time. For example, if a
user contacts the helpdesk to change the password, then it is appropriate for a default password to be
set. However, the password should then be changed within minutes, not weeks. Organizations are dir-
ected to configure systems to automatically lock workstation sessions after a specified inactivity
period. This setting is a common configuration and is set using Group Policy Objects for Windows com-
puters.

The three specific sub-controls that are part of Implementation Group 1 (IG1) are:

l 16.8: Disable Any Unassociated Accounts

l 16.9: Disable Dormant Accounts

l 16.11: Lock Workstation Sessions After Inactivity

For CIS Control 16, there is a strong connection to CIS Control 4 which speaks to elevated privileges.
Control 16 looks at all accounts and how local computer/application policy can be configured to sup-
port good account hygiene. Tenable products allow security operations teams to use Tenable.sc

For more information about the CIS Control 4/5 dashboard, see CIS Control 4/5: Secure Configurations
& Group Memberships.

NIST also provides helpful information directly related to this CIS Control under the NIST Special Public-
ation 800-53 (Rev. 4) - AC-2 ACCOUNT MANAGEMENT.

Sub Controls 16.8 & 16.9

Sub-control 16.8 is not a technical control, as this requires a human to make the association between
the role of the person and the account. However, Tenable.sc is able to query systems and retrieve
account names. Once the account names are collected, an organization can set up a manual process
to review the accounts. There are plugins that can be used to look for accounts that are not active, and
priority can be given to those systems. This process supports 16.9, as the dormant accounts may be
identified during the review process. The “CSF - Account and Group Information” table located in the
CIS Control 4/5 dashboard provides the query to use to get the information needed to support the
account review process.

This table displays detections of account and group information, such as accounts that have never
been logged into, disabled accounts, and group user lists. This information is obtained through Nessus
credentialed scans. Most of these detections contain lists of accounts in the output. The "Obtains the
Password Policy" detection contains the retrieved password policy in its output. Click on the Browse
Component Data icon on the component to view the vulnerability analysis screen. Here, you can view
the detections and investigate further. On the analysis screen, set the tool to Vulnerability Detail List
to view the full details for each detection, including description and output.

In the “CSF - Compliance Checks By Keyword” matrix, the “Log” row finds all audit checks with the
word “Log” present. Each column provides a specific view into the queries with different tools and
respective filters. The key to this control hover is illustrated in the “CIS Microsoft Windows Server 2019
Benchmark” setting index 2.3.7.3. In this setting, a Windows 2019 server is audited for the Interactive
Logon setting. This is the key setting used to track this session timeout. The organization must review
each benchmark and look for similar examples to find the exact matches. However, if the base work
used in the setting is “log”, then this filter in this row returns the results. For Cisco routers, the search
would be “exec-timeout”, which would not match. While Tenable can provide some keywords for

l CIS Microsoft Windows Server 2019 Benchmark

o https://workbench.cisecurity.org/files/2630
o "2.3.7.3 Ensure 'Interactive logon: Machine inactivity limit' is set to '900 or fewer second(s),
but not 0'"
o CIS_DC_SERVER_2019_Level_1_v1.1.0.audit

l Cisco IOS 15 Benchmark v4.0.1

o https://workbench.cisecurity.org/files/2585
o 1.2.9 Set 'exec-timeout' to less than or equal to 10 minutes 'line vty'"
o CIS_Cisco_IOS_15_v4.0.1_Level_1.audit

Below is a series of search terms and regular expressions to match:

Search Terms

l Inactive

l Timeout

l Idle connections

l Idle Timeout

l user shell timeout

l connection Timeout

l SSH Idle Timeout

l DCUI timeout

l shell services timeout

l terminate idle ESXi

l exec-timeout

Asset Type Security Function Implementation Groups

Users Respond 1, 2, 3

Dependencies
l None

Inputs
1. Inventory of accounts: An inventory of all accounts.

2. Inventory of business processes and/or business owners: An inventory of all business pro-
cesses and/or business owners.

Operations
1. For each account, enumerate any associated business processes or ownership.

Measures
Measure Definition

M1 = List of Accounts A list of all accounts. This number should be calculated per sys-
tem/application/centralized authentication source.

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of accounts not A list of all accounts not associated with any business process or
associated with any busi- ownership.
ness process or ownership.

M4 = Count of items in M3 A count of the total number of items in M3.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Coverage

Metric Calculation

The percentage of accounts that are associated with at least one business pro- M6 / M2
cess or ownership.

Asset Type Security Function Implementation Groups

Users Respond 1, 2, 3

Dependencies
l None

Inputs
1. Account Inventory: The list of all accounts created in the enterprise

2. Definition of "dormant threshold: An organizationally defined policy indicating a “dormant

threshold”. This serves as the period of inactivity after which the account is considered dormant.
The CIS recommends this be set to 1 month.

Assumptions
l The list of accounts for the enterprise includes OS-level, database, internal, and external applic-
ation accounts.

l Based on the account location, a query interface is assumed that enables the collection of a “last
activity” timestamp, such as last logon, as well as a status indicating if the account is enabled or
disabled.

Operations
1. For each account, enumerate any associated business processes or ownership.

Measures
Measure Definition

M2 = Count of items in M1 A count of the total number of items in M1.

M3 = List of accounts marked as enabled A list of all accounts marked as enabled.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of accounts enabled and not A list of all accounts that are enabled and have not
used for a time period outside the been used for a time period outside the dormant
dormant threshold threshold.

M6 = Count of items in M5 A count of the total number of items in M5.

Metrics
Dormant Accounts

Metric Calculation

The percentage of all accounts that are currently dormant but still enabled. M6 / M2

Enabled Dormant Accounts

Metric Calculation

The percentage of accounts that are marked enabled, that are currently M3 / M2
dormant and still enabled.

Asset Type Security Function Implementation Groups

Users Protect 1, 2, 3

Dependencies
l Sub-control 1.4: Maintain Detailed Asset Inventory

l Sub-control 1.5: Maintain Asset Inventory Information

l Sub-control 5.1: Establish Secure Configurations

Inputs
1. List of workstations with locking: A list of workstations which have enabled automatic work-
station locking

2. List of workstations: A list of all workstations.

3. Workstation configuration policy: The workstation configuration policy that establishes the
organization’s workstation locking time threshold.

Operations
1. For each workstation with locking enabled, collect the locking time threshold.

2. Collect the list of workstations whose locking time threshold exceeds the value specified by I3.

Measures
Measure Definition

M1 = List of Workstations A list of all systems discovered using Tenable.sc

and checked with audit files.

M3 = List of workstations with automatic A list all of workstations with automatic work-
workstation locking enabled station locking enabled.

M4 = Count of items in M3 A count of the total number of items in M3.

M5 = List of appropriately configured work- A list of all systems with the appropriate bench-
stations mark configured correctly.

M6 = Count of items in M5 A count of the total number of items in M5.

M7 = List of inappropriately configured work- A list of all systems with the appropriate bench-
stations mark configured incorrectly.

M8 = Count of items in M7 A count of the total number of items in M7.

Metrics
Misconfigured Workstations

Metric Calculation

The percentage of workstations with automatic locking enabled that are con- M6 / M2
figured within the locking time threshold.

Unconfigured Workstations

Metric Calculation

The number of workstations that do not have automatic locking enabled. M2 - M4

The four Organization controls are:

l CIS Control 17: Implement a Security Awareness and Training Program

l CIS Control 18: Application Software Security

l CIS Control 19: Incident Response and Management

l CIS Control 20: Penetration Tests and Red Team Exercises

The CIS groups these final 4 controls into the Organization Controls, and states:

“All of these topics are a critical, foundational part of any cyber defense program, but they
are different in character than CIS Controls 1-16. While they have many technical elements,
these are less focused on technical controls and more focused on people and processes.
They are pervasive in that they must be considered across the entire enterprise, and
across all of CIS Controls 1-16. Their measurements and metrics of success are driven
more by observations about process steps and outcomes, and less by technical data gath-
ering. They are also complex topics in their own right, each with an existing body of lit-
erature and guidance.

Therefore we present CIS Controls 17-20 as follows: for each CIS Control, we identify a
small number of elements that we believe are critical to an effective program in each area.
We then describe processes and resources which can be used to develop a more com-
prehensive enterprise treatment of each topic. Although there are many excellent com-
mercial resources available, we provide open and non-profit sources where possible. The
ideas, requirements, and processes expressed in the references are well supported by the
commercial marketplace.”

CIS Control 17 states:

“For all functional roles in the organization (prioritizing those mission-critical to the busi-
ness and its security), identify the specific knowledge, skills, and abilities needed to sup-
port defense of the enterprise; develop and execute an integrated plan to assess, identify
gaps, and remediate through policy, organizational planning, training, and awareness pro-
grams.

Why Is This CIS Control Critical?

It is tempting to think of cyber defense primarily as a technical challenge, but the actions
of people also play a critical part in the success or failure of an enterprise. People fulfill
important functions at every stage of system design, implementation, operation, use, and
oversight. Examples include: system developers and programmers (who may not under-
stand the opportunity to resolve root cause vulnerabilities early in the system life cycle); IT
operations professionals (who may not recognize the security implications of IT artifacts
and logs); end users (who may be susceptible to social engineering schemes such as phish-
ing); security analysts (who struggle to keep up with an explosion of new information); and
executives and system owners (who struggle to quantify the role that cybersecurity plays
in overall operational/mission risk, and have no reasonable way to make relevant invest-
ment decisions).”

Tenable.sc provides reports and other data display tools to help the security awareness team under-
stand how risk mitigation efforts are progressing. As shown in the image below, we have created
accounts for the executive team who organizationally, is responsible for assets. This visualization can
be used to help provide awareness of the current state of the vulnerability management program.
Other filters and queries can also be used to help illustrate risk management functions. As the organ-
ization matures and becomes more security aware, these types of reports can also serve as Key Per-
formance Indicators (KPI).

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
CIS Control 18: Application Software Security
As an organization grows, custom applications are often developed to help with business workflow or
other services which are offered to customers. These applications expose the organization to risk.
Additionally, if the data stored is customer data, the customers may also be exposed. There are several
tools in the market to help with Application Software Security. For example, the non-profit group Open
Web Application Security Project® (OWASP) provides information to aid in the detection and mitigation
of such risk.

CIS Control 18 states:

“Manage the security life cycle of all in-house developed and acquired software in order to
prevent, detect, and correct security weaknesses.

Why Is This CIS Control Critical?

Attacks often take advantage of vulnerabilities found in web-based and other application
software. Vulnerabilities can be present for many reasons, including coding mistakes, logic
errors, incomplete requirements, and failure to test for unusual or unexpected conditions.
Examples of specific errors include: the failure to check the size of user input; failure to fil-
ter out unneeded but potentially malicious character sequences from input streams; fail-
ure to initialize and clear variables; and poor memory management allowing flaws in one
part of the software to affect unrelated (and more security critical) portions.

There is a flood of public and private information about such vulnerabilities available to
attackers and defenders alike, as well as a robust marketplace for tools and techniques to
allow “weaponization” of vulnerabilities into exploits. In one attack, more than 1 million web
servers were exploited and turned into infection engines for visitors to those sites using
SQL injection. During that attack, trusted websites from state governments and other
organizations compromised by attackers were used to infect hundreds of thousands of
browsers that accessed those websites. Many more web and non-web application vul-
nerabilities are discovered on a regular basis.”

Tenable.io Web Application Scanner (WAS) and Container Security products provide assistance in the
discovery and assessment of application vulnerabilities. However, tools that review the source code
should also be used. Detailed analysis tools can be integrated into the build process to assess the soft-
ware against vulnerable libraries or common coding mistakes. Addressing vulnerable libraries or com-
mon mistakes can help address these risks.

CIS Control 19 States:

“Protect the organization’s information, as well as its' reputation, by developing and imple-
menting an incident response infrastructure (e.g., plans, defined roles, training, com-
munications, management oversight) for quickly discovering an attack and then effectively
containing the damage, eradicating the attacker’s presence, and restoring the integrity of
the network and systems.

Why Is This CIS Control Critical?

Cyber incidents are now just part of our way of life. Even large, well-funded, and tech-
nically sophisticated enterprises struggle to keep up with the frequency and complexity of
attacks. The question of a successful cyber-attack against an enterprise is not “if” but
“when.”

When an incident occurs, it is too late to develop the right procedures, reporting, data col-
lection, management responsibility, legal protocols, and communications strategy that will
allow the enterprise to successfully understand, manage, and recover. Without an incident
response plan, an organization may not discover an attack in the first place, or, if the
attack is detected, the organization may not follow good procedures to contain damage,
eradicate the attacker’s presence, and recover in a secure fashion. Thus, the attacker may
have a far greater impact, causing more damage, infecting more systems, and potentially
exfiltrating more sensitive data than would otherwise be possible were an effective incid-
ent response plan in place.”

Tenable.sc CV provides a passive sensor that can help with enumeration of systems on the network.
This passive sensor monitors network flows and looks for vulnerability based on clear text information
or other traffic patterns. This detection method may assist organizations during incident response (IR),

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
CIS Control 20: Penetration Tests and Red Team Exercises
As a final testament to a good security program, the CIS Control 20 recommends the organization test
all the security controls. These exercises are very beneficial to training and security awareness. Many
times well intended measures can be exploited. For example, a really strict password policy can result
in users taping passwords to their keyboard. A great technical control, thwarted by a forgetful user
and an observant adversary. Many times developers find protocols they find useful, and never realize
there is an inherent security flaw, for example FTP and Telnet, are great tools. But in both cases, all cre-
dential exchanges are in clear text, allowing passwords and other information to be captured easily.
Many chat programs use a form of HTTP and not HTTPS, again data is exchanged in the clear. With
wireless technologies, many times with a simple wireless receiver, anyone can monitor the full
exchanges of information. Penetration tests and red team exercises help to bring this information to
the forefront of the security conversation.

CIS Control 20 states:

“Test the overall strength of an organization’s defense (the technology, the processes, and
the people) by simulating the objectives and actions of an attacker.

Why Is This CIS Control Critical?

Attackers often exploit the gap between good defensive designs and intentions and imple-
mentation or maintenance. Examples include: the time window between announcement of
a vulnerability, the availability of a vendor patch, and actual installation on every machine.
Other examples include: well-intentioned policies that have no enforcement mechanism
(especially those intended to restrict risky human actions); failure to apply good con-
figurations to machines that come on and off of the network; and failure to understand the
interaction among multiple defensive tools, or with normal system operations that have
security implications.

A successful defensive posture requires a comprehensive program of effective policies

and governance, strong technical defenses, and appropriate action by people. In a com-
plex environment where technology is constantly evolving, and new attacker tradecraft
appears regularly, organizations should periodically test their defenses to identify gaps
and to assess their readiness by conducting penetration testing.”

Tenable.sc and Nessus are often good tools to use to aid in pre-assessment activities. Many red team
members use Nessus as a network discovery tool. By using tools that do similar tasks conducted by

Referring back to the Basic Controls (CIS Control 1 - 6) these are the initial steps the red team will per-
form. The first step is to scan the network and identify hardware, then software. Now the red team has
targets, they will then begin to enumerate vulnerabilities and test for baseline configurations, and so
on. After a good list of vulnerabilities are collected, the fundamental controls will be tested. The vul-
nerabilities discovered by Tenable.sc have an attribute called, exploitable. With this attribute the organ-
ization can easily see the low hanging fruit and plan to take the required mitigation efforts.

Shown in the “Exploitable by Malware - Exploitable Matrix” the organization can quickly see which pop-
ular attack tools their environment is most exploitable by. In these cases there are well known and
widely used tools to exploit vulnerable systems. The red team will often use these tools to illustrate the
likelihood a system could be compromised. Many attackers may use the same tools, or develop their
own, but in either case if the organization has several exploitable systems, then there is a lot of work
needed before a penetration test will be valuable. Once a majority of these vulnerabilities are mit-
igated, then the red team should be engaged.

While Exploitable is a great attribute to use, in some cases an exploitable attribute may require a per-
fect storm condition. As this is the case, Tenable created the Vulnerability Priority Rating (VPR). VPR is
the output of Tenable Predictive Prioritization, and helps organizations improve their remediation effi-
ciency and effectiveness by rating vulnerabilities based on severity level, technical impact, and threat.
The technical impact measures the impact on confidentiality, integrity and availability following exploit-
ation of a vulnerability and is equivalent to the CVSSv3 impact subscore. The threat component

To install the CAS Implementation Group 1 (IG1) dashboard:

1. Navigate to the Dashboard page.

2. Select Add Dashboard under options.

3. Search for “Implementing the CIS Control Assessment Specification (CAS)”.

Note: Use quotes when searching for the dashboard.

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
After installing the dashboard from the feed, take a minute to review the contents in each matrix. This
dashboard is specifically designed to work with this guide. For each control, where data can be dis-
played, there is a corresponding matrix. These cells provide the queries for a specific metric or input.
The column or row headers indicate the sub-control or the focus related to the sub-control. The first
component in the upper left hand corner is crafted to take full use of the questionnaire file CAS Imple-
mentation Group 1 Audit File.

Note: For information about scanning and collecting data, see the Tenable.sc Large Enterprise Deployment Guide and
the Tenable Professional Services Scan Strategy Guide.

The results from the CAS Implementation Group 1 Audit File help drive focus on more administrative
controls, such as the existence of a policy and where it is located. Risk managers are frequently asked
to provide a single report to auditors, and to provide all the data related to the audit. The audit file fea-
ture allows risk managers and the security team to provide answers to the audit questions. The first
cells provide an indicator of the data collection process. If the answers are any value other than the
default of “None” or “No”, the “Data Collected” indicator will be enabled. For any of the questions that
are still the default, the “Data Missing” indicator will be enabled. For each of the controls with ques-
tions that are present in the audit file, there is a separate question.

Tenable provides organizations with the means to effectively address a number of the security chal-
lenges with implementing the CIS Controls v7 and assists with navigating the CAS. Tenable.sc CV is the
most strategic source to start cyber hygiene for both public and private sector organizations, making
foundational cybersecurity more affordable, accessible, and actionable. By providing this guide, dash-
board, and report, Tenable is the first and only vendor to automate both the implementation and audit-
ing of an organization’s adherence to IG1, maximizing limited budgets and resource-constrained
teams. Tenable.sc and CAS together helps organizations transform the Controls into actionable cyber-
security recommendations and integrate basic cyber hygiene across their operations.

l CIS CAS Audit Requirements

l Create a New Repository + Scan Zone

l Create a New Audit File + Policy

l Create a Scan

l Run Scan + See the Results

l CAS Implementation Group 1 Audit Questions

Copyright © 2022 Tenable, Inc. All rights reserved. Tenable, Tenable.io, Tenable Network Security, Nessus, SecurityCenter, SecurityCenter Continuous View and Log Correlation Engine are registered trademarks of
Tenable,Inc. Tenable.sc, Tenable.ot, Lumin, Indegy, Assure, and The Cyber Exposure Company are trademarks of Tenable, Inc. All other products or services are trademarks of their respective owners.
Audit File Scan Tutorial
This tutorial walks you through creating a policy compliance scan using a custom audit file. The
tutorial is written with the assumption that the scan will be run on a known and scanned target. Addi-
tionally, when selecting a target to scan, the system should be RHEL 7 or CentOS 7 server. For ease of
operation, Tenable recommends that you scan a single system and set up a single repository so the
data will not be a part of any other scan result. By using a target that is known, and scans that are
already working, the policy creation is much easier. The tutorial also assumes that the target system is
being scanned with valid credentials, and the credentials have elevated permissions. Note that these
audit checks will not actually do any scanning on the system, but the individual plugins that are used
to perform the audit needs the same access as if a typical audit scan is being executed. Finally, we’ll
want to create a new repository and scan zone to isolate the scan data to ensure that only the desired
target is being scanned.

l Root credentials

l Successful scans currently completed

l Separate repository used for the audit data collected

l Separate scan zone with only the single target used in the scan

1. While logged in as an admin user, navigate to Repositories and click Add button. You should
then select IPv4 repository.

2. Enter a name in the Name field and an IP range in the IP Ranges field. The IP range should be
just the system that will be scanned to ensure that no other targets are scanned. Additionally,
ensure that an organization is selected to allow a security manager to access the repository.

3. Under the Resources menu in the top bar, click Scan Zones.

4. Enter the required fields, Name and Ranges. The IP range should be just the system that will be
scanned to ensure that no other targets are scanned. Ensure a scanner is selected.

After creating the repository and scan zone, the next step is to prepare the requirements for the scan
(Audit file, Credentials, and Policy). The credentials for the target should be known, therefore they will
be re-used. Next the audit file must be imported before creating the policy. The questions for the audit
file are listed in CAS Implementation Group 1 Audit Questions along with the possible values. Please
refer to the questions before uploading the audit file.

The scan will use a Policy Compliance Auditing policy since the scan will be run on a known target,
but if the scan will be done on a new target it may be helpful instead create a custom policy with only
the “General”, “Policy Compliance”, and “Settings” plugin families enabled. Having the custom policy for
the scan will allow the user to troubleshoot the scan easily if something fails (ex. credentials).

1. Under Scans, navigate to Audit Files and add the CAS Implementation Group 1 audit file.

2. In the Name field, enter a name.

3. Fill out the compliance questions with the answers as described in CAS Implementation Group 1
Audit Questions.

Note: The audit questions have two parts. The first part requires a Yes or No. The second part requires a
location. If the answer to the first question is is No then the answer to the second question should be
“None”. Every audit question that is answered “Yes” will pass, while every “No” will fail.

4. Under Scans, navigate to Policies and add a Policy Compliance Auditing policy.

5. Add the audit file that was created above, under Compliance.

After the policy is created the active scan can be created. Keep in mind, the target should match or be
within the IP range that was input when creating the repository and scan zone.

1. After creating an active scan, ensure the correct Policy is selected.

2. Ensure the correct Import Repository is selected.

3. Select the Scan Credentials that were created earlier.

4. Enter the target IP in IPs / DNS Names.

Once the scan is created and run, the user can navigate to scan results and drill into the scan. Drilling
into the scan result will bring the user to the Vulnerability Analysis page. Each CIS Control plugin

To see the scan results:

1. Select the correct scan under Scan Results to see the Vulnerability Analysis page.

Audit Question Answer

1.4 - Maintain Detailed Asset Inventory No

1.4: Location of Policy or Policy Statement None

1.6 - Unauthorized assets are removed No

1.6: Timeframe for removing/updating assets 999

10.1 - Ensure Regular Automated Backups No

10.1: Location of List of which services are in use None

10.2 - Perform Complete System Backups No

10.4 - Protect Backups No

10.5 - Ensure All Backups Have Offline Backup Destination No

12.1 - Maintain an Inventory of Network Boundaries No

12.1: Location of the diagram/plan None

12.4(a) - Deny Communications Over Unauthorized Ports No

12.4(a): Location of the list/document None

12.4(b) - Deny Communications Over Unauthorized Ports No

12.4(b): Location of Policy or Policy Statement None

13.1 - Maintain an Inventory of Sensitive Information No

13.1: Location of Policy or Policy Statement None

13.2: Location of Policy or Policy Statement None

13.6 - Encrypt Mobile Device Data No

13.6: Location of Policy or Policy Statement None

14.6 - Protect Information Through Access Control Lists No

14.6: Location of Policy or Policy Statement None

2.1(a) - Maintain an Inventory of Authorized Software None

2.1(a): Location of List of Approved Software None

2.1(b)) - Maintain Inventory of Authorized Software No

2.1(b): Location of Policy or Policy Statement None

3.4(a) - Deploy Automated OS Patch Management Tools No

3.4(a): Location of Policy or Policy Statement None

3.4(b) - Deploy Automated OS Patch Management Tools No

3.4(b): Location of the exception policy None

3.4(b): Location of the list of endpoints that have an exception None

3.4(c)) - Deploy Automated OS Patch Management Tools None

3.4(c): Location of Policy or Policy Statement None

3.6(a) - Deploy Automated Software Patch Management Tools No

3.6(a): Location of Policy or Policy Statement None

3.6(b) - Deploy Automated Software Patch Management Tools No

3.6(b): Location of the exception policy None

4.2 - Change Default Passwords No

4.2: Location of Policy or Policy Statement None

4.3 - Ensure the Use of Dedicated Administrative Accounts No

5.1 - Establish Secure Configurations No

5.1: Location of the Secure Configuration documentation No

6.2(a) - Activate Audit Logging No

6.2(a): Location of Policy or Policy Statement None

6.2(b) - Activate Audit Logging No

7.7 - Use of DNS Filtering Services No

7.7: Location of List of which services are in use None

8.4 - Configure Anti-Malware Scanning of Removable Media No

8.5 - Configure Devices to Not Auto Run Content No

16.8(a) - Does the Organization have a list of all business roles? No

16.8(a) - Location of Policy or Policy Statement None

16.8(b) - Does the Organization have a list of all computer and applications No
accounts?

16.8(b) - Location of Policy or Policy Statement None

Attesting user to the answers provided for this report. Attesting

User

CIS Controls v8.1 Mapping To NIST CSF v2.0 6-24-2024 Final 1
No ratings yet
CIS Controls v8.1 Mapping To NIST CSF v2.0 6-24-2024 Final 1
92 pages
JTT1078 Protocol 2016 For Video MettaX
No ratings yet
JTT1078 Protocol 2016 For Video MettaX
42 pages
CIS Controls and Sub-Controls Mapping To ISO
No ratings yet
CIS Controls and Sub-Controls Mapping To ISO
47 pages
CIS Controls v8 Mapping To NIST SP 800 53 Rev 5 Moderate and Low Base
No ratings yet
CIS Controls v8 Mapping To NIST SP 800 53 Rev 5 Moderate and Low Base
264 pages
CIS 18 Critical Security Controls Checklist: Learn How To Achieve CIS® Compliance
No ratings yet
CIS 18 Critical Security Controls Checklist: Learn How To Achieve CIS® Compliance
6 pages
CIS Controls v7.1 Mapping To ISO 27001 v19.07
100% (1)
CIS Controls v7.1 Mapping To ISO 27001 v19.07
46 pages
CIS Controls Checklist
No ratings yet
CIS Controls Checklist
6 pages
CIS Controls v7.1 Mapping To NIST CSF
No ratings yet
CIS Controls v7.1 Mapping To NIST CSF
60 pages
Critical Controls Poster 2016
No ratings yet
Critical Controls Poster 2016
2 pages
Tenable Csis Compliance Whitepaper
No ratings yet
Tenable Csis Compliance Whitepaper
22 pages
CIS Controls Version 7.1 Implementation Groups 1.2
No ratings yet
CIS Controls Version 7.1 Implementation Groups 1.2
64 pages
NYS Cyber Security Toolkit
100% (1)
NYS Cyber Security Toolkit
112 pages
Cis Controls v8 Mapping To Nist CSF Final 06-11-2021
No ratings yet
Cis Controls v8 Mapping To Nist CSF Final 06-11-2021
111 pages
CIS Controls v8 Mapping To NIST CSF FINAL 06 11 2021
No ratings yet
CIS Controls v8 Mapping To NIST CSF FINAL 06 11 2021
111 pages
CIS Controls v8 Mapping To UK NCSC Cyber Assessment Framework v3.1 - 8-16-2022
No ratings yet
CIS Controls v8 Mapping To UK NCSC Cyber Assessment Framework v3.1 - 8-16-2022
115 pages
CIS Controls Version 7.1 Implementation Groups 1.2
No ratings yet
CIS Controls Version 7.1 Implementation Groups 1.2
64 pages
CIS Controls V7.1 8.5x11 Singles 2
No ratings yet
CIS Controls V7.1 8.5x11 Singles 2
4 pages
CIS Controls v7.1 Mapping PCI DSS V1.0.a
No ratings yet
CIS Controls v7.1 Mapping PCI DSS V1.0.a
126 pages
CIS Controls Version 8.1!6!24 2024
No ratings yet
CIS Controls Version 8.1!6!24 2024
46 pages
CIS Controls v8 Mapping To ISACA COBIT 19 V21.10.spreadsheets
100% (1)
CIS Controls v8 Mapping To ISACA COBIT 19 V21.10.spreadsheets
88 pages
CIS Controls V7.0.1-EBOOK - Parte3
No ratings yet
CIS Controls V7.0.1-EBOOK - Parte3
2 pages
The CIS Top 20 Controls Explained
No ratings yet
The CIS Top 20 Controls Explained
4 pages
CIS_Controls_v8_Mapping_to_CSF_2.0__February_2024_
No ratings yet
CIS_Controls_v8_Mapping_to_CSF_2.0__February_2024_
100 pages
CIS Controls v8.1 Mapping to NIST SP 800 53 Rev 5 Moderate and Low Ba
No ratings yet
CIS Controls v8.1 Mapping to NIST SP 800 53 Rev 5 Moderate and Low Ba
268 pages
CIS Controls and Sub Controls Mapping To NIST CSF
0% (1)
CIS Controls and Sub Controls Mapping To NIST CSF
64 pages
CIS Controls v8 Mapping To CMMC v2 0 4 2023
No ratings yet
CIS Controls v8 Mapping To CMMC v2 0 4 2023
154 pages
CIS RAM v2.1 For IG1 Workbook.22.05
No ratings yet
CIS RAM v2.1 For IG1 Workbook.22.05
174 pages
20 Critical Controls Poster 062010
No ratings yet
20 Critical Controls Poster 062010
2 pages
CIS Critical Security Controls (Center For Internet Security) (Z-Library)
No ratings yet
CIS Critical Security Controls (Center For Internet Security) (Z-Library)
96 pages
CIS Controls V7.0.1-EBOOK - Parte8
No ratings yet
CIS Controls V7.0.1-EBOOK - Parte8
2 pages
CIS Controls v8 Mapping To SOC2 2 2023
100% (1)
CIS Controls v8 Mapping To SOC2 2 2023
68 pages
CIS Controls v8 CMMC Mapping
No ratings yet
CIS Controls v8 CMMC Mapping
122 pages
CIS Controls Version 8 ES
No ratings yet
CIS Controls Version 8 ES
49 pages
CIS Controls v8.1 Mapping To ISO - IEC 27001.2022 6 2024 07 15
No ratings yet
CIS Controls v8.1 Mapping To ISO - IEC 27001.2022 6 2024 07 15
105 pages
CIS_Controls_v8_Mapping_to_PCI_DSS_v4.0_9_2023
No ratings yet
CIS_Controls_v8_Mapping_to_PCI_DSS_v4.0_9_2023
168 pages
Implementation Groups: Basic Cyber Hygiene
No ratings yet
Implementation Groups: Basic Cyber Hygiene
4 pages
CIS-Controls-v8--Mapping-to-PCI-DSS-v40
No ratings yet
CIS-Controls-v8--Mapping-to-PCI-DSS-v40
151 pages
CIS Controls v8 NEW MAPPING To ISO - IEC 27001.2022 2 2023
No ratings yet
CIS Controls v8 NEW MAPPING To ISO - IEC 27001.2022 2 2023
109 pages
CIS_Controls_v8.1_Mapping_to_800_171_Rev2_7_2024__1_
No ratings yet
CIS_Controls_v8.1_Mapping_to_800_171_Rev2_7_2024__1_
104 pages
CIS Controls v8 Mapping To PCI v3.2.1 Final 08-19-2021
100% (1)
CIS Controls v8 Mapping To PCI v3.2.1 Final 08-19-2021
113 pages
Qadeer Arbab (MS-IS-074) Waqas Syed Mubbashir Mahmood (MS-IS-070)
100% (2)
Qadeer Arbab (MS-IS-074) Waqas Syed Mubbashir Mahmood (MS-IS-070)
24 pages
Cyber Threat Management Summary
No ratings yet
Cyber Threat Management Summary
19 pages
CIS Controls v8.1 Mapping to PCI DSS v4.0!6!2024!07!15
No ratings yet
CIS Controls v8.1 Mapping to PCI DSS v4.0!6!2024!07!15
172 pages
CIS Controls v8 Mapping To ISO - IEC 27002.2022 2022 0406
100% (3)
CIS Controls v8 Mapping To ISO - IEC 27002.2022 2022 0406
121 pages
Sy0 601 01
100% (1)
Sy0 601 01
17 pages
CIS Controls v8 Implementation Groups Handout.22.02
No ratings yet
CIS Controls v8 Implementation Groups Handout.22.02
4 pages
CIS Controls v8 Mapping To SOC2 Final 08-19-2021
No ratings yet
CIS Controls v8 Mapping To SOC2 Final 08-19-2021
105 pages
Nessus Compliance Checks Reference
No ratings yet
Nessus Compliance Checks Reference
446 pages
CIS Controls v8 Mapping To CSA Cloud Controls Matrix v4 2 2023
No ratings yet
CIS Controls v8 Mapping To CSA Cloud Controls Matrix v4 2 2023
119 pages
CIS_Controls_v8_Mapping_to_800_171_Rev_2_5_24_2021
No ratings yet
CIS_Controls_v8_Mapping_to_800_171_Rev_2_5_24_2021
81 pages
CIS Updates The 20 Critical Security Controls
No ratings yet
CIS Updates The 20 Critical Security Controls
3 pages
CIS_Controls_Version_8.1.2_Change_Log___March_2025
No ratings yet
CIS_Controls_Version_8.1.2_Change_Log___March_2025
164 pages
AuditScripts CIS Controls Initial Assessment Tool v7.1b
No ratings yet
AuditScripts CIS Controls Initial Assessment Tool v7.1b
23 pages
CIS Controls v8 Guide
No ratings yet
CIS Controls v8 Guide
87 pages
Cis Controls V7.0.1-Ebook
No ratings yet
Cis Controls V7.0.1-Ebook
31 pages
CIS Controls v8.1 Mapping To CSA Cloud Controls Matrix v4 2024 07 19
No ratings yet
CIS Controls v8.1 Mapping To CSA Cloud Controls Matrix v4 2024 07 19
133 pages
AuditScripts CIS Controls Initial Assessment Tool v7.1b
No ratings yet
AuditScripts CIS Controls Initial Assessment Tool v7.1b
23 pages
About Kubernetes and Security Practices - Short Edition: First Edition, #1
From Everand
About Kubernetes and Security Practices - Short Edition: First Edition, #1
Ami Adi
No ratings yet
Kubeadm Cluster Deployment and Management Guide: Definitive Reference for Developers and Engineers
From Everand
Kubeadm Cluster Deployment and Management Guide: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Minikube in Practice: Definitive Reference for Developers and Engineers
From Everand
Minikube in Practice: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Mastering Shell for DevOps
From Everand
Mastering Shell for DevOps
Gilbert Stew
No ratings yet
OpenHIM Product Overview
No ratings yet
OpenHIM Product Overview
17 pages
RN.MPiec.04 MPiec_2_6_0 Release_Notes
No ratings yet
RN.MPiec.04 MPiec_2_6_0 Release_Notes
5 pages
3.4 - Principles of Reliable Data Transfer
No ratings yet
3.4 - Principles of Reliable Data Transfer
2 pages
W6100 Ethernet Shield User Guide: How To Use The Wiznet Ethernet Library
No ratings yet
W6100 Ethernet Shield User Guide: How To Use The Wiznet Ethernet Library
16 pages
CAU HOI ON TAP PE NWC203c FALL 2021
No ratings yet
CAU HOI ON TAP PE NWC203c FALL 2021
4 pages
2.intro Networks2
No ratings yet
2.intro Networks2
24 pages
Q. No. 1-5 Carry One Mark Each: Ax Ax
No ratings yet
Q. No. 1-5 Carry One Mark Each: Ax Ax
32 pages
ZM-Protocol (Version A1.3) ) VNET Version
No ratings yet
ZM-Protocol (Version A1.3) ) VNET Version
7 pages
Here
No ratings yet
Here
4 pages
Roomie DDK
No ratings yet
Roomie DDK
15 pages
CN QUESTION BANK 21CS52
No ratings yet
CN QUESTION BANK 21CS52
4 pages
I-Direct System Presentation
No ratings yet
I-Direct System Presentation
34 pages
Network Protocol (CSE - 306) (Makeup) PDF
No ratings yet
Network Protocol (CSE - 306) (Makeup) PDF
2 pages
Question Bank for CN Network and Transport Layer
No ratings yet
Question Bank for CN Network and Transport Layer
3 pages
SV Hotel v9.5
No ratings yet
SV Hotel v9.5
112 pages
Quectel EC2x&EG25-G&EG9x&EM05 FILE AT Commands Manual V1.0
No ratings yet
Quectel EC2x&EG25-G&EG9x&EM05 FILE AT Commands Manual V1.0
27 pages
Sliding Window Protocol
100% (1)
Sliding Window Protocol
10 pages
Zixi Receiver - Aws Mediaconnect User Guide: Software Version 12.4 Document Version Doc26-450-0002 All Rights Reserved
No ratings yet
Zixi Receiver - Aws Mediaconnect User Guide: Software Version 12.4 Document Version Doc26-450-0002 All Rights Reserved
42 pages
The Application Layer: Lecture-9
No ratings yet
The Application Layer: Lecture-9
66 pages
Network Hardware
No ratings yet
Network Hardware
15 pages
Computer Abbreviations - Ritambhara Pandey
No ratings yet
Computer Abbreviations - Ritambhara Pandey
4 pages
Socket Presentation
No ratings yet
Socket Presentation
13 pages
Internet of Things Cloud Architecture
No ratings yet
Internet of Things Cloud Architecture
20 pages
CSC Unit-3
No ratings yet
CSC Unit-3
21 pages
Unit 5 (CSS)
No ratings yet
Unit 5 (CSS)
9 pages
Apj Abdul Kalam Kerala Technological University: (Kolam Cluster - 02)
No ratings yet
Apj Abdul Kalam Kerala Technological University: (Kolam Cluster - 02)
79 pages
DELTA - IA-HMI - DOPSoft-2-00-07 - Technical Announcement - UM-EN - 20171124 PDF
No ratings yet
DELTA - IA-HMI - DOPSoft-2-00-07 - Technical Announcement - UM-EN - 20171124 PDF
32 pages
R1 (Config) #Interface Ethernet0/0.20 R1 (Config) #Encapsulation Dot1q 20 R1 (Config) #Ip Address 10.20.20.1 255.255.255.0
No ratings yet
R1 (Config) #Interface Ethernet0/0.20 R1 (Config) #Encapsulation Dot1q 20 R1 (Config) #Ip Address 10.20.20.1 255.255.255.0
5 pages
CN Lab Manual
No ratings yet
CN Lab Manual
79 pages