|
Bayou Bytes // Issue #9 · Offboarding Week
Come, Take Your First Byte.
Three sections, twelve minutes. Starting now.
|
|
|
The Pulse
|
|
Every Tuesday: the threats that actually moved, one fix you can ship before lunch, and the plain-English version your non-technical CEO needs to hear. This week the fix isn’t a product — it’s one afternoon spent finding out who still holds keys to the doors you counted last week.
Now, this week:
|
|
🔴 Threat level: elevated — this week’s exploited systems look like one story to me: neglect.
CISA just added vulnerabilities from 2015. Read that again. In a single batch on Aug 26 the Known Exploited Vulnerabilities catalog picked up CVE-2015-3246 (Red Hat Libuser), CVE-2015-5287 (Red Hat ABRT privilege escalation), CVE-2019-1068 (Microsoft SQL Server RCE) and CVE-2021-23758 (Ajax.NET Professional deserialization) — alongside a Linux kernel out-of-bounds write and a Citrix NetScaler flaw. Entries land there on evidence of active exploitation, which means someone is still exploiting a bug that turned eleven years old. The catalog doesn’t say why. The likeliest reason isn’t that the bug is clever — it’s that it is still running somewhere, on a box nobody owns, that nobody has logged into on purpose since the person who built it left. That is what decay looks like once it finally lands in the KEV catalog. Federal remediation deadlines: Aug 29 for two of them, Sep 9 for the rest.
“Missing Authentication for Critical Function” — on a print server. CISA added two PaperCut NG/MF flaws on Aug 31: CVE-2026-81578, whose catalog entry is literally Missing Authentication for Critical Function, and CVE-2026-82078, an unsafe reflection bug. Federal remediation due Sep 14. Print management is the archetypal thing an MSP installs once, in year one, and never revisits — it sits inside the network, it is wired into directory and print infrastructure, and it is nobody’s Monday-morning problem. That Sep 14 date binds federal agencies, not you — but if you manage PaperCut for clients it is a reasonable date to hold yourself to, and the question after patching is the one this week is about: who still has an account on it?
A 2023 authentication bug, catalogued in 2026, already past its federal due date. CVE-2023-49105 — ownCloud Improper Authentication — was added Aug 27 with a federal remediation deadline of Aug 30. Three days. The identifier is a 2023 one. The same batch carried a JFrog Artifactory path-traversal flaw (CVE-2026-66384, federal due date Sep 10) and a Linux kernel issue. The pattern across all three items this week is not “patch faster.” The common thread, as I read it, is that these are systems that fell out of somebody’s attention — and access falls out of attention the same way, just more quietly, because an orphaned account never throws an alert.
|
|
|
The Hardened Stack
Deep Dive: you counted the doors. Now count who still has keys.
|
|
Last week you enumerated every place on the internet that accepts a credential. Good. Here is the follow-up nobody enjoys: for each of those doors, who can currently open it — and does that list match the people who currently work there? Offboarding gets treated as an HR event. It isn’t. HR closes a person; access lives as identities, and one person leaves behind more than one. The SSO account is the easy one — disabled the day they leave, and the one everyone points at when you ask whether offboarding works. Underneath it sits the stuff that never routes through HR at all: the local admin account on the firewall, the shared credential four people know and nobody rotated, the API token still running a nightly script, the personal phone still enrolled in MFA, the vendor portal where they are the registered contact, the client tenant they had delegated access to, their repo access, their forwarding rule. The kit up top runs the whole review; here’s the skeleton:
|
THE OFFBOARDING REVIEW — ONE AFTERNOON
1 PICK the last 5 people who left — or 5
contractors whose engagement ended.
NOT recent ones. Six months back.
2 HUNT every identity, not every person: SSO,
local accounts, shared vault entries,
API tokens, MFA enrolments, vendor
portals, client tenants, repos, rules.
3 VERIFY don’t trust the checklist that says it
was done. Look at the system.
4 REVOKE and write down what, from where, on
what date, checked by whom.
5 FIX FWD what you found is a gap in the process,
not in one person’s file. Fix the runbook.
|
|
|
Step 1 is deliberate. Reviewing last week’s leaver tells you almost nothing — the ticket is still open and someone remembers. Reviewing someone who left in March tells you what your process actually produces once attention moves on. And step 3 is where most reviews quietly fail: a completed offboarding checklist is a claim; the system’s actual user list is evidence. On the first pass those two usually disagree, and when they do, the checklist is the thing that is wrong. Same instinct as testing a restore instead of trusting a green backup job. And the rule stays the rule: every claim gets a NUMBER and a DATE. “We offboard people properly” is a mood; an answer 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.
|
|
GB011: identity hunt worksheet, revocation log, evidence register →
|
|
⚠️ The kit is a review format and a starting point — not managed security services, and not legal, compliance, or audit advice. Account and token lifecycle behaviour varies by product and license; verify against your vendor’s current documentation before relying on it. If a review turns up evidence of unauthorised access, follow your incident-response plan and engage counsel and your insurer per its terms.
|
|
|
The Boardroom Bridge
Asking for the afternoon without the fear budget
|
|
The talking point (a literal script for non-technical execs — steal it)
|
|
“We’re good at closing accounts the week someone leaves. What I don’t have is proof of what is still open six months later — the shared logins, the API tokens, the vendor portals nobody thinks of as accounts. I want one afternoon to pull the last five departures and check every system against them. Best case, I hand you a signed record that access is clean. Worst case, we find a door somebody left open in March and close it on our schedule — before it becomes the thing we explain to a client.”
|
|
|
Boards don’t fund fear. They fund an afternoon and a one-page record either way it lands.
|
|
|
|
Next week’s Reader Q&A answers the winning option.
|
|
This week’s tool — AxiomLens
|
|
The afternoon produces the revocation log; keeping it true as people come and go is the grind. That rhythm — reviews on a schedule, evidence tied to controls, a board-readable report — is what AxiomLens systemizes: a local compliance engine over all 106 NIST CSF 2.0 subcategories that reports your coverage as a number and writes a board-ready report on demand. Built to be owned, not rented — one-time license, per named user, node-locked, and after a one-time activation it runs fully offline. It supports compliance documentation and audit-prep workflows; a tool, not a certification, and not legal, compliance, or audit advice.
One-time license — check the store for current pricing.
|
|
|
|
Sources:
CISA (KEV catalog, v2026.08.31) |
CISA (KEV alert, Aug 26 — the 2015/2019/2021 batch) |
CISA (KEV alert, Aug 27 — ownCloud, JFrog) |
CISA (KEV alert, Aug 31 — PaperCut)
|
|
THE SECURITY GATOR // BAYOU BYTES // EVERY TUESDAY
|
|
