Practitioner field notes
Practitioner-led writing on threat-model discipline, detection engineering, realistic red teaming, and the operational work required to make red and blue teams genuinely effective together.
Latest essay
The last essay in the identity series ended with a promise: the next thread would cover the joins. This is that essay — why the join between your identity provider and your asset inventory is a maintained artefact with an owner, what happens to an exercise when the join is stale, and why the join work is where a quarterly cadence quietly dies.
Purple Teaming Identity Detection Engineering Programme Operations
Archive
The first three essays in this thread built the framework. The fourth is the one the framework was for: what happens when the same exercise runs four quarters in a row in the same environment, against the same boundary, with the previous gap list as its scope. This is a longitudinal essay — one anonymised regulated environment, four quarterly runs, the deltas in the gap list, the CDE model, the response time, and the evidence pack. It closes the identity series with the thing the previous essays deferred: a cadence that survives a year.
Purple Teaming Identity PCI Detection Engineering Programme Operations
A generic identity-focused purple team exercise will tell you whether you can detect a credential-driven intrusion. A PCI environment is a different problem. The Cardholder Data Environment is segmented, the QSA is watching, the assessor sign-off is at stake, and the parts of the framework that hold in a flat enterprise are the parts that break first behind a PCI scope. This is the essay on what changes when the perimeter is a regulated one, and why a generic exercise is the wrong shape of test
Detection is half the problem. The other half is what happens in the first hour after the SOC believes the credential is real — the joins, the actions, the order, and the things the playbook never rehearsed. This is the response side of identity-focused purple teaming
Purple Teaming Identity Incident Response Detection Engineering
Identity is the perimeter most attackers now attack first. This is the guide to a purple team exercise that actually tests it: where to look, what to emulate, what to detect, what to measure, and what to do when the exercise finds a real one
An IT tabletop finds a process gap and the team rewrites the runbook. An ICS tabletop finds the same gap and the team can do nothing with it, because the person who would have to act on the gap is two floors down, on a different shift, under a different chain of command.
There is a lot of advice about ICS detection that talks about MODBUS, DNP3, and the protocol layers. This is the part that comes after the protocol talk: what a good detection actually looks like in the SIEM, and what the SOC analyst does with it
Most threat-modelling advice assumes you have weeks, a working relationship with the engineering team, and a system that is stable. None of those apply when you are walking into a new environment on a Tuesday afternoon. Here is the version that does
Most insider-risk programmes are aimed at the wrong target. The detection engineering is theatre. The behavioural analytics are noise. The case management is a black hole. Here is how to build a programme that finds the cases that actually matter
There is one detection rule in my career that genuinely changed how I think about detection fidelity. It was not a clever rule. It was a simple rule. The simplicity is what taught me the most. Here is the rule and what it taught me
The CISO job description reads like a strategy role. The actual job is mostly operational. Here is what a competent CISO does on a typical Tuesday afternoon, and what the things look like in practice
Most detection engineer hiring fails because the job description is wrong. Here is what to actually look for, what to test in the interview, and the most common mistakes programmes make on the first hire
Most purple team advice is written for teams that have done several. Here is the version for the team that is about to do their first one, in order, with the parts that most programmes get wrong
Most tabletops are theatre. A senior person reads a scenario, the room talks through what they would do, nobody changes anything, and the postmortem is a one-pager that says 'we are well prepared.' Here is how to run one that is not theatre
Most 'detection engineering programmes' are not programmes. They are a person with a Sigma rule and a prayer. Here is what a real six-month build looks like, in order, and what each phase actually costs
Threat intelligence is one of the most expensive parts of a security programme and one of the most under-used. Most programmes pay for feeds they do not read, run platforms they do not use, and produce reports that do not change anything. Here is the honest version of the work
There is one engagement in my career that genuinely changed how I think about cybersecurity risk. It was not the most sophisticated operation I have run. It was not the most expensive. It was the one that taught me the most. Here is what it was and what it taught me
Most red team reports are unreadable. The good ones are gold. Here is what makes the difference, in order, with the parts that most red teamers get wrong
The job description for a detection engineer reads like a software engineer with a security focus. The actual job is more like an editor at a small newspaper. Here is what the work looks like when the title is right and the work is also right
Every detection engineer has been told to build a baseline. Almost nobody has been given a clear answer about what a baseline actually is, what data it needs, or how it connects to the rules the SOC actually runs. Here is the honest version of the work
Most purple team advice is written for a team of three. If you scale to twenty, the bottlenecks move, the failure modes change, and the programme either matures or quietly dies on contact with reality. Here is what shifts, and what does not
You paid €80,000 for a \"red team engagement.\" The report arrived with 47 findings, a 12-page executive summary, and a heat map of your network that looked like something out of a disaster movie
You ran a three-week purple team exercise. Your team worked hard. The red team executed a realistic adversary emulation. Your blue team detected some of it, missed most of it, and the gaps are clear. The debrief went…
Volt Typhoon maintained access to critical infrastructure networks in the United States for at least five years. Microsoft, Mandiant, and the Five Eyes governments published the technical details in 2024. The…
Your insider threat programme is aimed at the wrong target
If you run enough OT pen tests, you start to notice a pattern. The report arrives, the client is confused, and the findings have a peculiar quality: technically correct, operationally impossible to remediate, and…
I keep hearing the same thing in conversations about operational technology security
Most red team engagements produce an impressive document and a set of \"critical findings\" that the security team could have predicted before the first phishing email was sent
You've got a red team and a blue team. They hate each other
Red team comes in on Monday. They've got a scope, a timeline, and a list of techniques to test. By Friday, they've \"successfully executed\" initial access, lateral movement, persistence, and exfiltration
I walked into a SOC last month where they'd deployed 847 Sigma rules
You ran a purple team exercise last week. Your red team executed a flawless attack chain: initial access via phishing, lateral movement via Kerberos relay, privilege escalation, and data exfiltration. Picture perfect