Last updated at Fri, 22 Dec 2023 15:29:40 GMT
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 probably thinking “great! Now how do I do it?” I’m glad you asked. There are a number of ways to perform attack surface analysis, but the ways we’ll be discussing in this blog series are vulnerability assessment, penetration testing, red teaming, and purple teaming. First up is vulnerability assessments!
Vulnerability Assessments
Vulnerability assessments are focused on identifying vulnerabilities, not exploiting them. The purpose is to (1) identify and catalog assets / installed software, (2) discover if said software is potentially exploitable, (3) find open ports and the associated protocols, and (4) determine if system / network configuration issues exist. This is normally accomplished via either a commercially available vulnerability scanner (*cough* InsightVM *cough*), open-source tools (Nmap, OpenVAS, rumble.run, etc.), or a combination of both.
What types of activities do these vulnerability assessment tools perform? A non-exhaustive list of capabilities would include:
- Discovery scans. Usually very quick (time-wise) and, as the name implies, focused on discovery of systems and tcp/udp ports that are open.
- Unauthenticated scans. Without using credentials to log into discovered systems, this type of scan performs more detailed enumeration, which can include dns resolution, operating system type, services running, etc. (Think an nmap scan using the -A flag.)
- Authenticated scans. Utilizes credentials to log into discovered systems and perform even more detailed enumeration, which can include software vulnerabilities, system configuration issues, benchmarks against frameworks such as CIS, NIST, and more.
Vulnerability assessments are usually performed on a quarterly basis (at a minimum), when new equipment/systems are installed, or when the network has experienced a significant change. The output of said assessment(s) is a report which provides a comprehensive list of what vulnerabilities exist, what has changed since the last time the assessment was performed, and (ideally) a list of recommended actions to mitigate any discovered vulnerabilities.
The value of vulnerability assessment is that it is a non-destructive form of testing which enables you to take a pulse of the health of your network. It does this by establishing a baseline of your systems and their vulnerabilities, maintaining continuous visibility of your environment (i.e. ensuring only approved systems, devices, software, etc. are operating on your network), and making the business aware of the potential risks present. The challenges of vulnerability assessments are that they typically do not test vulnerabilities for exploitability, and that they ignore the “human element” (often the most vulnerable and unpredictable element in our environments).
I hope the information above is helpful as you determine which analysis strategy makes sense for you! Stay tuned for the upcoming posts in this series for additional analysis techniques to take your program to the next level.
