Chapter 21 — Security operations and blue team: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Integration points"]
N2["21.2 Escalation per client"]
N3["21.3 Contractor tickets"]
N4["21.4 Reliability"]
N5["21.5 Message content"]
N6["21.6 Testing"]
N7["21.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Integration points"]
N2["21.2 Escalation per client"]
N3["21.3 Contractor tickets"]
N4["21.4 Reliability"]
N5["21.5 Message content"]
N6["21.6 Testing"]
N7["21.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Integration points]
|
v
[21.2 Escalation per client]
|
v
[21.3 Contractor tickets]
|
v
[21.4 Reliability]
|
v
[21.5 Message content]
|
v
[21.6 Testing]
|
v
[21.7 Case]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) integrate SOC alerts with client contacts and IT contractors; (2) design escalation paths per client; (3) use ticketing and messaging integrations reliably; (4) handle integration failures.
21.1 Integration points
Copperleaf's case system connects to phone paging for on-call analysts, email and SMS to client contacts, and the IT contractors' ticket systems for follow-up work.
Each integration carries an alert to a person who can act on it. Paging reaches the on-call analyst, messages reach the client contacts, and tickets give the contractor a record of the work they are asked to do. On the incident night the SMS integration was the one that failed, which is why the fallbacks below exist.
21.2 Escalation per client
Each client profile lists who to contact for which severity and when. BrightSmile: high severity at night — office manager by phone, then IT contractor; medium — email next business day.
Matching contacts to severity avoids two opposite mistakes: waking the office manager for a medium alert that can wait until morning, and emailing her about a high-severity incident she would not see until the next day. The order matters as well, since at night BrightSmile wants the manager called first and the contractor second.
21.3 Contractor tickets
When a fix needs the IT contractor, Copperleaf opens a ticket in the contractor's system automatically with the details and links back to the case.
For BrightSmile, the ticket for closing the 3389 forward and setting up the VPN would carry the case link, so the contractor sees the evidence and Copperleaf sees when the work was done. Automatic tickets also remove the step where an analyst retypes the details, which is where host names and times get copied wrongly. The ticket status flows back to the case, so the analyst can close the case only after the contractor marks the work done.
21.4 Reliability
If an integration fails — SMS gateway down, contractor ticket rejected — the case system flags the failure and the analyst uses the fallback: phone call.
The fallback matters because the case system can report a failed SMS but cannot make the client read it. A phone call either reaches someone or tells the analyst immediately that it did not, which is exactly the information needed to move on to the next contact on the list. The analyst records the fallback call in the case, with the time and who answered, so the failure and its workaround are both visible later.
21.5 Message content
Automated messages are short, plain and never include sensitive data such as patient names; details stay in the secure portal.
An SMS can be read on a lock screen or by a family member, so a message about BrightSmile would say that a high-severity alert needs a call, not which patient records were on the server. The office manager then logs in to the portal or takes the analyst's call to hear the details. The same rule applies to email, which can be forwarded or read on shared clinic PCs where other staff may see it.
21.6 Testing
Integrations are tested monthly with a test alert routed to a test contact.
The test alert travels the same path as a real one, through paging, SMS and email, but goes to a contact set up for testing so no client is disturbed. A failed test then shows the broken link during working hours, when fixing it is easy, rather than at night during an incident. Each test result is recorded with the date, so a failed integration can be traced to the month in which it stopped working.
21.7 Case
During the BrightSmile incident, the automatic SMS to the office manager failed because her number had changed.
The failure was not technical: the gateway sent the message, but to an old number that the client had never updated. Monthly integration tests would not have caught it, because they use a test contact rather than the client's own details. That gap is what the quarterly contact confirmation in the worked example closes. The night analyst recorded the failed SMS in the case at the time, which later made the cause easy to identify during the review.
Language and tone
Night calls to clients start with what is happening and what Copperleaf has done, then what the client needs to decide. Analysts practise a short script so they stay calm and clear even when the client is alarmed or half asleep, and they always confirm the next contact time before ending the call.
Worked example
The night analyst called the backup contact (the IT contractor), who reached the office manager. Afterwards, Copperleaf adds a quarterly contact confirmation step to every client's review and records the failed SMS as an integration issue.
Synthetic case. Integrations and events are invented.
Errors and limits
Integrations depend on details clients forget to update; verify them regularly.
Exercises
- EX061 — Escalation profile. Describe BrightSmile's escalation for high severity at night. Rubric: 3 = office manager by phone, then IT contractor; 2 = partial; 1 = email; 0 = none.
- EX062 — Message safety. What must automated messages avoid? Rubric: 3 = sensitive data like patient names; details in portal; 2 = partial; 1 = vague; 0 = none.
- EX063 — SMS failure. Why did the SMS fail and what changed? Rubric: 3 = number changed; quarterly contact confirmation added; 2 = partial; 1 = vague; 0 = none.
Synthesis
Integrations carry alerts to people who act; test them and keep contact data current.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →