Last updated at Tue, 03 Sep 2024 20:53:10 GMT

Stop No. 5 on our tour of the CIS Critical Security Controls (previously known as the SANS Top 20 Critical Security Controls) deals with Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers. This is great timing with the announcement of the death of SHA1. (Pro tip: don't use SHA1). The Critical Controls are numbered in a specific way, following a logical path of building foundations while you gradually improve your security posture and reduce your exposure. Control 1: Inventory and Control of Hardware Assets, and Control 2: Inventory and Control of Software Assets are foundational to understanding what you have. Now it's time to shrink that attack surface by securing the inventory in your network.

As stated in the control description, default configurations for operating systems and applications are normally geared toward ease-of-deployment and not toward security. This means open and running ports and services, default accounts or passwords, older and more vulnerable protocols (I'm looking at YOU telnet), pre-installed and perhaps unnecessary software, and the list goes on. All of these are exploitable in their default state.

The big question is, what constitutes secure configurations? As with most questions in information security, the answer is all contextual, based on your business rules. So before you attempt a secure configuration, you need to have some understanding of what your business needs to do and what it does today.  This also means a lot of detailed analysis of your applications, and this can be a complex task. This is also a task that is a continuous process; it is not just “one and done.” Secure configuration must be continually managed to avoid security decay. As you implement vulnerability management, your systems and applications will be patched and updated, and this will change your position on secure configurations. Configurations will change based on new software or operational support changes, and if not secured attackers will take advantage of the opportunities to exploit both network-accessible services and client software.

What It Is

Secure Configuration for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers is part of the "basic" group. This is in the back office, by IT and security, and should not be handled by users in the front office. It's very likely that your organization is using some kind of secure configs unless you run 100% out-of-the-box. Rapid7 finds that most orgs do not go far enough, and a lot of exposure exists that has no defined business purpose or need.

This control is broken down into seven sub-controls. The sub-controls describe the entire process of managing secure configurations, but do not go into specifics about the configurations themselves. So we will cite resources here you can use to help you start to securely configure your enterprise (and even your home systems).

How to Implement It

There are many ways to go about secure configurations, and it's likely that not everything publicly available is going to be completely relevant. Like you would with a deny all rule in a firewall deployment, approach these with a mindset of starting as small as you can and gradually opening up your systems and applications until they are usable. This is great for new systems or those yet to be deployed. But what about older systems? It's not very likely you can just shut them down and work this process. Still, you should seek to reduce the running services and ports, especially those which are known to be vulnerable and not in use.

The Configs

There are a number of usable resources for secure configurations. Rapid7 regularly recommends to clients the following:

  • NIST 800-70 rev 3
    • This NIST special publication is a document that governs the use of checklists, it is not itself a configuration guide. It is most valuable in breaking down configuration levels for using multiple checklists. This is especially useful in complex business environments, when you will need to have many different configuration baselines for your systems. It also contains information on developing, evaluating and testing your checklists.
  • National Vulnerability Database (NVD)
    • The NVD maintained by NIST is a great repository for many things in control 4 (Vulnerability Management), and it is also useful for control 3 with their checklists. This repo contains SCAP content, Group Policy Objects for Active Directory, and human readable settings. This is a great first start for any secure configuration activity.
  • CIS Benchmarks
    • Sometimes these are referred to hardening guides, their official name is the CIS Benchmarks. Curated by the same organization that handles the Critical Controls, the CIS Benchmarks are available for multiple operating systems, web browsers, mobile devices, virtualization platforms and more. You can also get SCAP-compliant checklists in XCCDF format for direct application to systems.
  • Security Technical Implementation Guide (STIG)
    • The STIGs are curated by the federal government, adhering to rules and guidelines issued by the Department of Defense. These pages contain actual configuration templates (some in SCAP format) that can be directly applied to systems. There are also templates for cloud-based services, application security and a lot of training references. STIGs are great, but not for the faint of heart, or for organizations who don't have a deep technical understanding of the application or OS they're attempting to reconfigure. So handle them with caution, but they are very helpful in locking down systems.

Minimum Standards

All of the above resources are based on consensus and community or government standards and are considered to be sound strategies to reduce your attack surface. They are not comprehensive, and as already stated your mileage may vary and you should take a customized approach that best supports your business needs.

At the end of the day, what you are looking to do is maintain a set of minimum standards for your configs. You can pore through the checklists to give you ideas, like disable IPv6 if it is not necessary, don't use RDP without TLS, don't ever run Telnet ever for any reason ever. Did I mention not to run telnet? Build your checklist and use it for all your deployments, and don't forget about your existing and vulnerable systems! They need extra love too.

Rapid7 observes many organizations that know they have a vulnerable legacy system that they cannot modify directly to reduce the attack surface. If you have one of these brittle/fragile/unfixable systems, consider ways to limit inbound/outbound access and connectivity to help mitigate the risk until it can be upgraded or replaced with something more securable.

All The Other Things

Everything above talks about the first sub-control, which is the secure config itself. There are several more things this control covers, such as:

  • Follow strict configuration management processes for all changes to your secure builds.
  • Create master images (gold images) that are secure, and store those in a safe and secure location so they can't be altered.
  • Perform remote administration only over secure channels, and use a separate administration network if possible.
  • Use file integrity checking tools or application whitelisting tools to ensure your images are not being altered without authorization.
  • Verify your testable configurations and automate this as much as possible – run your vulnerability scanner against your gold image on a regular frequency and use SCAP to streamline reporting and integration.
  • Deploy configuration management tools (SCCM, Puppet/Chef, Casper) to enforce your secure configurations once they are deployed.

As you can see there's quite a bit to getting your systems and applications secured, as well as having processes to support the ongoing care and feeding of your secure configs. This is a foundational control, so it's important to get right and keep going with continual improvement. Putting the required time and effort into this will yield you a lot of return, simply because your exposure will have shrunk significantly, and allow you to focus on the more advanced security measures without worrying about some Powershell script kiddie popping your box because of insecure telnet. Oh, by the way, you should probably disable telnet.

Like what you see? Check out our next post in this series, “The CIS Critical Security Controls Explained, Part 6: Maintenance, Monitoring, and Analysis of Audit Logs.”