By applying hardening best practices to host and guest operating systems, hypervisors, and infrastructure control planes, you can significantly reduce the attack surface and improve your overall security posture. Combining hardening with supporting technical controls provides a robust security baseline to build upon.

Where did this come from?

This security control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. The matrix provides a comprehensive set of controls that cover all the key domains of cloud security.

For more background on OS hardening, check out the CIS Benchmarks, which provide industry-standard hardening guidelines for various operating systems and cloud platforms. Major cloud providers like AWS also provide their own hardening recommendations.

Who should care?

• System administrators responsible for configuring and maintaining operating systems
• Security engineers tasked with defining and implementing security baselines
• DevOps teams who need to ensure their build and deployment pipelines produce hardened images
• Compliance officers who must demonstrate adherence to hardening standards

What is the risk?

Insufficiently hardened operating systems are much more vulnerable to:

• Malware infections that can lead to data theft or ransomware
• Unauthorized access via unnecessary open ports or overly permissive settings
• Elevation of privilege attacks that take advantage of unpatched vulnerabilities
• Compliance failures due to lack of alignment with expected benchmarks

While hardening alone is not a complete security solution, it addresses many common risks and provides a vital layer of defense. Exploits against un-hardened systems are widely available, making them low-hanging fruit for attackers.

What's the care factor?

Hardening should be considered a high priority for most organizations. While the specific risk will vary based on exposure and sensitivity of the systems, hardening is a widely-acknowledged best practice with clear benefits.

Hardening does require some initial effort to analyze and configure systems appropriately. But this is easier than cleaning up after a major incident. Many hardening steps can also be automated for consistency and efficiency. The level of caring should be high, but need not be difficult.

When is it relevant?

OS hardening is relevant for essentially every compute host that has a general purpose operating system, whether physical or virtual. It applies equally to on-premises and cloud-based infrastructure. Even PaaS services often provide some hardening options.

The exception is some fully-managed services where you do not have any access to the underlying host OS. But even then, understanding the provider's hardening posture is worthwhile.

What are the trade offs?

The main downside of hardening is the time required to assess systems, define a standard, and implement the changes. For large fleets, this can be a major project. Organizations have to ensure hardening does not break any required functionality.

Some hardening settings like reduced GUI interaction or disabled convenience features may be noticeable and unpopular with users. Finding the right balance is important. Hardening may also necessitate acquiring new tools for configuration management, monitoring, etc.

How to make it happen?

1. Select an applicable hardening benchmark like CIS for your OS and version
2. Review each recommendation and control against your requirements
3. Test hardening controls on a non-production system to identify any incompatibilities
4. Define hardening profiles or machine configs based on server role (web, DB, etc)
5. Integrate hardening config into provisioning process (e.g. Terraform, Ansible, Packer)
6. Implement supporting controls like FIM, anti-malware, vTPM, etc.
7. Regularly review and update hardening baselines as new versions are released
8. Monitor hosts for drift from hardening standard and remediate automatically if possible

Container hosts require special attention:

1. Use a minimalist host OS optimized for containers with other services disabled
2. Continuously scan hosts for vulnerabilities and patch aggressively
3. Disable any unnecessary system services on the host
4. Strictly limit access to container hosts based on least privilege
5. Employ file integrity monitoring and host IDS in addition to container-focused security

What are some gotchas?

• Requires deep understanding of OS specifics, easy to overlook key settings
• Some hardening guides are complex and setting dependent - test thoroughly
• Older hardening guides may conflict with modern management tooling
• Hardening a live system can be disruptive and error prone
• Hardening not properly tested can lead to system outages and emergencies
• Changing certain setting to be more secure may make management harder (e.g. SSH key auth only)
• Over-hardening can impact business functionality and productivity if not careful
• Monitoring for compliance with hardening standard can be a challenge at scale
• Make sure your configuration management tools have necessary permissions like modification on files

What are the alternatives?

Some alternatives to full OS hardening:

• Vulnerability management - patch diligently but skip other hardening steps
• Compensating security controls - rely more on detection/blocking vs hardening
• Accept risk of un-hardened systems for some use cases (may still need exceptions/waivers)

However, hardening is widely considered a bare minimum, so skipping it entirely is hard to justify. Wherever OS access is available, some degree of hardening is almost always recommended.

Explore further

• NIST 800-123 - Guide to General Server Security
• Azure Security Baseline for Linux VMs
• Related CIS Benchmark guidance:
  • CIS Microsoft Windows Server Benchmarks
  • CIS Distribution Independent Linux Benchmark
  • CIS Ubuntu Linux Benchmarks
  • CIS Red Hat Enterprise Linux Benchmarks

?