Chapter 5 — Security architecture and engineering: tools and interpretation
Lesson map
Lesson 05 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Tools available"]
N2["5.2 Interpreting output"]
N3["5.3 Common misreadings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Tools available"]
N2["5.2 Interpreting output"]
N3["5.3 Common misreadings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]
[Learning outcomes]
|
v
[5.1 Tools available]
|
v
[5.2 Interpreting output]
|
v
[5.3 Common misreadings]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) use simple tools to examine access and configuration; (2) interpret tool output correctly; (3) avoid common misreadings.
5.1 Tools available
Owen does not need advanced tools to start. He uses the identity provider's admin reports, the cloud provider's security recommendations page, the supplier portal's user export and a spreadsheet. Kwame also gives him read-only access to the vulnerability scanner Thornbury already runs monthly against its public services. Ines encourages him to learn what existing tools can show before asking for new ones, because organisations often already own capabilities that nobody has time to use well. He lists each tool, its owner and what access he has to it.
5.2 Interpreting output
The scanner reports forty findings on the tenant portal. Owen's first reaction is alarm, but he reads each one. Most are informational, such as server version banners. Two are rated high: an outdated library and a weak TLS configuration on an old test subdomain still pointing at a live server. He confirms with the developer that the test subdomain is unused and asks for it to be removed. Interpretation means checking what each finding actually means in context, rather than counting findings or trusting severity labels alone.
5.3 Common misreadings
Owen collects misreadings he nearly made. A cloud page showing a high secure score does not mean tenant data is safe; it measures settings against a vendor list. An identity report showing no risky sign-ins may reflect a feature that is switched off. A scanner showing no findings on a server may mean it could not reach it. For each tool he writes down what it measures, what it cannot see and how to confirm a surprising result. This habit makes his later reports far more reliable.
Worked example
Owen uses existing tools, interprets forty scanner findings to find two real issues and records common misreadings for three tools.
Synthetic case. Tools and findings are synthetic.
Errors and limits
Severity labels are generic. Tool coverage gaps are easy to miss.
Exercises
- EX021 — Existing capability. Why learn existing tools first? Rubric: 3 = organisations often own unused capabilities;; 2 = already owned;; 1 = vague;; 0 = none.
- EX022 — Real findings. Which two scanner findings mattered? Rubric: 3 = an outdated library and weak TLS on an old live test subdomain;; 2 = two;; 1 = vague;; 0 = none.
- EX023 — Secure score. What does a high cloud secure score not mean? Rubric: 3 = that tenant data is safe;; 2 = not safety;; 1 = safe;; 0 = none.
- EX024 — Empty scan. What might no findings on a server mean? Rubric: 3 = the scanner could not reach it;; 2 = reachability;; 1 = secure;; 0 = none.
- EX025 — Tool notes. What three things does Owen record for each tool? Rubric: 3 = what it measures, what it cannot see, how to confirm surprises;; 2 = two;; 1 = vague;; 0 = none.
Synthesis
Tool output needs interpretation in context, with clear notes on what each tool measures and misses.
Continue studying — chapter 05 of 12
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →