IT Security 101: Essential Cyber Hygiene of the CIS Controls® v8.1
Introduction
In a previous IT Security 101, I took a look at the CIS Controls® v8.1 in their entirety. Today I will dive into the CIS Controls® Integration Group (IG) 1, which covers what CIS considers to be “essential cyber hygiene”. I suggest reading the previous article to become acquainted with the framework before continuing.
The official documents are found here. Download them now if you have not done so already.
As mentioned in the previous article on the topic, there are 18 Controls with a total of 153 Safeguards, and three IGs that basically represent different levels of organizational security maturity: IG1, IG2, and IG3.
IG1 represents the lowest level of organization, and the least complex control tasks. However, these tasks are considered best-practice for all organizational levels, and are included in IG2 and IG3. This is why the Safeguards associated with IG1 are considered “essential cyber hygiene”. I will simply refer to them as "The Essentials”.
I will provide a general explanation for each essential, and some tips for success. Though some of the Safeguards specify creating documents and processes, while others prescribe technical controls, it is important to remember that to be successful, the goal is to develop a complete and cohesive security program. All administrative and technical controls should support each other, to foster a positive security culture and an effective security program.
Put the kettle on and settle in.
The Essentials
Of the 153 total Safeguards, 56 are considered essential. Not all of the 18 Controls are represented, as some are considered out of scop for IG1, such as AppSec (C16) and pentests (C18).
I will now provide an explanation of the essential Safeguards. I will also provide some insights and suggestions based on struggles and successes I have experienced.
Control 1 | Inventory and Control of Enterprise Assets | IG1: 2/5
1.1 | Establish and Maintain Detailed Enterprise Asset Inventory
1.2 | Address Unauthorized Assets
C1 focuses on identifying device assets, managing their authorization, and cataloging them. It offers technical controls to address this, but they are beyond the scope of IG1.
This is often overlooked, underrated, or proves difficult to address for a number of reasons:
Decentralized organizational purchasing that allows business units to select, order and deploy devices without proper oversight or interdepartmental communication.
Lack of company-wide policies, procedures, standards and guidelines ensuring that devices are vetted, secured, deployed and tracked appropriately.
Lack of documentation, leading to unknowns and blind-spots about the environment.
Lack of device control that allows anyone to introduce a device into the network.
Mobile devices that may roam and may not always be online.
A “Can’t be bothered,” mentality.
A very large or complex network topology.
Some of these concerns are addressed in the 18 Controls, however not always within the scope of the essentials. C1 is a critical first step, so take the time to do this correctly for effective defense, and do not neglect its upkeep. This is a continuous activity.
A company should know its assets and their purpose so proper categorization and prioritization can be assigned to assist with assessing security requirements and implementing effective controls. The bad guys want to know this information, so company’s should too.
1.1 | Establish and Maintain Detailed Enterprise Asset Inventory
Devices | Identify
A detailed inventory of device should be developed and maintained. This should include all devices that have the potential to store, transmit, or process data. So, all workstations, servers, network equipment, IoT devices, and mobile devices. The inventory should be reviewed and updated at most bi-annually.
S1.1 states that it should collect:
IP Addresses
Hardware Addresses
Machine Names
Asset Owners
Associated Departments
Approvals
I would also suggest including (if applicable):
Device Make & Model
OS Name
OS / Software Versions
Firmware Versions
Vendor Support / Contact Information
This could later be expanded to include details regarding its purpose, the type of data it stores/processes/transmits, and any associated accounts, but that goes beyond the scope of The CIS Controls. However, I would suggest considering some ways to associate the device asset inventory with other inventories, such as installed software (S2.1) and data (S3.2), and even associated accounts (S5.1), to get a complete picture of the environment.
1.2 | Address Unauthorized Assets
Devices | Respond
Only authorized devices should be allowed in the environment. S1.2 prescribes a weekly process to enforce this. Unauthorized devices can be removed, denied, or quarantined. S1.2 does not specify how, simply that a process should exist.
This seems to me ineffective without the how, so look to the other Safeguards for specific methods. Also look for future posts in which I provide tools and practices to address all of the Controls.
Control 2 | Inventory and Control of Software Assets | IG1: 3/7
2.1 | Establish and Maintain a Software Inventory
2.2 | Ensure Authorized Software is Currently Supported
2.3 | Address Unauthorized Assets
C2 focuses on identifying software assets, managing their authorization, and cataloging them. This includes addressing unauthorized software through preventive technical controls to block installation and execution, but their specifics are outside the scope of IG1.
This one usually proves unpopular with end-users, so care should be taken to ensure productivity and business functions are not negatively impacted. Try to find authorized alternatives when possible to appease disgruntled users. Also, a shift in security culture may be required through increased training and awareness (addressed in C14), to help the users understand why they can’t just install any software that they want. This will also include the removal of local Admin rights, so prepare for that battle. Admin rights are addressed in S5.4 and their reduction/removal are considered essential.
In general try to prevent, to the greatest extent possible, software that:
has not come from an approved official source,
violates any licensing agreements, regulations or laws,
is not required for any business purpose,
may be leveraged by an attacker to “live-off-the-land”.
Another important aspect of this control is to manage software life cycles, to ensure that outdated and unsupported software is managed. In general, unsupported software should be upgraded or replaced. However, it is often the case that systems cannot be upgraded due to dependencies or budgetary restrictions - typically things like legacy business systems or expensive healthcare and manufacturing equipment. In that case a risk assessment should be conducted, and an authorized exception should be documented. Mitigating controls should be implemented to reduce the residual risk to an acceptable level.
2.1 | Establish and Maintain a Software Inventory
Software | Identify
S2.1 is similar to S1.1, except this detailed inventory is for software assets. The inventory should be reviewed at most bi-annually. S2.1 dictates that the following details must be included (if applicable):
Title
Publisher
Initial Install / User Date
Business Purpose
Uniform Resource Locator (URL)
App Store(s)
Version(s)
Deployment Mechanisms
Decommissioned Date
Number of Licenses
2.2 | Ensure Authorized Software is Currently Supported
Software | Identify
A process should be developed that authorizes software based on its support status. The software’s entry in the inventory should reflect its authorization state. Any unauthorized software should have a risk assessment performed on it, and mitigating controls need to be implemented to reduce its risk to an acceptable level. An exception should be documented, following predefined exception policy and procedure.
S2.2 does not specify a technical control for identifying unauthorized software, but this could be addressed in Safeguards outside of IG1 scope.
2.3 | Address Unauthorized Assets
Software | Respond
S2.3 mandates the removal of unauthorized software from the environment. If software cannot be removed, a risk assessment should be conducted and mitigating controls should be put into place to reduce risk to an acceptable level. An approved exception should then be documented. Further, S2.3 mandates a monthly review at most. It does not clarify what is being reviewed, but the assumption is they are referring to the inventory list.
Control 3 | Data Protection | IG1: 6/14
3.1 | Establish and Maintain a Data Management Process
3.2 | Establish and Maintain a Data Inventory
3.3 | Configure Data Access Control Lists
3.4 | Enforce Data Retention
3.5 | Securely Dispose of Data
3.6 | Encrypt Data on End-User Devices
C3 focuses on “controls to identify, classify, securely handle, retain, and dispose of data”. This is straightforward. Data should be identified and categorized so that appropriate controls can be put into place.
The primary goal is to protect data deemed critical by the organization, which could be based on many factors, including its type, its value to the business, and any regulations or laws that govern it. For this to be effective, the first two controls are critical steps, or data may be missed or misidentified.
3.1 | Establish and Maintain a Data Management Process
Data | Govern
S3.1 mandates the creation and maintenance of a data management process, to be reviewed and updated yearly or after any impactful changes that could affect the process. The process should address the following:
data sensitivity
data owner
data handling
data retention
data disposal
Sensitivity refers to the data’s classification. This can be dictated by an existing framework, or it could reflect the data’s type. For example, public, confidential, PII, PHI, financial, proprietary, copyright, etc.
A data owner is the individual accountable for the governance of the data, perhaps being responsible for ensuring its security and dictating access to others.
Handling refers to the who/what/where/when/why/how of data collection, processing, analysis, storage, transmission, access, and use. This may depend on data sensitivity, laws, or regulations.
Retention is the length of time that data will be held onto, and should include minimum and maximum timeframes. Again, this may depend on the data sensitivity, laws or regulations.
Disposal is how data is destroyed when retention periods end, or possibly for a number of other reasons.
An interesting thing to note here is the framework’ss lack of consistency. Creating a process is considered essential, and it should include data sensitivity; however, S3.7: Establish and Maintain a Data Classification Scheme is not considered essential cyber hygeine.
3.2 | Establish and Maintain a Data Inventory
Data | Identify
An inventory of data should be created and maintained. This should be guided by the data management process, and at a minimum should contain an inventory of sensitive data.
Further, I think the entry should include ownership, data location, and data category/sensitivity/type.
3.3 | Configure Data Access Control Lists
Data | Protect
Data access should be controlled on a need-to-know basis. This should be applied across the environment including local and remote file systems, databases and applications.
There are different methods of access control that may be dictated by industry standards or regulatory requirements, such as Role-Based Access Control (RBAC), Mandatory Access Control (MAC) or Attribute-Based Access Control (ABAC).
3.4 | Enforce Data Retention
Data | Protect
Data should be retained according to the timelines codified in the data management process. Retention should include min and max retention.
This may be dictated by the company requirements, legal obligations, financial reporting obligations, or other regulations.
3.5 | Securely Dispose of Data
Data | Protect
Data should be disposed of according to the requirements and methods codified in the data management process. Data sensitivity is paramount when determining the disposal process.
Data identification and categorization are key precursors. In general, data that is highly sensitive should be disposed of with the most care to avoid its recovery.
3.6 | Encrypt Data on End-User Devices
Data | Protect
End-user devices containing sensitive data should be encrypted.
Again, sensitivity requires categorization -S3.7 - which is not essential so consider reviewing that Safeuard.
Control 4 | Secure Configuration of Enterprise Assets and Software | IG1: 4/6
4.1 | Establish and Maintain a Secure Configuration Process
4.2 | Establish and Maintain a Secure Configuration Process for Network Infrastructure
4.3 | Configure Automatic Session Locking on Enterprise Assets
4.4 | Implement and Manage a Firewall on Servers
C4 focuses on secure configuration of assets. This includes hardening and baselining devices, applications and operating systems, and configuring client firewalls. It is a good practice to close gaps before systems are ever introduced into the environment.
In general, aim to remove any unnecessary services, programs, and protocols, and change unsecured default system settings, especially administrative passwords, as well as unsecured protocols like Telnet and HTTP (i.e. enforce SSH and HTTPS).
This process should be continuously managed, to ensure systems are checked against baselines prior to deployment, and hardening processes should be updated when changes call for new hardening standards, such as when standards are no longer secure, or to address impactful changes in the environment.
4.1 | Establish and Maintain a Secure Configuration Process
Documentation | Govern
A documented secure configuration process should be established for end-user devices and servers. The process should be reviewed and updated annually, or when impactful changes occur.
4.2 | Establish and Maintain a Secure Configuration Process for Network Infrastructure
Documentation | Govern
A documented secure configuration process should be established for network devices. The process should be reviewed and updated annually, or when impactful changes occur.
4.3 | Configure Automatic Session Locking on Enterprise Assets
Devices | Protect
As part of the hardening process, automatic session lockouts should be configured for periods of inactivity. For general operating systems, this should be no more than 15 minutes. For mobile devices, this should be no more than 2 minutes.
Generally, this is to prevent unauthorized access if a system is left logged in and unattended.
4.4 | Implement and Manage a Firewall on Servers
Devices | Protect
As part of the hardening process, firewalls should be enabled on servers, where supported.
There is a lot of prep work that goes into this process. Turning on the firewalls without configuring them securely is going to be ineffective, and could be disruptive. Analysis is required to ensure only authorized traffic can get through, but the Controls do not specify as such.
Control 5 | Account Management | IG1: 4/6
C5 focuses on identifying, cataloging and managing user and service accounts.
The identification of service accounts can be challenging. Quite often accounts are spun up for test or dev and are not removed when no longer required, accounts may contain nondescript or misleading names, and there may be a general lack of documentation. This is another area that highlights the importance of the identification processes in Controls 1, 2 and 3. The data gathered form those activities can assist with identifying service accounts.
C5 also contains Safeguards that prescribe unique passwords, and minimum password length requirements of 8 for MFA protected accounts, and 14 for those without MFA (MFA is addressed in Control 6). There is also a Safeguard to disable dormant accounts, and to remove/reduce administrative privileges.
Remember to warn users about any removal of admin rights, especially if they are used to having the access. Ensure processes are in place to respond to requests for admin tasks, and warn IT support about an influx of support requests from unhappy users. Make sure the helpdesk has playbooks or canned responses to handle this.
From my experience, taking away admin rights is always a battle, so be prepared and try to make it as seamless as possible. Users are going to come up with various reasons why they need admin rights, so try to identify where it might be unavoidable and develop an exception process, or alternative methods.
Finally there are Safeguards that mandate account reviews. This is a process in which systems are reviewed for unauthorized accounts. This includes accounts created by accident, by malicious actors, are unnecessary, are generic, or belong to terminated users.
5.1 | Establish and Maintain an Inventory of Accounts
Users | Identify
There should be an inventory of all accounts. It should catalogue all standard users, administrative users, and service accounts with the following information:
the person’s name,
username,
start/stop dates, and
department.
An account review should be conducted at most quarterly.
This can be a big undertaking. For service accounts, consider the person’s name to be the owner of the service. This will require some analysis of its purpose, which should also be catalogued.
Another item that is not discussed in the CIS Controls is the use of generic accounts. In general, accounts should be unique and assigned to a user for accountability. Interactive generic accounts make it difficult to identify who is using the account, without other controls to track this. Try to avoid interactive generic accounts for users, and consider additional controls to ensure that service accounts cannot be used for interactive logins. As with any control, exceptions might be unavoidable.
5.2 | Use Unique Passwords
Users | Protect
All accounts should use unique passwords, with 8 characters minimum with Multi-Factor Authentication (MFA) and 14 characters without.
This is standard best practice for everyone everywhere. Longer is better.
5.3 | Disable Dormant Accounts
Users | Protect
Any account that is inactive for 45 days should be disabled.
Use caution when applying this to avoid disabling service accounts that might not be used regularly unless there is a solid process to enable it when needed. For example, a system that runs end of year processing.
5.4 | Restrict Administrator Privileges to Dedicated Administrator Accounts
Users | Protect
Administrative privileges should be restricted to dedicated admin accounts. Standard accounts should be used for everyday activities.
This is another standard best-practice. A lot of common threats are prevented, or their impact is reduced, simply by not running as admin. As I mentioned in my overview of C5, this can be a struggle to implement without upsetting the users, and in some cases without disrupting productivity, so make sure processes and training are in place to address this.
Control 6 | Access Control Management | 5/8
6.1 | Establish an Access Granting Process
6.2 | Establish and Maintain an Inventory of Accounts
6.3 | Require MFA for Externally-Exposed Applications
6.4 | Require MFA for Remote Network Access
6.5 | Require MFA for Administrative Access
This Control and its Safeguards focus on the creation and revocation of accounts, the enforcement of MFA, and the management of account access, ideally through centralization. This is a continuation of Control 5, which set the groundwork.
There is a heavy focus on MFA here, with 3/8 Safeguards specifying it for different types of accounts. So, that highlights the importance of it.
Surprisingly, Role Based Access (RBAC) is listed here only for IG3. The reasoning is unclear, but it seems that the creators may be using it broadly, combining it with other access control practices such as Attribute-Based Access Control (ABAC) and Mandatory Access Control (MAC), which are seen in more strict environments. Or, perhaps, they are adhering to the heirchal structure of the framework and suggesting that RBAC is not possible without first having cenralized access control. This is all conjecture on my part.
In either case, it is my understanding that RBAC is simply granting access based on role, where roles are assigned permissions instead of permissions being assigned directly to users. This is a standard practice that reduces the administrative overhead of user and permissions management, and helps control permission sprawl. I think it should be considered basic hygiene.
6.1 | Establish an Access Granting Process
Documentation | Govern
A process should be developed to grant access for new hires and during role changes.
If a solid process is not in place, and staff are not trained well, they may default to a mode of, “Give this user the same rights as so-and-so.” Care should be taken to avoid this. It can cause privilege sprawl, and the granting of access beyond the user’s intended job functions, which in turn can lead to accidental or intentional unauthorized access, use, disclosure, or even damage. This can grow exponentially if the process is not adhered to, and users are granted privileges ad-hoc.
6.2 | Establish and Maintain an Inventory of Accounts
Documentation | Govern
A process should be developed to revoke access for terminated users, during role changes, or when otherwise required. Disabling accounts may be necessary to maintain audit trails.
If disabling accounts make sure there is a process in place to review active accounts for any that should be disabled, and consider other controls to identify their use.
6.3 | Require MFA for Externally-Exposed Applications
Users | Protect
All external-facing and 3rd-party applications should enforce MFA, if supported. MFA via directory services and SSO are satisfactory.
Make sure processes are in place to handle MFA reset requests, or lost / stolen MFA devices. Lost / stolen devices should be reported immediately and care should be taken to secure and monitor the account.
6.4 | Require MFA for Remote Network Access
Users | Protect
MFA should be enforced for remote access. This includes any access that originates from outside the network, such as RDP, or VPN.
6.5 | Require MFA for Administrative Access
Users | Protect
All administrative access, regardless of its placement inside or outside of the network, should enforce MFA whenever supported.
Make sure processes are in place to handle MFA reset requests, or lost / stolen MFA devices. Lost / stolen devices should be reported immediately and extra care should be taken to secure and monitor the account.
Control 7 | Continuous Vulnerability Management | IG1: 4/7
7.1 | Establish and Maintain a Vulnerability Management Process
7.2 | Establish and Maintain a Remediation Process
7.3 | Perform Automated Operating System Patch Management
7.4 | Perform Automated Application Patch Management
C7 focuses on vulnerability and patch management. This includes development of an overall management process to identify, remediate and track vulnerabilities. It considers vulnerability scanning to be out of scope for IG1, but patch management should be implemented by everyone.
Vulnerability scans can cause disruption and overwhelm resources if not properly configured. A good vulnerability scanner will have safeguards for identifying impact, such as unresponsive hosts, and network congestion.
7.1 | Establish and Maintain a Vulnerability Management Process
Documentation | Govern
A documented vulnerability management process should be established and maintained, with an annual review, or when environment changes warrant.
Patch management is often considered a separate activity from vulnerability management, but the two are connected and should be developed together to ensure cohesion and effectiveness.
7.2 | Establish and Maintain a Remediation Process
Documentation | Govern
A risk-based remediation process should be developed, maintained and reviewed weekly, or more often.
This is really a continuation of S7.1. It wouldn’t be an effective vulnerability managements strategy without addressing remediation. This can be difficult when it comes to legacy systems that are no longer supported by the vendor but are still required, or in environments that require constant up-time (but lack redundancy or failover capabilities). The process should include a testing phase to ensure remediation efforts do not cause disruption.
7.3 | Perform Automated Operating System Patch Management
Software | Protect
An automated process should be developed and maintained to patch operating systems monthly, or more often. Patching is a critical function to ensure the latest security fixes are implemented as quickly as possible, especially in today’s world of constant cyber attacks and 0-days.
7.4 | Perform Automated Application Patch Management
Software | Protect
An automated process should be developed and maintained to patch applications monthly, or more often. As with operating systems, patching applications is a critical function to ensure the latest security fixes are implemented as quickly as possible.
In general, deploying patches to operating systems has become routine for IT departments. However, it can still be a struggle to patch 3rd-party applications. Other Safeguards can assist, such as application control to help reduce the applications introduced into the environment and centralize their management.
Control 8 | Audit Log Management | IG1: 3/12
8.1 | Establish and Maintain an Audit Log Management Processs
8.2 | Collect Audit Logs
8.3 | Ensure Adequate Audit Log Storage
C8 focuses on the collection and retention of audit logs, as well as configuration log alerts and conducting log reviews. The purpose is to assist in the identification of, and analysis of, and recovery from a malicious event.
8.1 | Establish and Maintain an Audit Log Management Process
Documentation | Govern
A process should be created and maintained to codify logging requirements. It should address the collection, review and retention of audit logs. The process should be reviewed and updated annually, or when impactful changes occur in the organization.
8.2 | Collect Audit Logs
Data | Detect
Logging should be enabled throughout the environment, per the scope defined in the audit log management process, and potentially dictated by other policies, standards and guidelines, both internal and external.
8.3 | Ensure Adequate Audit Log Storage
Data | Protect
There should be enough storage for the audit logs as prescribed by the audit log management process, and potentially dictated by other policies, standards and guidelines, both internal and external.
Control 9 | Email and Web Browser Protections | IG1: 2/7
9.1 | Ensure Use of Only Fully Supported Browsers and Email Clients
9.2 | Use DNS Filtering Services
C9 focuses on the protection against threats through email and web.
9.1 | Ensure Use of Only Fully Supported Browsers and Email Clients
Software | Protect
Only supported browsers and email clients should be allowed to execute in the environment. It specifies using only the latest version of browsers and email clients provided by the vendor. It is surprising that this would be considered IG1, because it can be difficult to enforce if some form f application control is not in place, and especially when users are able to install their own software.
9.2 | Use DNS Filtering Services
Devices | Protect
DNS filtering should be enabled for all end-user devices. This specifies blocking known malicious domains. This can be accomplished by a network-level device; however, some solutions provide agents as well to cover remote assets, or mobile systems that might be outside of the internal network’s permiter defenses.
Control 10 | Malware Defense | IG1: 3/7
10.1 | Deploy and Maintain Anti-Malware Software
10.2 | Configure Automatic Anti-Malware Signature Updates
10.3 | Disable Autorun and Autoplay for Removable Media
C10 focuses on anti-malware, and mandates controlling its installation, spread and execution. This includes apps, code and scripts. Basically, it provides Safeguards that describe the installation and configuration of anti-malware software and system settings.
10.1 | Deploy and Maintain Anti-Malware Software
Devices | Detect
Anti-malware software should be deployed to all assets. This is basic and straightforward, though I don’t think they are adhering to their definition of assets on this one, so focus on deploying to any supported assets.
10.2 | Configure Automatic Anti-Malware Signature Updates
Devices | Protect
Automatic updates of anti-malware signatures should be configured. This is also straightforward. The Controls often emphasize automation to reduce administrative overhead and help ensure system security is always up-to-date.
10.3 | Disable Autorun and Autoplay for Removable Media
Devices | Protect
Autorun / Autoplay should be disabled for removable media. Removable devices are a common vector for introducing malware, so this will help reduce the chance that a compromised device can spread its payload to the asset.
Control 11 | Data Recovery | IG1: 4/5
11.1 | Establish and Maintain a Data Recovery Process
11.2 | Perform Automated Backups
11.3 | Protect Recovery Data
11.4 | Establish and Maintain an Isolated Instance of Recovery Data
C11 focuses on the ability to recover assets after an incident. This means keeping regular backups that can return systems and data to a known good state. This will often be dictated by a Disaster Recovery Plan (DRP) and Business Continuity Plan (BCP), which in turn may be based on customer contracts and SLAs, or regulatory requirements. This Safeguard aligns with the I and A of the CIA Triad.
11.1 | Establish and Maintain a Data Recovery Process
Documentation | Govern
A process should be created and maintained that codifies:
the scope of asset recovery,
asset recovery prioritization, and
back data security controls.
The documentation should be reviewed and updated yearly, or when impactful changes to the organization occur.
11.2 | Perform Automated Backups
Data | Recover
Automated backups should be run weekly or more frequently.
11.3 | Protect Recovery Data
Data | Protect
Recovery data should be protected with the same level of controls as that of the original.
11.4 | Establish and Maintain an Isolated Instance of Recovery Data
Data | Recover
Recovery data should be duplicated in an isolated location. This includes offline, cloud or off-site, separate from the organization’s network.
Control 12 | Network Infrastructure Management | IG1: 1/8
12.1 | Ensure Network Infrastructure is Up-to-Date
C12 focuses on the management of infrastructure assets that support the rest of the environment. Only one Safeguard is considered essential and applies to IG1.
12.1 | Ensure Network Infrastructure is Up-to-Date
Network infrastructure should be kept updated. This is a basic concept that aligns with the best-practice of ensuring systems are patched with the latest supported versions, especially security related fixes. It also mandates a monthly review of software versions to validate that they are still supported. Many major vendors provide transparency on their equipment’s support life cycles, so proactive steps should be taken to get ahead of end of life deadlines and avoid gaps in support availability.
Control 13 | Network Monitoring and Defense | IG1: 0/11
No Safeguards apply to IG1.
Control 14 | Security Awareness and Skills Training | IG1: 8/9
14.1 | Establish and Maintain a Security Awareness Program
14.2 | Train Workforce Members to Recognize Social Engineering Attacks
14.3 | Train Workforce Members on Authentication Best Practices
14.4 | Train Workforce on Data Handling Best Practices
14.5 | Train Workforce Members on Causes of Unintentional Data Exposure
14.6 | Train Workforce Members on Recognizing and Reporting Security Incidents
14.7 | Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates
14.8 | Train Workforce on the Dangers of Connecting to and Transmitting Enterprise Data Over Insecure Networks
C14 focuses on security awareness and skill training to ensure staff is kept up to ate on the latest best practices, and company policies. The entire list apart from one is considered essential hygiene, and each Safeguard addresses a specific topic or area on which to train staff.
This should be engaging and effective. See my recent article on gamification in cybersecurity for a closer look at this topic.
14.1 | Establish and Maintain a Security Awareness Program
Documentation | Govern
A security awareness program should be established and maintained. It should address best practices and company policy related to the safe and appropriate use of company assets. Training should be conducted at time of hire and yearly, at least, if not more often. The program should be reviewed and updated annually, or as required by impactful changes in the organization.
14.2 | Train Workforce Members to Recognize Social Engineering Attacks
Users | Protect
Staff should be trained on how to recognize social engineering, such as phishing, business email compromise (BEC), pretexting and tailgating.
14.3 | Train Workforce Members on Authentication Best Practices
Users | Protect
Staff should be trained on authentication best practices, such as MFA, passwords and credential management.
14.4 | Train Workforce on Data Handling Best Practices
Users | Protect
Staff should be trained on best practices for handling data including how to identify, store, transfer, archive, and destroy sensitive data. This also includes training staff on best practices for clear desk and screen.
14.5 | Train Workforce Members on Causes of Unintentional Data Exposure
Users | Protect
Staff should be trained on how to avoid unintentional data exposure, such as mis-delivery, lost devices, and publishing to unintended audiences.
14.6 | Train Workforce Members on Recognizing and Reporting Security Incidents
Users | Protect
Staff should be trained on how to recognize and report security incidents.
This should be developed with guidance from the process developed for S17.3.
14.7 | Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates
Users | Protect
Staff should be trained on how to verify and report out-of-date software and failures in automated patching. The training should include notification to IT.
I have never seen this in action in any environment. It seems like a difficult task, given that most automated patching deployments are done so silently and with the intention of reducing disruption to end-users. It might require technical skills beyond those of the average user, and given the number of disparate systems and applications, a daunting endeavor. If the reader can identify a good solution to this, then bravo.
14.8 | Train Workforce on the Dangers of Connecting to and Transmitting Enterprise Data Over Insecure Networks
Users | Protect
Staff should be trained in secure data transmission. This follows basic best-practice of securing communication channels. Training should include training remote users on how to secure their home network.
Control 15 | Service Provider Management | IG1: 1/7
15.1 | Establish and Maintain an Inventory of Service Providers
15.1 | Establish and Maintain an Inventory of Service Providers
Users | Identify
A list of service providers should be maintained. The service providers should be classified and should have a internal employee assigned as the primary point of contact. The list should be updated annually, or when significant changes affect the list.
Control 16 | Application Software Security | 0/14
No Safeguards apply to IG1.
Control 17 | Incident Response Management | IG1: 3/9
17.1 | Designate Personnel to Manage Incident Handling
17.2 | Establish and Maintain Contact Information for Reporting Security Incidents
17.3 | Establish and Maintain an Enterprise Process for Reporting Incidents
C17 focuses on the development of an incident response plan.
17.1 | Designate Personnel to Manage Incident Handling
Users | Respond
There should be a primary and a backup person to manage the process. The manager is responsible for the coordination and documentation of response and recovery efforts. The managers can be employees, service providers or a combination. When using service providers, an employee should be designated to oversee 3rd-parties. The process should be reviewed annually or when significant changes to the organization affect the process.
17.2 | Establish and Maintain Contact Information for Reporting Security Incidents
Documentation | Govern
During an incident, there are many stakeholders that need to be kept informed. A contact list should be created and maintained. The list should be verified yearly. Stakeholders could be:
internal staff,
service providers,
law enforcement,
cyber insurance providers,
government agencies, or
Information Sharing and Analysis Center (ISAC) Partners.
Internal staff should be kept informed of an ongoing incident as necessary, especially if it affects them, their work or any of their owned systems. They should also be trained on how to handle questions related to an incident, with policy in place to address communication with family, friends, news agencies and social media (ideally there is a designated person for such communications - likely from HR, Legal, or a PR department).
Laws and regulations might dictate who should be contacted and when, in the event of an incident for a number of reasons including, as a general rule for all incidents, for specific types of incidents, if data has been compromised, or if certain categories of individuals have been affected. Some regulations also require reporting to affected users in the event of data compromise.
17.3 | Establish and Maintain an Enterprise Process for Reporting Incidents
Documentation | Govern
A documented process for security incident reporting should be created and maintained. The process should include:
timeframe,
personnel or report to,
mechanism for reporting, and
minimum information for reporting.
Timeframe is ambiguous, but take it to mean how quickly after discovery an incident must be reported. Personnel to report to should be dictated by the Incident Response Plan. Likely, it will begin with a ticket or call to the support desk, or directly to a member of security. The mechanism is the manner in which an incident should be reported. This helps to streamline the process, and catalog the reports. It should be consistent, include a backup method, and reflect the criticality of the event.
Control 18 | Penetration Testing | IG1: 0/5
No Safeguards apply to IG1.
Essential Cyber Hygiene Safeguards
1.1 | Establish and Maintain Detailed Enterprise Asset Inventory
1.2 | Address Unauthorized Assets
2.1 | Establish and Maintain a Software Inventory
2.2 | Ensure Authorized Software is Currently Supported
2.3 | Address Unauthorized Software
3.1 | Establish and Maintain a Data Management Process
3.2 | Establish and Maintain a Data Inventory
3.3 | Configure Data Access Control Lists
3.4 | Enforce Data Retention
3.5 | Securely Dispose of Data
3.6 | Encrypt Data on End-User Devices
4.1 | Establish and Maintain a Secure Configuration Process
4.2 | Establish and Maintain a Secure Configuration Process for Network Infrastructure
4.3 | Configure Automatic Session Locking on Enterprise Assets
4.4 | Implement and Manage a Firewall on Servers
5.1 | Establish and Maintain an Inventory of Accounts
5.2 | Use Unique Passwords
5.3 | Disable Dormant Accounts
5.4 | Restrict Administrator Privileges to Dedicated Administrator Accounts
6.1 | Establish an Access Granting Process
6.2 | Establish and Maintain an Inventory of Accounts
6.3 | Require MFA for Externally-Exposed Applications
6.4 | Require MFA for Remote Network Access
6.5 | Require MFA for Administrative Access
7.1 | Establish and Maintain a Vulnerability Management Process
7.2 | Establish and Maintain a Remediation Process
7.3 | Perform Automated Operating System Patch Management
7.4 | Perform Automated Application Patch Management
8.1 | Establish and Maintain an Audit Log Management Process
8.2 | Collect Audit Logs
8.3 | Ensure Adequate Audit Log Storage
9.1 | Ensure Use of Only Fully Supported Browsers and Email Clients
9.2 | Use DNS Filtering Services
9.3 | Maintain and Enforce Network-Based URL Filters
10.1 | Deploy and Maintain Anti-Malware Software
10.2 | Configure Automatic Anti-Malware Signature Updates
10.3 | Disable Autorun and Autoplay for Removable Media
11.1 | Establish and Maintain a Data Recovery Process
11.2 | Perform Automated Backups
11.3 | Protect Recovery Data
11.4 | Establish and Maintain an Isolated Instance of Recovery Data
12.1 | Ensure Network Infrastructure is Up-to-Date
12.2 | Establish and Maintain a Secure Network Architecture
14.1 | Establish and Maintain a Security Awareness Program
14.2 | Train Workforce Members to Recognize Social Engineering Attacks
14.3 | Train Workforce Members on Authentication Best Practices
14.4 | Train Workforce on Data Handling Best Practices
14.5 | Train Workforce Members on Causes of Unintentional Data Exposure
14.6 | Train Workforce Members on Recognizing and Reporting Security Incidents
14.7 |Train Workforce on How to Identify and Report if Their Enterprise Assets are Missing Security Updates
14.8 | Train Workforce on the Dangers of Connecting to and Transmitting Enterprise Data Over Insecure Networks
15.1 | Establish and Maintain an Inventory of Service Providers
17.1 | Designate Personnel to Manage Incident Handling
17.2 | Establish and Maintain Contact Information for Reporting Security Incidents
17.3 | Establish and Maintain an Enterprise Process for Reporting Incidents
Some Additional Insights
Asset Ownership
I’d like to address what I would consider an essential component to many of the identification tasks prescribed by the CIS Controls: Ownership Assignment. Though not directly addressed by any Control, it is mentioned in Safeguards such as 1.1 and 2.2.
This is an idea that goes beyond simply cataloging the primary user of a workstation. This is a concept that should be codified in any effective security program. All asset types, in essence, have owners of one form or another. It is most common to think of device owners, but applications, systems, and data all have owners. Even documentation should have an owner. This guarantees accountability, and assists when attempting to implement changes, updates, patches, remediations, etc. Establishing this before or during the development of any inventorying activity is good practice.
This is also an essential practice when developing plans such as Business Continuity Plans (BCP), Incident Response Plans (IRP), Disaster Recovery Plans (DRP), or when conducting Business Impact Analyses (BIAs). Having any of these already on-hand could also assist with inventorying activities.
Security Exceptions
Another important concept to keep in mind is security exceptions. I want to emphasize the importance of this process and its need to be managed. This requires consistent policy and procedure to control how exceptions are requested, validated, approved, implemented and documented. This is not addressed by any of the CIS Controls, but it is mentioned in them, and is a valuable component of any successful and effective security program.
Conclusion
The Essentials are a good starting point to begin building a solid program. It is important to remember that consistency and cohesion across all Controls and their Safeguards is vital to ensure compliance and effectiveness. Security is not about checking boxes, it is about creating layered and balanced controls that make the entire organization safe, resilient and productive.
Watch for future articles where I discuss methods and tools to assist with compliance.
Daily Cuppa
Today’s cup of tea is Organic Earl Grey provided by Equal Exchange. Organic, fair trade, and full of flavor. A great alternative to coffee on a chilly Saturday morning.
¹CIS Critical Security Controls® v8.1
Any text or images pulled directly from the control documents provided by CIS are covered by the Creative Commons License.
If you enjoyed this article, or the site in general, feel free to buy the author a cup of tea.