The county wants one playbook to disable an account in IAM, open a ticket, and isolate a host in EDR during an incident. What enables that cross-tool workflow?
Select an answer to reveal the explanation.
Short Explanation
APIs are the translators that let IAM, ticketing, and EDR join the same incident dance—one playbook, three tools, no sticky-note relay.
Full Explanation
A single incident playbook that disables an account in IAM, opens a ticket, and isolates a host in EDR requires machine-to-machine orchestration. API integrations provide the programmatic interfaces that let automation engines invoke those actions across identity, ticketing, and endpoint platforms in one coordinated workflow. For a county SOC, APIs are what turn a written playbook into consistent, auditable cross-tool response instead of a slow human relay between consoles.
Verbal phone trees with no system integration are slow, error-prone, and hard to audit under incident pressure. Air-gapping every security tool so none can exchange data prevents the very orchestration the county wants (air gaps belong in carefully chosen OT/safety contexts, not as a blanket ban on SOC tool integration). Replacing APIs with handwritten sticky notes on the NOC glass is non-scalable theater without authoritative system updates.
Exam caveat: APIs need authentication, least-privilege service principals, rate limits, and logging—compromised orchestration credentials can become a powerful attack path. Prefer approved SOAR/automation platforms over ad-hoc scripts with standing admin keys.
Operational check: implement a controlled playbook using IAM, ITSM, and EDR APIs with scoped tokens, test account disable + ticket + isolation on a lab host, verify each action is logged, and restrict who can edit production playbooks that call those municipal APIs.