RobotnixAcademy
← Courses

Computing

CS1337: Systems, Networks, and Cyber Defense

A systems-first defensive computing course where students learn how programs, data contracts, services, networks, identities, controls, telemetry, risk, and recovery fit together. Students build baselines, analyze supplied or isolated evidence, safely change bounded conditions, verify controls, retest required function, and defend claims without unauthorized or operational hacking workflows.

Length
18 weeks
Audience
Grades 9-12
Entries
90

Week 01

  1. overviewWeek 1: Authorization, Lab Boundaries, and EvidenceSecurity work starts before a scanner, terminal, packet capture, or alert. It starts with a more basic question:
  2. Lesson 1Authorization Is a Technical BoundaryA security tool does not know whether you have permission.
  3. Lesson 2Baselines Turn Activity Into EvidenceA log entry by itself is not a security conclusion.
  4. Lesson 3Change One Thing, Prove One ThingA security control is not proven because someone wrote it in a policy.
  5. reflectionWeek 1 Reflection: Evidence Before ConfidenceUse your Defensive Evidence Record from this week. Keep the response short enough that every sentence has a job.

Week 02

  1. overviewWeek 2: Systems, Users, Processes, and ServicesLast week you defined the authorized boundary and learned to separate evidence from inference.
  2. Lesson 1Who Is Doing What?A user is not a process.
  3. Lesson 2Process and Service State Are EvidenceOne system can tell several different stories at the same time.
  4. Lesson 3Least Privilege Is a Relationship“Run it as administrator” is a troubleshooting shortcut that often hides the real problem.
  5. reflectionWeek 2 Reflection: Trace the Responsibility ChainUse your Service Responsibility Map.

Week 03

  1. overviewWeek 3: File Hashes and Troubleshooting EvidenceA hash can tell you that two byte sequences are the same or different.
  2. Lesson 1A Hash Is a Fingerprint, Not a VerdictSuppose two files have the same name:
  3. Lesson 2Troubleshooting Is Hypothesis TestingA service fails at 11:20.
  4. Lesson 3Build an Integrity Baseline and RetestA baseline is useful only if you can use it later.
  5. reflectionWeek 3 Reflection: What Did the Hash Actually Prove?Use your Integrity and Troubleshooting Record.

Week 04

  1. overviewWeek 4: Programs Are SystemsA program is not just a pile of lines that execute from top to bottom. It is a system that accepts inputs, stores state, makes decisions, changes state, and produces outputs. This week you will learn to read small…
  2. Lesson 1Programs Have StateA computer program looks static when you read the file. The interesting part begins when it runs.
  3. Lesson 2Branches Create Alternate FuturesA branch is where one program becomes several possible programs.
  4. Lesson 3Validate Before You TrustPrograms do not receive “good data” and “bad data.” They receive bytes, text, numbers, objects, messages, and signals. The program decides what those values mean.
  5. reflectionWeek 4 Reflection: What Changed the Program's Behavior?Choose one Week 4 case where the program produced a different result than expected.

Week 05

  1. overviewWeek 5: Data Needs a ContractPrograms exchange values constantly, but two components can use the same bytes and disagree about what those bytes mean. This week moves from program logic to data representation: types, schemas, parsing,…
  2. Lesson 1A Value Has Type, Meaning, and UnitsThe text 42 can mean many things.
  3. Lesson 2Parsing Is a BoundaryA parser turns one representation into another.
  4. Lesson 3Schemas Turn Assumptions Into TestsA schema is a machine-checkable or human-checkable statement about the shape of data.
  5. reflectionWeek 5 Reflection: Valid Structure Is Not TruthPick one malformed message from the week.

Week 06

  1. overviewWeek 6: Automation Needs GuardrailsAutomation is useful because computers repeat instructions quickly and consistently. That same property makes a bad assumption repeat quickly and consistently too.
  2. Lesson 1Automation Multiplies DecisionsA manual mistake may happen once. An automated mistake can happen a thousand times before anyone notices.
  3. Lesson 2Exit Codes and Logs Are Part of the InterfaceA script that prints “done” is not necessarily done.
  4. Lesson 3Safe Automation Is Repeatable and ReversibleThe best automation is not the script with the most features. It is the one whose behavior remains understandable when run twice, when something fails halfway through, and when a human needs to recover.
  5. reflectionWeek 6 Reflection: What Makes Automation Safe Enough to Trust?In 6–9 sentences, describe the strongest guardrail in your Week 6 automation design.

Week 07

  1. overviewWeek 7: Networks Are Paths, Not MagicA network message does not teleport from one application to another. It is wrapped in protocol information, placed on a local link, forwarded across one or more paths, and delivered to a receiving process.
  2. Lesson 1A Packet Has Context at More Than One LayerWhen an application sends data, several systems have to agree about where that data belongs.
  3. Lesson 2Routes Decide the Next StepAn IP address tells a host the destination. A routing table helps the host decide where to send the packet next.
  4. Lesson 3Reachability Is a Chain of DependenciesWhen an application says “cannot connect,” the network may be blamed immediately.
  5. reflectionWeek 7 Reflection: Where Did the Path Actually Fail?Use the fictional RNX client incident.

Week 08

  1. overviewWeek 8: Ports, Transport, and Service ExposureAn IP address identifies a network-layer destination. A service still needs a transport endpoint and a listening process. This week connects TCP and UDP behavior to sockets, ports, service binding, and defensive…
  2. Lesson 1Ports Belong to Transport EndpointsA port number is not a program.
  3. Lesson 2TCP Keeps Connection State; UDP Does Not Promise ItTCP and UDP both carry application data over IP, but they offer different transport behavior.
  4. Lesson 3Listening Is Not the Same as ReachableA service can listen locally and still be unreachable from another host.
  5. reflectionWeek 8 Reflection: What Does a Listening Socket Prove?In 6–9 sentences, compare these statements:

Week 09

  1. overviewWeek 9: Names, Requests, and Trust on the Web PathA browser request can fail even when IP routing works and a TCP port is reachable. Name resolution, HTTP semantics, TLS identity, certificates, time, and application behavior all add dependencies above the basic…
  2. Lesson 1DNS Maps Names to Data, Not TrustHumans like names. Networks route using addresses.
  3. Lesson 2HTTP Is a Request and Response ConversationOnce a client reaches an HTTP service, application-layer evidence begins.
  4. Lesson 3TLS Protects a Session Under Specific Trust ConditionsHTTPS is HTTP carried through TLS.
  5. reflectionWeek 9 Reflection: Which Layer Failed First?Choose one Week 9 failure: stale DNS, HTTP 503, hostname mismatch, or bad client time.

Week 10

  1. overviewWeek 10: Threat Modeling Starts With ArchitectureSecurity controls are weak when they are selected before anyone understands the system.
  2. Lesson 1You Cannot Defend What You Have Not ModeledA security product cannot tell you what matters to the system owner.
  3. Lesson 2Threats Are Paths Through a SystemA threat is more useful when it is tied to a mechanism.
  4. Lesson 3Controls Should Break a MechanismA security control is strongest when you can point to the exact part of a threat path it changes.
  5. reflectionWeek 10 Reflection: Which Control Actually Changes the Path?Choose one threat scenario from your model.

Week 11

  1. overviewWeek 11: Identity Is a Chain of DecisionsA username is not authorization. A successful login is not permission to perform every action. A session token is not the human. This week separates identification, authentication, authorization, session state,…
  2. Lesson 1Authentication and Authorization Answer Different QuestionsIdentity systems become easier to reason about when you separate the questions.
  3. Lesson 2Sessions Carry Authority After LoginMost applications do not ask a user to authenticate from scratch before every request.
  4. Lesson 3Least Privilege Is an Ongoing LifecycleLeast privilege is not a one-time configuration.
  5. reflectionWeek 11 Reflection: When Should Authority End?Choose either a human account or service identity.

Week 12

  1. overviewWeek 12: Hardening Is Controlled ChangeHardening means reducing unnecessary exposure and making system behavior more deliberate. It does not mean changing every setting that sounds secure.
  2. Lesson 1A Baseline Makes Configuration Drift VisibleYou cannot detect configuration drift if nobody knows what the expected configuration is.
  3. Lesson 2Reduce What the System Does Not NeedEvery unnecessary service, permission, interface, package, network path, or feature creates something else that must be configured, patched, monitored, and understood.
  4. Lesson 3Every Hardening Change Needs Rollback and RetestA correct idea can still be implemented badly.
  5. reflectionWeek 12 Reflection: When Should You Roll Back?Use either the successful legacy-service hardening change or the failed binding change.

Week 13

  1. overviewWeek 13: Logs Are Evidence With ContextA log line is not the event itself. It is a record produced by a component according to its code, configuration, clock, permissions, and logging policy.
  2. Lesson 1A Log Records a System's ViewLogs are one of the most useful defensive evidence sources because they can preserve what a system believed happened at a particular time.
  3. Lesson 2Correlation Builds a Stronger TimelineOne log source sees one part of a system.
  4. Lesson 3Missing Logs Are Also a System ConditionA monitoring system can fail while the application keeps working.
  5. reflectionWeek 13 Reflection: What Does Silence Mean?In 6–9 sentences, explain why “no matching logs” is not automatically the same as “the event did not happen.”

Week 14

  1. overviewWeek 14: Detection Is a Testable HypothesisAn alert is not proof of an incident. It is a rule or model saying, “this observation matches a condition we decided to notice.”
  2. Lesson 1An Alert Is a Claim About EvidenceA detection system receives evidence and applies logic.
  3. Lesson 2Thresholds Trade Sensitivity for NoiseMany detections use thresholds.
  4. Lesson 3Detections Need Tests and MaintenanceA detection rule is code or logic operating on changing data.
  5. reflectionWeek 14 Reflection: When Is an Alert Wrong?Choose either a false positive, false negative, or detection regression from Week 14.

Week 15

  1. overviewWeek 15: Vulnerability Is Not the Same as RiskA vulnerability describes a weakness or condition. Risk asks what that weakness means in this system, with this exposure, these assets, these controls, and these consequences.
  2. Lesson 1A Weakness Needs ContextSuppose two systems have the same software weakness.
  3. Lesson 2Risk Scores Are Inputs, Not DecisionsSecurity teams often use published severity systems to communicate characteristics of vulnerabilities.
  4. Lesson 3Prioritization Is a Defensible TradeoffA risk register is useful only if it changes what the team does next.
  5. reflectionWeek 15 Reflection: Why Isn't the Highest Score Always First?Choose one finding whose local priority differs from its external/technical severity.

Week 16

  1. overviewWeek 16: Incidents Require Decisions Under UncertaintyAn incident-response team rarely starts with complete information. It receives alerts, user reports, system failures, logs, and partial evidence while the system may still be changing.
  2. Lesson 1Triage Separates Facts, Hypotheses, and UrgencyIncident response begins before you know the full story.
  3. Lesson 2Containment Is a Systems DecisionContainment tries to limit ongoing harm or uncertainty.
  4. Lesson 3Recovery Ends With Learning, Not Just UptimeA system can return to service without the organization understanding why it failed.
  5. reflectionWeek 16 Reflection: What Changed After the Incident?In 7–10 sentences, explain one lesson that should permanently change the fictional Northstar system after INC-016.

Week 17

  1. overviewWeek 17: Review the Architecture Before You Defend ItThe final project begins by rebuilding the system model from evidence. Students will not start with recommendations. They will start by proving what the fictional organization actually depends on, which trust…
  2. Lesson 1Reconstruct the System From EvidenceA final architecture diagram should not be a drawing made from memory.
  3. Lesson 2Control Coverage Has Gaps and Failure ModesA control map should answer two questions:
  4. Lesson 3An Architecture Review Produces DecisionsA review is not complete when the diagram looks good.
  5. reflectionWeek 17 Reflection: Which Gap Changes the Architecture Most?Choose one Week 17 finding.

Week 18

  1. overviewWeek 18: Defend the System With EvidenceThe capstone does not ask you to prove a system is secure. No responsible review can prove that from a classroom test set.
  2. Lesson 1Freeze the System Model and Test PlanTesting becomes meaningless when the system changes every time the result is inconvenient.
  3. Lesson 2Test Normal, Boundary, Failure, and Recovery StatesThe capstone is not graded by how many green boxes you produce.
  4. Lesson 3Defend Claims, Limits, and Next ActionsYour final defense is not a sales pitch.
  5. reflectionWeek 18 Final Reflection: What Can You Defend Now?Write 8–12 sentences answering: