The Basics
Security Configuration Hardening is the practice of changing configurable settings for various applications and platforms in such a way as to improve security configuration. Products such as Windows and Linux do this to some extent but generally have features and settings enabled for compatibility reasons that are risky to have if they are not needed.
You or your organization may also have certain policies and restrictions which you would like to be enforced with technology such as password policies or account lockout policies. You or your legal team may have a login banner they want to display to set a boundary to deter potentially unauthorized users from committing cyber-crime, or to remind users their activity is being monitored. You may also want to just generally configure your systems in such a way as to make things harder for an attacker, by configuring some settings you may have never considered before.
This topic can get into the weeds very fast. How do you know what settings to configure? How do you maintain all of the configurations you need or want? How do you implement everything to begin with?
Configuration baselines
As you accumulate configuration settings, you’re going to want to establish configuration baselines if you haven’t already. Your baselines will be the set of controls you or your organization decide to implement across all devices by default. Depending on your risk appetite, you will very likely have deviations to baselines for different use cases. You could standardize these use cases by branching out and creating additional baselines, you could accommodate the majority of use cases in a single baseline by removing certain high impact settings, or you could live with the risk that not all systems will have all settings implemented.
As a part of this, you will also want to make sure you have processes to create new baselines for brand new platforms and update baselines as new versions of the platform come out and add new features. You will also want to work closely with your developers to give them an opportunity to test. If you have a strong DevOps model or are just starting out with fresh infrastructure this will be easier, if not you may want to look for support from the top-down (i.e. officer level employees) to ensure the developers are engaged and prioritize accordingly. This is an oversimplification, and quite a complicated topic, since without unanimous support and proper management your baseline program may fall flat on its face.
Now that you have established configuration baselines, and either a plan for configuration management or have already started implementation, what comes next?
Technical Implementation Guides
Technical implementation guides (either DISA-STIGs or CIS Benchmarks) are comprehensive lists of configuration settings with how-to steps for each.
STIGS
The department of defense publishes Security Technical Implementation Guides (STIGs). These cover a wide array of platforms and are fairly thorough. Although they have a negative reputation for locking things down too much for non-military applications, you can incorporate these recommendations into your configuration baseline with a bit of work if you test and iterate.
You can find the official STIGs Document Library here: https://public.cyber.mil/stigs/downloads/
This includes automation content for certain platforms and tools: https://public.cyber.mil/stigs/supplemental-automation-content/
There are also GPO files available:
https://public.cyber.mil/stigs/gpo/
Unified Compliance Framework (UCF) also has a useful tool called stigviewer which can be used to browse through the various STIGs and download them in machine data formats: https://www.stigviewer.com/stigs
CIS
Center for Information Security (CIS) publishes the CIS Benchmarks which are community driven hardening guidelines which find a nice balance between security and usability. With CIS SecureSuite membership, you can also access build kits for certain platforms, which are generally GPO based for Windows, and shell script based for Linux. https://www.cisecurity.org/
Vendor best practices and resources
The companies who created the platform you’re trying to secure may in some cases provide their best practices for security configuration. These best practices can be a great way to start implementing certain hardening controls in the environment. Since they are recommended by the vendor for whatever product you are using, it is hard for anyone to refute the effectiveness or applicability. In many cases, these may be the path of least resistance to getting security up and running. Many vendors also have native tooling for their platform which can help implement their best practices (or help with compliance to the DISA-STIGs or CIS Benchmarks).
Here are a few common ones as examples:
- Microsoft:
- Microsoft provides a set of recommendations and practices as a guide to securing Active Directory: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/best-practices-for-securing-active-directory
- Microsoft provides a Security Compliance Toolkit to help implement their best practices on supported versions of Windows Server and Desktop: https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10
- Microsoft provide a security best practice guide for SQL Server: https://learn.microsoft.com/en-us/sql/relational-databases/security/sql-server-security-best-practices?view=sql-server-ver16
- Linux:
- Ubuntu has a native hardening and auditing tool similar to OSCAP called The Ubuntu Security Guide (USG) which leverages configuration settings mapped to the CIS benchmarks and DISA-STIGs: https://ubuntu.com/security/certifications/docs/usg
- VMware:
- VMware publishes a Security Configuration Guide for vSphere with a number of technical configuration steps to enhance security from the out of the box settings. https://core.vmware.com/security-configuration-guide
- MongoDB:
- MongoDB provide a security checklist designed for pre-deployment: https://www.mongodb.com/docs/manual/administration/security-checklist/
- Apache HTTP Server:
- Apache provides a list of “Security tips” specific to the HTTP Server platform: https://httpd.apache.org/docs/2.4/misc/security_tips.html
- NGINX:
- NGINX provides a list of security controls and recommendations in the admin guide: https://docs.nginx.com/nginx/admin-guide/security-controls/
Auditing
So, you’ve got your baselines and they’re running fine now. How do you make sure they stay that way? Here are a few options:
- Vulnerability management platforms will generally have some kind of auditing or compliance features to check security configurations of different platforms.
- CIS publishes a configuration assessment tool (licensed to SecureSuite members) which can scan a number of different platforms for compliance against the CIS Benchmarks.
- Depending on the platform, your vendor might have native tooling to enable configuration auditing against either the vendor’s best practices, CIS, or STIG.
- There are a number of third party tools (open source and free) that can do this too, though most are platform specific.
Automation or Other resources
Infrastructure as code tools such as Ansible, CFEngine, Chef, Puppet, SaltStack, and others can be a great way to implement and maintain your configuration baselines in a way that scales easily. As the term (“infrastructure as code”) suggests, you write code to define how the infrastructure should be configured, and the infrastructure follows.
OpenSCAP and the ComplianceAsCode projects are great to use on certain platforms such as Windows and Linux to actually implement some of these settings. OpenSCAP is native to RedHat Linux and supported in their documentation since RedHat originated the project https://www.open-scap.org/ OpenSCAP can also generate Ansible playbooks from xccdf content, which are published on Ansible Galaxy.
There are many many other resources not mentioned here depending on the platforms you are running. I just mentioned some of the commonly used ones.
There are also a number of paid third party tools out there to help manage, implement, and audit configuration baselines, including consulting services. Most of the major Infrastructure as Code projects I mentioned above also have enterprise versions. These all generally cost money but may be cheaper and more effective if your team lacks experience.