Security Brutalism Under Real Conditions, Part 3: Knowing What You Have

Part 2 established the frame: survivability is the metric and the important question is how long you stay failed when something goes wrong. Before anything else can work, that question depends on a simpler one, what do you actually have?

Most inventories run outdated or inaccurate, and most security teams already know it. The CMDB carries systems no one touches anymore and misses ones built last quarter. The architecture diagram shows what someone intended two years ago. The identity list reflects hiring history more than current access. Every mature environment accumulates this drift silently and by no fault of anyone. It just becomes one under normal operating conditions.

This is important because susceptibility can't be evaluated for a system you don't know exists, blast radius can't be scoped for a system missing from the inventory, and recovery can't move fast when you're still learning which system got hit during the incident itself.

The inventory phase is focused on building accurate, queryable knowledge of what exists, what it touches, and what it holds in a way that is good enough to answer what can reach a given system and what it can reach within ten minutes for anything consequential. That bar is achievable. A full CMDB with perfect coverage isn't, and chasing it delays the work that actually makes more sense.

The fastest path to a working inventory runs through sources that already track what exists, rather than building from scratch. Start with your identity provider, since querying every application with an SSO or SAML integration surfaces every system employees authenticate to centrally in a single pull, faster and more accurate than asking teams to self-report. Follow with your cloud provider's resource inventory across every account and region, running compute, managed databases, storage, serverless functions, and load balancers, pulling all accounts if you span multiple providers, since orphaned accounts with running resources show up constantly after team changes and acquisitions.

DNS gives you your external surface. Pull the full zone, enumerate subdomains, and check certificate transparency logs for anything issued against your domains, including certificates you never authorized. A subdomain you can't explain deserves investigation before it becomes the path into something consequential.

Finance and expense records go underused here and they are awesome resources. Accounts payable usually holds a more accurate SaaS list than IT does, since payment approval leaves a paper trail that adoption never does. Pulling SaaS subscriptions from expense records and comparing them against what IT knows about exposes your shadow IT surface, which almost always runs larger than expected.

After the automated sources, talk to five people. Start with the engineering lead, the IT lead, the product lead, the operations lead, and the most senior engineer at the organization. Give each of them thirty minutes and one task: list the systems your team owns or depends on that would cause the most damage if compromised or broken. That conversation surfaces institutional knowledge about legacy systems and dependencies that never made it into any automated source because nobody wrote them down.

Identity and Consequence

System inventory is the easier half. The identity inventory holds most organizations' largest undocumented attack surface and it stays consistently underestimated.

Service accounts, API keys, OAuth tokens, CI/CD credentials, and machine identities outnumber human users in most environments by a large factor. They accumulate through integrations built and forgotten, automation that outlived its purpose, and turnover where nobody knew to revoke what the departing person provisioned. They skip headcount, rarely surface in audits, and just sit there holding permissions.

Finding them means querying the identity provider for non-interactive accounts, pulling IAM roles and service principals from every cloud account, checking CI/CD systems for stored credentials, and, very important, running secret scanning across the code repositories, since tokens committed to source or left in environment variables form a consistent and often unreviewed access path.

For each non-human identity, record what it accesses, when it was last used, and whether a documented owner exists. Anything with no recent activity and no owner gets revoked immediately, without waiting for the consequence map. Remembre that an unused credential with no owner is unambiguous attack surface regardless of what it touches.

That work sets up the consequence map. A working system list and a reasonably complete identity inventory give you what drives every prioritization decision in the program: mapping what it actually costs when each system fails. This isn't a risk register, and it needs no probability scores, maturity ratings, or CVSS numbers. It needs a real answer to one question per system, and that is "if this fails or is compromised, what does the business lose, and can that loss be recovered?"

Three classifications cover the map. A system is "existential" when the realistic worst case produces an outcome the organization doesn't recover from, regulatory action that shuts down operations, permanent loss of data the business runs on, financial liability that exceeds survival capacity, or reputational damage that permanently destroys customer trust, calibrated to the organization's actual capacity rather than an abstract standard. "High-recoverable" describes something costly but survivable, revenue loss measured in days or weeks, absorbable fines, customer attrition addressed over time. "Low-impact" covers what stays contained and gets readily restored with minimal business effect. When a system sits between existential and high-recoverable, classify it existential, since over-protecting something slightly less critical costs less than under-protecting something that turns out to matter more.

The consequence map gets built through structured conversations with system owners, not a form-filling exercise the security team runs alone. Security facilitates while the technical owner and business owner do the talking, and finance or legal joins for systems touching revenue, regulated data, or contractual obligations. Thirty to forty-five minutes per system, with a shared document open so everyone sees answers recorded in real time.

The questions run in order:

1. What does this system do? In one sentence describing business function, not architecture
2. What does it connect to, and what depends on it?
3. What data does it hold or process?
4. What happens if it's unavailable for one hour, one day, one week?
5. What happens if its data is corrupted or destroyed, not just the system going down?
6. What happens if its data is exfiltrated silently with no disruption to service? Who could be impersonated with it, and what obligations does that trigger?
7. What does recovery look like today, and has anyone timed a full restore?
8. Is there any realistic scenario where compromise of this system produces an outcome the organization doesn't recover from?

Question eight goes last, since people give more grounded-in-reality answers to the existential question after they've already walked through specific consequences earlier in the conversation. Asked cold, it almost always produces optimistic answers.

A few things deserve watching and keeping attention to during these sessions. Optimism bias shows up constantly, as system owners underestimate what compromise of their own systems would mean, and the way to counter it is tying the existential question back to what already came out of the session. For example, pointing out that admin credentials there would hand an attacker the billing system and the customer database, then asking what that looks like on day three. That produces a sharper answer than asking about impact in the abstract.

Probability creep shows up when participants push to attach likelihood scores to classifications. Redirect it without mercy, since the map runs on consequence only. Likelihood estimates shift too easily downward and defend too poorly, while what happens if compromise occurs stays far more stable and actionable than how likely it is.

This is why running these sessions with only the security team in the room produces a fictional map, since security can't know what financial exposure a system creates, what a trust failure looks like from the product side, or what the dependency chain looks like three teams away.

The End Result

What comes out of this is a working system list with owners and data categories, a non-human identity list with access and activity status, a picture of what's externally reachable and what it touches internally, and a consequence map ranking systems by what failure actually costs, each classified as existential, high-recoverable, or low-impact, each carrying a documented worst-case scenario and a recovery status of tested with a date, untested with a procedure, or unknown.

The systems at the top of the existential list are where the deep work starts, full trust relationship mapping, complete data flow documentation, and tested recovery procedures, and that work runs depth-first from the worst consequences down rather than evenly across every system.

The inventory and the consequence map don't run as sequential steps. A rough inventory gets you into the first mapping sessions, those sessions surface gaps in the inventory, and the consequence map tells you which gaps to close first. They build together, iteratively, and what results is sharper knowledge of what you have and what it costs, which becomes the foundation for every decision that follows.