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
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.