Hardening what we run
Exposure, access and recovery on a system we built or operate, fixed in the order consequence dictates rather than the order a severity label suggests.
the business problem
Most breaches are not clever.
They are a known weakness in something ordinary that nobody had a reason to look at, reached through a door left open for a good reason years ago and never closed.
The organisations this happens to are rarely careless. They are busy, and security is the work that never announces its own urgency until the morning it does.
What makes it worse is that most security reports are unusable. Forty findings with no ranking get read once and filed, and the next report is discounted before it arrives.
what we provide
- No port open on the origin server: traffic reaches it through a tunnel the server opens outward
- TLS everywhere, with certificate expiry watched rather than assumed
- Access and accounts reviewed, including the ones nobody remembers creating
- Secrets kept out of the repository and out of shell history
- Backups that somebody has actually restored from
- Dependencies and base images patched on a schedule rather than after an incident
typical engagements
Access review
Who can reach what, which accounts are still live, and which of them should not be.
Exposure review
What is reachable from outside on something we delivered, and what it would cost if somebody used it.
how we approach it
A finding is only useful if it comes with a ranking.
We report what we found in the order it matters: what is exposed now, what it would cost the business if it were used, and what to do first. A list without that ordering is a document rather than a plan.
We will tell you when something is fine. Manufacturing urgency to justify a fee teaches you to discount the next warning, which is worse than never having been warned.
We fix rather than report. A finding handed over as a list leaves you with work and no evidence it was ever done, and we are the ones operating the system afterwards.
reference architecture
Where we look
A reference model rather than any client's system. Exposure is usually at a boundary, and these are the boundaries worth checking first.
- 01
Perimeter
What is reachable from outside, intentionally or otherwise, including the things exposed for a demo two years ago.
- 02
Identity and access
Who can get in, how they prove it, and which accounts still exist for people who left.
- 03
Application
The software itself and its dependencies, including the libraries nobody has updated because nothing broke.
- 04
Data
Where it rests, how it moves, whether it is encrypted, and how long it is kept after it stops being needed.
- 05
Recovery
What happens after a bad day. Backups nobody has restored from are a plan rather than a capability.
technologies
- Cloudflare Tunnel
- Let's Encrypt
- Docker
- PostgreSQL
questions
- Is this a separate purchase?
- No. It runs through the work rather than being sold after it. A system handed over with its exposure unexamined is not finished.
- How long does it take?
- It depends entirely on what is there, and we will not know until we have looked. We would rather say that than give you a number we would have to walk back.
- What if you find something serious?
- You hear about it the day we find it, not in a report at the end. Then we agree what to fix first, by consequence rather than by severity label.
- Do we need this if we are small?
- Being small changes what is worth doing, not whether it is worth doing. An expired certificate takes a site down whatever its size, and most of what matters here costs attention rather than money.
often runs with
Bring us the problem.
We start with a working session on your actual operation, not a generic pitch. You leave it knowing what is happening, what is worth fixing first, and what the path forward looks like.