Want the safest vehicle you can buy? Volvo? Hummer? A Challenger Tank is fitted with composite ceramic and tungsten-alloy armor and can withstand a direct missile strike. It’s noisy and slow, and maneuvering in tight spaces is difficult although this may not be much of an issue: You can literally park it anywhere you want.
Safety for IT systems is similar in that you may set maximum security as the objective but there will always be compromises in favor of optimizing service delivery. The two key principles of system hardening are to remove unnecessary function and apply secure configuration settings. Unlike most security frameworks, the Center for Internet Security (CIS) provide prescriptive guidance for configuration settings and, in the CIS Benchmark guides, even provide the required remediation commands.
However, even with such comprehensive knowledge of vulnerable settings and how to remediate them, there are still issues to resolve:
- Which settings are suitable for your environment to balance function with security?
- How do you deploy a hardened build policy to your infrastructure?
- How can a hardened configuration be maintained 24/7/365 when there is always change in an IT environment?
In terms of security settings, a CIS Benchmark will give you a Challenger Tank: by adopting all configuration guidance provided, your defenses will be maximized although you may be unable to deliver required services.
Welding up the doors on your car makes it less easy to steal, but you will need the bus to get to work. For example, one recommendation is to rename and disable the local administrator account, so it’s crucial that the server is enrolled to a domain first. Fortunately, for any sensitive settings like these, the CIS Benchmark gives you a warning of the impact, but it still gives you some decisions to make when looking to maximize security.
The Challenger is also much less effective in say, jungle conditions. Similarly, the CIS Benchmark is provided in the context of a base platform-build. In other words, the recommendations are ‘one-size fits all’ based on a basic starting point. Your usage, applications, and environment are going to be unique and therefore the appropriate hardening measures can only be determined by you. Worth mentioning that, if you want to take hardening further, NNT provide supplementary guidance on both open port hardening and secure services profiles for all platforms.
To deploy your hardened build standard, the Windows world gives us Group Policy as a solution. This automatically hardens the local security policy from a central Domain Controller. Group Policy also goes some way to addressing another major issue, which is to maintain this hardened configuration by regularly refreshing settings.
Unfortunately, this isn’t the end of the story. If you have misconfigured settings that require a reboot to be set, Group Policy may actually serve to mask vulnerable gaps in your hardened policy, leaving you more prone to attack than assumed.
In the Linux world, numerous options exist for pushing configuration settings, but they equally suffer from the same issues as Group Policy.
Beyond configuration settings, a hardened build standard naturally needs to be extended to a software image in terms of installed packages and approved versions, a further key source of vulnerabilities.
The Group Policy strategy, whereby the build is repeatedly reset is even less effective for maintaining a software image. You wouldn’t want to unnecessarily re-install/re-image servers, but the only way to ensure that there have been no changes or even worse, breach activity, is to periodically reset everything, complete with all the associated downtime and hassle. While this is secure, it is unworkable in practice for mission-critical platforms, although a virtual desktop infrastructure can prove viable.
Instead, it is far better to monitor for any configuration ‘drift’, then correct this as required. System integrity monitoring, aka FIM, is still the best option for managing drift. It can be used to baseline and track changes, from software installations through registry settings right down to detecting minute file changes, to both system and configuration files.
No changes detected? No need to re-image or re-configure the server, and no need for any unnecessary reboot or downtime. When there is drift, this can be remediated with laser precision, exactly where needed with no more disruption than is essential.
Implementing a hardened build standard is a critical security control. It will require refinement of CIS guidance for your environment, then enforced with continuous integrity monitoring. System hardening is a process, not a one-off task, just as staying safe on the roads doesn’t mean driving a tank.