The Second Job

The first of the Laws of Security is "know what you have", and that means being aware of your systems, processes, and networks, how they work together, and where each one ranks in criticality. However, ranking all that by what it would cost the business to lose them, and knowing what happens once the system at the top of that list breaks, are two separate jobs. Finishing the first does not answer the second.

The first job, as we saw before, is the consequence map, and building one works best as a short conversation rather than a company-wide audit. Sit down with whoever owns a system that would hurt to lose, and ask what the system does, what happens if it goes down for an hour, a day, or a week, what happens if someone destroys or exposes its data, and whether anyone has actually tested recovering it or everyone is simply assuming it would work. Classify the answer as existential, high-recoverable, or low impact based only on what the owner just said, and when the classification is unclear, call it existential, because treating something as more dangerous than it turns out to be costs far less than the reverse.

The map tells you where to look. Once a system lands at the top of the list, the second job is figuring out what actually happens when something goes wrong there. Three things drive that. How someone would actually reach the system? What can they do once they're inside? And how fast can you detect it, stop it, and clean up after? Each answer shapes the next one. A path that dead-ends somewhere unimportant poses less risk than one that leads straight to production, and you can't judge how long recovery should take until you know how bad the damage actually is.

Test reachability against the live environment, not the documentation. An access list or a firewall rule can say one thing while what actually gets through says another, and the difference only shows up under a real test. Retest it on a schedule, since what's closed today doesn't stay closed on its own.

The consequence map already holds a rough answer to the damage question, based on whatever the owner said about someone destroying or exposing the data. Check whether that answer is specific, for example, "some customer data would be exposed" isn't specific. It says nothing about which data or how many customers. Checking what an admin account on that exact system can actually touch right now turns a vague answer into a specific one. If you know the exposed data is 40,000 unencrypted social security numbers, you know exactly what you're protecting.

Recovery time comes from the same map. It already asked whether anyone had tested recovery. If the answer was no, a realistic, timed restore needs to go on the calendar this month, not next quarter. If someone has tested it, confirm the number rather than trusting it on faith. A result from eighteen months ago describes a system that has likely changed by now.

Work down the map in order, existential systems first, then the high-recoverable ones after that, and for each system aim to bring down all three areas (susceptibility, damage, and recovery time) together. Cut the paths in, limit the ability for damage to happen, shrink what's reachable once someone gets past them, and get the recovery time as low as a real, tested number allows.

Entropy has a say in all of this as well. Access changes, systems change, and a recovery number from a year ago describes a system that probably doesn't exist in the same form anymore. Rebuild the map and rerun the three checks on a fixed schedule, and start again whenever something material changes, since something always does. The map decides where to look, but these three areas of focus decide what is there once you arrive.