Building on my last article about Network Assessments, let’s take a closer look at vulnerability assessments. (Because entire books have been written on conducting vulnerability assessments, this article is only a high level overview.)

What is a vulnerability assessment?

A vulnerability assessment can be viewed as a methodology for identifying, verifying and ranking vulnerabilities (a “fault” that may be exploited by attackers) in a given system. That system could be a single application or an entire infrastructure, including routers, switches, firewalls, servers/applications, wireless, VoIP (voice over Internet protocol), DNS (domain name system), electronic mail systems, physical security systems, etc. The list of possible elements assessed could be much longer, but you get the idea.

Step One: Reconnaissance

Vulnerability assessments can be conducted with little to no information about the target system (black box) or with full information, including IP addresses, domain names, locations and more (white box). Of course, the less information you have about the system, the more reconnaissance you must do to conduct the assessment. Some of your reconnaissance might need to be done during the assessment itself, which could alter your attack profile.

Step Two: Attack Profile

Once an initial reconnaissance is complete, the next step involves developing an attack profile, which can be most easily compared to a military term: a “firing solution.” Essentially, when a target has been identified, it is the adversary’s responsibility to consider all the factors and options involved in attacking a target, including stealth, tools and evasion.

An attack profile should at least include the following elements:

• Determine IP addresses to scan
• Determine automated tools/scripts/modules to use for discovering vulnerabilities:
  • May include a suite of commercial tools from vendors such as Tenable Networks, Rapid7, Immunity, Inc., etc
  • May include a myriad of other commercial or freely available tools such as MetaSploit Framework, NMAP, Burp Suite, etc
  • Determine points of ingress/egress through Internet service providers
  • Determine filtering strategies/defenses in place

Step Three: Scans

After developing an attack profile, you must execute your scans using automated tools and manual processes to collect information, enumerate systems/services and identify potential vulnerabilities. As I mentioned, you might need to perform further reconnaissance during the attack, which may alter your profile. Being prepared to—and open to—adapting your profile as you gain additional information is vital during a vulnerability assessment.

In general, your attack profile should assess the following elements of security (including but not limited to):

• Authentication/authorization and session management
• Transport-layer security (SSL, TLS, etc)
• Susceptibility to Denial of Service (DoS)
• Web-based Cross-site Scripting/Cross-site Forgery
• Security misconfiguration (inadequate access controls, firewall rules, etc)
• Inadequate controls for SQL injection, web-based cookie injection, etc
• Inadequate input validation for web, database or other applications
• Remote code execution

In addition to traditional system scanning through automated or manual processes, many assessments also include social engineering scans, such as:

• Posing via telephone as an employee of the organization to obtain password access to email, VPN (virtual private network), or web-based applications, etc
• Phishing/spear-phishing attacks to validate corporate security policies and/or malware and anti-virus countermeasures, etc
• Searching for leaks of credentials or intellectual property through publicly available information such as search engines, social networking sites, etc
• On-site visits to pose as an employee and gain physical access to facilities, potentially dropping USB-based reconnaissance tools, etc

As you can see, vulnerability assessments can be very narrowly focused on a single system/application—or they can span an entire global infrastructure, including an organization’s external and internal systems.

Step Four: Eliminating False Positives

Finally, I’d like to touch upon one of the most important aspects in performing vulnerability assessments: eliminating false-positives and documenting remediation steps for your customers. Automated tools are only as good as the developers that create them. Security engineers must understand the applications, protocols, standards and best practices in addition to understanding when an automated tool is flagging a vulnerability that doesn’t actually exist (false-positive). Customers need to be confident that you are reporting real vulnerabilities, and they then need actionable steps for mitigation.

Of course, this isn’t everything there is to know about vulnerability assessments, but hopefully this article offers up a good snapshot of what’s important. Stay tuned for the next article in this series, where we will take a closer look at penetration testing.

See Neustar’s Professional Services for additional helpful information and services on vulnerability assessments.