Commercial and open-source system configurations such as Windows, Linux and Oracle do not always have all the necessary security measures in place to be deployed immediately into production. These configurations often have features and functionalities enabled by default, which can make them less secure, especially given the sophistication and resourcefulness of today’s cybercriminals.
A system hardening program can help address this issue by disabling or removing unnecessary features and functionalities. This enables security teams to proactively minimize vulnerabilities, enhance system maintenance, support compliance and, ultimately, reduce the system’s overall attack surface.
Unfortunately, many companies lack a formal system hardening program because they have neither an accurate IT asset inventory nor the resources to holistically maintain or even begin a program. An ideal system hardening program can successfully track, inventory and manage the various platforms and assets deployed within an IT environment throughout their life cycles. Without this information, it is nearly impossible to fully secure configurations and verify that they are hardened.
Planning and Implementing Your System Hardening Program
System hardening is more than just creating configuration standards; it also involves identifying and tracking assets in an environment, establishing a robust configuration management methodology, and configuring and maintaining system parameters to expected values. To manage and promote system hardening throughout your organization, start by initiating an enterprisewide program plan. Most companies are engaged in various stages of a plan, but suffer from inconsistent approaches and execution.
A plan builds on the premise that hardening standards will address the most common platforms, such as Windows, Linux and Oracle, and IT asset classes, such as servers, databases, network devices and workstations. These standards will generally address approximately 80 percent of the platforms and IT asset classes deployed in an environment; the remaining 20 percent may be unique and require additional research or effort to validate the most appropriate hardening standard and implementation approach. By adopting the 80/20 rule, hardening will become more consistent, provide better coverage and increase the likelihood of continued success.
Let’s take a closer look at the components of a system hardening program plan and outline the steps you can take to get started on your hardening journey, gain companywide support of your strategy and see the plan through to completion.
1. Confirm Platforms and IT Asset Classes
First thing’s first: Determine the types of platforms and IT asset classes deployed within your environment. For example, list and document the types of server versions, such as Windows 2016, Windows 2012 R2, Red Hat Enterprise Linux or Ubuntu, and the types of desktop versions, such as Windows 7 and Apple iOS. Then, list the types of database versions, such as MySQL, Oracle 12c and MongoDB. The IT asset inventory should be able to report on the data needed to create the platform and IT asset class list. However, some companies struggle to maintain an IT asset inventory that accurately accounts for, locates and tracks the IT assets in their environment.
If there isn’t an up-to-date IT asset inventory to report from, review network vulnerability scan reports to create a list of platforms and asset classes. The scan reports will help verify and validate existing platforms and IT asset classes in your environment, as well as devices that may be unique to your company or industry. Interviewing IT tower leads can also support this information-gathering exercise, as can general institutional knowledge about what is deployed.
2. Determine the Scope of Your Project
Once you’ve documented the platforms and IT asset classes, you can determine the full scope of the system hardening program. From a security perspective, all identified platforms and IT asset classes should be in scope, but if any platform or IT asset class is excluded, document a formalized rationale or justification for the exception.
Any platform or IT asset class not included in the hardening scope will likely increase the level of risk within the environment unless compensating controls or countermeasures are implemented.
3. Establish Configuration Standards
Next, develop new hardening builds or confirm existing builds for all in-scope platforms and IT asset classes. Create this documentation initially from industry-recognized, authoritative sources. The Center for Internet Security (CIS), for example, publishes hardening guides for configuring more than 140 systems, and the Security Technical Implementation Guides (STIGs) — the configuration standards for U.S. Department of Defense systems — can be universally applied. Both of these sources are free to the public. It is generally best to apply one set of hardening standards from an industry-recognized authority across all applicable platforms and IT asset classes whenever possible.
This is the step in the plan where you’ll reference the in-scope listing of all platforms and IT asset classes. For each line item on the list, there should be a corresponding hardening standard document. Start with the industry-recognized source hardening standards and customize them as necessary with the requisite stakeholders.
As an example, let’s say the Microsoft Windows Server 2008 platform needs a hardening standard and you’ve decided to leverage the CIS guides. First, download the Microsoft Windows Server 2008 guide from the CIS website. After orienting the Windows Server team to the overall program plan objectives, send the hardening guide for review in advance of scheduled meetings. Then, walk through the hardening guide with the Windows Server team to determine whether the configuration settings are appropriate.
During these discussions, the team should be able to verify which configuration settings are currently in place, what is not in place, and what may violate company policy for pre- and postproduction server images. If there are hardening guide configuration settings that are not already in place, conduct formal testing to ensure that these changes will not degrade performance, lead to outages or cause other problems within the production environment.
Let’s take the configuration setting “Cryptographic Services to Automatic,” a Microsoft Windows Server 2008 hardening standard from the CIS guide, for example. If this configuration setting is not already in place, can it be implemented? If it cannot be implemented, document the reason why it causes problems as determined through testing, whether it violates company policy or anything else that’s applicable. Note this particular configuration setting as an exception in the overall hardening standard documentation for future reference.
4. Implement Your System Hardening Standards
After you’ve established the hardening build and maintenance documentation and conducted any necessary configuration testing, implement the hardening standards accordingly. The preproduction “golden,” or base, images should be hardened initially to proactively disable or remove unnecessary features prior to deploying in production. Starting with the preproduction images should be less time- and labor-intensive because only one image per platform typically needs to be hardened, removing the need for a change management process or scheduled downtime.
Once a particular platform image is hardened, that image can be used to re-image the postproduction platforms already deployed in the environment. The hardened configuration changes can be deployed with configuration management tools, depending on the platform. For example, the Windows team can implement a vast array of configuration settings throughout the environment it manages with Group Policy. If you cannot make automated hardening changes globally for some or all platforms, you’ll need to physically visit these systems individually and manually apply the configuration changes.
5. Monitor and Maintain Your Program
An effective system hardening program requires the support of all IT and security teams throughout the company. The success of such a program has as much to do with people and processes as it does with technology. Since system hardening is inherently interdisciplinary and interdepartmental, a variety of skill sets are needed to carry it out. Hardening is a team effort that requires extensive coordination.
It’s important to appoint a hardening lead to ensure accountability and responsibility for the management and oversight of the program. This individual should possess the drive to achieve results, a knack for problem-solving, and the ability to direct others in collaboration and teamwork. The system hardening lead is ultimately responsible for the success of the program and should provide the focus, support and momentum necessary to achieve its objectives.
Still, accountability for hardening-related activities should be formally assigned to the teams best suited to ensure their completion and maintenance. The information security team should help facilitate improvements when gaps are identified and serve in a governance role by monitoring the hardening practices of all teams, challenging poor processes and approaches, and verifying compliance against hardening standards. If configuration management tools are not available, verify compliance using vulnerability scans.
All this complexity demands a great deal of synchronization. The roles and responsibilities must be clearly delineated so teams can focus their efforts on activities that truly advance the hardening program plan.
System Hardening Has Never Been So Crucial
Implementing and managing an effective system hardening program requires leadership, security knowledge and execution. Obtaining executive commitment, management support and sufficient investment for the program is also crucial. If you carefully choose a combination of easy-to-implement platforms and IT asset classes and more challenging, longer-term hardening efforts, you’ll see incremental improvements in program execution and support.
Companies everywhere and across industries face an ever-accelerating rate of change in both the threat and technology landscapes, making system hardening more crucial than ever. A hardening program isn’t built in a day, but an effective, thoughtfully constructed plan can significantly lower your company’s risk posture.
Cloud Security and Compliance Leader, IBM Cloud