Exposure review
Services, ports, DNS, reverse proxies, HTTP headers, certificates, accounts and administrative access paths.
SECURITY / HARDENING
I analyse service exposure, system and application configuration, scan results and access paths. Recommendations aim to reduce risk without accidentally cutting off production.
APPROACH
A scanner's list of recommendations does not show the whole picture. The same vulnerability can have a different priority depending on exposure, data, compensating controls and the service's role in the environment.
First, I establish the attack surface, traffic flows, accounts and permissions, the update process and recovery options. Only then do I select the changes and their order.
Every significant modification should have a test, a deployment window and a rollback plan. The aim is measurable risk reduction, rather than the largest number of ticked boxes.
AREAS OF EXPERTISE
The scope follows your goal and the current state of the environment. We can start with a single issue or a complete project.
Services, ports, DNS, reverse proxies, HTTP headers, certificates, accounts and administrative access paths.
SSH, firewalls, permissions, updates, containers, secrets, logging and restricted capabilities.
Verification of vulnerabilities, elimination of false positives, impact assessment and a remediation plan ordered by risk.
CSP, rate limiting, HSTS, form protection, host validation, data minimisation and safe rollback.
WHAT YOU RECEIVE
A deployment should be verifiable, maintainable and safe to develop further.
A map of exposure and the most important system access paths.
Findings with priorities, impact and recommended fixes.
Hardening changes to system, reverse proxy or container configuration.
Tests confirming the fix is effective and has not caused functional regressions.
A maintenance plan covering updates, log retention, reviews and responsibilities.
HOW I WORK
I establish the data involved, exposure, service criticality and operational constraints.
I check findings manually and compare them with the actual configuration.
I order actions by risk, cost and likelihood of regression.
I implement or describe fixes, including a test and a rollback method.
WHEN IT HELPS
You do not need a finished specification. A specific problem, risk or desired outcome is enough.
FAQ
Not always. The result needs verification, exposure and dependencies need checking, and regression risk needs assessment. An automated list does not know the full production context.
Yes. That is why SSH, firewall and network changes require a second session, tested emergency access and a staged rollout.
The focus is on configuration reviews, exposure analysis, verification of scan results and remediation. A full offensive penetration test requires a separately agreed scope and rules.
Only data needed for the service is collected. Logs and messages should not contain additional information unless it is necessary for diagnostics or handling an enquiry.
NEXT STEP
Let's establish exposure, priorities and a safe order of changes. We address the largest risks first, then work through the rest.