Security Brutalism Under Real Conditions, Part 6: Starting from Zero

This series has spent four parts on how to apply Security Brutalism and Survivability Engineering to programs that already exist. This post is for the organization that doesn't have a security program yet, or has one in name only. It covers what a solid baseline looks like, how to know when you actually have it, and why these foundations never stop being important, even for teams that have been doing this for years.

Start With the Baseline

A baseline security program isn't a compliance certification and it isn't a tool stack. It's a set of capabilities that answer the survivability questions for the systems that carry the most weight. Nothing more than that, and nothing less.

Start with a consequence map for at least five systems: authentication, customer data storage, payment processing if applicable, the production deployment pipeline, and source code. For most organizations these five account for the scenarios that would actually end the business, so map them before touching anything else. Know what failure costs for each one and whether that cost is recoverable or existential. Everything else flows from that list.

Build a working inventory of identities. Query the identity provider for every active account, human and non-human, pull IAM roles and service accounts from every cloud environment, and run secret scanning against code repositories. For every non-human identity, record what it can access, when it was last used, and whether it has a current owner, and revoke anything with no recent use and no documented owner right away. Unused credentials with no owner are exactly the path an automated attack will find and use.

Put MFA on everything. Every authentication path that reaches from the internet into any system should require a second factor and, if possible, a passkey based on biometrics. This single control removes a large share of credential-based attack paths, and it delivers the highest return per hour of effort for a program starting from zero.

Then, remove long-lived credentials to consequential systems. Standing API keys, service accounts with permanent production access, and credentials that haven't rotated in months are the access paths a breach converts into persistent intrusion. Rotate or revoke them, and treat a broken system as useful information about an undocumented dependency rather than a reason to keep the credential.

As you architect and build your systems, plan to deploy honeytokens in at least three locations. For example, a canary credential in a configuration file no longer in active use, a fake API key in an internal wiki or documentation page, and a canary database credential in an old backup directory. These cost almost nothing to deploy or maintain, and they produce near-zero false positives, so when one activates, something is actively looking through your environment. That's the first layer of detection, available to a two-person security team with no SIEM.

After that, set up logging on consequential systems, with a human who actually reads it. This doesn't need comprehensive SIEM coverage of everything, just logging on the five systems from the consequence map, shipped to an immutable log store where systems can write but never read or modify what's already there, and configured to alert on first-time access, access outside normal hours, changes to access controls, and unusual data volumes. Someone needs to read those alerts within a reasonable window, because a log nobody reads isn't detection. It's storage cost.

Run one tested restoration. Pick the most consequential system on the list, run an actual restoration from backup to a test environment, time it end-to-end, and document what broke or was missing. This single exercise tells you more about that system's actual survivability than any other activity, and if the restoration fails, that failure is the most valuable thing you can learn, far cheaper to discover during a scheduled test than during an incident.

Name an owner for each of the above, a person rather than a team. A baseline where every item has a named human accountable for it survives turnover and growth. Diffuse or assumed ownership decays the moment the person who built it leaves.

How to Test That It's Working

A baseline that exists on paper and a baseline that actually works are different things, and testing means more than reviewing documentation.

Run the survivability test on the most consequential system. Assume it's compromised right now, walk through what a realistic attacker can do with current access, and measure three numbers: how long before someone on your team notices something is wrong, how long to revoke all access to that system, and how long to restore it to a known-good state from the last backup. Write those numbers down and compare them to what you assumed before running the test. The difference is what you're actually working with.

Trigger one honeytoken manually. Access one of the canary credentials you deployed and time how long the alert takes to reach a human, how long that human takes to understand what it means, and how long before an investigation starts. An alert that takes hours to surface, or lands on nobody who knows what to do with it, means the detection capability isn't actually working.

Revoke your own access to a production system. Pick an account that shouldn't have standing access and revoke it, then watch whether any legitimate process breaks and how long it takes before someone raises it as a problem. A broken undocumented process points to a mapping gap worth closing, and if nobody notices for days, that silence tells you how much standing access in your environment sits idle rather than in use.

Try answering three questions from evidence, not memory. What identities have access to your most consequential system right now? If it were compromised this moment, what else could an attacker reach from it? When was the last time a backup was successfully restored? Any question that takes more than ten minutes to answer, or comes back as "I don't know", points to the gap worth closing first.

This testing should be mandatory because AI-assisted attack tools run continuously against exposed services, find misconfigurations before anyone reports them, and identify which credentials in which repositories stay active and what they can reach. None of that takes a sophisticated nation-state capability, just a moderately resourced attacker running automated tooling. An organization with no documented non-human identity inventory, no tested recovery procedure, and no detection on its most consequential systems isn't sitting in a stable waiting position, but in a state that automated scanning will find, characterize, and potentially act on while the security team is still building its program. The urgency behind the baseline is based on removing the easiest paths while the harder work continues.

AI-assisted attacks excel at a few specific things, and the baseline tries to address each directly. Automated credential discovery moves fast through secret scanning, so rotating credentials proactively removes the value of what gets found and revoking unused credentials removes access before it gets discovered at all. Scale lets AI-assisted phishing and credential attacks operate at a volume that makes low-friction access paths reliable targets even at low success rates per attempt, and MFA removes the value of that volume since a valid password alone stops being sufficient. Speed of exploitation keeps shrinking the window between a vulnerability becoming known and getting actively exploited, and a system where compromising one component immediately grants access to everything else offers a much faster path to the objective than one with bounded blast radius. Segmentation doesn't slow the initial compromise. It slows everything after it.

Mature Programs Need This Too

The baseline described here isn't a beginner program that mature teams graduate past. It's the foundation a mature program needs to maintain.

Mature programs decay. They accumulate tools, access grants, and service accounts faster than they review them. Permissions granted for a project that ended two years ago stay active, or detection baselines calibrated in a different environment never get reviewed as that environment changes. Frankly, I've seen a consequence map that came out of a workshop that nobody has revisited since the last acquisition.

A sixty-person security team can carry weaker foundations than a three-person team that has maintained discipline, because the larger team manages more complexity and gives the foundations more chances to decay. The survivability test applies just the same and so does the quarterly entitlement review and the tested restoration.

The most common failure mode in mature programs is foundations that were assumed stable while reality moved on underneath them, more often than a missing tool or an unfunded control. A solid standing program needs the same ongoing maintenance as any other security control, and that maintenance is exactly what the cadence in Part 3 is designed to provide.

As Part 5 discussed, the active layer of a security program, the specialist cell operating outside the walls with deception technology and continuous war-gaming, needs a clean environment to be effective. A mature program that has let its foundations decay won't get the value it should from that layer. Deception intelligence produced in a noisy environment gets buried, and war-gaming results against a poorly understood environment aren't actionable. The active layer makes the foundation more powerful, it doesn't replace one.

For a team that already has the foundations in place, the next priorities organize around three questions.

Is detection still calibrated to the actual environment? Environments change faster than detection rules, and a behavioral baseline built two years ago reflects a different system, a different team, and different access patterns. Review it, and treat rising alert volumes alongside dropping investigation rates as the signal that recalibration is overdue.

Has the consequence map kept up with the business? Acquisitions, new products, new regulated markets, and architectural changes all shift what the existential list looks like, and a consequence map that predates a significant business change is a fictional map being used to make real prioritization decisions.

Is recovery capability still real? Test it, not with a tabletop but with an actual timed restoration. A most-recent test older than six months means the recovery capability is assumed rather than known.

Remember, the foundation never stops being the foundation. What changes as the program matures is depth of coverage, accuracy of testing, and the extensions built on top of it, not whether it needs maintaining.

If you’re interested in building a stronger security program along these lines, you can reach out at Black Arrows.