Lab 9 — Diagnostic Challenge

Purpose

Every lab to this point handed you working commands. This one does not.

Your instructor has introduced a number of faults into the laboratory environment. Some are obvious. Some produce no error message at all and are visible only as an absence — a dashboard that is quieter than it should be.

Your task is to find them, prove what they are, fix them, and document your reasoning.

This is the closest exercise in the course to the actual work of security operations. The first two years of most analyst careers contain more "why is this not reporting?" than "here is a confirmed intrusion."

Why this matters: An investigation built on incomplete telemetry produces a confident wrong answer. Before you can trust any alert, you must be able to prove your instruments work.

Rules for This Lab

1. Diagnose in pipeline order. Confirm collection before decoding, decoding before rules. Testing at random produces confusion, not answers.
2. Prove each fault before you fix it. Record the evidence that identifies the root cause. "It works now" is not a diagnosis.
3. Change one thing at a time. If you change three settings and the symptom clears, you have not learned which one mattered.
4. Document as you go. Reconstructing your reasoning afterward from memory is unreliable, and the record is what you are graded on.
5. You may use the Field Guide, the textbook, and official documentation. You may not ask another student for the answers.

The Reported Symptom

A colleague reports:

"The SOC dashboard looks fine, but something feels off. I ran an attack simulation on WIN11 an hour ago and I am not seeing what I expected. Some things are there, some are not. Can you check the environment?"

That is all the information you are given. It is also, realistically, all the information you would be given.

Part 1 — Establish What Is Actually True

Before forming any hypothesis, establish ground truth. Complete the table below with what you observe, not what you expect.

Checkpoint 1. You have completed the table above using observed values. Do not proceed on assumptions — an unchecked row is an unknown, not a pass.

Part 2 — Identify the Faults

For each fault you find, complete one block. Use as many blocks as you need; blank blocks are acceptable if you find fewer faults than provided.

Part 3 — Verify End to End

Fixing individual faults is not the same as restoring the environment. Prove the whole path works.

1. Generate activity on WIN11 that you know should produce telemetry.
2. Confirm the event is recorded locally on the endpoint.
3. Confirm the event reached the Manager.
4. Confirm the event was decoded into populated fields.
5. Confirm a rule evaluated it and produced an alert at the expected level.
6. Confirm the alert is visible and searchable in the Dashboard.

Record the evidence for each stage:

Checkpoint 3. You have traced one event end to end and can show evidence at every stage.

Part 4 — The Silent Fault

At least one fault in this environment produces no error message anywhere. It is visible only as missing data.

Which fault was it?

Why did it produce no error?

What routine check would have caught it before it mattered?

If this fault had gone unnoticed for a week, what would the operational consequence have been?

Part 5 — Operational Report

Write a brief report, as you would submit to a SOC lead. Use complete sentences.

Summary of findings (what was wrong, in plain language):

Impact assessment (what visibility was lost, and for how long, as far as you can determine):

What you could not determine (gaps are findings — state them):

Recommended preventive measures (which checks, at what interval, would have caught these earlier):

Checkpoint 4. Your report states impact and names at least one thing you could not determine.

Deliverables

1. Completed ground-truth table from Part 1.
2. One completed fault block for each fault identified.
3. Completed end-to-end verification table from Part 3.
4. Answers to Part 4.
5. Operational report from Part 5.

Key Terms

Silent failure. A fault that degrades or stops a function without producing an error message. Detected only by monitoring the expected behavior, not by waiting for an alarm.

Ground truth. What is actually observed to be the case, as distinct from what is expected or assumed.

Pipeline-order diagnosis. Testing each stage of the telemetry path in sequence — collection, transport, decoding, evaluation, storage, presentation — rather than changing settings at random.