◇ OpenCyber Academy
Engineering · Chapter 4 · English

Chapter 4 — Programming I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 4 — Programming I

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Programs as precise procedures"]
  N2["4.2 Core constructs"]
  N3["4.3 Reading records"]
  N4["4.4 Testing on known input"]
  N5["4.5 Readability"]
  N6["4.6 Standard library first"]
  N7["Version control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Programs as precise procedures"]
  N2["4.2 Core constructs"]
  N3["4.3 Reading records"]
  N4["4.4 Testing on known input"]
  N5["4.5 Readability"]
  N6["4.6 Standard library first"]
  N7["Version control"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Programs as precise procedures]
    |
    v
[4.2 Core constructs]
    |
    v
[4.3 Reading records]
    |
    v
[4.4 Testing on known input]
    |
    v
[4.5 Readability]
    |
    v
[4.6 Standard library first]
    |
    v
[Version control]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) write small programs that read and summarise log records; (2) use variables, loops, conditions and functions; (3) test a program on known input; (4) keep code readable for reviewers.

4.1 Programs as precise procedures

A program is a procedure a computer follows exactly. In a SOC, small programs count, filter and summarise records faster and more consistently than people. Because they are exact, mistakes in them are repeated exactly too, so they must be tested.

A person counting failed logins by eye might miss a few lines or count one twice, and each count would differ slightly. A program gives the same answer every time, which is reassuring when it is right and dangerous when it is wrong. That is why SOC scripts are reviewed and tested like any other engineering artefact before analysts rely on their output.

4.2 Core constructs

Variables hold values such as a count. Loops visit every record. Conditions choose what to count. Functions package a step, such as "extract the /24 network from an address", so it can be reused and tested alone.

Amara's first script uses all four: a dictionary of counts keyed by network, a loop over log lines, a condition selecting failed logins and a function returning the /24 prefix. Keeping the prefix step in its own function means she can test it with tricky addresses, such as ones at the edge of a range, without running the whole script.

4.3 Reading records

Logs arrive as lines of text or structured records. A program splits each line into fields, converts types (text to numbers or times) and handles malformed lines without crashing, recording how many were skipped.

Real logs contain truncated lines, unexpected encodings and fields in odd formats. A script that crashes on the first bad line gives no answer at all; one that silently ignores bad lines may give a wrong one. Counting skipped lines and reporting them alongside results lets the reader judge whether the data were clean enough to trust.

4.4 Testing on known input

Before running on real logs, Amara feeds her function five hand-made lines whose correct answer she already knows. If the output differs, the code is wrong, not the data.

Her five lines include an ordinary failure, a success, a malformed line, an address at the boundary of a /24 range and a line with a time from a different zone. Each tests one possible mistake. When the first run counts the malformed line as a failure, she fixes the parser and reruns before touching real data.

4.5 Readability

Short functions, clear names and comments on intent help Paolo review her code. Code that only its author understands is a risk in operations.

In a SOC, scripts are often run at 3 a.m. by someone other than their author, during an incident. A function named failed_logins_by_network explains itself; one named proc2 does not. Comments should say why a step exists, for example that one log source writes local time, rather than restating what the code does.

4.6 Standard library first

Python's standard library reads CSV, JSON and dates. Using it avoids installing unreviewed packages on SOC machines.

Every installed package is code from outside the organisation running on machines that see sensitive data. Each one needs review, updates and trust in its maintainers. For counting, filtering and parsing common formats, the standard library is enough, and SOC machines stay simpler to secure and rebuild. Larger tools are added deliberately when a real need appears. Paolo keeps a short list of approved packages, each with a named owner who tracks its updates.

Version control

Amara keeps her scripts in the team's version-control repository. Each change has a message explaining why, and Paolo reviews changes before they run on production data. History lets the team see which version produced a given result.

Worked example

Amara's first function returns the /24 network for an IPv4 address. Her test cases include "203.0.113.14" → "203.0.113.0/24" and a malformed "203.0.113" which must return None rather than crash. One test fails at first because she forgot the malformed case; she fixes it before using the function on portal logs.

Synthetic case. Code and data are synthetic.

Errors and limits

Passing tests show the code handles the cases you thought of, not all cases; add tests when new inputs surprise you.

Exercises

Synthesis

Small, tested, readable programs make log analysis consistent; their exactness is a strength only when they are checked.

Continue studying — chapter 04 of 50

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →