Build an Integrity Baseline and Retest

A baseline is useful only if you can use it later.

That means an integrity record needs more than a long hexadecimal string.

You need to know:

• which artifact was hashed;
• when the reference was created;
• what state the reference represents;
• why that state is trusted;
• which algorithm was used; and
• what happened when the current artifact was compared with it.

This lesson turns those pieces into a small repeatable workflow.

Part 1 — Define the artifact

For the fictional service, the artifact is:

/etc/rnx/status-service.yaml

Purpose:

Configure the local status service's listener, template path, and status-data path.

Trusted-reference state:

Approved classroom image immediately after instructor provisioning at 09:00.

Algorithm:

SHA-256.

Baseline digest:

6d31b8e7...baseline-example...f09a

In a real record, store the full digest. The abbreviated course digest here exists only to keep the synthetic example readable.

Part 2 — Compare current state

Current digest:

e9507c11...current-example...3b27

Result:

Mismatch.

Bounded integrity claim:

The current configuration is not byte-for-byte identical to the approved 09:00 baseline artifact.

Now add the content comparison from Lesson 2:

-status_file: /var/lib/rnx/status.json
+status_file: /var/lib/rnx/stats.json

And the log:

reason=status-file-not-found path=/var/lib/rnx/stats.json

The evidence now supports a specific test.

Part 3 — Restore one intended condition

In the isolated fictional lab, the modeled correction is:

status_file: /var/lib/rnx/status.json

Nothing else changes.

That “nothing else” constraint matters.

If you change the path, permissions, service identity, package version, and listening port at the same time, a successful retest will not tell you which change fixed the behavior.

Controlled change reduces ambiguity.

Part 4 — Retest function

Supplied post-correction evidence:

11:42:03Z level=INFO event=startup status_file=/var/lib/rnx/status.json
11:42:04Z level=INFO event=status-read records=6
11:42:04Z level=INFO event=service-ready result=true
11:42:09Z level=INFO event=response route=/status result=200

Service-manager evidence:

rnx-status.service
state: active
main_pid: 733

The expected function now succeeds in the supplied test window.

Part 5 — Recalculate integrity evidence

The restored configuration produces the trusted baseline digest again:

6d31b8e7...baseline-example...f09a

What does that add?

It supports:

The restored configuration bytes match the approved 09:00 baseline bytes.

Combined with the successful service evidence, we can state:

After restoring the intended status_file path, the configuration matches the approved baseline digest and the supplied service evidence records successful startup, status-data reading, and a 200 response for /status.

That is a useful troubleshooting conclusion.

Still not:

The entire host is secure and no unauthorized change occurred.

The workflow tested one artifact and one service behavior.

Positive, negative, and integrity checks

Week 1 introduced multiple test types. Use them here too.

Positive functional check

Expected service function succeeds.

Negative/boundary check

An unrelated protected resource should remain outside the service's permissions from Week 2.

Integrity check

The configuration digest matches the intended baseline.

A good correction preserves the system around the problem instead of flattening all boundaries just to make one error disappear.

Your own harmless local baseline

If your instructor provides an approved local Linux workspace, create a harmless file such as:

robotnix-integrity-demo.txt

with non-sensitive content:

mode=training
status=ready

Then calculate:

sha256sum robotnix-integrity-demo.txt

Record the digest.

Change one harmless line:

status=review

Hash it again.

Restore the original line and hash it a third time.

Expected reasoning:

1. original and changed digests differ because the bytes differ;
2. restored content returns to the original digest if the bytes are truly identical; and
3. none of those digest results tells you who made the change or whether the text is “safe.”

No-shell alternative

Your instructor may provide three digest records and file contents. You can complete the same reasoning without executing a command.

Do not build a “malware checker” from raw hashes

A common oversimplification is:

hash seen before = bad
hash not seen before = good

That is not a reliable security model.

Known hashes can be useful in reputation systems, allowlists, deny lists, software distribution, evidence management, and incident investigation—but context matters.

A new harmless build has a new hash. A known-good file can be placed in the wrong context. A known malicious hash may identify exact known bytes while saying nothing about a modified variant. A reference database also has its own trust and freshness questions.

Week 3 is about integrity evidence, not magical classification.

Build the final Integrity and Troubleshooting Record

Use this structure.

Artifact identity

Path/name:
Purpose:
Reference state:
Reference source:
Algorithm: SHA-256

Baseline

Baseline digest:
Why trusted:

Observation

Current digest:
Match/mismatch:
Relevant content/metadata difference:

Corroborating evidence

Log/service evidence:
What it supports:

Hypothesis

Proposed explanation:
Evidence that would weaken it:

Controlled correction

One condition changed:

Retest

Functional result:
Boundary result:
Post-change integrity result:

Conclusion

Strongest claim supported:

Limitation

What this workflow still cannot prove:

Unit 1 defense

You can now connect the first three weeks:

I worked inside an explicit authorization boundary. I traced the service through its identity, process, resources, and evidence. I compared a changed artifact with a trusted baseline, correlated the difference with the failure evidence, changed one relevant condition, and retested both function and boundary.

That is a much stronger foundation for cybersecurity than “I ran a tool and it printed something red.”