8 Keys to a Successful Penetration Test
Pen tests are expensive, but there are key factors that can make them worth the investment.
September 19, 2018
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blte14d8a30255832c8/64f0d66819d3276982672517/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
In 1880, Prussian Field Marshal and military theorist Helmuth von Moltke the Elder wrote what can be translated in English as, "No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force." He meant that all plans are great until they run into reality.
That statement resonates today in cybersecurity. Many security professionals vet their security plans with reality via a penetration test, aka pen test, where a red team of white-hat hackers does their best to defeat the defenses established by the blue team of security. It is frequently an eye-opening experience for the blue team and their managers.
While virtually every security plan for an organization of any size calls for pen testing, these exercises tend to be expensive and frequently disruptive. It pays to make them as effective as possible. So what's the difference between a costly pen test that puts a tick in a check box versus one that's a legitimate tool for improving security?
Putting in the work to properly prepare for a pen test can lead to solid security benefits for the organization. More than half of the steps to a solid pen test occur prior to when the testing begins. That's not terribly unusual - aphorisms about practice, planning, and perfection are common - but it reinforces the idea that pen testing is not the sort of activity that can be taken lightly. And if it's going to be most effective for the organization, it can't be taken as an activity just for the sake of making auditors, regulators, or insurers happy.
The following steps for a successful pen test were gathered from personal experience, conversations with professionals including Tod Beardsley, director of research with Rapid7, Yonathan Klijnsma threat researcher at RiskIQ, and Stephen Boyer, founder and CTO of Bitsight Technologies, as well as numerous discussions with researchers at Black Hat USA and DEF CON 2018.
Have you been part of a pen test that has been highly valuable - or not? What steps did you find critical to making the pen test matter? Let us know in the comments section below.
What's the point of performing a pen test? Is it to fulfill the requirements of an audit? Do you need to know how a new application will fare in the real world? Have you recently changed a major component of your security infrastructure and need to know whether it's effective? Or is a pen test something that is on your schedule to perform on a periodic basis as a health check for your defenses?
When you're clear about the reason for a test you can be clear about what you want from the test - and that makes planning the test much more productive. Among other, critical, aspects, knowing the reason for test will allow you to properly establish the scope of the test (more on that later) and determine just what the results of the test will tell you.
Perhaps the most important piece of this step is that it sets up the team to draw the right conclusions from the test results. If the test is intended to look at a single aspect of the IT infrastructure (a new Web application, for example) then it will say very little about the overall security of the organization. An understanding of why the test is being run sets you up to ask the right questions and get results that can be properly understood.
Gaps are critical to security. The gap, for example, between an enterprise network on the day it went live and today, can be a wide open door if an attacker knows the gap better than the organization's IT staff.
It's not the job of the pen test team to map your network. If they are doing that job, it means that there are implications of their results that you're likely to miss because they'll be overwhelmed by the network architecture messages you'll be getting.
An up-to-date network map (including both logical and topological aspects) should be considered a mandatory prerequisite for a pen test. If the pen testers are telling you things about your network that you didn't already know, then you're paying for a very expensive network map.
Just how wide should the red team to cast its net? The answer will depend largely on why you're conducting the test, because too wide of a scope can be just as unhelpful as one that's too narrow.
The problems with an overly narrow scope are obvious: If the problem you're looking for is outside the scope of the test, then there will be no data provided that can help determine the component's security. So it's vital to make sure that the test's parameters include the components that are critical to your current security questions. In particular, you should decide whether you're looking at security generally or the performance of a particular system, and whether or not human factors (susceptibility to phishing and other social engineering attacks) will be included.
If the test's scope is too broad, then two problems can occur. The first is financial: Tests become more expensive as the scope increases, and tests for which the price and the needed information are out of step tend to limit executive enthusiasm for future tests.
The second is more pernicious. When the scope of the test is too broad, the test is likely to return too much information and the data you need could easily be lost in the sheer volume of the test's findings. The lesson is clear: If you want to test the security of one piece of your architecture, then limit the pen test to that piece. Save the full system test for another time.
Once you know why you're conducting the test and how much of your infrastructure will be included in the test, it's time to start planning, and it's important to build a strong set of test requirements rather than anything that's loose or subject to interpretation. There are several reasons for this, but most have to do with controlling cost and increasing the test results' usability.
A strong test plan will be present in several phases. In one, it will help the commissioning organization solidify their request for a test proposal. In another, it will help firm up the type of data expected to be returned from the test. In yet another, the plan will be vital in justifying the test's expense to the executive committee.
Building a strong test plan at this stage doesn't mean there won't be the opportunity for revision later in the process. Once the testing team is hired, they may have suggestions about testing elements that will deliver more useful results for one or another requirement. The key is that, by internally agreeing on the plan now, the security team will be able to judge whether the pen testers' proposals will satisfy the test requirements - rather than simply working within the strengths of the testing team.
There are many companies and consultants who will conduct a pen test for you. Those companies each have areas of strength and weakness, technologies, and techniques in which they are more or less competent, and ways in which they are better or worse at presenting results. It's your organization's job to make sure that the testing group's strengths match as closely as possible the needs of the test.
Notice that it's the needs of the test - not the needs of the customer - that are emphasized. While there are certainly groups that might be better or worse at tasks like navigating a particular RFP process or getting on an approved vendor list, those skills might or might not accompany skills at performing the test activities required by a plan. It's important not to let skills at accounting and administration become more important than skills in testing when judging a pen testing group.
Consider how adept the testing group is at making suggestions to improve the test plan presented to them without steering that test in an entirely new direction. This is one of the points at which the strong test plan developed earlier in the process is critical. It functions as a check on any changes later in the test.
In general, we want to be told that we're doing well. It's human nature. But the purpose of a pen test is to show an organization the facts about its security, so it's important to let the pen testers do their jobs without trying to give an unfair advantage to the defenders.
The fact is that the red team almost always penetrates the perimeter to some extent. It's the nature of the exercise and of our current technology. The real question, in many cases, is how quickly the blue team understands that a breach has occurred and how they respond to the breach.
Regardless of the facts presented in the results, it's important to allow the process to work so that the results are factual, accurate, and useful. That can't happen if management tilts the scales in either direction, so be sure you're keeping hands scrupulously off the test until after it's completed.
Once the test is over, you'll have a full report to wade through. The pen testers should present you with the results, and odds are you'll have the opportunity to make improvements in your security systems. Seize that opportunity.
It's possible that the pen test was conducted to fulfill regulatory requirements. It's even possible that you weren't looking for any reason to make changes to your security. That doesn't matter. Your security has now met "the enemy's main force" and you can see where your plan has succeeded and where it has not.
A pen test becomes much more cost-effective if the results are used to make meaningful changes. And cost-effective pen tests are much more likely to lead to executive support for security investments in the future.
For most organizations, the results of a pen test don't stay in the security group. At the very least, there will be implications for the IT department as a whole, and in many cases there will be information that executives need to see.
For many security professionals, telling the story of the pen test to non-security managers is the hardest part of the process. Not only do you have to tell them what was done and why, but you also have to explain the need for change in language that makes sense to them. That often means putting it in business, rather than technology, terms.
Just as a pen test can be seen as practice for a real attack, it can be useful to enlist colleagues in other departments to provide test-reads and an audience for practice presentations to make sure that the message received is the same one you want to send.
Cybersecurity is scary and confusing for many line of business managers; build a story that gets the point across without leaving them either trembling in their seats or with their eyes glazed over from a barrage of jargon.
You've taken the time to plan and execute a solid pen test; now, make sure that the results are useful to the entire organization.
For most organizations, the results of a pen test don't stay in the security group. At the very least, there will be implications for the IT department as a whole, and in many cases there will be information that executives need to see.
For many security professionals, telling the story of the pen test to non-security managers is the hardest part of the process. Not only do you have to tell them what was done and why, but you also have to explain the need for change in language that makes sense to them. That often means putting it in business, rather than technology, terms.
Just as a pen test can be seen as practice for a real attack, it can be useful to enlist colleagues in other departments to provide test-reads and an audience for practice presentations to make sure that the message received is the same one you want to send.
Cybersecurity is scary and confusing for many line of business managers; build a story that gets the point across without leaving them either trembling in their seats or with their eyes glazed over from a barrage of jargon.
You've taken the time to plan and execute a solid pen test; now, make sure that the results are useful to the entire organization.
In 1880, Prussian Field Marshal and military theorist Helmuth von Moltke the Elder wrote what can be translated in English as, "No plan of operations reaches with any certainty beyond the first encounter with the enemy's main force." He meant that all plans are great until they run into reality.
That statement resonates today in cybersecurity. Many security professionals vet their security plans with reality via a penetration test, aka pen test, where a red team of white-hat hackers does their best to defeat the defenses established by the blue team of security. It is frequently an eye-opening experience for the blue team and their managers.
While virtually every security plan for an organization of any size calls for pen testing, these exercises tend to be expensive and frequently disruptive. It pays to make them as effective as possible. So what's the difference between a costly pen test that puts a tick in a check box versus one that's a legitimate tool for improving security?
Putting in the work to properly prepare for a pen test can lead to solid security benefits for the organization. More than half of the steps to a solid pen test occur prior to when the testing begins. That's not terribly unusual - aphorisms about practice, planning, and perfection are common - but it reinforces the idea that pen testing is not the sort of activity that can be taken lightly. And if it's going to be most effective for the organization, it can't be taken as an activity just for the sake of making auditors, regulators, or insurers happy.
The following steps for a successful pen test were gathered from personal experience, conversations with professionals including Tod Beardsley, director of research with Rapid7, Yonathan Klijnsma threat researcher at RiskIQ, and Stephen Boyer, founder and CTO of Bitsight Technologies, as well as numerous discussions with researchers at Black Hat USA and DEF CON 2018.
Have you been part of a pen test that has been highly valuable - or not? What steps did you find critical to making the pen test matter? Let us know in the comments section below.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024