About Defence Lab
an ongoing service, not a series of projects.
We work with growing product companies across the United States, Canada and Europe. Where the tools we needed for that didn’t exist, we built them.
This page is the longer version of that: how an engagement actually runs, the standards it is run against, and what we can and cannot show you.
How we work
four rules the engagements have in common.
Not a philosophy. These are the patterns that repeat across the engagements written up on this site, and they are the part clients actually notice while the work is happening.
Changes land in stages, while the business keeps working
A platform gets replaced in steps rather than over one weekend, and the moment that carries real risk is scheduled for when people are around to watch it.
from the workOne network platform was replaced rather than secured on top of, in stages, so the office kept working throughout. On another site a redundant firewall pair was cut over in daylight carrying 1,310 active connections, and not one user was disconnected.
A control nobody can live with gets reversed, so it has to be usable
Separation and hardening only count if they are still in place months later. The work therefore includes making the everyday things keep working across the new boundaries, deliberately and narrowly.
from the workTwelve networks are still in place at one site because printing, scanning and screen sharing were made to work across them — down to identifying the two non-standard ports one printer needed before scanning worked again.
We remove the cause instead of waiting for a vendor fix
Where a fault is known and the manufacturer’s schedule is not ours, the fault is engineered out and the device is given an automatic response to it.
from the workA firewall leaking 30 to 40 megabytes of memory a day crossed 88 percent after about 25 days and dropped into a protective mode, passing traffic without inspecting it. The fault was removed permanently instead of waited out.
The first site is built as the template for the next one
Configuration is held as templates with the site-specific details kept as variables, and the environment is documented in plain language, so a second location is a repeat rather than a redesign.
from the workOne estate of 24 switches, five wireless networks and twelve segments runs from a single console, and equipment is registered centrally before it ships so it finds its own configuration when powered on.
Published methodology
six frameworks, and what each one is for.
We work to published methodology rather than a house checklist, so the coverage of an engagement can be argued about instead of taken on trust.
NIST CSF 2.0
A governance framework organised around six functions — govern, identify, protect, detect, respond and recover. It gives posture assessments and vCISO work a structure a board or an auditor already recognises, so findings arrive in a shape somebody can act on rather than a list only engineers can read.
PTES
The Penetration Testing Execution Standard: the phases a test is expected to cover, from pre-engagement scoping through exploitation to reporting. It is what makes two tests comparable with each other instead of dependent on who happened to run them.
NIST SP 800-115
NIST’s technical guide to information security testing and assessment. Where PTES sets the phases, this governs the discipline inside them: how a test is planned, how evidence is handled and how results are reported — which is also what makes a result usable afterwards in a forensic or audit context.
OWASP WSTG
The Web Security Testing Guide: what to test in a web application, and how to test it. It turns application coverage into a list that can be checked and argued about, instead of a claim that the application “was tested”.
OWASP Wireless
OWASP’s wireless testing material, covering the Wi-Fi side of an estate: how the network decides who you are, what a guest network exposes, and whether a device that joins can reach anything it should not. It is the framework behind the wireless and guest-access work.
MITRE ATT&CK
A catalogue of the techniques attackers actually use, arranged by stage of an intrusion. Detection and response work is mapped onto it, so “we monitor your environment” becomes a specific list of what would be seen — and, just as usefully, what would not.
A framework says what to cover, not what matters most in your environment. That judgement is made with you, and written down where you can see it.
What we can and can’t show you
we publish the method, not the logos.
Every engagement described on this site is written up with the client anonymised. That is the same discretion your own work would get, and it is why this page names standards and evidence rather than customers.
Six of them are written up in full — the situation as the client found it, what was built, and what changed afterwards, including the parts that were awkward. They are the closest thing to a reference we can publish: read the six engagements.
Engagements are staffed by senior engineers only. What you will not find on this page is a headcount, a client logo or a satisfaction percentage: the engagements above are the evidence we have, and they are anonymous by agreement.
Next step
talk to the people who would do the work.
Tell us what you are protecting and what worries you. One working conversation, no pitch and no deck — and if the answer is that you are fine for now, we will say that too.