A Baseline Makes Configuration Drift Visible

You cannot detect configuration drift if nobody knows what the expected configuration is.

A baseline is a documented reference state used for comparison.

It is not automatically perfect. It is a known state with an owner and reason.

Baseline the things that affect behavior

For a fictional Linux-like web host, a useful baseline might include:

• operating-system/version family;
• approved services;
• listening sockets;
• required user/service identities;
• important configuration file hashes or versions;
• update state;
• expected firewall/policy relationships;
• log destinations;
• backup agent state; and
• time synchronization state.

You do not need to collect every possible fact. Collect the facts needed to verify the intended architecture.

Expected services should tie to required function

Example baseline:

The last row is a hardening opportunity because it has no stated requirement.

Drift is a difference, not automatically an incident

Suppose baseline says:

status-web bind=127.0.0.1:8080

Current state says:

status-web bind=0.0.0.0:8080

That is configuration drift relative to the baseline.

Possible causes include:

• approved change that was not documented;
• manual mistake;
• automated deployment difference;
• software update;
• recovery from backup;
• unauthorized change.

The difference is evidence. The cause requires more evidence.

Hashes can support configuration comparison

Week 3 taught you that SHA-256 can show byte-level equality or difference.

That idea returns here.

If a known baseline configuration file has digest:

A1...

and the current file has:

B7...

then the bytes differ.

That does not tell you whether the change is good, bad, approved, or malicious.

Correlate with change records and content.

Ownership matters

A baseline needs an owner who can answer:

• who approves changes;
• which requirements justify each setting;
• when the reference was updated;
• which evidence validates it; and
• how exceptions are documented.

Otherwise “baseline” becomes an old file everyone ignores.

Activity: build a fictional host baseline

Create a baseline table with at least ten items across:

• services;
• sockets;
• identities;
• configuration;
• logging;
• update state;
• backup/recovery; and
• network policy.

For each item, include:

expected state
reason/requirement
owner
evidence source
acceptable exception process

Supplied drift set

Compare:

1. legacy-test-server: baseline disabled; current enabled
2. status-web bind: baseline 127.0.0.1; current 0.0.0.0
3. log-forwarder: baseline running; current stopped
4. backup-agent version: baseline 4.2; current 4.3 with approved change record CHG-118
5. admin role: baseline coach only; current coach + temp-helper with expired approval

Classify each as:

• expected/approved change;
• unexplained drift requiring review; or
• clearly inconsistent with the stated baseline/approval evidence.

Do not call unexplained drift an attack.

Baselines should evolve intentionally

After an approved change is validated, the baseline may need updating.

Otherwise the monitoring system will keep reporting a difference that is now expected.

Sequence:

PROPOSE CHANGE
   ↓
APPROVE
   ↓
IMPLEMENT
   ↓
VERIFY
   ↓
UPDATE BASELINE

Do not update the baseline before verification merely to make the alert disappear.

Begin your Hardening Change Dossier

Include:

1. fictional host purpose;
2. ten baseline items;
3. requirement for each;
4. five drift classifications;
5. evidence used to classify them; and
6. one baseline item that should change only after a successful retest.

Lesson 2 chooses one unnecessary function and reduces it safely.