Chapter 19 — Identity and cryptography | 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 19 — Identity and cryptography

Lesson map

Lesson 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Identity as the new perimeter"]
  N2["19.2 Authentication and authorisation"]
  N3["19.3 MFA signals"]
  N4["19.4 Hashing"]
  N5["19.5 Encryption and signatures"]
  N6["19.6 Identity attacks seen defensively"]
  N7["19.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Identity as the new perimeter"]
  N2["19.2 Authentication and authorisation"]
  N3["19.3 MFA signals"]
  N4["19.4 Hashing"]
  N5["19.5 Encryption and signatures"]
  N6["19.6 Identity attacks seen defensively"]
  N7["19.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Identity as the new perimeter]
    |
    v
[19.2 Authentication and authorisation]
    |
    v
[19.3 MFA signals]
    |
    v
[19.4 Hashing]
    |
    v
[19.5 Encryption and signatures]
    |
    v
[19.6 Identity attacks seen defensively]
    |
    v
[19.7 Case]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) explain authentication, authorisation and multi-factor methods; (2) relate identity events to detection; (3) describe hashing, encryption and signatures in SOC tooling; (4) recognise identity-based attacks from the defender's view.

19.1 Identity as the new perimeter

Many attacks today use valid credentials rather than technical exploits. Authentication logs — successes, failures, MFA challenges, token issuance — are therefore among a SOC's most valuable data.

With cloud services and remote work, there is no single network edge that all access crosses. Credentials are what grant access, so attackers buy, guess or steal them. Logs from identity systems show who tried to sign in, from where, with what result and which second factor was used, which makes them central to spotting misuse.

19.2 Authentication and authorisation

Authentication proves who a user is; authorisation decides what they may do. The portal authenticates customers by password; Lindqvist staff use single sign-on with MFA. Authorisation logs show access to sensitive functions, such as changing a delivery address.

A correct password satisfies authentication, but the portal still decides whether that customer may view a given order. Logs from each step answer different questions: authentication logs show who got in, authorisation logs show what they tried to do. An attacker who signs in successfully often shows up later in authorisation logs through unusual actions.

19.3 MFA signals

MFA reduces credential-stuffing success. Its logs add signals: repeated MFA prompts denied by the user may indicate someone holding the password; a sudden change of MFA device warrants checking.

Denied prompts suggest that the password is known to someone else, since the real user is refusing a sign-in they did not start. Repeated prompts sent in quick succession may be an attempt to wear the user down until they approve one. A new MFA device registered right after a sign-in from an unfamiliar place deserves prompt review.

19.4 Hashing

A cryptographic hash gives a fixed-length fingerprint of data. SOCs use hashes to identify files and verify that exported evidence is unchanged. Passwords should be stored using slow, salted password-hashing functions so stolen databases resist cracking.

A file hash lets analysts search across many machines for the same file without moving the file itself. Exported evidence hashed at export can be checked later by anyone. Password hashing is different: functions designed to be slow and salted make each guess expensive, so a stolen database cannot be checked against billions of guesses quickly.

19.5 Encryption and signatures

Encryption protects confidentiality in transit (TLS) and at rest. Digital signatures prove origin and integrity: signed software, signed log batches. Signed load-test tools, as in chapter 14, let rules make reliable exceptions.

Encryption in transit stops someone on the network from reading logins; encryption at rest protects stored data if a disk is stolen. Signatures answer a different question: did this come from who it claims, unchanged? A rule can safely exclude load tests from a tool whose signature verifies, while still alerting on an unsigned copy using the same name.

19.6 Identity attacks seen defensively

Credential stuffing, password spraying and token theft all leave traces in identity logs. The defender's job is to collect those logs and know normal patterns, not to reproduce the attacks.

Credential stuffing tries leaked username and password pairs across many accounts; password spraying tries a few common passwords against many accounts; token theft reuses a session token without needing the password at all. Each pattern looks different in logs, and detections are built from those defensive views using synthetic data rather than from live attempts.

19.7 Case

After the incident, Lindqvist offers customers optional MFA and alerts on address changes immediately after a login from a new network.

Optional MFA protects customers who choose it; the address-change alert protects everyone, because a change of delivery address is often what an attacker wants after entering an account. The alert combines two signals, a new network and a sensitive change, though its first week shows how often honest customers who move house also match both. The security team plans to review uptake of MFA after six months. Customers are told how to enable it.

Worked example

Amara designs a rule: "address change within 10 minutes of a successful login from a network not seen for that customer in 90 days". In monitor-only mode it fires 12 times in a week; 11 are customers who moved house and logged in from a new home network. She adds a customer email confirmation step for such changes instead of an analyst alert, keeping the alert only when the confirmation fails.

Synthetic case. Rules and counts are invented.

Errors and limits

Identity logs from external providers may arrive late or lack fields; check delivery times.

Exercises

EX055 — Why identity logs. Why are authentication logs among the most valuable SOC data? Rubric: 3 = attacks often use valid credentials; logs show their use; 2 = partial; 1 = vague; 0 = none.
EX056 — MFA signals. Give two MFA-related detection signals. Rubric: 3 = repeated denied prompts; new MFA device; 2 = one; 1 = vague; 0 = none.
EX057 — Confirmation design. How did Amara reduce noise from the address-change rule? Rubric: 3 = customer email confirmation; alert only on failed confirmation; 2 = partial; 1 = deleted rule; 0 = none.

Synthesis

Identity events and cryptographic tools are central SOC material; design detections around how legitimate users behave.

Continue studying — chapter 19 of 50

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →