Why do we pen test?
A penetration test is a method of evaluating the security of computer systems or networks using manual or automated tools. Basically, we set some experienced folks out with the instruction to figure out a way to break the security of our own systems. This will usually come with some rules of engagement (no testing during business hours, don’t corrupt any of our production data, etc).
I’ve been a part of numerous penetration tests. It seems that every organization has them these days. For the purposes of this article, I am limiting us to internal penetration testing, not tests performed by customers or other third parties.
The reception testing receives varies wildly from department to department or person to person. Joe the network admin is eager to get the results of the test and see how his security measures hold up against an experienced penetration tester. However, Jan the server admin hears that a test is coming and starts shutting down services she knows are vulnerable. In reality, I see a lot more Jan’s than Joe’s. As a general rule, the response to a penetration test is a barely-covered groan, and gritted teeth.
So, why is there such a negative response to our penetration testing efforts? The primary issue isn’t that these technical folks want to hide from the truth. These are well-intentioned, competent professionals who truly want to create world-class information systems. Their reluctance to undergo a penetration test is directly related to how the results are relayed to them.
Oftentimes penetration testing becomes a ‘gotcha’ game:
- “You told us that there were no systems running telnet… GOTCHA.”
- “All your email servers are supposed to use TLS… GOTCHA.”
- “I found a Windows box still vulnerable to this old vulnerability… GOTCHA.”
When we get deep into the weeds of any penetration test, the results are not going to be pretty. Some systems don’t get patched like they should. Some servers get stood up outside the proper change controls. These types of exceptions cause penetration test findings and look bad. They are gotchas.
But is that why we’re performing penetration testing? Yes, there is value in documenting the exceptions so they can be fixed. But my take on penetration testing is that our goal is less about finding those specific failures than it is about tracking our technical risk trend. Are we becoming more secure or less? If we have more unpatched systems, this shows us that our enterprise patching process needs some tweaking (or maybe complete reworking).
Penetration testing is simply one way to measure progress over time
Before we can change the way our IT departments will react to our penetration testing, we must change the way we view, conduct and report them. No penetration test is ever going to come back clean. As the security department delivering the results, it’s important that we set the proper expectations. We are not performing this test to give a long list of To Do’s. We’re providing this as a snapshot of how risk mitigation is going, and where we should apply more emphasis going forward.
What do we do with the results of the test? If we’re simply handing them to IT and walking away, we’re missing a critical opportunity. When we deliver these results, we should schedule time to meet with the stakeholders, discuss the findings, and give meaningful, actionable steps for remediation. Just providing the findings will be seen as handing off the issue. We can become partners by working toward a solution that will satisfy both the security, resource and business requirements.
Remember, the goal of security is progress. Penetration testing is simply one way to measure progress over time. We support the business by showing them how they can improve within their constraints. Penetration testing may never be the most popular activity for IT, but if we stop saying ‘gotcha’ and start providing meaningful solutions to real problems, it can be a more welcome event.
Cross-posted from Enterprise InfoSec Blog from Robb Reck