argus part 1: the overseer idea
why i built an enterprise security overseer to bridge the gap between raw telemetry, itsm workflows, and human action.
security operations centres (soc) have a communication problem. it is not that they do not talk enough, it is that they talk in the wrong way, at the wrong time, and often to the wrong people.
as a security engineering manager, i have spent years watching high-fidelity alerts get buried in email chains or lost in the infinite scroll of a general chat channel. when an incident occurs, the "update gap" between technical telemetry, itsm workflows, and the human response is where risk lives.
i built argus to bridge this gap.
the problem: fragmented workflows
most security tools are designed for data collection, not for an end-to-end human workflow. you get a notification, you click a link, you log into a portal, you find the right screen, and only then do you start work. then you have to log into an itsm tool to create a ticket. then you have to manually update your team.
this "friction" is catastrophe during a major incident. i noticed several recurring pain points:
- context switching: engineers lose time jumping between sentinel, xdr portals, itsm tools, and communication platforms.
- fragmented state: the "truth" of an incident is split between an itsm ticket, a sentinel alert, and a teams chat.
- manual overhead: logging tickets, updating statuses, and triggering playbooks usually requires manual intervention across multiple dashboards.
the idea: the enterprise overseer
the concept for argus was to create an automated enterprise overseer that sits directly over the security and itsm stack. instead of just being another bot that "posts to a channel," i wanted an omniscient layer that transforms raw telemetry into a unified, interactive workspace.
the core mission: deliver a highly tailored, real-time security operations hub directly into the place where engineers already live: microsoft teams.
what does it actually do?
argus is an event-driven router and orchestrator. it does not just notify; it manages the lifecycle of an incident:
- itsm integration: it automatically logs tickets, monitors for updates via callbacks, and allows engineers to query itsm data directly from teams.
- interactive command & control: it uses adaptive cards to turn a notification into a functional dashboard where engineers can trigger playbooks and automation without leaving the chat.
- enterprise-grade rbac: built with strict role-based access control, it manages permissions for both internal and federated teams users.
- hardened security: it leverages azure key vault for all api authentication and secret management, ensuring that automation does not come at the cost of security.
why "argus"?
in mythology, argus panoptes was an all-seeing giant with a hundred eyes. it is a fitting name for a system designed to provide total visibility and control across a complex enterprise estate.
this is the first post in a series where i will break down how i built it. in part 2, i will discuss the architectural decision-making process and why a custom azure bot was the right tool for this level of orchestration.