In the simplest terms, the “attack surface” is the sum total of resources within your infrastructure that could be exploited. The attack surface has been branching out in multiple directions with the rise of new computing functions (virtual, software-defined networking, IoT, containers, public cloud, private cloud, federated networks). It’s a massive hassle for security professionals to manage.
There is a four-step process to reducing your attack surface, however, and we’re going to tackle the four steps in a series of posts.
First: visualizing your vulnerabilities. Networks built for the previous century had no context around visibility, but the ones being constructed now are designed with visibility in mind. Stands to reason, too: if you can’t actually see your resources and understand how big the attack surface might be, everything else is for naught, right?
Many enterprises use vulnerability scanners to figure out their visibility issues. That’s a good start.
Problem: Vulnerability scanners will give a severity score to a specific asset, application or host, but the score is incomplete without showing just how an attacker could reach the weak spot. Knowing that bombs can level buildings is not the same as locating the missile’s launch pad and understanding its booster strength.
Rather, you need a three-pronged attack to increase visibility:
Attack Surface Modeling: This is in and of itself a three-pronged approach. It combines an understanding of network assets, topologies and policies to reveal just how the system can operate in the real world. Assets are the stock of everything you have in-network; topologies show the potential paths to a vulnerable asset; and policies essentially make the whole model three-dimensional by letting you visualize potential attacks in the distance.
Attack Simulation: Attack simulation allows you to take a small input (change) to the network and see how any of your vulnerable exposures could turn to exploit. What if we moved this asset? What if we changed the topology and routing rules? What if we added (or removed) this policy? What if an attack came in door #1, what would happen next? All of these questions can be answered with attack simulation.
Patch Simulation: This lets you organize your patching efforts, quickly seeing the asymmetric effects of a given fix. For example, your vulnerability scanner may reveal 782 weak spots in a specific subnet. But patch simulation allows you to speed up security by showing the single patch that can reduce those 782 exposure points to a handful. Just as with attack simulation, a small input can have a dramatic output. This is dramatically better than random patching, which has somehow emerged as “strategic” in some enterprises.
How does FireMon play into all this? Glad you asked. We actually do all of this for thousands of clients. Our suite helps in creating models from existing rules, scoring your risks and simulating attacker movements that could lead to exploit.