Linux Security / Advanced: constrained design and verified change / Lesson 16

Make bounded Linux incident-response decisions

Separate a symptom, a supported compromise finding, containment, correction, and recovery evidence.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Preserve useful facts and uncertainty without running live response actions.
Choose accountable next questions rather than automatic destructive cleanup.

Describe the observation before naming a cause

A report worker unexpectedly requests host administration or returns a permission error. That is a symptom requiring context, not automatic proof of compromise. A deployment change, stale policy, programming defect, or malicious action can produce overlapping signals. Preserve source, time, workload, exact nonsecret outcome, and the relevant expected boundary. Do not delete files, terminate processes, revoke accounts, change firewall rules, restart services, or scan a host as a classroom diagnostic step. This course performs none of those actions and handles only invented records with no actual incident material.

Keep missing evidence distinct from confirmed failure

The first program routes fictional reviewed facts into investigate, confirmed-boundary-failure, or no-failure-in-reviewed-case. It does not decide a real incident or identify an attacker. A negative conclusion applies only to the reviewed case and cannot establish the entire host is clean. Preserve the evidence and missing observations that justify the status. NIST incident-response guidance supplies a reference for accountable preparation, detection, response, and recovery; operational choices must fit the organization and actual authority. A local decision table is a teaching tool rather than permission to perform containment.

python Route declared synthetic incident facts

def route(reviewed, boundary_failed):
    if reviewed is not True or boundary_failed is None:
        return "INVESTIGATE"
    return "CONFIRMED_BOUNDARY_FAILURE" if boundary_failed else "NO_FAILURE_IN_REVIEWED_CASE"

assert route(False, None) == "INVESTIGATE"
assert route(True, True) == "CONFIRMED_BOUNDARY_FAILURE"
assert route(True, False) == "NO_FAILURE_IN_REVIEWED_CASE"
print("three evidence-based triage categories distinguished")

Expected output

three evidence-based triage categories distinguished

The complete program checks three local status decisions. It collects no logs or host facts and establishes no compromise, attribution, or clean bill of health. The category names are classroom markers.

Separate containment from root-cause correction

A temporary restriction may reduce exposure while leaving the underlying defect unresolved. A source correction may not yet be installed or effective. The non-runnable response record keeps those states separate and assigns roles rather than real people. It does not issue commands or send messages. A real response plan needs accountable authority, protected evidence, privacy limits, service impact, and recovery requirements. Avoid claiming remediation because a process stopped or a file disappeared. Broad cleanup can remove useful evidence or damage unrelated work if the scope and cause are not understood.

json A fictional response record preserving unfinished stages

{"case":"LAB-RESPONSE-2","symptom":"unexpected-authority-request","containment":"not-executed","rootCause":"unresolved","sourceCorrection":"not-prepared","effectiveRemediation":"unverified","ownerRole":"response-reviewer","nextQuestion":"which-reviewed-boundary-failed","liveActionPerformed":false}

The JSON is planning data only and names no real person, host, or account. It performs no containment or correction. The unverified statuses prevent the record from being treated as a completed response.

Restore protected behavior rather than only availability

A running service can still retain excessive authority, a compromised dependency, or an unintended disclosure path. Recovery should verify the required legitimate workflow and the boundaries that failed, with a compatible corrected artifact and reviewed credentials/policies. An older backup may reintroduce the weakness. Keep actual restore, revocation, deployment, and host operations inside the approved organizational process; they are not performed here. Learn from the cause and review equivalent paths so the same assumption does not remain elsewhere. Preserve a synthetic regression rather than copying private incident content into tests.

Use status language that matches actual evidence

Report observed symptom, supported findings, confidence basis, containment state, correction state, verified artifact, recovery observations, and remaining questions distinctly. A planned or local result must not be presented as a deployed fix. No real Linux system is investigated or altered in this course. The examples establish routing and record semantics only. Clear status lets the accountable owner decide the next authorized action without an unsupported claim of compromise, successful containment, total safety, or completed remediation based on a handful of synthetic booleans.

Common errors and fixes

A permission error proves compromise

Why it happens: A symptom is assigned a cause without corroboration.
How to fix it: Preserve alternatives and identify the failed boundary.
Prevent it next time: Separate observations from supported incident findings.

Stopping work is called remediation

Why it happens: Containment and root-cause correction are conflated.
How to fix it: Track the stages and actual verification separately.
Prevent it next time: Require evidence for effective correction and recovery.

A passing local case proves the host clean

Why it happens: A bounded observation becomes a universal conclusion.
How to fix it: Qualify by reviewed material and untested boundaries.
Prevent it next time: Keep scope and uncertainty near the finding.

Check your understanding

1. The model returns NO_FAILURE_IN_REVIEWED_CASE. What must the report avoid?

Show worked solution

It must avoid claiming that the entire host is uncompromised or every control is correct. State the exact case and evidence, plus missing context. The program inspects no host and validates only its declared routing policy.

2. A temporary restriction stops unexpected exports. Is the underlying issue closed?