Who it is for · How costs are covered · Ways to give back
Objective-Based Penetration Testing & Red Teaming
Testing whether agreed objectives can be reached, and how your organisation responds
We answer ‘would we hold up against a real attack?’ with evidence from actually trying.
We set an objective worth protecting, such as customer data or a core system, and go after it as a real attacker would. It runs as an objective-based penetration test, which shows the path to the objective, or as a red team exercise, which also records how your organisation responds.
❯When a realistic attacker goes after an objective, how does the organisation prevent, detect and respond?
Whether the objective was reached, and where it was noticed and stopped, assessed with a record of every stage.
● Reviewed
Playing the attacker, we move towards the objective within the agreed scope; who in your organisation knows in advance is one of three choices.
When it fits
You don't know whether you'd notice a real attack
You have security tools, monitoring and response procedures, but nothing to show when someone asks ‘would we actually catch it?’
You want to know how far one breach could spread
If one staff PC or account were compromised, would it spread across the company, and where along the way could it be stopped?
Your yearly tests may not look like a real attacker
A real attacker does not stop at one vulnerability but chains several towards an objective. You want to see that journey, and how you respond along the way.
Leadership wants a test close to the real thing
Your board is asking how well you would hold up against a real attack, or leadership wants a test run like the real thing, without the security team being told.
The SAFE SQUARE approach
We start from the objective
We first set an objective such as ‘can anyone reach customer data?’ and put our effort into the paths that lead there.
Threat analysis to testing, all in-house
Analysing the threats aimed at your organisation and sector, building scenarios from them, and running the test: SAFE SQUARE does all of it itself.
People and premises too
Within the approved scope, phishing and social engineering, the supply chain, wireless and physical access can all be part of the scenario.
Two ways to run it
Objective-based penetration testing
Can an attacker actually reach the objective, and by what path?
Playing the attacker, we chain weaknesses towards the objective and show, with evidence, under which conditions and by which path it was reached, or where the attempt stopped.
What it looks at
Whether the objective can be reached, and by what path
The defence team
Told as much as needed in advance
What you get
The attack path to the objective with evidence, and improvements that break it
Red teaming
Would the organisation notice and stop an attacker going after the objective?
We act as a real attacker going for the objective, and record and assess, stage by stage, when your organisation notices and how it stops and responds.
What it looks at
Whether the objective is reached, and how you prevent, detect and respond
The defence team
Announced, limited or unannounced; the response is observed as it happens
What you get
Attack paths and timeline, and an assessment of the response at each stage
An example red team record: how far the attack got at each stage, and when the organisation noticed, escalated and responded, on one timeline.
To train and fix detection technique by technique together with your defenders, see Purple Teaming & Detection Exercises, part of Security Capability Development for People & AI.
When a supervisor or parent company sets the framework
We run it to that framework's requirements, led by threat intelligence.
We agree with you the objective and scope, and how much your defenders are told in advance.
Prepare the scenario
We prepare realistic attack scenarios for the objective we have set.
Run and record
Playing the attacker, we move towards the objective and record, at each stage, what we did and how the organisation reacted.
Review together
Afterwards we go through the attack record and the response record with the teams involved.
Improve and re-check
We set out what to strengthen and, if you wish, check again after changes are made.
Keeping it safeWhere an attempt could affect operations, we go ahead ready to stop it at once.
What you receive
Attack scenario and timeline
The paths taken, how they unfolded over time, and whether the objective was reached or where the attack was stopped.
Detection and response assessment
What was actually blocked, detected and reported at each stage, and how your organisation responded.
Improvements and follow-up checks
Where detection and response need strengthening, and what to check again after changes are made.
A sample objective-based testA fictional example, written for illustration.
Objective
Can one staff PC lead all the way to the customer database?
Starting point: one ordinary staff PC · Defenders: only the head of security and the approver know in advance
Stage
Result
Evidence
From the staff PC to the business servers
Got through
The business servers’ admin pages were open to staff PCs on the same office network.
From a business server to admin rights
Got through
Every server used the same admin account, so rights on one carried straight over to the others.
From admin rights to the customer database
Stopped
The database sat in a separately controlled zone, so even admin rights could not reach it.
Detection along the way
Needs work
Use of admin rights was logged but raised no alert, so nobody noticed while it was happening.
Assessment
The objective was not reached, but one staff PC led to admin rights over every business server.
Where to cut
Open the servers’ admin pages only from the management zone, give each server its own admin account, and alert on any use of admin rights.
The response assessed here is prevention, detection and response in the cyber-attack scenarios set for the test. Whether ransomware could halt your operations and block recovery is examined in Ransomware Resilience Validation.