Protect / Cybersecurity
Security work measured by what changed in the system, with findings prioritized by real exposure rather than scanner severity.
TechSteps does practical cybersecurity engineering: finding what is actually exposed, prioritizing by real risk rather than scanner severity, implementing the remediation, and leaving monitoring behind so the next problem is visible. The measure of the work is what changed in the system, not the length of the report.
What this solves
A great deal of security spending produces documents. A scanner runs, a report is generated, findings are ranked by a severity score computed without any knowledge of your environment, and the document goes to someone who cannot action it.
Meanwhile the things that actually get organizations compromised are mundane: an unpatched service reachable from the internet, a credential reused across systems, an administrative interface exposed without restriction, a backup that would not restore.
We work on the exposure that exists rather than on the theoretical threat model. That means access to real systems, prioritization by what an attacker could actually reach, and changes made rather than recommended.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
You cannot secure an inventory you do not have. Systems, services, accounts, data and who has access. This step alone frequently surfaces things nobody knew were running.
What is reachable, what is out of date, what is authenticated weakly. We prioritize by whether an attacker could actually reach it, which is often very different from the scanner ranking.
An exposed admin interface matters more than a theoretical vulnerability in an internal service nobody can route to. Order the work by exploitability.
Logging, alerting and baselines, so a future change is noticed. Security is not a state you reach; it is a thing you keep observing.
Restore a backup. Confirm how long it takes. An organization that can recover reliably has a fundamentally different risk profile from one that assumes it can.
What was fixed, what was accepted as a risk and why, and what remains outstanding. A security document that implies everything is resolved is not useful.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Severity scores are computed without knowledge of your environment. A critical finding on an unreachable internal service can matter less than a medium on an exposed login page.
A policy document, a training slide deck and an annual review, with no change to what is actually exposed. This is compliance theatre and attackers are unaffected by it.
Alerts routed to an unread mailbox, or so noisy that the real one is lost. This produces the confidence of monitoring without the benefit.
The plan says restore from backup. Nobody has, so nobody knows it works or how long it takes. This is discovered during the incident.
Security changes applied without understanding the workload, so people work around them. A control that gets bypassed is worse than one that was never applied.
Questions we actually get asked
With three things, in order. Know what you have exposed to the internet and remove what does not need to be. Get multi-factor authentication on email and anything holding customer data. Prove you can restore from backup. Those three cover a disproportionate share of real incidents, and none require a large budget.
No. A penetration test attempts to exploit weaknesses to demonstrate impact, and is most valuable once you already have reasonable hygiene. This work is about finding and fixing exposure. If you are not patching consistently or do not know what you run, a penetration test will produce an expensive report telling you that.
Only if you established how they got in and whether they retained access. Cleaning malware and closing a compromise are different jobs. If nobody checked for persistence such as added keys, scheduled tasks or new accounts, and nobody rotated credentials, the answer is that you do not know.
Not necessarily. It is a monitoring layer for Linux servers, and it is useful where you have servers that need continuous watching and nobody to do it. It is not a prerequisite for working with us, and we will not recommend it where the actual problem is that you have not patched in a year.
By having the underlying practice, then describing it accurately. Most questionnaires ask about patching, access control, backups, logging and incident response. If those exist and are documented, the questionnaire is straightforward. If they do not, we would rather help you build them than help you word around the gap.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.