Chapter 19 — Identity and cryptography
Lesson map
Lesson 19 published. Map, example, EX055.
flowchart TD
N0["Learning outcomes"]
N1["19.1 Partner identity"]
N2["19.2 Signatures"]
N3["19.3 Key life cycle"]
N4["19.4 Analyst access"]
N5["19.5 Multi-factor"]
N6["Practice note — Break-glass access"]
N7["Synthesis"]
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 Partner identity"]
N2["19.2 Signatures"]
N3["19.3 Key life cycle"]
N4["19.4 Analyst access"]
N5["19.5 Multi-factor"]
N6["Practice note — Break-glass access"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]
[Learning outcomes]
|
v
[19.1 Partner identity]
|
v
[19.2 Signatures]
|
v
[19.3 Key life cycle]
|
v
[19.4 Analyst access]
|
v
[19.5 Multi-factor]
|
v
[Practice note — Break-glass access]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX055]
Learning outcomes
You will (1) authenticate partners and analysts with appropriate strength; (2) use digital signatures to protect feed integrity; (3) manage keys and certificates over their life cycle; (4) apply role-based access to TLP-labelled content.
19.1 Partner identity
TAXII 2.1 servers authenticate clients, typically with HTTP authentication over TLS or client certificates. Mutual TLS lets both sides prove identity. Credentials are per-partner so that one can be revoked without affecting others.
Kofi keeps a register of partner credentials with their expiry dates and owners. When a partner's staff member leaves, the partner can ask for the credential to be replaced without stopping other feeds. Shared credentials across partners would make that impossible and would hide which partner made a given request.
19.2 Signatures
A signature over an exported bundle lets the recipient verify that it came from Lantern and was not altered. Hash first (SHA-256), sign the hash with a private key kept in hardware, publish the public key through a trusted channel.
If verification fails, the bundle is set aside and both sides are told, because either the content changed in transit or the wrong key is in use. Kofi's export job signs automatically, and the public key's fingerprint is read aloud on a call with each new partner.
19.3 Key life cycle
Generate, distribute, use, rotate, revoke, destroy. Certificates expire; expired certificates on a TAXII client stop collection at the worst moment. Calendar and monitor them.
The worked example shows the cost of skipping this. Kofi's register lists every certificate and key with its expiry, owner and replacement steps, and alerts arrive weeks in advance. Revocation is tested once a year with a test certificate, so the team knows the steps work before they are needed. Destroyed keys are recorded with the date and method, which an auditor may ask to see.
19.4 Analyst access
Roles map to TLP: all analysts read CLEAR and GREEN; the SOC team reads AMBER; AMBER+STRICT content is limited to BEN only; RED reports go to named individuals listed on each report. Access decisions are logged.
The mapping lives in the identity system, not in Lantern's code, so changing who may read AMBER content is an access change with its own approval. Kofi reviews group membership monthly with the SOC lead. For RED reports, Lantern checks the recipient list on each report rather than a group, which matches the label's meaning of named individuals only.
19.5 Multi-factor
Analyst access to Lantern requires MFA. ATT&CK T1078 Valid Accounts describes adversaries using legitimate credentials; MFA raises the cost.
A stolen password alone then does not open the platform. Kofi chose hardware keys for analysts with access to AMBER and RED material, because codes sent by text message can be intercepted or redirected. Service accounts cannot use a second factor in the same way, so they rely on certificates and network restrictions instead. Sign-ins from new devices are logged and reviewed weekly.
Practice note — Break-glass access
If the identity provider fails during an incident, analysts still need Lantern. A sealed break-glass account with a long random password, stored offline and logged on use, provides access. Its use triggers an alert and a review afterwards so that emergency access never becomes routine. Each break-glass use is reviewed within one working day by someone other than the user.
Worked example
A partner's client certificate expires on a Sunday, halting their feed. Kofi adds certificate-expiry monitoring with 30-, 14- and 3-day alerts and documents a rotation runbook with the partner.
Synthetic case. The expiry incident is invented.
Errors and limits
Signatures prove origin and integrity, not truth of the content. Shared team accounts defeat access logs.
Exercises
- EX055 — Signature limit. What does a valid signature on a feed prove, and what does it not? Rubric: 3 = origin/integrity; not accuracy of indicators; 2 = one half; 1 = proves truth; 0 = none.
- EX056 — RED access. Who may read a TLP:RED report in Lantern? Rubric: 3 = only named recipients listed on the report; 2 = small team; 1 = all SOC; 0 = none.
- EX057 — Expiry alerts. Propose an alert schedule for certificate expiry. Rubric: 3 = multiple lead times (e.g. 30/14/3 days) + owner; 2 = one alert; 1 = vague; 0 = none.
Synthesis
Authenticate per partner, sign exports, manage key life cycles, and map roles to TLP with logged access.
Continue studying — chapter 19 of 50
← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →