Linux Security / Basic: identity, resources, and evidence / Lesson 6

Build baselines and distinguish effective evidence

Compare intended and declared observations without running host audits or confusing configuration text with enforcement.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate desired configuration, loaded state, and observed behavior.
Document drift, missing evidence, exceptions, and review triggers.

Choose a baseline for a role and environment

A security baseline is a reviewed set of expectations for a particular system role and environment. A report worker, interactive workstation, and storage server need different access and recovery requirements. Do not turn one checklist into universal tuning. Record the selected distribution, kernel, package features, workload, data classification, and operational constraints. Ubuntu 24.04 LTS is a named teaching reference here, not a claim about the current host. The course never inventories this machine or reads its configuration. All baseline records are authored synthetic data for comparing intended claims and evidence states.

Keep absent evidence separate from observed drift

The first program distinguishes an observed match, an observed mismatch, and no observation. Treating unknown as compliant hides missing verification, while treating it as confirmed compromise invents a conclusion. The function compares declared fixture values only and does not collect any host setting. A real observation needs a trusted method, source, time, and environment context. Document whether a value came from a desired file, a loaded manager property, or actual behavior, because those sources answer different questions and may disagree after a change that has not taken effect.

python Classify declared baseline evidence locally

def compare(desired, observed):
    if observed is None:
        return "UNVERIFIED"
    return "MATCH" if desired == observed else "DRIFT"

assert compare("restricted", "restricted") == "MATCH"
assert compare("restricted", "broad") == "DRIFT"
assert compare("restricted", None) == "UNVERIFIED"
print("match, drift, and missing evidence remain distinct")

Expected output

match, drift, and missing evidence remain distinct

The complete program compares ordinary strings and None. It reads no file, system property, service manager, or kernel state. DRIFT means a mismatch in the fixture, not a security incident or assessment of this host.

Bind expectations to a reviewed baseline revision

A changed baseline should explain which requirement changed and why. The second record identifies the workload, reference environment, expected boundaries, and unexecuted enforcement status. It is non-runnable planning data and uses no real machine identifier. Do not rewrite the desired value merely to make a mismatch disappear. An approved exception needs a reason, accountable owner, scope, compensating controls where justified, and a review trigger. A baseline revision and an exception are different decisions; preserve both so future reviewers can understand whether the product requirement changed or a temporary deviation was accepted.

json A fictional versioned baseline record

{"baseline":"LAB-REPORT-BASELINE-1","referenceDistribution":"Ubuntu-24.04-LTS","role":"public-schedule-report-worker","expected":["scoped-inputs","scoped-outputs","no-host-administration"],"hostInventoryPerformed":false,"effectiveEnforcementVerified":false,"reviewTrigger":"workload-or-platform-change"}

The non-runnable JSON does not configure or inspect Ubuntu. Its named reference makes the design assumption visible while actual package versions, loaded policies, and runtime enforcement remain unverified.

Use measurements for specific questions

A configuration score or checklist can organize review but cannot prove a protected outcome. Some controls are environment-dependent, some interact, and some may be unavailable or inapplicable. A missing item should lead to a concrete question and owner, not an automatic broad mutation of the host. No security scan, benchmark, audit command, or administrative discovery runs in this lesson. Instead, define which approved future observation would distinguish desired text from effective behavior, and what positive and denied cases would show whether the requirement is actually enforced.

Communicate baseline status without overclaiming

A useful report names baseline revision, workload, evidence source, actual observation, deviation, unresolved boundary, and next action. Preserve unverified state when no observation exists. If a policy changed but a service was not reloaded in the actual approved environment, do not claim the new text is effective; that operational question requires its own authorization and evidence. The local examples support record interpretation only. They make no host compliance, hardening, security, or recovery guarantee. Clear state distinctions let a reviewer prioritize meaningful checks and changes without mistaking a spreadsheet for a protected Linux system.

Common errors and fixes

Missing evidence becomes compliant

Why it happens: An empty observation is interpreted as success.
How to fix it: Retain UNVERIFIED and assign the needed observation.
Prevent it next time: Require source and method for compliance claims.

Desired text is called effective state

Why it happens: Configuration and runtime evidence are conflated.
How to fix it: Record intended, loaded, and observed states separately.
Prevent it next time: Verify actual behavior only in an authorized environment.

The baseline changes to match every failure

Why it happens: The requirement is silently weakened.
How to fix it: Review requirement changes and exceptions explicitly.
Prevent it next time: Keep revision rationale and accountable ownership.

Check your understanding

1. No effective policy observation exists, but the desired file is reviewed. What status is accurate?

Show worked solution

The intended configuration has review evidence, while effective enforcement remains unverified. Identify the approved observation needed to test it. Do not run host audits or reload services in this exercise, and do not convert the absence into either compliance or a confirmed incident.

2. A report worker gains a new export destination. Should the old baseline be reused unchanged?