I’m very excited to contribute my first series of posts to the new GTRI Technology Blog!
Recently, I have spent some time talking with GTRI customers about how to assess the information security posture of their organizations. While security assessments are nothing new for many of our customers, we are seeing an uptick in the level of interest in these types of engagements, especially among organizations that previously have not focused on security. These conversations often reveal confusion surrounding the different types of security assessments and when each should be used. For example, does your organization need a penetration test, a network vulnerability assessment, or a security architecture review? How about a risk assessment, a client-side vulnerability assessment, or a web application security review? Should your organization perform just one of these types of assessments, several of them, or even all of them? How often should they be performed and will they satisfy your compliance requirements? Clearly there is a lot to consider.
The purpose of this series of posts is to assist you and your organization in better understanding the different types of security assessments available in the marketplace and how to best utilize them.
Disclaimer: GTRI offers most of the services that I will discuss in this series however the purpose here is simply to educate. In that spirit I will also refrain from mentioning specific partners of GTRI.
There is one more thing to touch on before we begin. It is important to understand that security assessments make up just one part of an organization’s overall security program. It does no good to compile a long list of vulnerabilities if there is no systematic approach to understanding and managing the risks these weaknesses pose to the organization’s mission. Most importantly, please understand that building the capability to prevent, detect, and respond to security incidents is more important than any security assessment.
Network Vulnerability Assessment
The first type of assessment to understand is the network vulnerability assessment. Every computer network has vulnerabilities (weaknesses) associated with it and the objective of this type of assessment is to discover as many of these weaknesses as possible. After initial discovery, a security analyst eliminates false positives and the remaining vulnerabilities are prioritized based on quantifiable characteristics such as the common vulnerability scoring system (CVSS) score. This is an initial prioritization and it is very likely to change later when your organization performs a risk assessment. Network vulnerability assessments almost always involve the use of automated scanning tools to sweep a network range for live hosts, scan discovered hosts for open ports, and test open ports for known security flaws. Automation is very important in security however, as mentioned above, it is important to have a security analyst review the results, eliminate false positives, and provide organizational context to the findings. Ideally a network vulnerability assessment will be part of a larger, comprehensive vulnerability management program that tracks the status of vulnerabilities over time.
Network vulnerability assessments can be performed externally or internally. An external assessment originates from the Internet and is launched towards the organization’s externally facing assets like web sites, email servers, and firewalls. An internal assessment, on the other hand, starts with the level of access that an insider such as an employee or contractor might have. It is often very useful to perform multiple different internal vulnerability assessments, each one originating from a different part of the organization’s network such as the DMZ, a server network, a user/workstation network, software development or QA network, and so on.
Generally speaking network vulnerability assessments can be performed by organizations themselves or by a firm that specializes in these types of engagements. If your organization plans to use the assessment to demonstrate compliance with the Payment card Industry Data Security Standard (PCI DSS) you should be sure to use a firm that is designated as a PCI Authorized Scanning Vendor (ASV). More information on the PCI DSS requirements can be found here.
Network vulnerability assessments are very useful however here are some common mistakes to avoid:
Believing that a network vulnerability assessment is a penetration test: I will discuss penetration tests in an upcoming post in the series but suffice to say that attackers have far more tricks up their sleeves than a network vulnerability assessment can uncover.
Believing that a network vulnerability assessment will secure the organization’s web site: It’s true that most network vulnerability assessments will test discovered web servers for common vulnerabilities but that’s not enough! To identify the most damaging web server vulnerabilities like SQL injection, cross site scripting, and cross-site request forgery a web application security review should be performed. We will discuss this type of assessment in an upcoming post.
Relying too heavily on automated scanner output: Raw output from a vulnerability scanner is not a vulnerability assessment. It’s only part of it. Treating hundreds of pages of scanner output as though it is the finished product is a rookie mistake.
Trying to fix every discovered vulnerability in an environment: This is a costly mistake often made by inexperienced or overzealous security personnel. Attempting to fix every vulnerability without considering factors like the value of the underlying asset, potential impact of a successful exploit, existence of attackers capable of exploiting the weakness, and existence of controls in other layers of the security architecture, will result in exhaustion of both resources and the reputation of the security team. As mentioned earlier, this is where a risk assessment can be extremely valuable.
Believing that a network vulnerability assessment can stop spear phishing or other social engineering attacks: A network vulnerability assessment is simply not the right tool for the job to measure client-side vulnerabilities, weak operational security, or poor security awareness.
Relying on an assessment beyond its shelf life: Modern networks and the devices connected to them change all the time. New vulnerabilities are discovered daily and patches are released nearly as often. These factors combine to make the useful life of a single network vulnerability assessment extremely short. This is one of the primary reasons that it is so important to automate network vulnerability assessments and run them regularly.
Ignoring IPv6: A network vulnerability assessment that focuses only on the Internet Protocol version 4 (IPv4) is simply not adequate. Even if an organization believes it is not using IPv6 and even if an organization believes it is prohibiting the use of IPv6 by policy, the fact is that most devices on modern networks are capable of using IPv6. Indeed many organizations are surprised at how much IPv6 traffic is actually running on their networks. Attackers know all of this and take advantage of it.
In future posts we will discuss a number of other types of security assessments like web application security reviews, client-side vulnerability assessments, penetration tests and more.
Dave Herrald
