Making Web Applications Secure

How Pennsylvania Vets Its Software
When the Commonwealth of Pennsylvania suffered a major security breach a few years back, vulnerabilities in a Web application were to blame. To prevent such a problem in the future, the state developed a centralized certification and accreditation process to review all applications before they can be used.

Because many different agencies have their own application-development teams, security can often be overlooked. To fix the problem, Pennsylvania developed a centralized system where developers must upload their source code to be scanned for vulnerabilities. according to Erik Avakian, chief information security officer for the commonwealth.

The process "bakes in security from the ground up," Erik Avakian, the state chief information security officer, says in an interview with Information Security Media Group's Eric Chabrow (transcript below).

The state's Web-app review system scans source code and applications, checking them to ensure they're compliant with internal policies and controls. "It's a workflow, really," Avakian says of the process. "But it also ensures that the application, once it's finally vetted through the process, gets an accreditation seal of approval from us."

Pennsylvania uses this review system for applications that deployed several years ago. The system also reviews all applications every few years. If changes are made to an application, Avakian says, it must go through the process again.

In the interview, Avakian explains how:

  • The system vets new and legacy applications.
  • Software that must be deployed immediately is eventually evaluated.
  • Automation helps speed deployment of secure applications.

Pennsylvania promoted Avakian to state CISO in June 2010 after serving 3½ years as deputy CISO. Before joining state government, Avakian spent more than a year as a security consultant to the commonwealth. He holds a number of certifications, including Certified Information Systems Security Professional, Certified Information Systems Auditor and Certified Information Security Manager. Avakian studied finance at Bentley University.

Centralized Review Process

ERIC CHABROW: Please explain the state government's centralized approach that assures applications deployed on its systems are secure.

ERIK AVAKIAN: One of the things that we're doing that I don't think a lot of states are doing is in the areas around application security when it comes to certification and accreditation, and I think that's a pretty hot topic just because a lot of the different threats - a lot of the Web threats - are really based around application security.

CHABROW: Tell me a little bit about what you're doing in that area?

AVAKIAN: We have an application certification, our CA2 process as we call it. It's a process that basically bakes security in from the start as applications are developed. We have a lot of different agencies in the commonwealth and they all have their own application-development teams, but what we've done is we've created policies and procedures around when people do develop applications they have to go through a certification and accreditation process, which basically bakes in security from the ground up.

The processes it goes through that we provide are source-code scanning and Web-application scanning. We make sure that early on the application is compliant with all of our internal policies and controls so that whatever they're doing, whether it be what kind of authentication-authorization processes they're using, it all comes around to complying with our current policies. In the past, when it comes to application development, application security in the commonwealth was lacking, and as a result, the commonwealth several years ago was successfully attacked, sequel-injection attacks, that were successful due to the poor programming and security around Web apps that were actually out there on the Internet.

To get a handle on that, what we've done is we have a process where all of those new applications that get developed have to go through this process. In addition, all the applications that have already been in production for those how ever many years have to go through the process as well. Then we do a review every so often, every few years, and this is all in our policy that we have, they have to get revisited for recertification. If there are changes to the application they also have to go through the process again.

All this is done within a centralized system, so the agencies can actually upload their source code and then we can actually upload our completed scans, so it's kind of like a back-and-forth system with the agency submitter so that they can see where things are in a queue. It's a workflow really, but it also ensures that the application, once it's finally vetted through the process, gets an accreditation seal of approval from us, and if it's not secure or if there are things where an application has to go live because of whatever mandate, or if there are risks, then we put together a remediation strategy where they have to do it by a certain amount of time, and that also goes in the process. It's an effective way of actually not only documenting where applications are from a risk basis, because from this application we could take a look at applications and see where our risks are, where our highest critical applications are and where the risks are based on whether an application has security flaws or issues or things that need to require remediation, but it's a good way to just control that from an entire database standpoint. You're basically improving the security of the Commonwealth bit-by-bit as you get to all these different Web applications.

Automating the Process

CHABROW: How much of this process is automated?

AVAKIAN: That's a good question because we're getting it to do more from an automated standpoint. There are a few components and we talk about the scanning component. There's source-code scanning, there's Web-application scanning, there's host scanning and then there's an application, a centralized application, which I was talking about. The centralized application is an automated process, so once somebody submits a CA2 request to us, it starts the flow. E-mails get sent out by the system. They can upload their source code. Going from one phase to the next, we have the initiation phase, certification phase, accreditation phase and then a finalization phase. That's kind of automated by the system that's doing it and different e-mails are getting sent out to people automatically based on which phase it's in, including the reviewers.

But the actual scanning component, the Web-app scan, source-code scan, those are manual right now, but we're getting to the point where we've incorporated some new technologies, some scanning tools in the commonwealth where we can now do automated Web-app scans. We're just implementing that now. We're trying to get to an automated process, but it's going to be tough when you talk about things like source code to really incorporate a fully automated process.

CHABROW: Is that because it's primarily the source code and to understand the programming language, they actually have to look at it and see if there's a flaw or something that's not meeting certain controls, unapplied or applied?

AVAKIAN: Right and because there's that developer, you have to converse with the developers and we're also getting to the point where we're going to get some of these tools into the developers' hands so that they can start doing these scans, but right now all of these scans our team is performing this process, and we vet the security of commonwealth applications. It definitely works because of the CA2 process. Just by doing some of the scans that we've done, we have found significant vulnerabilities in either existing or new commonwealth applications, and obviously when you're dealing with applications that have to do with sensitive data, protecting that data is critical to not only safeguarding it from the citizen standpoint but ensuring that we meet the citizens' trust.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing healthcareinfosecurity.com, you agree to our use of cookies.