Home / Services / Infrastructure security

SVC/SEC — Infrastructure security

The boring controls are the ones that work.

Almost nothing that goes wrong involves a clever attack. It is an exposed management port, a password reused from a breach, a device nobody patched, or a backup that turns out not to restore. Security work is mostly the discipline of closing those, and then proving they stayed closed.

CAP/ — Capabilities

What we do in this practice.

SEC/HRD

Host & server hardening

Key-only access, no root login, a firewall that is actually closed, unattended security updates, and unused services switched off. Applied deliberately rather than by running a script off the internet.

SEC/IAM

Identity & access

Single sign-on, enforced two-factor, least privilege, and joiner-mover-leaver that actually removes access. Most breaches are a login, not an exploit.

SEC/NET

Network security

Segmentation with default-deny between zones, firewall policy written from intent, and no management interface reachable from the internet.

SEC/RA

Remote access

WireGuard-based mesh tied to your identity provider, replacing VPN appliances and the inbound port they require — which is the class of device that keeps appearing in breach reports.

SEC/SEC

Secrets management

Credentials out of repositories and group chats, injected at deploy time from somewhere with access control and an audit trail. The most common finding when we review an existing setup.

SEC/PATCH

Patching & vulnerability management

Automated OS patching, container image scanning as a release gate, and a defensible position on the findings you choose not to act on.

SEC/RANS

Ransomware resilience

Immutable off-site backups, backup credentials separated from domain accounts, and a tested restore — because recovery is the control that actually decides the outcome.

SEC/OBS

Monitoring & detection

Log collection, uptime and integrity checks, and alerting tuned so a message means somebody needs to act. You cannot respond to what you never see.

PRN/ — Principles

How we approach it.

Verify from outside

What a host believes about its own firewall and what is actually reachable are different claims. Cloud VMs have two independent firewall layers, and container runtimes write rules around one of them — so a port is closed when a scan from elsewhere says it is closed, not when iptables -L looks right.

Assume the perimeter fails

Something will eventually run inside your network with someone else's intent. Segmentation, least privilege and immutable backups are what decide whether that is an incident or a catastrophe. Perimeter-only security has a single point of failure by design.

Controls you can prove

A backup counts once it has been restored. A patch policy counts when you can show what is outstanding. Anything asserted but not evidenced is a belief, and beliefs are what audits and incidents are both very good at testing.

Gates people won't disable

A scanner that fails every build gets bypassed within a fortnight. We block on critical findings that have a fix available and report the rest, because a narrow control that stays enforced beats a broad one that gets switched off.

No security theatre

We removed a cryptographic signing feature from our own invoicing once we established it proved nothing to the people reading it. If a control cannot be verified by whoever it is meant to reassure, it is decoration with a maintenance cost.

Silence means success

Alerting fires on failure only. A channel full of routine green notifications is a channel nobody reads on the day something is actually wrong.

REV/ — Where most people start

The security review.

A structured assessment of what you have, carried out remotely from system access and configuration exports. It stands alone — there is no obligation to do the remediation with us, and the report is written to be handed to whoever does.

Findings are ordered by risk against effort rather than by severity label, because a list sorted by CVSS is a list nobody starts.

You get

An exposure map — what is reachable from the internet, deliberately or otherwise
An access review — who can reach what, and who still has access who shouldn't
Patch and version state — what is out of date, and what is out of support entirely
Backup verification — not whether jobs run, but whether a restore works
Secrets audit — credentials in repositories, chat history and shared documents
A prioritised plan — what to fix this week, this quarter, and what can wait

FAQ/ — Common questions

Questions we get asked.

Do you do penetration testing?

No, and you should be wary of anyone offering both hardening and the test that grades it. We do configuration review, architecture review and exposure assessment — reading how the system is built and finding what is wrong with it. If you need a formal penetration test or a certification audit, engage a specialist firm; we will happily fix what they find.

Can you help us get ISO 27001 or SOC 2?

We can build and document the technical controls those frameworks expect — access control, patching, logging, backup, change management. We are not auditors and we do not issue certifications. Most of what makes an audit painful is missing evidence rather than missing controls, so the documentation matters as much as the configuration.

Something has happened. Can you help right now?

For an active incident, your first calls are your backup, your insurer if you have cyber cover, and a specialist incident response firm. We are not an IR retainer and would be misrepresenting ourselves to take that call. What we do well is the part afterwards: rebuilding properly, and closing the path that was used.

Is this not overkill for a business our size?

The realistic threat to a small business is not a targeted attacker; it is ransomware, credential theft and an unpatched device facing the internet. All three are addressed by unglamorous controls — segmentation, MFA, patching, and a backup that has been restored from. None of that is enterprise-scale work, and the cost of skipping it is not proportional to your size.

How is this different from your network architecture practice?

Considerable overlap, different starting point. Network architecture asks how traffic should flow; security asks what an attacker could do with what you have built. The same person does both, which is the point — segmentation designed by someone who has thought about lateral movement tends to be segmentation that works.

RD/ — Related reading

CTA/ — Security work

Not sure what you're exposed to?

That is the normal position, and it is what a review is for. Tell us roughly what you run and where it lives, and you'll get a scope for the assessment.

Ask about a security review →