Threat-Led Penetration Testing (TLPT)
Red team testing led by threat intelligence
We test detection and response against the threats actually aimed at your organisation and sector.
Threat analysis becomes scenarios, the scenarios are run as a controlled red team exercise, and we review the detection and response results with you.
If the attackers relevant to us came for real, how would the organisation respond?
For each scenario: whether the objective was reached, and when you noticed and how you responded, with the evidence.
Expert reviewed
When it fits
- A supervisor or parent company has asked for testing under its framework
We start from the framework's requirements and prepare the threat analysis and the test to meet them.
- You are worried about the groups that target your sector
You want to know whether your defences hold against the methods actually used by attackers who have gone after your sector.
- You want threat findings to lead into a real test
The signs and attacker behaviour found in a threat investigation or exposure analysis become the basis of a real response test. Exposure Intelligence
The SAFE SQUARE approach
Analysis to review, all in-house
SAFE SQUARE carries out the threat analysis, the scenario design, the red team exercise and the review itself, so the evidence behind the analysis carries straight through to the test and its results.
Confirmed exposure goes into the scenarios
Where our exposure intelligence has already mapped your attack surface or found signs of leaks and impersonation, the scenarios are built on top of them.
Real, but under control
It runs as a real attacker would, kept under control within the set scope so that it can stop at any moment.
When a framework applies
Frameworks such as TIBER-EU, the UK's CBEST and the EU's DORA set out TLPT, and a supervisor or parent company may have a framework of its own. TIBER-EU, for example, is a controlled red-teaming framework that uses tailored threat intelligence to test people, processes and technology.
Such frameworks set their own roles, controls and reporting requirements. We confirm the requirements before starting and, in line with them, state clearly which part SAFE SQUARE takes on. Recognition under the framework and supervisory judgement follow each body's own process.
How it runs
Scope and framework
We agree targets and objectives, whether a framework applies, and which part of it SAFE SQUARE takes on.
Threat and scenario analysis
We analyse the threat actors and methods relevant to your organisation and sector, along with your attack surface and leaked information, and set them out as scenarios and objectives, recording where the evidence comes from and its limits.
Test design
From those scenarios we set how the red team exercise will run, with its safety and stop criteria.
Controlled run
The red team exercise runs within the set scope and controls, and prevention, detection and response are recorded at each stage.
Review and improve
We review the results with the teams involved and agree what to improve.
What you receive
Threat basis
Which threat actors and methods the scenarios were built on, with the sources, timing and limits of that information.
Detection and response record
What was blocked, detected and reported at each stage, and how the organisation responded.
Improvements and follow-up checks
What to improve, and what to check again afterwards.
Using the methods of a group known to target the sector, can an attacker reach operator rights on the payment system?
Basis: published incidents in the sector, signs of leaked staff accounts, staff details visible from outside
| Stage | Response | Evidence |
|---|---|---|
| Way in: tailored phishing of staff | Missed | Some of the phishing emails were filtered, but one person entered their login details, and the alert on that login went unanswered because nobody was responsible for checking it. |
| Spreading inside | Late | The monitoring team detected and reported it four hours later, but with no first action defined, containment took a day. |
| Objective: payment operator rights | Stopped | Operator rights were protected by a separate approval step, so the objective was not reached. |
- Assessment
- The objective held, but the first alert went unchecked and the first action after detection came late.
- Improvements
- Name who checks suspicious login alerts and on what basis, and write the first action on detection into the response procedure. Afterwards, the same stages of the scenario are tested again.
The principles every engagement follows, safe conduct and stop conditions, facts kept apart from assumptions, and how material is kept and destroyed, are set out under How we work.