What Is A Penetration Test And Why Would I Need One For My Company?
With information security now being included in corporate risk strategies, it is vital to be able to answer the question: "How effective is my company's security in the real world?"
What is a Penetration Test?
There are a lot of different ways that penetration testing is described, conducted and marketed. Often confused with conducting a “vulnerability scan”, “compliance audit” or “security assessment”, penetration testing stands apart from these efforts in a few critical ways:
- A penetration test doesn’t stop at simply uncovering vulnerabilities: it goes the next step to actively exploit those vulnerabilities in order to prove (or disprove) real-world attack vectors against an organization’s IT assets, data, humans, and/or physical security.
- While a penetration test may involve use of automated tools and process frameworks, the focus is ultimately on the individual or team of testers, the experience they bring to the test, and the skills and wherewithal they leverage in the context of an active attack on your organization. This can’t be over-emphasized. Even highly automated, well-resourced, and advanced networks employing sophisticated counter-measure technologies are often vulnerable to the unique nature of the human mind, which can think laterally and outside of the box, can both analyze and synthesize, and is armed with motive and determination.
- A penetration test is designed to answer the question: “What is the real-world effectiveness of my existing security controls against an active, human, skilled attacker?” We can contrast this with security or compliance audits that check for the existence of required controls and their correct configurations, by establishing a simple scenario: Even a 100% compliant organization may still be vulnerable in the real world against a skilled human threat agent.
- A penetration test allows for multiple attack vectors to be explored against the same target. Often it is the combination of information or vulnerabilities across different systems that will lead to a successful compromise. While there are examples of penetration testing that limit their scope to only one target via one vector (example, a web application pen test conducted only from the point of view of the Internet browser), their results should always be taken with a grain of salt: while the test may have provided valuable results, its results are only useful within the same context the test was conducted. Put another way, limiting scope and vector yields limited real-world understanding of security risk.
What is the Value of a Penetration Test?
Here are a few of the reasons organizations invest in penetration testing:
- Determining the feasibility of a particular set of attack vectors
- Identifying higher-risk vulnerabilities that result from a combination of lower-risk vulnerabilities exploited in a particular sequence
- Identifying vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software
- Assessing the magnitude of potential business and operational impacts of successful attacks
- Testing the ability of network defenders to successfully detect and respond to the attacks
- Providing evidence to support increased investments in security personnel and technology to C-level management, investors, and customers
- Meeting compliance (for example: the Payment Card Industry Data Security Standard (PCI DSS) requires both annual and ongoing penetration testing (after any system changes)
- Post security incident, an organization needs to determine the vectors that were used to gain access to a compromised system (or entire network). Combined with forensic analysis, a penetration test is often used to re-create the attack chain, or else to validate that new security controls put in place will thwart a similar attack in the future.
As is apparent, there are many reasons penetration testing is conducted. Defining the scope and nature of a penetration test is largely dependent on what the drivers are for an organization, which will determine the stated goals going into an engagement. Those drivers may also influence other aspects of the engagement such as target selection scope, assumptions, and even funding ceilings that limit the amount of time a test team has to explore and compromise the organization’s assets. For example, if the goal is merely to ‘check off the box’ that says an organization has conducted penetration testing in order to meet compliance, then the scope and allocated funding may be much more constrained. Contrast that with an organization that is genuinely worried about its intellectual property and cares about the real-world risk to that IP from a motivated, skilled attacker’s perspective, and you might want to allocate a budget amount that will allow for a more thorough test.
This brings us to the most important question of the day: “What is the right kind of penetration for your organization?” If penetration testing is something that is mandated in your industry, you may be tempted to find the lowest cost automated pen testing service available so that in a few days’ time you’ll have a branded report on your desk and be finished. But there are a few considerations to think about before going this route. 1) If you are already going to allocate funds to do a penetration test, and since it is already mandated that you have one done, then whey not leverage the situation to gain the benefits of a more comprehensive and personalized test? 2) If you go with a light weight online pen test service and then get compromised later down the road, will you be able to rationally defend your selection of pen testing service, and the associated narrow scope of coverage? Ultimately, if we care about the security of our people and our data, it is the real world threat that counts the most. While compliance requirements may be a necessary evil, they do not equate to a necessarily secure environment. We’ve seen this time and time again in the Department of Defense in the context of meeting FISMA requirements. So much effort is spent meeting compliance requirements that sometimes actual operational security isn’t assessed adequately. It is easy to forget the reasons for having security in the first place when we are running around just trying to validate compliance, instead of analyzing real world threats and risks that are the ones that lead to eventual compromise. This is called “doing the job right instead of doing the right job.”