If you are in the IT space, you’ve most likely encountered or are bound by some form of regulation/framework such as PCI, HIPAA, FISMA, and/or CGIS. Most of these compliance programs require a hardened baseline to be implemented within your information systems to reduce the risk and impact of an adverse security event. In this post, we’ll take a brief look at building a hardened baseline, examine some tools to assist in a phased approach to deployment, and discuss some common issues that may arise from deploying a system hardening regime.
Building a Hardened Baseline
The first step to building a baseline is to identify the equipment, operating systems, and applications to be hardened. After we’ve identified everything with a baseline requirement, we can move on to choosing a standard. There are multiple standards in existence that we can choose from such as DISA’s Security Technical Implementation Guide (STIGs), Center for Internet Security (CIS) Level 1 or 2, and Microsoft’s Security Compliance Manager (SCM). If a standard doesn’t exist for the devices needed to be hardened, vendor best practices can be utilized. Choosing the proper standard as a starting point depends heavily on your environment and requirements.
Since the standard chosen is used as a starting point, it’s time to review each setting and determine how it will impact the environment. If a setting will adversely impact the environment, it should be documented with a thorough deviation justification. Changes to the system should be ranked by impact severity, allowing the use of a phased rollout approach.
Deploying a baseline manually can be an insurmountable task given the size and complexity of most information systems in existence today. Luckily there are a few tools to help automate deployment.
Microsoft Active Directory Group Policy Objects (GPOs)
- Works with Microsoft Operating Systems and Software
- Generally simple to set up and configure
- Already in place with standard Active Directory deployments
- Microsoft Security Compliance Manager aids in baseline creation
- Agentless, uses SSH to push settings
- Quick deployment
- Learning curve – Ansible uses its own Domain Specific Language (DSL)
- Linux native, but can be used to configure some Windows settings
- Client/Server Deployment with Agents
- Flexible and will manage diverse assets
- Learning Curve – Uses Ruby/DSL
- Client/Server Deployment with Agents
- Cross Platform support for Linux and Windows
- Targeted toward STIG compliance but can do other benchmarks
- Agentless, quick spin up
- Remediation rollback and integration with Plan of Action and Milestones (POA&Ms )
- Used mainly in virtual environments (VMWare, AWS, Azure)
- Can be more time intensive to maintain depending on the number of gold images
- Methods exist for baselining both Linux and Windows platforms
Choosing the best tool for the job depends on the type of environment and assets it will need to support. Additionally, leveraging in-house knowledge of a specific tool can speed up implementation and decrease the learning curve. Once a tool is chosen, the baseline configuration settings will need to be scripted or programmed in the native language of the tool for deployment. Initial baseline deployment should be attempted in a test environment, followed by a phased rollout to production. Most tools referenced above will make use of tagging. That’s where the impact analysis performed earlier in this process comes in handy. Using those tags, the baseline can be rolled out with low-impact items first followed by moderate- and high-impact – ensuring the system is still functioning properly each step of the way.
Automate the Automation
Configure the tools to automatically detect the presence of a new asset and to deploy the proper baseline. Automatic deployments are specifically important in elastic environments such as AWS. Enforcing and auditing to ensure the baseline has been applied correctly can be performed by the tool itself or a compliance scanning tool such as Nessus or SCC.
What might go wrong with deploying a hardened baseline, and how do we navigate the issues?
It’s sometimes possible to see necessary ports or required encryption protocols blocked by the configuration and application communication fails. We’ve seen remote access and account restrictions break service accounts, additional audit log requirements fill disks, least privilege block people from a needed function, and more elaborate password requirements frustrate/confuse users who begin writing their password down among many other things.
The dedicated engineering team at Coalfire can help your organization navigate these issues and meet your goals of successfully deploying a hardened information system baseline.