The Defender lab series standard

Version 1.0 · 5 September 2026 · Applies to: Lab 1 incident triage · Lab 2 endpoint containment · Lab 3 advanced hunting · Lab 4 identity attack paths · Lab 5 Office 365 campaign response · Owner: Pradeep Raju, founder, RCW IT Training

This page is the contract the five labs are written against. It exists because “resembles the real console” and “stays inside the lines” are usually treated as opposing goals. They are not: the fidelity is in the workflow, the judgement and the vocabulary; the restraint is in the branding, the data, the access and the claims.

1 · Console fidelity without impersonation

2 · Synthetic data rules

Every identifier in the series is fabricated, and the fabrication follows reserved ranges so a learner can paste a value into a ticket, a blog post or a class without exposing anything real.

Prohibited in this series. Real customer data, real tenant identifiers, screenshots taken from a production portal, live IOC feeds, real malware files or URLs, and anything derived from an unpaid or undisclosed source. If a value could be looked up and belong to somebody, it does not go in.

3 · Privacy, storage and evidence

• Local only. State is written to localStorage under one key per lab (rcw.defender-lab.<labId>) plus the shared learner-name key. There is no server component, no account, no cookies, no analytics script, no ad call and no web font inside a lab page.
• No mailbox content, ever. Lab 5 models a mail incident using headers, telemetry and metadata only — no message body, no attachment, no credential. That is a design rule, not an oversight: mail is the most privacy-sensitive evidence a SOC touches, and a teaching replica has no need of it.
• Redaction by default. The in-lab audit log masks anything shaped like an identity (mailbox, UPN, bearer- or PAT-shaped string) in exports and clipboard output, and the learner must actively switch redaction off to see unmasked values. The switch itself is recorded.
• Learner-owned artefacts. The evidence pack is downloaded by the learner, from their browser, to their machine. It is never uploaded. Instructors should collect it only with the learner’s consent and store it under the organisation’s own retention rules.
• Minors. The content is written for adult practitioners; no personal data is sought from anyone, and no feature depends on knowing who the learner is.

4 · Safety gate and authorisation model

Each lab asks for an explicit authorisation confirmation before the first graded field accepts input, and the confirmation is itself written into the audit record. Inside the lab the same rule is taught as content: no destructive action is accepted without an approver, a change reference, a declared scope, an expiry and a rollback. The labs deliberately refuse, and remember the refusal:

• Hard delete requested before the evidence export → flagged, and the flag survives a reset of the sequence.
• A destructive live-response verb with no recorded approval → refused, then allowed only after the approval fields are complete.
• A company-wide notification drafted as a mail operation → flagged as outside the analyst’s authority.
• An exclusion, exception or suppression with no owner, no expiry or no review date → refused.

Real-environment rule. Nothing in these labs authorises a learner to run a command against a production system. Isolation, purge, ZAP, credential reset, krbtgt rotation, registry persistence removal and firewall blocking all require the organisation’s own change control, and several are irreversible on live assets.

5 · Assessment integrity

6 · Accessibility conformance

Target: WCAG 2.2 AA. The labs are dense console simulations, which is exactly where accessibility usually fails first, so the following are implemented in the shared layer rather than per-lab:

Verification. Each lab is checked with keyboard-only operation, a screen reader pass over every objective, automated axe checks against the rendered DOM, contrast measurement of the actual palette, forced-colours and reduced-motion emulation, and a print render. Findings are fixed in the shared layer so all five labs inherit them. Anything unfixable is recorded here as a known limitation rather than silently claimed as done.

7 · Standards and regulation mapping

Mapping is educational: it tells a learner which control a given habit serves. It is not an audit opinion, a certification, or a statement that completing a lab satisfies any requirement.

Deliberate negative. The series teaches *choosing* a regime, not reciting one. Several objectives mark a wrong-but-plausible citation (DORA for a hospital, “NIS2 has no deadline”, “no regulator applies to internal incidents”) as the failure mode, because that is how it fails in practice.

8 · Content accuracy and review

• Sources. UI flow, terminology, action names, retention windows and query columns are taken from Microsoft Learn documentation for Defender for Endpoint, Defender for Identity and Defender for Office 365; notification timings from the texts named in §7. Product behaviour is described, never copied as artwork.
• Version anchoring. The labs describe the 2026 portal. Where the real product changes naming or moves a control, the lab is updated in the shared layer and the version history below records it. A lab that cannot be kept accurate is retired rather than left to mislead.
• Errata. Report a factual error through the contact page; corrections are published in the version history and in the affected lab’s guide. Where the product itself is ambiguous, the lab states the ambiguity instead of inventing a rule.
• Scope discipline. Anything unverifiable is dropped: if a panel’s behaviour cannot be confirmed from documentation, the lab does not claim it, and the view says “not reproduced”.

9 · Legal, trademark and licence notices

Microsoft, Microsoft Defender, Microsoft Defender XDR, Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft Defender for Office 365, Microsoft 365, Azure, Windows and Active Directory are trademarks of Microsoft Corporation. This series is not affiliated with, endorsed by, or sponsored by Microsoft Corporation. No Microsoft logo or trademark artwork is reproduced; product names appear only to describe the workflow being taught. MITRE ATT&CK is a registered trademark of The MITRE Corporation. NIST publications, ISO/IEC 27001, CIS Controls, and the EU texts cited are referenced for education; their own terms govern their use.

The labs are provided “as is”, for education, without warranty of any kind. They are not professional security advice, not a compliance or audit deliverable, and not a substitute for your organisation’s incident-response plan, legal counsel, or the vendor’s official documentation. RCW IT Training is not liable for actions taken in a production environment on the strength of a practice lab.

10 · Version history