RobotnixAcademy

Week 01 · overview

Week 1: Authorization, Lab Boundaries, and Evidence

Security work starts before a scanner, terminal, packet capture, or alert. It starts with a more basic question:

What system are you allowed to touch, what are you allowed to do to it, and what evidence would prove what happened?

That question sounds administrative until something goes wrong. Then it becomes technical very quickly.

A system can be owned by your school and still be outside your authorization. A lab can be authorized for observation but not for configuration changes. A log line can be real but still fail to prove the conclusion someone attached to it. A control can look correct on paper and still fail when tested.

This week establishes the operating discipline for the entire course.

The course operating loop

CS1337 will keep returning to the same cycle:

BUILD
  ↓
BASELINE
  ↓
OBSERVE
  ↓
SAFELY MISCONFIGURE
  ↓
DETECT
  ↓
HARDEN
  ↓
RETEST
  ↓
DOCUMENT

Not every week will use every step. The order matters because it prevents guessing.

If you do not know the authorized boundary, stop. If you do not know the expected state, build a baseline. If you cannot point to evidence, weaken the claim. If you change a control, retest it.

The lab boundary for this course

Required security work uses only one of these environments:

  • a Robotnix-provided fictional scenario;
  • a synthetic log, configuration, packet trace, or system state;
  • an isolated classroom lab explicitly approved for the activity; or
  • a system you have been specifically authorized to inspect in the way the lesson describes.

Public websites, school production systems, home networks belonging to other people, random IP addresses, and systems that are merely reachable are not course targets.

Reachable is not the same as authorized.

Week 1 artifact

You will build a short Defensive Evidence Record containing:

  1. an authorization/scope card;
  2. a baseline claim;
  3. an evidence ledger;
  4. one controlled before/after comparison;
  5. one defensive control;
  6. a retest result; and
  7. one limitation on what your evidence proves.

The artifact matters more than memorizing vocabulary. By the end of the week, another person should be able to inspect your record and understand what system you were studying, what you were allowed to do, what changed, what evidence you observed, and why your conclusion is reasonable.

This week

Lesson 1 — Authorization Is a Technical Boundary

Build a scope card that separates ownership, authorization, permitted actions, prohibited actions, evidence sources, and stop conditions.

Lesson 2 — Baselines Turn Activity Into Evidence

Learn the difference between an event, an observation, an interpretation, and a defensible claim. Build an evidence ledger from a synthetic service scenario.

Lesson 3 — Change One Thing, Prove One Thing

Compare a safe before/after configuration, identify the defensive failure, choose a control, and design a retest that could actually show whether the control worked.

Reflection — Evidence Before Confidence

Summarize what changed in your reasoning and identify where your evidence is still incomplete.

One rule to carry forward

When security work becomes confusing, return to this sequence:

boundary → baseline → evidence → claim → control → retest

If one of those pieces is missing, the answer is not to sound more confident. The answer is to find the missing evidence.