How we work
Detection reports. Defense intervenes.
A SIEM tells you something happened. We build the response that acts on it, instead of just logging it.
Typical starting points
- „Our SIEM generates alerts. What happens next depends on who has time right now.“
- „We don't know whether our detection would even see a real attack.“
What we do
A SIEM detects and logs. That's its job, and its limit. Defense is active: an alert is followed by an action. SOAR is the umbrella term for that response, automated wherever possible. Cut the session, lock the account, isolate the system, send anything suspicious to a sandbox instead of the workstation: sandboxing and jailing are active measures, not log entries. And we don't assume detection works just because it's configured. We test it against real attack techniques, not a checklist.
How we start
- Week 1
Intake
Which detection runs in your environment today, which alerts it produces, and what follows them now.
- Weeks 2 to 4
Define the response
Per alert type: which action, automatic or with approval, and who sees it.
- afterward
Test and go live
Test detection against real attack techniques, then activate the response, step by step.
For your IT
SIEM operation and alert triage, isolation of endpoints, locking accounts and sessions, sandboxing and jailing of suspicious processes, perimeter blocklists.
Detection is tested against real attack techniques, not assumed. Results feed back into the rules.
A SIEM detects and logs. Whether an action follows an alert is a different question, and that's answered by the response, not the SIEM.
You decide, per alert type. What runs automatically and what needs approval is agreed together, and every action is logged.
What follows an alert at your company today?
30 minutes. We look at your detection and what follows it today.