CASE STUDY · MANAGED DETECTION & RESPONSE (MDR)
Cutting incident response time from hours to minutes for a manufacturer.
- 4 hoursResponse time down from about 4 hours to 15 minutes in tested scenarios
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market manufacturer. Name withheld under confidentiality.
Monitoring across endpoints and cloud, response playbooks, escalation paths and 24/7 analyst coverage.
- 1When a security alert fired, it took about 4 hours to reach action.
- 2The alert went to a shared mailbox.
- 3Someone had to notice it, find out whether it mattered, work out who owned the affected machine and decide what to do.
- 4There was no after-hours cover at all.
- 5A plant that runs around the clock was relying on an office-hours security process.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01During testing, a scenario exposed a gap in the escalation path
The analyst correctly spotted the simulated threat within minutes, then spent a long time trying to reach the person who could approve action. The listed contact was on leave, and no deputy was named.
- PROBLEM 02The detection worked
The process did not. We added a deputy for every role, a clear order of calls, and a rule that if nobody answered within a set time, the analyst could take the lowest-impact containing step. We then ran the scenario again and timed it.
- PROBLEM 03A weakness like that is far better found in a test than at 3 a.m. during a real event
- PROBLEM 04In the first weeks, a group of alerts came from a legacy engineering tool that talked to machines in unusual ways
Analysts rightly treated them with suspicion, but they were normal. We sat with the plant engineers, documented the tool's behaviour and wrote narrow rules so that only unexpected use would alert. We kept the rule scope tight, because a broad exception would have given an attacker a place to hide.
03 · THE PROCESS
How we ran it.
We ran the engagement in four stages.
- 01Scoping
we listed the endpoints, servers and cloud accounts, and the systems that could not be taken offline without a plant impact. That list shaped every playbook.
- 02Onboarding and baselining
agents and log sources were connected, and we spent time learning what normal looked like on the factory network and in the office.
- 03Playbooks and escalation
we wrote response steps for the likely incidents, and agreed with the client who could approve which action, at any hour.
- 04Validation
we ran tested scenarios and timed the response from alert to action.
A weekly call with the IT lead covered tuning, open questions and anything odd we had seen.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Every alert has an owner and a defined path, whatever the hour.
- NOW 02
Escalation contacts and deputies are reviewed regularly.
- NOW 03
The plant team knows which systems are "call first", and why.
- NOW 04
Playbooks are rehearsed with simulated events on a schedule.
- 4 hours
Response time down from about 4 hours to 15 minutes in tested scenarios
After-hours coverage in place
05 · WHAT WE BUILT
How it works.
- Endpoint telemetry, cloud audit logs and identity events fed one monitoring platform.
- Analysts triaged alerts around the clock and investigated those that looked real.
- Detection rules were tuned against the client's normal behaviour, such as scheduled maintenance tools and engineering software that would otherwise look suspicious.
- Playbooks covered isolating a device, disabling an account and blocking a network address.
- Because some machines supported production, we marked them as "call first".
- An analyst could not isolate those without a named contact approving.
- What went wrong, part two
- In the first weeks, a group of alerts came from a legacy engineering tool that talked to machines in unusual ways. Analysts rightly treated them with suspicion, but they were normal. We sat with the plant engineers, documented the tool's behaviour and wrote narrow rules so that only unexpected use would alert. We kept the rule scope tight, because a broad exception would have given an attacker a place to hide.
- Handover and reporting
- The client's IT lead received a short summary after each real incident and a monthly view of trends. Playbooks and contact lists live in a document the client owns.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- When a security alert fired, it took about 4 hours to reach action. The alert went to a shared mailbox. Someone had to notice it, find out whether it mattered, work out who owned the affected machine and decide what to do. There was no after-hours cover at all. A plant that runs around the clock was relying on an office-hours security process. Leadership knew the gap was dangerous, but had no security staff to close it.
- What did Brandsmashers build?
- Monitoring across endpoints and cloud, response playbooks, escalation paths and 24/7 analyst coverage.
- How was the work run?
- We ran the engagement in four stages.
- What were the results?
- Response time down from about 4 hours to 15 minutes in tested scenarios; after-hours coverage in place.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
