Chapter 15 — Security fundamentals | Engineering Security operations and blue team

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 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 The three properties"]
  N2["15.2 Threats, vulnerabilities, controls"]
  N3["15.3 CSF 2.0 functions"]
  N4["15.4 Prevention and detection"]
  N5["15.5 Defence in depth"]
  N6["15.6 Least privilege"]
  N7["15.7 Case mapping"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 The three properties"]
  N2["15.2 Threats, vulnerabilities, controls"]
  N3["15.3 CSF 2.0 functions"]
  N4["15.4 Prevention and detection"]
  N5["15.5 Defence in depth"]
  N6["15.6 Least privilege"]
  N7["15.7 Case mapping"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 The three properties]
    |
    v
[15.2 Threats, vulnerabilities, controls]
    |
    v
[15.3 CSF 2.0 functions]
    |
    v
[15.4 Prevention and detection]
    |
    v
[15.5 Defence in depth]
    |
    v
[15.6 Least privilege]
    |
    v
[15.7 Case mapping]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) explain confidentiality, integrity and availability; (2) relate threats, vulnerabilities and controls; (3) place security operations within the NIST CSF 2.0 functions; (4) distinguish prevention from detection and response.

15.1 The three properties

Confidentiality keeps information from unauthorised people; integrity keeps it accurate and unaltered; availability keeps systems usable. The portal incident touched all three: customer data could be seen, addresses altered, and the login service slowed.

Thinking in all three keeps the response balanced. A team focused only on confidentiality might miss that customers' delivery addresses could have been changed, an integrity problem that could misdirect parcels. Availability suffered too, as genuine customers met slow logins during the burst. Amara's incident notes record the effect on each property separately.

15.2 Threats, vulnerabilities, controls

A threat is a possible cause of harm; a vulnerability is a weakness it can exploit; a control reduces risk. Reused customer passwords are the vulnerability credential stuffing exploits; rate limiting and multi-factor authentication are controls.

Separating the three clarifies what each fix does. Lindqvist cannot stop criminals buying leaked password lists, the threat, and cannot force customers to stop reusing passwords, the vulnerability. It can add controls that make reused passwords less useful, such as slowing repeated attempts and asking for a second factor.

15.3 CSF 2.0 functions

The NIST Cybersecurity Framework 2.0 organises outcomes into Govern, Identify, Protect, Detect, Respond and Recover. A SOC mainly delivers Detect and Respond, but depends on Identify (asset knowledge) and feeds Govern with risk information.

Without Identify, the SOC would not know which systems the portal depends on or who owns them. Feeding Govern means turning incident lessons into risk information that leaders use for decisions, such as funding MFA for customers. Mapping SOC work to the functions also shows where the team relies on others to deliver its own outcomes.

15.4 Prevention and detection

No prevention is perfect. Detection finds what prevention missed, and response limits harm. A balanced programme invests in all three.

Spending everything on prevention leaves the organisation blind when a control fails; spending everything on detection lets avoidable attacks through and floods analysts. Response turns detection into reduced harm, so a detection with no one able to act on it adds little. Budgets are argued using incidents like the portal burst, which needed all three. Each function has its own measures.

15.5 Defence in depth

Several layers — rate limits, bot detection, MFA, monitoring of account changes — mean one failure does not lead to full compromise.

Each layer catches a share of what slips past the one before. Rate limits slow the attempts, bot detection blocks automated clients, MFA stops a correct password from being enough, and monitoring of account changes spots misuse after login. Layers should fail independently, so a single misconfiguration cannot disable several at once. Amara lists which portal layers existed during the burst and which were missing.

15.6 Least privilege

Accounts get only the rights they need, limiting damage when one is misused.

At Lindqvist, the portal's database account can read and update customer records but cannot drop tables or read staff data. If an attacker controlled the portal, the damage would be limited to what that account allows. SOC analysts follow the same rule: they get read access to logs, while response actions such as account locks need separate permissions. Rights are reviewed each quarter and removed when roles change.

15.7 Case mapping

Amara maps the portal incident: the vulnerability (password reuse by customers), the missing control (no MFA option for customers), the detection (her burst rule) and the response (account lock, notice).

The mapping shows where effort would have the most effect. Detection and response worked, but both acted after a customer account had been entered. Adding an MFA option would address the gap before login succeeds. Amara presents the map to Paolo as a one-page table, which later becomes input to the security team's risk discussion with management.

Risk as the organiser

Risk combines how likely harm is and how bad it would be. Lindqvist ranks the customer portal high because it holds addresses and delivery schedules, so its monitoring gets priority over internal test systems.

Worked example

Paolo asks Amara which CSF function a new customer MFA option falls under. She answers Protect, and notes that monitoring MFA enrolment rates and failed second factors would add a Detect outcome.

Synthetic case. Mapping and controls are invented.

Errors and limits

Frameworks organise thinking but do not set priorities; risk assessment does.

Exercises

EX043 — CIA in the case. Show how the incident touched confidentiality, integrity and availability. Rubric: 3 = data visible, address altered, service slowed; 2 = two; 1 = one; 0 = none.
EX044 — Vulnerability and control. Name the vulnerability and two controls for credential stuffing. Rubric: 3 = password reuse; rate limiting and MFA; 2 = one control; 1 = vague; 0 = none.
EX045 — CSF placement. Which CSF functions does a SOC mainly deliver, and which does it rely on? Rubric: 3 = Detect and Respond; relies on Identify, informs Govern; 2 = partial; 1 = one; 0 = none.

Synthesis

Security fundamentals frame SOC work: properties to protect, risks to reduce and functions to deliver.

Continue studying — chapter 15 of 50

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →