How to build and run a security program when you are the entire security team.
A reference for the security engineer at a small multi-site organization — five clinics, roughly a hundred networked devices, a cloud identity provider, a vendor-hosted core application, and no one else to hand anything to. Healthcare is the worked example throughout, because that's the environment this was written from; the structural problem — owning identity, detection, vulnerability management, vendor risk, and incident response alone — is the same at a manufacturer, a credit union, or a fifty-person software company.
Most guidance in this space is written for organizations with a security team, then scaled down by deleting things. This is written the other way around: from the constraint that there is exactly one person, and everything that follows from it.
That constraint is not unusual. Below a few hundred employees, a dedicated security team is the exception — the security program is one person who also owns the helpdesk, the network, and the vendor relationships. That's a large share of organizations by count and a small share of the material written for them, which is the gap this tries to fill.
This is a blueprint — the program a security engineer should build at this size, with the reasoning behind each decision.
Where a section carries a Field Note, I built or operated that thing in production and the note records what actually happened, including what broke. Those come from detection engineering, endpoint telemetry and tuning, vulnerability management and remediation, network segmentation, cloud identity administration, and physical access control.
Cloud security posture and CI/CD supply chain controls sit slightly differently. I have built and run both, but in dedicated lab environments rather than in the clinical environment this document describes — a real isolated AWS account with a Prowler HIPAA audit, attack techniques detonated with Stratus Red Team, and custom detections written against the resulting telemetry, and a reusable GitHub Actions security pipeline with a coverage-attestation gate that fails the build when a scanner examined nothing. Both are published (see Related repositories). The lessons are real; they just aren't lessons from this environment, so they live in those repos rather than as Field Notes here.
Everything else is architectural guidance — researched and defensible, but not yet run by me. Application security is the main area in that category today.
I'd rather you know which is which up front than have to guess.
| Section | What's in it | |
|---|---|---|
| 01 | Reference Architecture | Trust boundaries and what enforces each one, identity as the real perimeter, the telemetry pipeline, inter-site connectivity models, and the known weaknesses |
| 02 | HIPAA Control Mapping | Every Security Rule standard mapped to a specific technical control and the evidence artifact that proves it, plus where the proposed rule update would change things |
| 03 | Tooling Decisions | What was selected, what was rejected and why, license landmines, and what the stack deliberately doesn't cover |
| 04 | Operating Cadence | Daily through annual, what each activity produces, and the degradation plan for when the cadence breaks |
| 05 | Metrics for Leadership | Nine metrics that change a decision, how each one can be gamed, and six commonly-reported numbers deliberately excluded |
| 06 | The First 90 Days | Sequenced by dependency rather than severity, with what's deliberately deferred and the three ways it goes wrong |
Silence is not success. A detection that has never fired in a test you ran is a hypothesis. A scan that returns fewer hosts than it targeted has not told you those hosts are clean. A collector that has stopped ingesting looks exactly like a quiet week. In a one-person program there is no second pair of eyes to notice, so verification has to be built into the rhythm rather than left to instinct.
A fix applied and a fix that worked are different things. Closure is proven by rescan, not by successful application. Every metric built on the wrong one of those inherits the error.
A control with no evidence artifact is an intention. If you cannot hand someone the thing that proves the control operates, it does not operate — for audit purposes and, usually, in reality.
Exclude the behaviour, not the software. Tuning is a fidelity problem, not a volume problem. The measure of a tuned detection is whether it would still catch the thing it was deployed to catch.
Attention is the scarce resource. Not budget, not tooling. An accepted risk documented with its reasoning is a legitimate outcome, and knowing when to stop investigating is a skill the literature almost never covers.
Every Field Note in this repository, in one place. Several appear in more than one section because the same incident carries a different lesson depending on where you meet it — a scan that silently dropped most of its targets is a compliance problem in §02, a metric integrity problem in §05, and a sequencing risk in §06.
| Incident | Lesson | Where |
|---|---|---|
| A detection loaded cleanly, passed CI, and never fired | Silence is not success; live-fire or it isn't a detection | 02, 03, 06 |
| A scan returned 4 of 28 targeted hosts, with no errors | Reconcile host counts against the target list before reading findings | 02, 03, 05, 06 |
| Two correctly-applied registry fixes didn't close the finding | Applied is not fixed; closure is proven by rescan | 02, 03, 05, 06 |
| Fleet-wide telemetry produced an unusable alert queue | Exclude the behaviour, never the software; tuning is a campaign | 02, 03, 04 |
| Three of seven designed detections were already covered natively | Enumerate platform alerting before building anything | 02, 03, 06 |
| Eight rounds spent on a sub-0.06 EPSS finding | Attention is the scarce resource; accepted-and-documented is a valid outcome | 03, 04 |
| Backhauled internet egress replaced with a policy-restricted overlay | Some performance problems are segmentation wins in disguise | 01 |
| The inter-site allowlist excluded the vulnerability scanner | Least-privilege constrains its author too; report the gap, don't quietly widen the policy | 01 |
| 226 discovered devices reduced to a 28-host scan scope | Scope is built from reconciled inventory, and exclusions get written down | 01 |
| An assessment returned zero KEV hits and nothing urgent | Report the boring result honestly; that's what makes the alarming one believed | 05 |
| Badge access and the identity provider are unlinked systems | An access review covering only the IdP is a partial access review | 02 |
| The badge system is a networked appliance | It belongs in the asset inventory and behind a boundary, not just on a wall | 02 |
| Security criteria entering at product selection rather than review | The recommendation decides the outcome; the review only objects to it | 02 |
This list grows. Cloud posture and CI/CD supply chain were built in dedicated labs rather than this environment, so their lessons live in the related repositories rather than as Field Notes here. Application security is the one area still carrying no lived work — guidance-only, as flagged above.
Detection, vulnerability management, and identity field notes in this document come from the first three repositories below. The last two are the lab-built cloud and CI/CD work referenced under Scope and experience.
- sigma-detection-pack — detection-as-code: Sigma rules mapped to ATT&CK, CI-tested, with the deployment notes covering the rules that loaded cleanly and never fired
- threat-model-casebook — STRIDE threat models for card-present payments, hosted online payments, and a multi-tenant SaaS API, including a real compliance-scope question resolved as an open question rather than guessed
- kev-epss-prioritizer — vulnerability prioritization by KEV membership, EPSS, and asset context instead of raw CVSS, run against a real authenticated scan
- aws-detection-lab — cloud detection engineering in an isolated AWS account: a Prowler HIPAA audit remediated from 38 to 49 passing checks, six techniques detonated with Stratus Red Team, and six custom detections with CI — where GuardDuty alone caught only two of the six
- secure-pipeline — a reusable GitHub Actions security pipeline (Gitleaks, Semgrep, Bandit, Trivy, Syft SBOM, Scorecard, cosign, OPA/Conftest) with a coverage-attestation gate that fails the build when a scanner examined nothing
Nothing here is legal advice. Breach determination, business associate agreement language, and enforcement exposure are questions for counsel; the engineering side is what's covered.
Nothing here contains real configuration, addresses, hostnames, or identifying details from any environment. It is a generic reference architecture throughout.
The regulatory content reflects the Security Rule as currently in effect. Rulemaking moves — verify current status before relying on any of it.