DEV Community: Gary Austin

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

Gary Austin — Thu, 10 Sep 2026 14:07:00 +0000

Nobody Broke In. They Signed In: The One-Afternoon Login-Surface Review

The instructive intrusions of the season share a shape: the authentication failed, not the firewall. Here's the afternoon review that counts every door your organization exposes — and turns the count into a signed record.

The pattern with no forced entry in it

Read this month's actively-exploited list with one question in mind — what actually failed? — and a theme emerges. A screen-sharing service that authenticated a network attacker without valid credentials. A collaboration platform whose security feature could be walked past after a public proof-of-concept dropped. A management console, weeks earlier, whose login could be skipped entirely via an alternate path. And in the same season, a seven-figure dump of contact records — name, email, address, phone — whose main criminal application is making the next call to a help desk sound exactly like the user it claims to be.

No malware had to beat your EDR in any of those stories. The doors did what they were configured to do. The configuration was the finding.

Which leads to an uncomfortable reframe: your perimeter is not a firewall diagram. It's the set of every internet-reachable place that accepts a credential for your organization — or for each client, if you're the MSP. And in most shops, that set has never been written down.

You can't lock a door you haven't counted

The review starts with an inventory, because every later question is per-door. Twelve categories jog the memory:

Identity provider / SSO — the front desk itself
Email & webmail — including the legacy paths (OWA, ActiveSync, basic auth)
VPN portals & remote-access gateways
Firewall / network-gear admin interfaces
RMM & remote-support tooling — last week's master key cabinet
Hypervisor & infrastructure management — vCenter, iLO/iDRAC, cloud consoles
File / intranet / collaboration platforms
SaaS admin consoles — PSA, billing, backup, the password manager
Remote desktop & screen sharing — RDP, VNC, OS-native sharing
Break-glass & emergency accounts
Service accounts & API keys — doors with no human attached
The help desk's reset procedure — a door that answers to a voice

One row per door: what it is, who uses it, what it accepts, who owns it, when it was last checked. If producing that table takes more than an afternoon, that fact is itself the first finding.

"We have MFA" is a per-door claim

Here's where last week's management-plane review and this week's shake hands. The five console questions asked is MFA enforced on the console itself — because a console with local accounts is indifferent to how good your identity provider's MFA is. This week generalizes it. For every row in the inventory, mark exactly one:

ON THE DOOR — the service itself enforces a second factor, local accounts included.
UPSTREAM — MFA lives at the IdP; anything the door authenticates locally walks past it.
NOWHERE — a password alone opens it.

Then two follow-ups per door: can any account skip it? (service accounts, legacy protocols, app passwords) and does this door hold accounts the IdP has never heard of? The org-level sentence "we have MFA" aggregates away exactly the information an attacker cares about. The matrix exists to de-aggregate it.

The side doors

Most gaps the matrix finds fall into a short, familiar list — the paths that skip the second factor:

Legacy mail protocols still answering basic auth
App passwords and long-lived tokens that outlive their owner's MFA
Vendor and default accounts that shipped with a product and still resolve
Break-glass accounts with no compensating alert on use
Admin interfaces exposed to the whole internet where an allowlist would do
API keys embedded in scripts older than the last rotation
The MFA exception that was "temporary" two migrations ago

Close what you can in the afternoon. For what you can't, write down the reason and an owner — an accepted risk with a name and a date is a decision; the same gap undocumented is just exposure.

The human door

The password reset flow is an internet-reachable authentication endpoint. It runs on a human, under social pressure, and its verification data — the things a caller is asked to prove — is precisely what large contact-data dumps put in criminals' hands. So the script is short and strict: never authenticate on knowledge alone; call back on the number already on file, never the one the caller offers; verify through a second channel the account owner controls; allow no urgency exceptions, because manufactured urgency is the technique; and log every reset — who asked, how verified, who approved, when.

Five lines, printable. It converts the softest login you own into one of the most defensible — and the log converts it into evidence.

The record is the deliverable

Same rule as restore week and console week: every claim gets a number and a date. The afternoon ends with one page: doors enumerated, MFA state per door, paths closed, exceptions accepted (with owners), script deployed, next check booked. "Twenty-two doors, MFA enforced on nineteen, three legacy paths closed, Aug 27, J.R., re-check November" is an artifact — the kind cyber-insurance applications and client questionnaires increasingly expect. "We're pretty locked down" is a mood.

The whole thing, packaged free

The Login Surface Kit (Gatorbyte #010) bundles the review: the 12-category inventory worksheet, the MFA coverage matrix, the legacy-path kill list, the help-desk verification script, and the evidence log — free: thesecuritygator.gumroad.com/l/gb010-login-surface-kit.

One afternoon. Twelve categories. One signed page either way it lands. Because a door you haven't counted is a door you can't lock.

This is a review format, not managed security services — and not legal, compliance, or audit advice. Authentication capabilities vary by product and license; verify against your vendor's current documentation. If a review turns up evidence of compromise, follow your incident-response plan.

Same Attack, Two Companies. One Never Responded: The One-Afternoon Alert Coverage Review

Gary Austin — Wed, 09 Sep 2026 14:07:00 +0000

Same attack, two companies. One never responded.

CISA ran the same red team playbook against two organizations at the same time and published both outcomes. One SOC quarantined the machines. The other received the alerts and never responded — and the reason it didn't is the cheapest problem in this whole story to fix.

In August, CISA published something unusual: the results of two red team assessments run at the same time, against two different critical-infrastructure organizations, using similar tradecraft. Advisory AA26-237A, titled "A Tale of Two SOCs."

It is unusual because it is the experiment nobody gets to run on themselves. Same attackers, same playbook, same week, two environments — and the results printed side by side.

Both organizations were compromised at domain level. In both, the red team reached sensitive business systems and cloud resources. So the interesting variable is not whether the attack worked. It worked twice.

The interesting variable is what happened in the minutes after.

The one that worked

Organization B, a water and wastewater entity, was phished. Three users clicked, and the red team landed on three workstations.

The SOC caught the payload on each one. Every execution generated a medium-severity alert; staff quarantined the workstation, analyzed it, and reimaged it before putting it back online. Three times. Command-and-control never held.

Then something worth noticing happened. Because the defenders removed that initial foothold, the red team could not proceed — so the engagement was restructured. Organization B's own trusted agents — IT staff who knew about the assessment — executed a red-team-provided payload on a designated internal host tied to a standard, non-administrative account, replicating the access the team would have had if they hadn't been thrown out.

Assume-breach is a standard phase of these assessments, so this isn't a trophy on its own. What it does tell you is the direction the pressure ran. The team didn't move to assume-breach on schedule; they moved to it because containment worked.

Later, when the red team reached a bastion host in the OT DMZ, that host blocked outbound connections and the payload execution triggered an alert. Staff quarantined it. When the team logged into the Azure portal with a compromised account, an automated alert fired and staff blocked the account.

None of that is exotic. It is ordinary tooling, plus somebody reading the output.

The one that didn't

Organization A, in government services, did not respond.

Not to the phishing. Not to the privilege escalation — a default Machine Account Quota and a misconfigured AD CS certificate template. Not to credentials sitting in cleartext, or static cloud access keys set never to expire. At one point the red team used an over-permissioned application to review SOC staff email, specifically to see whether staff were aware of the compromise. The SOC never responded.

Here is the part that should change how you think about your own program.

The alerts fired.

The advisory is explicit: the SOC received medium- and low-severity EDR alerts related to red team activity "but did not respond to them." Thousands of false positive alerts corresponding to normal business operations — many at higher severity — obscured the real ones.

That is not a detection failure. The tools detected it. It is a response failure, and it has a completely different fix, at a completely different price.

The detail worth an afternoon

One alert in that environment was real, and a human looked at it.

Red team members observed defenders' chat about an alert on an SCCM server. The defenders tried to determine who owned that system, what it did, and how it was normally used. They could not. The SOC eventually flagged it a false positive.

Read that again slowly. The detection worked. The alert was true. It died in triage because the asset inventory could not name a person.

Which means your CMDB is doing detection work, whether or not anyone staffed it that way. An alert arrives carrying a hostname. Whether it survives the next four minutes depends entirely on whether someone can attach meaning to that hostname at two in the morning.

CISA also found Organization A running multiple SOCs and multiple EDR products whose staff neither communicated with each other nor had visibility into each other's detection tools — and SOC staff and system owners did not communicate either. More consoles is not more coverage. Each additional console is another place a signal can arrive and stop.

The advisory's closing line is blunt, and worth quoting exactly:

"Detection tools are only as effective as the people, processes, and procedures supporting them."

It is not one unlucky organization

You could read all of that as a story about one badly-run SOC. The numbers say otherwise.

The Blue Report 2026, published in August by Picus Labs, measured more than 338 million attack simulations run in real production environments. Two of its scores matter here:

Logging: 58%
Alerting: 14% — flat year over year

Fewer than one simulated attack in seven produced an alert at all.

Worth naming the obvious: Picus sells breach-and-attack-simulation tooling, and a report finding that untested detection underperforms is a report that sells more testing. Read it as vendor research. It is still worth citing, because the methodology is stated, the sample is enormous, and the finding is independently corroborated by a government advisory with nothing to sell — one describing a SOC that received real alerts and did not act on them.

Put the two numbers side by side, because the gap is the entire argument. More than half the telemetry is arriving. The event gets written down. What almost never happens is a rule that reads it and routes it to a human.

That is not a collection problem, and it will not be fixed by more retention or a bigger ingest bill. It is a detection-engineering problem. One of those costs money. The other starts with an afternoon.

The afternoon

Five events. Not fifty.

Fifty detections is a project, a budget line, and a thing you never start. Five is an afternoon. Pick five you would be embarrassed to miss, and leave the rest for next quarter:

A new global or domain administrator
A log source going dark
An impossible-travel or anomalous-location login
A mass export or bulk download
A new mailbox forwarding or inbox rule

Pick by consequence, not by ease of detection. The temptation is to choose the five you already know alert — which measures your confidence, not your coverage.

Then, for each one, three questions:

Is it logged? Usually yes. Name the source and the retention window, not just "yes."
Does it raise an alert? Now you're guessing. A rule in a vendor template is not a rule that is enabled and scoped to your tenant.
Who receives it, at 2am? This is the one that decides everything.

Question three is where most programs quietly die. "Does it alert" is answerable on paper. "Who receives it at 2am" is answerable only by looking, and the answer is startlingly often a distribution list with one person on it who left, or a channel nobody has opened since the integration was built.

Then stop guessing

Everything above is still paperwork. This part isn't.

Generate the event. Get approval, work inside a change window, and tell the people who would otherwise page out that it's you. Create a throwaway administrator. Trigger a deliberate bulk download. Add a test forwarding rule.

Then watch three places: the console that should show it, the channel that should carry it, and the human who should receive it. Record the wall-clock deltas — trigger to alert, alert to acknowledgement. Those numbers are the deliverable.

And record the silences. An event that produced nothing is the most valuable row on the page, because it converts "would we catch that?" from an assumption into a finding — one you made on your own schedule instead of during an incident.

Then remove what you created, and log the removal.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"We'd catch that" is a mood. Something shaped like "five events tested Sep 10; three alerted within four minutes; one alerted to a dead channel; one produced nothing — two tickets filed, retest Sep 24" is an artifact. It is also the exact thing that answers an assessor asking whether your monitoring is real or aspirational, and the kind of evidence assessors and insurers increasingly ask about.

Fix the routing before you fix the rule, incidentally. An alert nobody receives and an alert that doesn't exist cost precisely the same during an incident, and the routing is usually the cheaper repair.

Both organizations in that advisory had tools. Both had logs. One of them knew what it would see.

Your logging is probably fine. Your alerting is the open question.

The worksheets are free. The Alert Coverage Kit (Gatorbyte #012) is a self-contained offline HTML file — the five-event picker, the three-question test, the generate-and-watch protocol, a coverage log with time columns, the asset-ownership check, and an evidence register — plus CSV and Excel export of every worksheet. No account required — thesecuritygator.gumroad.com/l/gb012-alert-coverage-kit

This is a review format and a practical starting point to adapt for your organization. It supports detection-coverage documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Generating test events changes state in a live environment — get approval and work inside a change window.

Sources: CISA AA26-237A — "A Tale of Two SOCs" · CISA KEV alert, Sep 2 · Blue Report 2026, Picus Labs

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Gary Austin — Wed, 02 Sep 2026 14:07:01 +0000

They Left in March. Their Account Didn't: The One-Afternoon Offboarding Review

Last week CISA added vulnerabilities from 2015 to the actively-exploited catalog. The mechanism that keeps an eleven-year-old bug exploitable is the same one that keeps a departed employee's API token alive — and here's the afternoon review that finds it.

Decay, with a date stamp on it

On August 26, 2026, the Known Exploited Vulnerabilities catalog picked up four entries worth reading twice: CVE-2015-3246 and CVE-2015-5287, both Red Hat, both from 2015; CVE-2019-1068, a SQL Server remote code execution; and CVE-2021-23758, a deserialization flaw in Ajax.NET Professional. Entries land in that catalog on evidence of active exploitation. Somebody is still exploiting a bug that turned eleven years old.

The catalog doesn't say why. But the simplest explanation for an eleven-year-old bug still being exploited is that it is still running somewhere, on a host nobody owns, that nobody has deliberately logged into since the person who built it left.

Five days later the same catalog added two PaperCut NG/MF flaws, one of which is described in its own entry as Missing Authentication for Critical Function — on a print management server, the archetypal thing an MSP installs once in year one and never revisits. And in between, on August 27, an ownCloud improper-authentication bug from 2023 was added with a three-day federal remediation deadline.

Read together, those look less like three patching stories than one ownership story. The risk factor is not unpatched; unpatched is a symptom. The risk factor is unowned — and access decays exactly the same way, only more quietly, because an orphaned account never throws an alert.

HR closes a person. Security has to close identities.

Offboarding gets filed as an HR event, and that framing is why it quietly fails. HR closes a person. Access lives as identities, and the mapping is one-to-many.

The directory account is the one identity that reliably has a human's name attached and a process pointed at it. It gets disabled on day one, and it is what everyone points to when you ask whether offboarding works. Underneath it sits everything that was created ad hoc, is owned by nobody in particular, and has no lifecycle tied to employment at all.

So the process reports success while most of the surface is untouched.

The six-month rule

Before the hunt, one decision determines whether this review measures anything: who you audit.

Reviewing last week's leaver tells you almost nothing. The ticket is still open, the manager remembers, someone is still copied on the thread. Of course it looks clean — you are measuring your attention, not your process.

Pull five people who left six months ago or longer, or five contractors whose engagement ended that long back. That tells you what your process produces once attention has moved on, which is the only condition it will actually operate under for the rest of its life.

It is the same logic as testing a restore instead of trusting a green backup job. The green light describes an intention. The restored file describes reality.

Ten places access hides

One row per identity, not per person. A single departure usually produces several:

Directory / SSO account — the easy one, and the one that flatters the process
Local accounts on appliances — firewall, hypervisor, NAS, print server, switch; tied to no directory
Shared credentials in the team vault — four people know it, so rotating it means telling four people, so it never gets rotated
Service accounts — nobody offboards one, because nobody thinks of it as a person; yet it carries their naming convention and their permissions
API tokens and app passwords — they outlive the human because the token appears in no list anyone reads
MFA enrolments on personal devices — the account is disabled, the phone is still a registered authenticator
Vendor and support portals — they are still the registered contact, so resets and license changes still route to them
Client tenants and delegated access — MSP-specific, and the highest blast radius on the list
Repos, CI, and deploy keys — org membership and personal access tokens both outlive employment
Mailbox rules and forwarding — survives the mailbox being converted to shared, and quietly keeps delivering

If your hunt produces one row per person, you have found the checklist, not the access.

Verify in the system, not on the checklist

This is the step most reviews skip, and skipping it makes the other steps decorative.

A completed offboarding checklist is a claim. The system's actual user list is evidence.

On a first pass those two usually disagree — and when they do, the checklist is what's wrong. It recorded an intention formed at the moment of ticking, and nothing re-validated it afterwards. A user list pulled today is a statement about now.

The failure modes are mundane, which is exactly why they persist:

The account was disabled but never removed from its security groups, so a re-enable for a mailbox restore silently returns full access.
The human was revoked and the token they generated wasn't, because the token isn't attached to them anywhere a person looks.
The shared vault entry was never rotated, because rotating it is a conversation with four people.
Two admins each assumed the other one did it.

None of these require carelessness. They require a process that stops at ticked.

The artifact is the point

The review is just how you produce the record. The record is what survives.

Log what you revoked, from where, on what date, verified how, and checked by whom — and fill it as you go, because retro-filling is how dates stop being true. Then write the per-departure summary: systems checked, identities found, how many were still active, when they were closed, and what process gap let it happen.

That last field matters more than it looks. What you found is a gap in the runbook, not in one person's file. Patching the record leaves the next departure exactly where this one was.

The rule carries over from every review in this series: every claim gets a number and a date. "We offboard people properly" is a mood. Something shaped like "five departures reviewed, 31 identities found across 9 systems, 6 still active, all revoked, Sep 4, verified by J.R." is an artifact — and it is the one an assessor asks for when they want to know whether your access-control process is real or aspirational.

When you find something

Preserve before you act — screenshots, exports, timestamps — and if there is any sign the access was used after the person left, stop and follow your incident-response plan. A worksheet is not one. Engage counsel and your insurer per your policy's terms before external communications.

And a clean review is still a deliverable. Identities counted, nothing still open, dated and signed, filed. An identity nobody owns goes on the risk register with one owner and one fix-by date, not in a drawer.

The worksheets are free. The Offboarding Evidence Kit is a self-contained offline HTML file — identity hunt across all ten categories, verification pass, revocation log, per-departure review record, evidence register — plus CSV and Excel copies of the three registers. No account required — thesecuritygator.gumroad.com/l/gb011-offboarding-evidence-kit

This is a review format and a practical starting point to adapt for your organization. It supports access-review and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security or incident-response services. Account and token lifecycle behaviour varies by product and license — verify against your vendor's current documentation.

Sources: CISA KEV catalog · KEV alert, Aug 26 · KEV alert, Aug 27 · KEV alert, Aug 31

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

Gary Austin — Wed, 19 Aug 2026 14:07:00 +0000

They Didn't Break In. They Logged In: The Two-Hour Management-Plane Review

One console in your stack can reach every machine you manage. This month an attacker demonstrated exactly what that means — without deploying a single piece of malware. Here's the two-hour review that turns that lesson into a signed record.

The intrusion with no malware in it

The most instructive incident reporting of the month describes an attack with no phishing email, no dropper, no encrypted payload. An authentication bypass in a widely deployed remote monitoring and management (RMM) platform gave the attacker administrative access to the management console — and from that point they never needed an exploit again. They used the product's own remote-control feature, the same one technicians use every day, to reach managed endpoints and leave persistence behind. In at least one confirmed case, the session ran under a default support account that ships with the product.

Read that chain again from your tooling's point of view. The endpoint agent saw a legitimate remote-support session. The firewall saw a signed, widely used tunneling utility connecting to a well-known service. The audit log saw a support account supporting. Every control was working correctly. They were answering questions nobody had asked.

Why the management plane is a different asset class

Compromise an endpoint and an attacker owns an endpoint. Compromise the management plane and they own every endpoint it manages — and if you're an MSP, that's not one company, that's your entire book, through one console that lives on the internet because it has to.

A workstation is a room. Your RMM is the master key cabinet. That asymmetry is why the console deserves harder questions than any other server you run — questions that outrank every feature comparison on the next renewal call:

Does the console share an identity system with your domain? Shared identity means one takeover becomes two.
Is MFA enforced on the console itself — not just on the technician's email account?
Can any technician open remote control on any endpoint at any hour, or is that scoped and scheduled?
Does the management server have unrestricted outbound access? A server that can tunnel anywhere can beacon anywhere.
Is there one session record an administrator of that same server cannot quietly edit? If the intruder is admin on the console, the console's log belongs to them too.

Patched is not fixed

Here's the detail worth tattooing on the inside of the ticket queue: the flaw being actively exploited exists because the patch for an earlier vulnerability was incomplete. The first fix shipped; the underlying path stayed open; a second CVE was issued for the same way in — and the second one is what attackers are using. A population of teams did everything right, applied the update, closed the ticket, and remained exposed.

So verify patches the way you'd verify a restore:

Check the version on the host itself. The console reporting on itself is a claim; the host is the fact.
Check every instance, not the one you remember.
Where the vendor documents the closed path, re-test the path rather than trusting the version string.
Re-read the advisory a week later. Incomplete fixes are usually discovered after the first patching wave, not before.

Then write it down: version confirmed, instances checked, date, who, what test. "We're patched" is a mood. That log is an artifact — the same artifact cyber-insurance applications and client security questionnaires keep asking for.

The four tells (context, not tooling)

What actually separates an attacker from a technician when the tool, the account, and the feature are all legitimate? Context. Four kinds of it:

1. HOUR    — a support session at 3 AM on a Sunday
2. SOURCE  — a consumer-VPN exit node, not your office or corporate VPN
3. IDENTITY— a default account name nobody on your team actually uses
4. SHAPE   — connect → enumerate → disconnect
             (reconnaissance looks nothing like support)

None of these are alerts in most shops today. All four are answerable this week, from logs you already collect.

Hunt backwards, then write it down

Because this class of flaw tends to be exploited before it's catalogued, forward-looking controls are half the job. The other half is a 90-day retro-hunt: pull remote-session history and read it against the four tells; look for tunneling utilities registered as services on machines with no business running them; look for executables in user document folders wearing system file names; search for persistence no ticket explains. You're not looking for a hit — you're building the ability to say you looked, and what you found. A clean hunt, dated and signed, is still a deliverable.

The whole thing, packaged free

The Management Plane Kit (Gatorbyte #009) bundles the review: the five-question hardening checklist, the patch verification log template, the four tells as a starting detection list, and the 90-day retro-hunt worksheet — free: thesecuritygator.gumroad.com/l/gb009-management-plane-kit.

Two hours. Five questions. One signed page either way it lands. Because a control you can't evidence is a control you're only assuming you have.

This is an exercise and review format, not managed security services — and not legal, compliance, or audit advice. Vendor advisories change; verify version guidance against the current advisory before acting. If you find evidence of compromise, follow your incident-response plan.

Your Backups Are a Hypothesis: The 45-Minute Restore Test

Gary Austin — Sun, 16 Aug 2026 09:15:00 +0000

The green checkmark problem

Every MSP dashboard has one: the backup column, green for months. Green feels like safety. But a green job proves exactly one thing — the job ran. It does not prove the data comes back, how long that takes, whether the increment you'll need survived the retention policy, or whether anyone alive can find the decryption key at 2 AM.

Two weeks ago this series argued that an incident response plan that's never been exercised is a hypothesis. Backups are the same species of hypothesis, with quieter failure modes:

Rotated credentials. The backup service account changed; jobs kept "succeeding" against a subset of targets.
Corrupt increments. The chain is only as good as its weakest link, and nothing verifies links like a restore.
Retention surprises. The copy you need is from 9 days ago; retention keeps 7.
Key-inside-the-vault. The decryption key or console password is documented… inside a system that's now encrypted.
Scope drift. The new file share, the new VM, the migrated mailbox — added to production, never added to the job.

Every one of these is invisible on a green dashboard, and every one of them is found in one of two moments: a scheduled drill on a Tuesday afternoon, or the worst hour of your year.

The drill

THE 45-MINUTE RESTORE TEST  (roles: an operator + a scribe. That's the team.)

0:00  Pick the target BEFORE you feel ready: one production system that
      would hurt Monday morning — file server, finance share, the PSA/RMM
      database. Not the easy one. The one that matters.

0:05  Restore last night's copy to an ISOLATED target: a spare VM, an empty
      VLAN, a cloud sandbox. NEVER over production. No internet egress
      required — isolation is the point.

0:35  Verify like a USER, not an admin: open three files, run one report,
      log in with a real non-admin account. "It boots" is not "it works."

0:40  Write four numbers: minutes to restore · GB restored · items verified
      · today's date. The scribe signs the page.

That signed page is the deliverable. Everything else — the war stories, the "huh, interesting" moments, the ticket you'll open about the service account — is bonus.

The one rule

Borrowed from the tabletop drill and repointed: every claim gets a number and a date.

"Restores work fine" is a mood. "47 minutes, 212 GB, three files opened and readable, August 11, signed by the scribe" is evidence — the kind cyber-insurance applications and enterprise security questionnaires are explicitly asking for when they say tested recovery and documented RTO. You're not doing extra work to satisfy the questionnaire; the drill's natural output is the answer.

The math you can finally do

Recovery time estimates usually divide a known number by a guess:

Real downtime ≈ (data that must come back) ÷ (restore throughput)

Every team knows the first number. Almost nobody has measured the second — and the difference between an assumed and a measured throughput is the difference between promising "a few hours" and delivering a long weekend. After one timed drill, your RTO conversations use a measurement. Guessing is over.

The trap: your backups are the first target

Ransomware crews have told reporters for years that backup infrastructure is their first stop — delete or encrypt the recovery path, then detonate. Recent KEV traffic makes the architectural point for them: Veeam's advisory for CVE-2026-44963 describes a critical RCE on domain-joined backup servers, reachable by any authenticated domain user. One stolen domain account, and the vault is another room on the sinking ship.

So alongside the restore drill, three architecture questions worth an hour:

Credential separation. Does the backup console share credentials (or auth domain) with production? It shouldn't.
An undeletable copy. Does at least one copy live where a domain admin cannot delete it — immutable object storage or genuinely offline?
Console-loss drill. If the console died tonight, who could still reach a copy, and by what path?

The commonly used rule of thumb is 3-2-1-1-0: three copies, two media, one offsite, one offline or immutable, zero errors on verification. The last digit is the one everyone skips — and it's the only one that involves actually restoring. Treat it as a starting point to adapt, not a certification to claim.

When the test fails

A restore test that fails is a successful test — it located a real gap for the price of 45 minutes. Run the tabletop rule on it: the gap gets an owner and a date, and the failed log page stays in the file next to the eventual passing one. The paper trail from red to green is itself evidence of a functioning program. The only failed test is the one never run.

Make it a rhythm

One drill is a data point; a rhythm is a program. Rotate targets quarterly — file server this quarter, the PSA database next, a full VM the one after. Fifteen minutes of scheduling covers a year: four calendar invites, each with an operator, a scribe, and a target named in advance. Booked beats intended.

Local-first GRC: why I'm building a compliance workbench that doesn't phone home

Gary Austin — Tue, 28 Jul 2026 09:27:58 +0000

I'm Gary — The Security Gator. I build a GRC command deck for vCISOs, MSPs, and consultants who are tired of renting access to their own compliance data.

The premise is simple: most compliance platforms are SaaS. Your control assessments, your risk scores, your client evidence — all of it lives on someone else's servers, behind a subscription that never ends. Stop paying, lose access.

The bet: own it, don't rent it

AxiomLens is a NIST CSF 2.0 workbench that runs entirely on your machine — SQLite under the hood, a local GUI on top, one-time license. After activation it's strictly offline.

	CaaS / SaaS	AxiomLens
Your data lives	On their servers	In a SQLite file you own
Access model	Log in to their cloud, every session	Activate once, then fully offline
Cost shape	Subscription, forever	One-time license
When you stop paying	Locked out	Nothing happens — it's yours

$ axiomlens status --json
{
  "controls_total": 106,
  "in_scope": 100,
  "coverage": "computed locally"
}

Coverage math, scored risk, board-ready reports, client hand-off docs — computed on your machine, owned outright. It supports compliance documentation and audit preparation; it's not a substitute for legal, compliance, or audit advice — and I'm careful to never claim otherwise. That honesty is part of the pitch.

What I'll write about here

The build, in public: SQLite schema decisions for framework crosswalks, packaging Python into a single exe with Nuitka, deterministic report generation instead of LLM roulette, and the general weirdness of shipping desktop software in a SaaS world.

The free stuff — field guides, a governance tool, starter kits — lives on the Gatorbyte Free Shelf.

Everything else: thesecuritygator.com · Bayou Bytes newsletter