Modern SOC work is not limited by data—it’s limited by the friction of collecting it. This post shows a local-first workflow that lets you investigate Microsoft Sentinel incidents from inside VS Code using GitHub Copilot Chat for reasoning and a small, deterministic MCP toolset for evidence retrieval and (optionally) approval-gated writeback.
What you’ll take away:
Sentinel triage is powerful but fragmented: you jump between the portal, KQL, entity pivots, and case notes just to answer “what happened?” The goal here is to collapse that into a single, repeatable loop inside the editor.
A local TypeScript MCP server exposes a handful of triage tools to Copilot Chat in VS Code. Reads come from Sentinel + Log Analytics; writes (incident comments) are optional and require explicit approval.
MCP is useful here because it separates reasoning from execution: Copilot can decide what to do, but only the MCP server can do it—and only through tools you explicitly define and can audit.
sentinel-triage-local Investigate Sentinel incident 1478 end to end in workspace Subscription ID/Resource Group/Workspace Name. Resolve the incident ID first, collect underlying alerts and entities, enrich with AzureActivity and TI, determine whether the activity is malicious or benign, and return:
1. Investigation summary
2. Key evidence
3. Entity analysis
4. TI enrichment result
5. Risk assessment
6. Recommended disposition
7. Final incident comment draft
Rules:
- Use tool output only, no guessing.
- If alert/entity subresource APIs fail, pivot to KQL and continue.
- Do not submit the comment unless I explicitly say: APPROVE COMMENT.
Resolve the human-friendly incident number to the Sentinel incident resource ID, then capture the metadata you need to drive every later pivot.
Incident numbers are convenient for analysts, but the actual investigation flow depends on the underlying incident resource ID. Resolving that first gives the workflow a concrete anchor for:
This gives you the stable identifiers (and the URL) needed to retrieve alerts, entities, and supporting logs.
Pull the alerts behind the incident and the entities they reference. When the incident subresource APIs behave, this is the fastest way to assemble the working set.
In the ideal path, the agent can call the incident alert and entity subresources directly. That gives fast access to:
In real environments, the incident subresource APIs for alerts/entities are not always dependable. When they fail, the workflow switches to Log Analytics and reconstructs the same evidence via KQL—so the investigation continues.
In the incidents I tested, AzureActivity was the fastest way to classify “suspicious deployment” alerts: it tells you who did the action, what operation ran, and whether it succeeded.
The evidence showed:
That pattern typically points to automation (service principal + policy-driven deployment) failing due to a bad template—not an interactive attacker.
Enrich observables against TI, but treat it as corroboration: a hit is not proof, and a miss is not a clean bill of health. In my test runs, TI mainly helped refine confidence after AzureActivity and alert evidence established the likely story.
Once the tools return results, Copilot’s job is synthesis: turn structured evidence into a short narrative an analyst can paste into the case.
Incident comment written back automatically (after approval) (screenshot):
The agent can draft a comment automatically, but it cannot change incident state unless the analyst explicitly approves. That boundary is what makes the workflow usable in real operations.
After approval, the tool submits the drafted comment directly to the Sentinel incident so the portal reflects the same evidence-backed narrative.
AI is most useful in a SOC when it is constrained: deterministic tools fetch the evidence, the model synthesizes it, and humans keep control of state changes. A local Copilot + MCP workflow hits that sweet spot—faster triage for the SOC analysts.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。