The Risk Rancher Field Manual, Ch. 2: You Can't Brand a Ghost

August 21, 2026 · 7 min read · #security, #vulnerability-management, #risk-rancher, #asset-inventory

Part of The Risk Rancher Field Manual, a hands-on guide to starting, scaling, and running a vulnerability management program.

You cannot protect what you do not know you have. Every program that falls apart falls apart right here, at the very start, because somebody bought a scanner and pointed it at “the network” without first asking what was actually on it. The scanner found three thousand things. Nobody could say which of them mattered, who owned them, or whether half of them even still existed. The program drowned on day one, in a lake of its own output.

So before the scanner, the inventory. Before you can hunt, you have to know the herd. This chapter leaves you with a short list of the systems that matter most to you, each with two labels and a human’s name, and that list is the fuel for every chapter after it.

The thing that gets you is the thing you forgot

The vulnerability that ends up in the breach report is almost never the one you were watching. It is the dev box somebody spun up in 2019 to test something, left running, and forgot, with a copy of the production database still on it. It is the marketing microsite nobody has logged into in two years. It is the storage bucket a contractor made public “just for a second.”

Attackers do not care about your org chart or your intentions. They care about what is reachable and soft. And what is reachable and soft is, nine times out of ten, the thing that fell off your map. You can run the most disciplined patching program in the world on the servers you know about and still get owned through the one you forgot. That is the ghost problem, and inventory is the only exorcism.

Do not try to count every cow

Here is where people overcorrect and die the other way. They hear “you need an inventory” and they launch a Configuration Management Database project, a two-year, cross-departmental march to catalog every laptop, printer, and VM in the company. These projects are a graveyard. They are never done, they are wrong the day they ship, and they burn the goodwill you needed for the actual security work.

You do not need to count every cow. You need to find the ones worth rustling.

Start with one brutal question: what would genuinely end us if it got popped? Not “what is a risk.” What would be a very bad day. The customer database. The public-facing application. The box that holds the domain admin credentials. The source-code repository. The payment system. For most companies that is a list of ten to thirty things, and you can write it down in an afternoon. Get those named, and you have mapped most of your real risk for a fraction of the effort a full inventory would cost. The rest is cleanup, and cleanup can wait its turn.

How to actually find it

The good news in a cloud world is that your estate is programmable, so you can ask it directly instead of guessing. A few hours with the right queries beats a year of spreadsheets:

• Ask the cloud. Every cloud has a way to list what you are running, from the console or the command line; an API is just that same question asked by a program instead of a person. In AWS, aws ec2 describe-instances, aws rds describe-db-instances and aws s3 ls list your servers, databases and storage buckets; GCP and Azure have the same three questions under different names, and every one of them has an Export button in the console. Paste the results into one sheet. That is your raw herd.
• Sweep your own perimeter. Export every name from your DNS provider, the service that turns names like app.example.com into addresses, and every public address your cloud or ISP has given you. Those are the doors on the street, where the attention is.
• Follow the identity. Whatever your people log in through (Okta, Google Workspace, Microsoft Entra) has a list of every application connected to it. Each one is a system you own, even if nobody remembers buying it.

As you go, tag each thing with two fields that matter more than any other: how bad is it if this is compromised, and who can fix it. Everything else is detail. The output is not a five-hundred-tab spreadsheet. It is a short, ranked list of crown jewels, each with a human’s name beside it. Here is the one the rest of this book runs on, sample-assets.csv, eight rows:

The notes column uses three shorthands you will meet again. PCI scope means the card-industry rules apply to that system. PII is personal data about real people. SSO is the company login that sits in front of a system. Two other columns do real work later. Criticality is how bad it is if the thing is compromised: crown-jewel, standard, or dev. Exposure is who can reach it: the whole internet, only people inside your network, or an isolated lab that nothing else can see. In chapter six you will multiply by both, and a scanner’s “Critical” on an isolated dev box will land near the bottom of your list while a “Medium” on the internet-facing payments system lands near the top. No tool sets these for you, including the one this book ships with; discovery is your job or your cloud’s. Anyone selling you “fully automatic asset discovery” is selling you a scanner with a markup and a nicer logo.

The most important column is a name

When people build an asset list, they obsess over the IP, the hostname, the operating system version. Those matter. But the single most important column is the one most inventories leave blank: the owner. The name of the human who can actually make the change.

An asset without an owner is a vulnerability you will never close. You will find the hole, you will write the ticket, and it will sit in a void because it is addressed to nobody. Half the reason vulnerability programs stall is not technical at all. It is that the finding has no home. So when you build your short list of crown jewels, do not stop at “payments-api.” Stop at “payments-api, owned by the Payments team, and the lead’s name.” The sample file keeps only the team name in its owner column, because teams outlive people; when the book needs a face for a team later, it will give one. Now you have something you can actually act on.

Try it. Download sample-assets.csv: eight assets, each with a criticality, an exposure, and an owner. That is the shape you want, not a CMDB, a short ranked list with a name in every row. Now build your own. Open a sheet with the same columns (asset, criticality, exposure, owner, notes) and fill it with the ten to thirty things that would genuinely end you. Mark each one crown-jewel, standard, or dev, and internet, internal, or isolated. Do not stop until every row has an owner’s name. You will use those two labels to score real findings in chapter six, so the list you build here is the engine’s fuel, not paperwork.

That is the whole inventory this book needs: eight rows, or your own ten to thirty, each with a criticality, an exposure and an owner. Chapter six scores findings against the first two; chapter seven addresses tickets to the third. It is also, as it stands, the file the tool takes: Configuration, Asset inventory, Load inventory, and the same five columns go in with no retyping. From then on the tool scores every finding that lands on a listed asset the way chapter six will teach you to. The owner column is shown beside the asset, not acted on; handing findings to a person is a separate rule in chapter ten, because that needs an email and this column holds a team. Once you know what you have, and who owns it, you have earned the right to turn on a scanner and point it somewhere that matters. But a scanner is only as good as the relationship that turns its findings into fixes, and that relationship is with the people who hold the wrenches. Before we cast the net, we need to talk about not being hated by IT.

← Back to the blog