SSQ.AISSQ.AI
English
help!

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

agreed objective, scope, rules Objective stopped Who knows in advance aware Announced Limited Unannounced
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
Illustration ATTACK Attack side RESPONSE Response side Initial access Moving inside Critical system reached time to detect to escalate to respond no alert First detection Escalation Contain, recover
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.

How it runs

  1. Agree objectives and conditions

    We agree with you the objective and scope, and how much your defenders are told in advance.

  2. Prepare the scenario

    We prepare realistic attack scenarios for the objective we have set.

  3. Run and record

    Playing the attacker, we move towards the objective and record, at each stage, what we did and how the organisation reacted.

  4. Review together

    Afterwards we go through the attack record and the response record with the teams involved.

  5. 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

StageResultEvidence
From the staff PC to the business serversGot throughThe business servers’ admin pages were open to staff PCs on the same office network.
From a business server to admin rightsGot throughEvery server used the same admin account, so rights on one carried straight over to the others.
From admin rights to the customer databaseStoppedThe database sat in a separately controlled zone, so even admin rights could not reach it.
Detection along the wayNeeds workUse 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.

Related research: Offensive Engineering (EXPLOIT) — We research ways to analyse and verify vulnerabilities and their impact from an attacker's perspective.