Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

We have many scripts that we call "secure baselines" that allow our server/desktop installation people to install operating systems using best security practice. We test that the baselines have been successfully configured by using automatic compliance checking tools.

The problem we are facing is that the Word documents quickly become out of date as the security threat changes and we are finding them a little unwieldy to maintain and manage.

Current process:

  1. server admin install servers to a secure baseline by following instructions in a Word document
  2. or write jump start scripts to auto install OS's to a secure baseline based on the Word document.
  3. Every now and then the Word document is updated when a new threat is recognised.

Is there a better way to store and maintain baselines? so that:

  • they are more easily auditable
  • easier to keep up to date acknowledging new and current threats
  • easier to record exceptions where some systems can't meet the best security principles
  • they are easily versioned.
share|improve this question
    
May I ask you what baselines need to change this often? Are you sure they were right from the first time? –  Lucas Kauffman Oct 9 '13 at 12:53
1  
You do not use any deployment tool like cfengine, puppet etc.? If not should could "take" the settings from their configuration, the configuration itself could be saved in a VC like git, cvs... –  Jiri Xichtkniha Oct 9 '13 at 12:54
    
While having baselines is admirable, requiring admins to process them as manual scripts is rather unfortunate. An admin can maliciously skip steps they don't want to do, or miss some because they received a phone call. This really needs to be automated into a provisioning and configuration management tool. That way you can master your baselines so that all systems start out exactly the same and your configuration management system handles the deviations from baseline. –  Scott Pack Oct 9 '13 at 12:56
    
If you just need to replace Word docs, just think about publican (docbook based documentation tool) with help of a VC (git, cvs...), or just use ruby-based Jekyll with help of VC (git, cvs...). Jekyll could be modified to your needs, you can "source" usual content (usual configuration data) and then define per server data and generate html documents... –  Jiri Xichtkniha Oct 9 '13 at 12:56
1  
If you start involving vulnerability intelligence feeds, you are in the field of patch management, not baselining. A baseline should state to update the machine to the newest version. A standard should explain all machines should be updated at regular intervals using the patch management method. The patch management process should not be defined within the baseline itself. –  Lucas Kauffman Oct 9 '13 at 13:18
show 2 more comments

2 Answers

up vote 2 down vote accepted

Generally a baseline is not be changed often. It generally goes a long with a standard which is a more theoretic approach and which can be technologically independent. The baseline is technologically dependent and should stipulate how to configure a new machine to make it adequately hardened with regards to security.

One step could be to make generic configurations, which are already hardened before being deployed.

If you start involving vulnerability intelligence feeds, you are in the field of patch management, not baselining. A baseline should state to update the machine to the newest version. A standard should explain all machines should be updated at regular intervals using the patch management method. The patch management process should not be defined within the baseline itself.

Normally auditing should be done in the following way:

  • after final deployment, the device is audited to see if the configuration has correct values
  • at certain intervals, machines should be selected at random and the configuration should be extracted, under the supervision of the auditor, and should be checked against the baseline. Compliance scripts can be run, but they will need to be updated at every baseline change (which should normally not be that often).

For the following steps:

  • easier to keep up to date acknowledging new and current threats
  • easier to record exceptions where some systems can't meet the best security principles

First of all note that, even when acknowledging current threats, these will not run into the hundreds a year, maybe ten at most (depending on the size of your organization's devices, if you have 10 different devices performing the same task you should review your infrastructure provisioning and design process/decision making).

To keep track of exceptions, it must be noted that exceptions should be logged into the risk assessment process. If there is a risk which needs to be accepted, a formal document should be created detailing the problem, the risk and the suggested solution. An audit/risk/business committee can then review this document and either approve or reject the solution.

Versioning will be better if:

  • you start using versioned PDFs
  • log every change to the baseline in your change management tool

Every document update will be the result of a certain incident. Either this incident was due to threat intelligence (for instance that you need to disable SSL compression) or due to operational problems. This incident will generate a response, from this response a new ticket should be generated saying the document should be updated and validated by the change committee.

If you haven't been using a risk management/change management tool, I would strongly suggest in setting one up.

share|improve this answer
add comment

As some people have recommended, use a configuration management tool like Puppet (recommended), Chef, etc. Use VCS like Git to store revisions of Puppet manifests. Using Puppet, you can define your secure baseline and simply apply it to any number of machines that you want. Add some comments to the Puppet code (Ops code) and you have your "configuration document".

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.