When the topic of infosec is discussed broadly, not at the level that infosec or cybersecurity professionals discuss it, but instead in the boardroom or at conference room tables the same question is brought up (without fail). What can "we" do to be more secure?
Invariably, vendor names & buzzwords are deployed like commandos in a 1980's Chuck Norris film. After that barrage, the next logical step is to discuss trusted third parties that can be brought in like mercenaries to "whip us into shape". This comes at a steep price however and I don't just mean monetarily. Often the organizations hiring these 'mercenaries' (no offense to the mercs reading this) have an advocate internally that has suggested meaningful changes for some time, but because they themselves are not viewed as a "consultant" their opinion may be invalidated.
This person brings common sense ideas that are tailored to your organization, but they are not well received. You may know this person. You may BE this person! You say things like "we need a CMDB!" or "I need your buy in to establish a routine audit of our Active Directory".
You may have even suggested establishing a Golden Image for the OS's that you deploy; Windows Server, RHEL, Debian, Windows Desktop, etc... if you know this person or this person IS YOU than these words, on this page are for you!
First, let’s get a few house keeping things out of the way. I want to level set and define some of these words so we can move forward quickly. Below are a few definitions. I will explore their relationships in the following sections....
Baseline: You will find a few variations on this keyword, but the one thing to remember is this is a snapshot in time of a systems current configuration (OS level settings, installed apps, app configurations, users, etc...). For example, if you were to baseline a web server you might say the baseline contains the following parameters:1) OS: RedHat 82) Applications: Apache; MySQL, Java3) Users: Root, Alice, Tom4) OS Settings: Disallow Root remote login
Those parameters, and most likely many other parameters like that, would create a baseline for a system. It’s nothing more (or less) than how a system is configured at a moment in time. This baseline can be used to "look back" and see what has changed.
Benchmark: A benchmark is an individual check that is performed. What is a check? Its literally checking a system setting, such as is an application installed. Is that application at XYZ patch level? Is it installed in a specific directory? All those questions are essentially a "check" and each one compromises a benchmark. The "benchmark" is a specific configuration or system setting that your organization (or industry) has determined to be a best practice. Benchmarks are a way of evaluating whether a system is adhering to known good configurations (which in turn should reduce the attack surface of that system).
What do you call it when you group together a bunch of benchmarks, harden a system and configure it just the way you need it...? Golden Image: A Golden Image is typically an entire server (or desktop) system that has all the applications needed for its purpose installed, all the system level settings configured, and all the unique changes needed to integrate it into your environment. Then you baseline this system (capture its configuration in a moment-in-time snapshot) and this baseline is now your "Golden Image". Think of this golden image as your 'gold standard', this is exactly how you would want every server deployed moving forward. It has been hardened, it is proven to be functional, and it can be managed.
1) Baseline So how do we use these new (shiny) terms to harden and secure our environment? First things first, we need a way to capture the existing baseline of all deployed systems. This can be done manually if you’re in a smaller environment, since most servers will be close to their "out of the box" configuration if they are newer and similar. Creating a spreadsheet with hostnames on the left and then a separate doc with even a handful of things to check (your benchmarks) is a great way to get started.
Remember, security is not an all-or-nothing exercise. You should think of it more along the lines of, "Am I better this week than I was last week?". Ideally you would have an automated method to perform this query and capture all the data you need, but if you don't, there are a few ways to automate this task (ala PowerShell or Bash). I won't cover those methods here though, as they fall outside the scope of this (introductory) post....
2) Benchmark Once you have a baseline captured, it’s time to look at the configuration using the benchmarks either your organization has defined or benchmarks like the ones available from the Center for Internet Security (CIS):The CIS Benchmarks main directory: HTTPs The CIS Benchmarks Windows Server:https://www.cisecurity.org/benchmark/microsoft_windows_server/
This is a crucial step. All the steps are vital, but this one is the most important. Using these benchmarks is where you discover system and configuration vulnerabilities that could lead to security incidents.
3) Golden ImageNow that you have gathered the system configurations (Baseline) and performed the configuration checks (Benchmark) you should be ready to create a Golden Image. This image is the product of this process, this will be what is deployed into the environment and known to be secure. Practically speaking, its great if you can use your Golden Image as the base for all future servers (literally cloning it using your hypervisor). I would make this your #1 choice if it is at all possible. If this is not practical, then you will need to create a process and document every step completely and build in an audit step to ensure all future systems getting deployed adheres to your Golden Image.
I thought it would be useful to see an example of how this can work in a small (to midsize) environment, which is typically where you see the most need for this type of configuration management.
1. Gather System Baselines let’s say this needs to be done manually, the first thing we want to do is prioritize the systems that we audit. What is the most critical system? Is it your AD Domain Controllers (DC)? Is it a line of business app server? Whatever it is, it goes first, then you pick a #2, #3, #4, etc... we want to pour our energy into where the most value can be found first!
For the purpose of this walkthrough let’s say we are starting with an AD DC, or your identity management server in a typical Windows environment. For brevity, I’ll say we only want to check the following 3
parameters (benchmarks):(I am pulling these from the CIS Windows Server 2012R2 Benchmarks)
1. CIS - Microsoft Windows Server 2012 R2 - 18.104.22.168: Ensure 'Audit: Shut down system immediately if unable to log security audits' is set to 'Disabled' https://workbench.cisecurity.org/benchmarks/288 r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa -> CrashOnAuditFail -> 1; r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa -> CrashOnAuditFail -> 2;
2. CIS - Microsoft Windows Server 2012 R2 - 22.214.171.124: Ensure 'Domain controller: LDAP server signing requirements' is set to 'Require signing' [https://workbench.cisecurity.org/benchmarks/288] r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters -> LDAPServerIntegrity -> !2;
3. CIS - Microsoft Windows Server 2012 R2 - 126.96.36.199: Ensure 'Domain member: Digitally encrypt secure channel data (when possible)' is set to 'Enabled'https://workbench.cisecurity.org/benchmarks/288 r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters -> SealSecureChannel -> 0;
So, we are clear, the actual contents of these benchmarks are pointless for this walkthrough, I just need something to refer too ;)
If I am doing this manually, I would either connect via remote registry, PowerShell (or RDP if no other option) and verify these registry keys exist. At this stage, all we are doing is 'looking' but not 'touching'. This is the baseline stage, no need to make changes yet. We will compare this systems configuration to the benchmarks in the next step.
2. Identifying system weakness via Benchmarks Once we have connected to our most important servers, gathered the information related to the (3) CIS Benchmarks above we can now compare the system baseline to the benchmarks provided by the CIS!
It is during this stage that misconfigurations or sub-par configurations will be identified, and changes will need to be implemented. Remember, good changes are thought out (tested!) and a complete back out strategy is known prior to beginning the change.
To keep track of the compliance (or non-compliance) to the benchmarks, you can use a simple spread sheet with the hostnames on the left side (as rows) and the Benchmark names on top (as columns). Mark compliance or non-compliance how you like, just make sure it makes sense to you in a month when you come back to this (because you will get sidetracked, re-tasked and have time away from this effort!).
3. Establish a Golden Image Once the high priority systems, those that are most critical, have had an initial baseline and hardening completed now would be a good time to go and create a golden image for all future server deployments. Typically, this looks like creating a new VM (lets continue to use Windows Server); then using the CIS Benchmarks to go through and modify the system to adhere to these Benchmarks. Once the benchmarks have been implemented a complete test of the system for its intended purpose is required. This is not a small-scale test, but instead full QA for all its intended purpose!
Deploying secure servers is easily the #1 "low hanging" fruit for most (SMB) organizations, this effort should have appropriate levels of buy in to ensure completion.
Again, this process would ideally be mostly (or completely) automated requiring only small amounts of human interaction. I don't have any platforms in mind to recommend, but systems that gather configuration and application settings and centralize that data to streamline this process would be my first choice!