In this three-part series, we’ll explore key considerations and strategies for choosing an attack surface analysis strategy, and the ways it can be used to increase awareness of both technical and process-related risks. We’ll start with vulnerability assessment below.
BREACH!!! A word you may hear shouted in undersea thrillers such as Hunter Killer, Greyhound, or Red October, but one you never want to hear when it involves your own organization. But whether we want them or not, breaches can and will happen. It’s our job as cyber first responders to figure out how to stop them where and when we can, and mitigate the damage when one occurs. A key step in this process is figuring out what can be hacked. To do this, you need to see what an attacker sees—which is to say, you need to analyze the attack surface.
If “see what an attacker sees” is a bit too vague, a more technical (and verbose) definition of attack surface analysis (courtesy of moi, at a recent presentation) would be:
“Attack surface analysis entails mapping out what parts of an organization need to be reviewed and tested for security vulnerabilities. The point is to understand areas of risk; to make IT, security personnel, and leadership aware of what areas are vulnerable to attack; to find ways of minimizing the risk; and to notice when and how the attack surface changes and what this means from a risk perspective.”
In more practical terms, attack surface analysis consists of 3 tasks:
Identification of areas for testing
Externally facing applications/systems
Internal applications/systems
“The cloud” (cue ominous sound effects)
Personnel
Processes
APIs, web forms, file shares
Identification of high-risk areas
Identification of changes in the attack surface
You’re now probabl ..
Support the originator by clicking the read the rest link below.
