Chapter 7 — Application and software supply chain security: data and telemetry
Lesson map
Lesson 07 published. Map, example, EX025.
flowchart TD
N0["Learning outcomes"]
N1["7.1 What logs show"]
N2["Lab — log summary"]
N3["7.2 Lab result"]
N4["7.3 Choosing telemetry"]
N5["7.4 Privacy"]
N6["7.5 From summary to action"]
N7["Error bursts after updates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX025"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 What logs show"]
N2["Lab — log summary"]
N3["7.2 Lab result"]
N4["7.3 Choosing telemetry"]
N5["7.4 Privacy"]
N6["7.5 From summary to action"]
N7["Error bursts after updates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX025"]
[Learning outcomes]
|
v
[7.1 What logs show]
|
v
[Lab — log summary]
|
v
[7.2 Lab result]
|
v
[7.3 Choosing telemetry]
|
v
[7.4 Privacy]
|
v
[7.5 From summary to action]
|
v
[Error bursts after updates]
|
v
[Worked example] --> [Exercise EX025]
Learning outcomes
You will (1) read web access logs for signs of problems; (2) summarise errors and failed sign-ins; (3) choose useful telemetry; (4) respect privacy in logs.
7.1 What logs show
Each request leaves a log line: time, source address, method, path and status code. Patterns in these lines show problems: bursts of errors after an update, repeated failed sign-ins to the admin page, or requests for pages that should not exist. In the lab log, the five 401 responses on /admin from one address show one pattern, and the two 500 errors on /shop show another. Reading lines one at a time misses both; counting them by hour and by source makes them visible.
Lab — log summary
"""Summarise a synthetic web access log: errors per hour and admin-page requests by source (stdlib only)."""
from collections import Counter
log = """10:02 203.0.113.5 GET /shop 200
10:05 203.0.113.9 GET /admin 302
10:07 198.51.100.7 GET /admin 401
10:07 198.51.100.7 GET /admin 401
10:08 198.51.100.7 GET /admin 401
10:08 198.51.100.7 GET /admin 401
10:09 198.51.100.7 GET /admin 401
10:15 203.0.113.5 GET /cart 200
11:01 203.0.113.12 GET /shop 500
11:02 203.0.113.12 GET /shop 500
11:20 203.0.113.5 GET /shop 200""".splitlines()
errors, admin = Counter(), Counter()
for line in log:
t, ip, _, path, code = line.split()
if code.startswith(("4", "5")):
errors[t[:2]] += 1
if path == "/admin" and code == "401":
admin[ip] += 1
for hour, n in sorted(errors.items()):
print(f"hour {hour}: {n} error responses")
for ip, n in admin.items():
print(f"{ip}: {n} failed admin sign-ins" + (" REVIEW" if n >= 5 else ""))
Run with python3 lab_logs.py. Verified output:
hour 10: 5 error responses
hour 11: 2 error responses
198.51.100.7: 5 failed admin sign-ins REVIEW
7.2 Lab result
The synthetic Ferncroft log shows 5 error responses in hour 10 and 2 in hour 11. All five hour-10 errors are failed sign-ins (401) to /admin from 198.51.100.7, which reaches the review threshold of 5. The two hour-11 errors are 500 server errors on /shop from another address, which point to an application fault rather than sign-in attempts. The summary does not say who was behind 198.51.100.7, only that it crossed the threshold. Tomás still checks with the customer before treating the address as hostile, because a staff member who forgot a password would produce the same count.
7.3 Choosing telemetry
Useful records for supply chain work include plugin installation and update events, file changes in code folders, error rates after updates and admin sign-ins. Pinecrest adds file-change monitoring for code folders after the Ferncroft case. File-change monitoring would have flagged Ferncroft's plugin folder had anything been written into it, and installation events would have recorded the mirror download. Error rates measured just after updates show a broken release within hours rather than days. Each record answers a question support actually asks, which keeps telemetry focused rather than collecting everything.
7.4 Privacy
Logs contain visitor addresses, which are personal data. They are kept for 30 days, access is limited to support and security staff, and examples in training use documentation addresses. Thirty days covers most support investigations, including the Ferncroft redirects once they were reported. Restricting access to support and security staff keeps visitor addresses away from people who do not need them. Using documentation addresses such as 198.51.100.7 in labs means training material never exposes a real visitor. Evidence copies taken for a case follow the case's retention instead.
7.5 From summary to action
A REVIEW line is a prompt to look further, not proof of an attack; repeated failures may be a customer who forgot a password. In the worked example, the REVIEW line for 198.51.100.7 led Tomás to ask Ferncroft whether any staff were working then; none were. That answer, not the count alone, made the failures worth acting on. A forgetful staff member would have produced the same five lines in the summary. The decision and the customer's answer are recorded in the ticket with the summary.
Error bursts after updates
When errors rise just after a plugin update, support first suspects the update and can roll back.
Worked example
Tomás checks the 198.51.100.7 failures with Ferncroft: no staff were working at that time. The customer turns on multi-factor sign-in for shop administrators, and the failures stop mattering because a password alone no longer signs in.
Synthetic case. Logs and addresses are synthetic documentation values.
Errors and limits
Logs only show what was recorded; missing logs leave blind spots.
Exercises
- EX025 — Lab hour 10. What did hour 10 show? Rubric: 3 = 5 failed admin sign-ins from one address; 2 = partial; 1 = vague; 0 = none.
- EX026 — Hour 11. What did the hour-11 errors suggest? Rubric: 3 = application fault, 500s; 2 = partial; 1 = vague; 0 = none.
- EX027 — New telemetry. What monitoring did Pinecrest add? Rubric: 3 = file-change monitoring for code folders; 2 = partial; 1 = vague; 0 = none.
- EX028 — REVIEW meaning. What does a REVIEW line mean? Rubric: 3 = prompt to look further, not proof; 2 = partial; 1 = vague; 0 = none.
Synthesis
Logs turn into useful signals when summarised and checked.
Continue studying — chapter 07 of 18
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →