06 / Discipline
Cybersecurity
The system tested the way an attacker would read it.
Security is a property of the architecture. It is not a product you can install on top of one that does not have it.
The interesting event is the refusal.
An attacker traverses: external surface, application, identity, network, data. Each boundary cleared is a boundary that was permissive. A finding only matters in terms of what it lets someone reach next.
So we test the path rather than the checklist, and we report in the order an attacker would work - not in the order the scanner printed.
What that means in practice
Six things this discipline actually does.
- 01
Penetration testing
Web, API, cloud and internal. Manual work against your actual system, with the reasoning shown rather than a tool's output pasted in.
- 02
Application security
Threat modelling, secure code review, and the design-level fixes that stop a class of bug rather than an instance of one.
- 03
Identity and access
Authentication, authorisation, session handling and privilege boundaries - where the highest-consequence findings usually are.
- 04
Cloud posture
Configuration, network boundaries, secrets handling and blast radius, reviewed against how the system is actually deployed.
- 05
Incident readiness
Detection, logging and a response plan that has been rehearsed, because the first time should not be the real time.
- 06
Remediation support
We stay to help fix it. A report that is handed over and never actioned is an expensive document.
How it runs
Four stages, in this order.
The order is the method. Every stage produces something the next one needs, and skipping one means the stage after it is guessing.
- 01Surface
Map what is reachable
Everything exposed, including the things nobody meant to expose. Most engagements find something here that was not on the asset list.
- 02Traverse
Follow the path inward
Chain findings the way an attacker would. Two medium issues that combine into domain access are not two medium issues.
- 03Report
Order by consequence
What can be reached, from where, and what it would take. Severity that reflects your system rather than a generic score.
- 04Harden
Fix the class, not the case
Design-level changes where possible, then verification that the fix holds under the same test that found it.
Outcomes
What came out of it.
Sample figures from representative engagements. Not a guarantee, and not an average.
- 5
- Trust boundaries testedSurface through to data
- 100%
- Findings retestedAfter remediation, at no extra cost
- 48h
- Critical disclosureReported before the engagement ends
Asked often enough to answer here.
Is this a scan or a manual test?
Manual, with tooling used to cover ground quickly. Anything a scanner can find on its own does not need us to find it.
Do you provide a report we can share with customers?
Yes - a technical report for your engineers and a summary suitable for customers or auditors, with sensitive detail removed.
Can you test a system that is not live yet?
Preferably. Threat modelling during design is the cheapest security work there is, and it is the only kind that can remove a problem rather than patch it.
Rarely on its own