Yet, in the age of compliance (at least from a short-term funding standpoint) is pen testing still relevant? Before we decide, let's take a moment to define penetration testing. I also call it "security assurance," and define it as anything and everything that tests where and how corporate networks, systems and applications can be compromised, as opposed to flagging theoretical vulnerabilities.
Compliance requirements aside, penetration testing is an absolutely critical aspect of any security program. Attackers test every company's defenses every day. An organization either knows what the bad guys are going to find, or it doesn't. If it doesn't, it will be surprised, and security professionals, CFOs and CEOs all hate surprises.
Great pen-testers think like hackers. They use the same tools and techniques, only they tend to be much more comprehensive in their testing of attack scenarios. This is a key aspect of my Pragmatic CSO methodology, and focuses on doing the right thing because it helps organization's become more secure.
Connecting compliance and pen-testing
Remember that compliance still remains one of the most powerful funding sources security folks have. For some reason, the bean counters haven't figured out that being compliant doesn't mean an organization will be secure, so they are still willing to throw a lot of money toward compliance efforts. So let's dig down a bit and figure out just where and why a pen test should be a critical part of a corporation's compliance efforts.
The most obvious reason for pen testing is that many of the regulations, such as PCI DSS, SOX and HIPAA require an annual penetration test from a third party. Yet an annual pen test is not nearly enough, since an organization could be compliant today and compromised tomorrow, or even worse – compromised yesterday.
Pen testing can also be justified by using the "scanning" or vulnerability management requirement within PCI, which requires scanning of networks, systems and applications, as does HIPAA and GLBA. But a pen test isn't a scan, now is it?
On the surface, the answer is no. But in a lot of cases, the data coming from a pen test is much more valuable than the reams of paper generated by a vulnerability scanner. The pen test tells security pros what can be compromised, not what is vulnerable. It tests not only systems, but also people, which are usually the path of least resistance for attackers.
Just because a device is vulnerable doesn't mean it can be exploited. Perhaps the device is behind two layers of firewalls or can't be reached by external parties. There are lots of reasons why a vulnerable machine may not be exploitable. A scanner will tell security professionals it's a problem. A pen test will assure them that it isn't, and that provides a lot of value.
Positioning pen-testing for compliance
If there is a worry about whether an auditor will accept a pen test, as opposed to a vulnerability scan, it's all about positioning. The auditor may need some convincing that the security team is in control of the process. The more detailed, actionable information the auditor gets, the more confidence they are going to have. If many of the issues discovered in the pen test are fixed, the only conclusion an auditor can draw is that things are OK. Of course, nothing is perfect, but I'm confident it will look better than folks mired in a morass of open vulnerabilities.
Pen-testing should be a key aspect of every security program, which means a process should be built to constantly test security defenses. Pen-testing results help to focus remediation efforts, which will bring a smile, or at least a disbelieving smirk to any auditors face. Sometimes that's a major victory, and we security folks need to take victories where we can get them.
About the author:
Mike Rothman is president and principal analyst of Security Incite, an industry analyst firm in Atlanta, and the author of The Pragmatic CSO: 12 Steps to Being a Security Master. Rothman is also SearchSecurity.com's expert-in-residence on information security management. Get more information about the Pragmatic CSO at http://www.pragmaticcso.com, read his blog at http://blog.securityincite.com, or reach him via e-mail at mike.rothman (at) securityincite (dot) com.
This was first published in May 2008