Quality & Support
Security measured by
what an attacker reaches
Compliance frameworks tell you what to document, not whether an attacker holding one phished account can reach your customer database in four steps. We work the second question first, then map the answer back to whichever framework you report against.
Overview
Threat modelling, identity hardening and detection engineering that finds real paths in.
Almost every breach we have been called into after the fact followed the same shape: valid credentials, an over-permissioned role, lateral movement nobody had instrumented, and detection that arrived from a third party rather than from the security team. Sophisticated exploits are rare. Identity and visibility failures are not, and they are cheaper to fix.
So the work concentrates there. Threat models built from the architecture as deployed, an identity model where standing privilege is the exception, detection rules written against the MITRE ATT&CK techniques that apply to your estate, and testing that assumes the perimeter is already breached, because in the scenarios that matter it usually is.
We will not tell you that a control set makes you secure. What we can do is measure how long an intrusion survives before detection, how far it can reach before containment, and whether the response works when it runs at 3am with two people awake. Those numbers move under engineering effort. A compliance score largely does not.
- 14 min
- median time to detect an emulated intrusion, from six hours
- 88%
- of standing privileged accounts removed in the first quarter
- 61
- ATT&CK techniques covered by validated detections, from 12
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Threat modelling and architecture review
STRIDE and attack-tree modelling against the design as built, producing a ranked list of attack paths with owners and fixes rather than a diagram with trust boundaries drawn on it.
Identity and privilege hardening
Removing standing administrative access, introducing time-bound elevation, inventorying and rotating service accounts, and phishing-resistant authentication for the accounts that matter most.
Detection engineering
Rules written and tested against ATT&CK techniques relevant to your estate, coverage tracked as a gap map, and every rule validated by an emulated attack rather than by reading its query.
Penetration testing and red teaming
Scoped external and internal testing, assumed-breach exercises and cloud configuration review. Findings arrive with a reproduction path so engineers can confirm the fix themselves.
Application and supply chain security
SAST and dependency scanning tuned to a signal rate developers will act on, secrets detection with automatic revocation, artefact signing and SBOM generation across the build pipelines.
Incident response readiness
Playbooks for the scenarios you are actually likely to face, tabletop exercises with the executives who must make the decisions, and forensic logging retained long enough to reconstruct an intrusion.
Deliverables
What you get
- Threat model with ranked attack paths, owners and remediation dates
- Identity hardening plan covering standing privilege and service accounts
- Detection rule set with an ATT&CK coverage map and validation results
- Penetration test report with reproduction steps and retest results
- Incident response playbooks and tabletop exercise findings
- Control mapping to ISO 27001, SOC 2 or DORA as your reporting requires
Stack
What we build it with
- Microsoft Defender XDR
- CrowdStrike Falcon
- Splunk
- Elastic Security
- Wiz
- Okta
- HashiCorp Vault
- Semgrep
- Burp Suite
- Sigma
- Atomic Red Team
- Trivy
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Attack surface baseline
External exposure, identity inventory and cloud configuration reviewed before any testing, so that the test targets what matters rather than what is easy to scan.
Threat model
Workshops with the engineers who built the systems, producing ranked attack paths. Ranking uses reachability and impact, not a generic severity score from a table.
Test the assumptions
Penetration testing and assumed-breach exercises check whether the modelled paths are real. Some of them are not, and some unmodelled ones turn out to be.
Close and detect
Remediation with the engineering teams, plus a detection rule for every path that cannot be fully closed. Each rule is validated by running the technique against it.
Rehearse the response
Tabletop and live-fire exercises measuring time to detect and time to contain, repeated quarterly so that the numbers can be compared over time.
When this is the wrong engagement
If you need a signed attestation for a customer deadline next month and nothing more, hire an auditor and a compliance automation tool, because this engagement is engineering work and it takes longer.
FAQ
Questions we get asked
- Is a penetration test enough?
A test tells you what was reachable on the days it ran, by the people who ran it, inside the scope you agreed. That is useful and it is not a security programme. The durable work is identity, detection and response speed; a test measures those, it does not create them.
- We need SOC 2 and ISO 27001. Do you handle certification?
We do the engineering and the evidence, and we map controls to the framework so the audit becomes largely a paperwork exercise. The certificate itself is issued by an accredited auditor we do not control, and any firm promising a specific outcome or date is overreaching.
- Should we build a security operations centre or buy managed detection?
Buy first, in almost every case. A round-the-clock rota needs eight to ten analysts before it functions, and most organisations under a few thousand staff cannot keep them busy or retained. Keep detection engineering in-house, since the rules must reflect your own estate.
- How disruptive is removing standing admin access?
Noticeably, for two to four weeks. Elevation requests spike, somebody hits a wall during a live incident, and the exception list needs daily attention at first. We stage it by account class and keep a break-glass path that is monitored and reviewed rather than merely documented.