Locking Down Your Systems: 5 Steps for Hardening to Security Benchmarks

Sometimes simpler is better, and when it comes to technology, simpler can also mean more secure.

From the data center to the cloud, modern technologies perform many functions designed to make our lives easier and users more productive. However, not every functionality is necessary for every organization. 

The process of system hardening removes or disables all non-essential software functionality, configurations, and utilities, thereby reducing the number of available pathways for unauthorized access to the system. In this way, system hardening improves system security while maintaining critical system operations.

There are, of course, specific methods for performing system hardening. Our previous blog entry, Beginners Guide to Linux Hardening: Initial Configuration, details the “how-tos” concerning system hardening implementation. Beyond the process, itself, though, it is crucial to follow an appropriate set of industry standards and benchmarks for ensuring that your system hardening efforts will be effective in reducing the risks associated with known and potential vulnerabilities.

Here are five important steps for hardening your system using benchmarks:

1. Choosing the Proper Benchmark

In the world of digital security, there are many organizations that host a variety of benchmarks and industry standards. Most benchmarks are written for a specific operating system and version, while some go beyond to specialize on the specific functionality of the server (e.g., web server, domain controller, etc.). Finding the right benchmark – one that fits the specifications of your system including the OS, version, and functionality – is the first step to ensuring that the changes you make are as accurate and applicable as possible. Selecting an inappropriate benchmark to apply could lead to errors, misaligned security measures, and interference with the system’s performance.

A recommended source for current benchmarks is the Center for Internet Security (CIS), which provides benchmarks for a variety of operating systems and platforms. Vendors also frequently provide benchmarks and other system hardening guidelines. Microsoft, for instance, offers guidance for securing Windows servers.

2. Review the Benchmark

Once you select a benchmark, review the contents so that you fully understand the direction provided. At its core, a system benchmark provides recommended settings to be applied in order to secure the system, but not all settings are appropriate for all environments. For instance, the CIS benchmark for Windows 10 recommends disabling the ability to download video codecs, thereby removing a pathway through which malicious content might be acquired. However, if this feature is used routinely by the enterprise (e.g., an organization in the entertainment industry), it would not be advisable to disable this functionality.

Evaluate and review each setting to determine the impact on your environment if it was enabled. If the benchmark does not provide adequate details, conduct additional research to determine the impact of the change. While a benchmark is designed to improve security, it does so at the sacrifice of some functionality. Therefore, it should not be applied blindly.

Before applying any changes to the system, it is important to keep a record of the settings you will be implementing. In addition to being a general best practice for IT operations, well-documented changes will be simpler to review and troubleshoot if an issue materializes. Documentation also supports compliance which, in many cases, requires that certain system hardening standards be implemented.

3. Apply Changes to the Test Environment

Once you have selected the benchmark and the specific changes you want to apply, changes should be made in a test environment. The test environment is useful for exploring how the desired changes will affect the production systems, without the risk of disrupting normal business operations, and helps determine which changes will be rolled out in the production environment.

Before starting, we recommend that you produce a testing procedure that documents all the critical functions the system serves so that an administrator can assess the impact (if any) on operations as changes are applied.

In the test environment, apply each change methodically, one at a time, and test the system frequently to ensure that the system functions as desired. Whenever possible, save images of the last stable state for quick and easy reversal should something go wrong or be implemented improperly. If anything is “broken” during the hardening process, revert the change, or if that is not possible, revert to the last saved stable state (this can be as simple as reversing the change previously implemented, but can vary).

4. Check Final Stable Test Environment for Full Functionality

The last step before you move to a production-level rollout of the system hardening changes is to test the final stable test environment for full functionality with all desired use cases. This step should be extensive and exhaustive of all necessary functionalities including access, authentication, services, networking, and all related capacities required for full system performance. Once the test environment has been checked thoroughly for compatibility and performance issues, be sure to save the state of that machine as the most stable version for the rollout process and for all necessary rollbacks should changes be made or errors occur in the future. Finally, check that all implemented measures are documented clearly.

5. Phased Rollout to All Production Systems

Once all desired changes have been verified and the test environment has been tested with an exhaustive set of use cases, it is time to apply the changes to your production systems. It is best to do this in phases to minimize impact if there are, for instance, uncaught errors or compatibility issues.

During this process, monitor all system activity to check for issues with the newly added changes and to ensure that full-system functionality is achieved. If performance is hindered to unacceptable levels, rollback the changes and go back to the test environment step. Review the changes to determine why the functionality of the specific system was interrupted. Derive new implementation plans from this information and re-test the changes test environment. Continue with the phased rollout until all changes have been implemented successfully in the production environment.

Conclusion

System hardening to the right benchmark improves system security by reducing the number of unnecessary vulnerabilities in your environment.

To be sure that your system hardening is viable, extensive testing of your system hardening changes should be performed in a test environment. Testers must have a complete understanding of “normal” system functionality so that the hardening measures they implement do not disrupt system performance. They also must be vigilant in monitoring all use cases for thorough error checking. One additional crucial step is to conduct periodic reviews of your systems to ensure system hardening is maintained across the enterprise.

When implemented properly, system hardening to security benchmarks will not affect performance. Instead, improvements to the overall security of the system will be gained.

About the Authors

Ben Dimick is an information security manager at Tevora.
Brandon Richardson is an information security associate at Tevora.

Links

https://techterms.com/definition/systemhardening

https://www.tevora.combeginners-guide-linux-hardening-initial-configuration/

https://www.cisecurity.org/cis-benchmarks/

https://technet.microsoft.com/en-us/library/cc526440.aspx