#baseline configuration

Way back in June of last year I covered the process and resources I use to build hardening templates for operating systems and applications.  While that article alone would be good enough for an administrator, coming from the security side we also need to be able to easily audit and assess compliance with the template specific to our company. While there are many ways to tackle this issue from a more administrator level such as using a system configuration management system like Puppet, Chef, or CFEngine on POSIX and Microsoft System Center for the Windows world (and I guess the Microsoft Baseline Security Analyzer) the scope of this post will be limited to tools that can audit both of these, in an automated and hopefully quick method.

The first way you could do this for any operating system is via custom scripts.  With POSIX operating systems being text based, as long as your familiar with parsing text and regular expressions, you can easily get any information you'd like from a target system.  You could run this script via an SSH key trust to automate it to every system and a pre-defined time.  The Windows equivalent could be a PowerShell script or VBscript ran with Domain Admin/Local Administrator credentials.  Both of these require time to develop and maintain.

Fortunately for those of us who's jobs don't allow us to spend as much time as we'd like on developing solutions ourselves, there exist some paid products that can help us out.

The first I'll mention is a tool you probably already use, Nessus.  Included with your ProfessionalFeed subscription you can login to the Support section of the site and they have a list of a number of .audit files particular to certain auditing standards.  These include things like PCI-DSS, HIPAA, as well as hardening guides from the NSA and CIS (two of the resources you should be consulting when designing and updating your hardening templates).  The .audit file format is fairly easy to understand and you can customize it to your specific requirements pretty quickly.

The second is CIS-CAT, offered to members of the Center for Internet Security.  This tool I like a bit more than Nessus in that it does more than just provide a pass or fail grade, it includes context for the settings and usually some reasoning why they recommend it or how to figure out how you should set it.  I also like the percentage it offers, while not necessary and its unlikely you'll ever see all 100%'s even with a well customized audit, it gives you a metric to make sure you don't drop below.  This tool seems a lot more customizable, though it does require a local installation on most of the devices.

Those are the only two I've really seen that provide value in this space, if your aware of any others, specifically free ones as I'm surprised there aren't any out there, please leave a comment.

So, now that we have a method for auditing, lets talk about expectations.  In my opinion, a system should be audited after initial build before being put into production (an active participant of a network), as well as after every patch cycle for that particular machine.  If you work at a place that patches very rarely, I'd at least set a threshold of 60 days for all systems, as this could be an indicator of a breach.  Obviously how you audit is up to you, someplaces like to test everything, some like to take a random or alternating small sample.

Once you've found a metric that was passing that no longer is, it needs to be treated as an incident unless it is the outcome of an approved change via change control.  You won't be your administrators best friend anymore, but sudden changes in configuration are often your first indicator of a breach, just as well as a misconfiguration done in error that could be costly if not detected and reacted to quickly.

A good configuration should take the entire life of the machine into account.  It should start with BIOS or EFI settings, lay out the process for installation or imaging, cover base software installation, describe configuration changes to harden the OS and application, and incorporate commands or instructions to validating these changes on a recurring basis.  Ultimately you should have a document, perhaps one per operating system that describes the standard build and hardening of a machine from it arriving to it rolling into production.  Once this document is created, exceptions to this standard can be clearly documented so a configuration trail can be created by combining the build document with the exception ticket.  Make sure you include the version of the configuration document in the exception ticket so you can easily track back exactly what was done to build out the machine/device when it was originally configured.

One of the biggest challenges when creating a hardening guide is finding the best practices.  Every system administrator has their own idea of how to harden a server dictated by industries they've worked in, their IT background, and their work ethic.  The same is true with security professionals, so it is necessary to start with a neutral baseline. To assist with this gap I recommend starting with best practices from various parties.  I like to start with the NSA Operating System Guidelines, though it is worth noting they do not have material for all operating systems. Next, I add in recommendations from the Center for Internet Security (CIS) Security Benchmarkswhich cover a wider range of operating systems and applications. After that I check theNational Vulnerability Database (NVD) National Checklist Program Repository hosted by NIST as they tend to aggregate material from both of the prior sites as well as other reliable sources. Finally I search the papers on SANS Information Security Reading Room as some of the certification holders have written great papers on securing both operating systems and applications.

After creating a baseline its great to add in the tuning that you've picked up in your experience, and gives you an opportunity to meet with the system administrators and record changes they typically make.

Now comes the fun part, combine both into one document and present it to both the administrators and management to discuss the settings your recommending and their justification.  Note and objections or changes and update the document with a new version to add the changes in.

Review these at least annually as service packs and updates can create drastic changes in security.

Components of a Configuration guide: