Why Pen Testing Is Central to Pennsylvania’s App Security

Fortify Co-Founder and Chief Scientist Brian Chess made a stir last year when he predicted — incorrectly, so far — that penetration testing would be a dead art in 2009. Among those who shrugged off the suggestion was Robert Maley, CISO for the Commonwealth of Pennsylvania.

In this Q&A, Maley — a customer of Core Security Technologies — explains how pen testing become an essential piece of his strategy to keep citizens’ personal data out of enemy hands.

MORE ON THE FUTURE OF PEN TESTING:

• Article: 3 Ways Pen Testing Helps DLP (and 2 Ways It Doesn’t)
• Opinion: 12 Reasons Pen Testing Won’t Die

Describe the environment you are responsible for.

Maley: My environment includes roughly 47 state agencies, boards and commissions, which comprises about 77,000 employees, 80,000 endpoints and 5,000 servers that my office is ultimately responsible for. We have agencies with remote offices all across the state, at least 1,000 locations.

Then there are citizens who don’t work for the state but regularly access your applications to pay bills and such?

Maley: You can pay taxes, get fishing and hunting licenses, renew driver’s licenses, register to vote, basically get every service the government has to offer. There has been a long-standing drive for e-government services.

Given that you’re processing cardholder data online, what have you had to do to meet the demands of PCI security compliance?

Maley: We don’t store cardholder data here, but we do handle the transactions that are then passed on to the bank. This is where penetration testing is important. We use internal vulnerability scanning to find and mitigate vulnerabilities before bringing in an outside vendor for additional scanning. We’ve had a lot of success with this approach so far.

Describe how pen testing has been woven into your core security procedures.

Maley: We have what’s called CA2 — Commonwealth Application Certification and Accreditation — patterned after the Department of Defense’s accreditation process for systems. We focus ours on Web-based applications. One of our challenges is that, like a lot of organizations, we have to be mindful that a lot of Web-based apps are the target of cross-site scripting and SQL injection attacks. Here in the Commonwealth we’ve had applications developed for years and years with no real underlying security process. So we have to constantly search for things that can be exploited and mitigate the problems before something happens. The bad guys are escalating their SQL injection attacks. We see these attacks constantly, in the thousands. Why are they doing that? Because there are so many vulnerabilities out there and they know they can eventually hit something.

Was CA2 designed to find the flaws left behind over time, or to catch flaws during the development of newer apps?

Maley: It injects security in at the very beginning of a project now. Whether a Web application is developed in-house or outsourced it now has to go through the CA2 process before going live. Part of that process is that the programs have to be pen tested.

Brian Chess at Fortify Software caused some controversy when he said pen testing was a dying art. You obviously disagree.

Maley: Source code analysis is also a critical part of our CA2 process. Early on in the certification process that’s what we require and it helps us tremendously. But application flaws are not the only thing we look at with our pen testing. Both are critical to our risk mitigation and I don’t see one replacing the other. They really go together. With PCI DSS, an important ingredient is vulnerability scanning. An automated pen testing tool allows me to go through and review vulnerability scans and see in real time what kinds of weaknesses can be exploited. I don’t see that as something you can replace.

Describe what your pen testing schedule typically looks like and, if possible, give an example of when you were able to catch and stop an attack through the process.

Maley: We don’t randomly go out and pen test things. We don’t have that kind of time. We use it at a specific point in the CA2 process. We also use it as a specific piece of the compliance process. Meantime, if we suspect something like an SQL injection attack against a certain app, we go back and do pen testing. One innocuous Web page with job descriptions was subject to such attacks. Through pen testing we were able to extract info about every state employee and their dependents through that page. So we shut it down and did a thorough investigation. We keep all our log files and were able to pinpoint the point in time where attackers started trying to target the data. That’s the kind of success we have had.