Chapter 34 — Security operations and blue team: integration
Lesson map
Lesson 34 published. Map, example, EX100.
flowchart TD
N0["Learning outcomes"]
N1["34.1 Why integration matters"]
N2["34.2 IT service management"]
N3["34.3 Identity platform"]
N4["34.4 Customer service"]
N5["34.5 Interface contracts"]
N6["34.6 Failure handling"]
N7["34.7 Testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX100"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["34.1 Why integration matters"]
N2["34.2 IT service management"]
N3["34.3 Identity platform"]
N4["34.4 Customer service"]
N5["34.5 Interface contracts"]
N6["34.6 Failure handling"]
N7["34.7 Testing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX100"]
[Learning outcomes]
|
v
[34.1 Why integration matters]
|
v
[34.2 IT service management]
|
v
[34.3 Identity platform]
|
v
[34.4 Customer service]
|
v
[34.5 Interface contracts]
|
v
[34.6 Failure handling]
|
v
[34.7 Testing]
|
v
[Worked example] --> [Exercise EX100]
Learning outcomes
You will (1) integrate the SOC with IT service management, identity and customer service systems; (2) design reliable interfaces and data exchanges; (3) handle integration failures; (4) test integrations end to end.
34.1 Why integration matters
A detection is only useful if its result reaches the people and systems that act. The possible-takeover alert must reach the case system, the customer service queue and the identity platform that holds accounts.
An alert sitting in the SIEM helps nobody until an analyst acts on it, a customer service agent knows what to tell the customer, and the identity platform actually blocks the account. Each handover is a point where information can be lost or delayed. Integration design maps every handover, including what data must pass across it and how quickly.
34.2 IT service management
Alerts that need IT action, such as fixing a log feed, become tickets in the IT service system with agreed priority mapping: SOC "high" means IT "P2", with a four-hour response.
Without an agreed mapping, a SOC 'high' might land in IT's queue as a routine request and wait days. The mapping translates urgency into terms the receiving team already uses. Four hours is agreed with IT as realistic for their staffing. Tickets carry a link back to the SOC case, so both teams can follow progress.
34.3 Identity platform
The automation calls the customer identity platform's interface to place holds and invalidate sessions. The interface uses a dedicated service account with only those permissions, and every call is logged.
A dedicated account with only hold and invalidate permissions limits damage if the automation is misused or compromised: it cannot read customer data or change passwords. Logging every call creates an audit trail showing which accounts were held, when and by which alert. Those logs are themselves monitored for unusual volumes.
34.4 Customer service
Customer service sees a simplified view: "account on security hold, reason: suspicious login, contact customer by registered phone". They do not see raw logs.
Raw logs contain details that customer service does not need and could misread or disclose. The simplified view gives exactly what an agent needs to act: that the account is held, why in plain terms, and how to contact the customer safely. Using the registered phone number guards against an attacker who changed the email address.
34.5 Interface contracts
Each integration has a contract: data fields, formats, rate limits, error codes and owner. Contracts prevent silent breakage when one side changes.
Rate limits matter because the automation might call the identity platform many times during a large incident. Error codes let the automation tell 'account not found' from 'platform overloaded'. Owners on both sides are notified of planned changes. Contracts are stored with the integration code and tested, so a breaking change shows up before production. Version numbers mark each contract revision.
34.6 Failure handling
If the identity platform does not respond, the automation retries twice, then raises a high-priority alert for manual action. It never assumes success.
Assuming success when the platform does not answer could leave a compromised account active while the SOC believes it is held. Two retries cover brief network hiccups without delaying too long. The manual alert gives an analyst the details needed to place the hold by hand through the platform's console, and the case records which path was used.
34.7 Testing
Integration tests run monthly with a synthetic test customer account reserved for this purpose.
A reserved test account behaves like a real customer but belongs to no one, so holds and session invalidation can be exercised safely. Monthly testing catches changes on the identity platform's side, such as a renamed field or a revoked permission. Test results are logged and failures open a ticket with the integration owner. A test that leaves the reserved account on hold is itself a failure, so the test ends by releasing the hold and checking that the account works normally again.
Ownership of integrations
Each integration has an owner on both sides who is told before changes.
Worked example
The first monthly test fails: the hold is placed but the customer service queue never receives the case, because a firewall change blocked the SOC's connection to the service system. The failure-handling path alerts the on-call engineer, who fixes the rule; the test is re-run and passes.
Synthetic case. Systems and tests are invented.
Errors and limits
Integrations multiply dependencies; each one is a new place to fail.
Exercises
- EX100 — Priority mapping. Why map SOC priorities to IT priorities explicitly? Rubric: 3 = shared meaning and response times across teams; 2 = partial; 1 = style; 0 = none.
- EX101 — Least-privilege account. How is the identity interface account limited? Rubric: 3 = only hold and invalidate permissions; all calls logged; 2 = partial; 1 = admin account; 0 = none.
- EX102 — Test failure. What did the first integration test reveal? Rubric: 3 = firewall change blocked case delivery; failure path alerted; fixed; 2 = partial; 1 = vague; 0 = none.
Synthesis
Integrations carry detections to action; contracts, least privilege, failure handling and regular tests keep them working.
Continue studying — chapter 34 of 50
← Chapter 33 (draft) · Course chapter index · Chapter 35 (draft) →