IT is an interesting world, one where the Web is simultaneously a key driver for business and a popular gateway for attackers.
With both these forces at work, it shouldn't be surprising enterprises are starting to take application security more seriously. Statistics from a recent survey by the Open Web Application Security Project (OWASP) found that a quarter of the respondents plan to increase spending on Web application security.
That's a good sign, because there is no shortage of Web application vulnerabilities. But the situation also begs the question as to how businesses should go about the process of building security into the application development lifecycle, which while it sounds nice, can often be quite messy and requires sound planning.
According to Forrester Research analyst Mike Gualtieri, many application development teams hear "security" and think user authentication, authorization and encryption of sensitive data. Those are only pieces of the puzzle, however.
In her position as chief information security officer of the New York State Office of Temporary and Disability Assistance Division of Legal Affairs, Deborah Snyder has seen firsthand how misperception can color the security process.
"When I first began talking about the concept [of secure development lifecycle], security was viewed pretty much as having to do with access controls only," she said. "[It was] something you add on later or in the latter part of your development efforts to control simply who could access or get to the application, and who could access what within the data it houses."
Early on, it was clear no one quite knew how to build security into the software development lifecycle (SDLC), she said. But what soon became clear was that a secure SDLC required proper planning.
"There's a lot that needs to occur even before those development efforts fire up," she continued. "But the reason that I mention that and feel so strongly about it...is that early planning creates awareness and results in terms of more accurate resource projections up front because security has a list associated with it. And what usually happens if you don't have the resources? It gets left by the wayside."
It's in the planning phase that the project team gets a sense of the system or application they are trying to create through profiling it based on its criticality, the type of data it involves and the transactions it will support or enable access to, Snyder said. This list is later refined and mapped to controls that provide the appropriate level of information security regarding acceptable risk levels.
At that point, project teams start to identify and document their high level requirements based on things such as federal and state industry mandates, she added.
"The project team also begins to conduct a preliminary risk assessment to identify and document what's known to them at that time, knowing that obviously as you proceed you are going to uncover and articulate additional risks... then lastly they conduct a business impact analysis to start to understand the related consequences of any disruption to that system in the context of the business operation."
At Sony Pictures Entertainment, specific groups were formulated to manage and get better visibility into the development lifecycle. The groups communicate upfront to discuss strategy and approaches. It's a far leap from when Erika Pecciotto started there several years ago, when there really wasn't any application testing to speak of.
"We've put in several things, like a plan check, where projects first come through for funding," explained Pecciotto, executive director of enterprise technology and quality. "All the enterprise groups - like the architecture group, the testing group, etc. - actually [review] what type of project this is, making sure they properly budgeted for it, they properly planned out their tools, their resources and their approach as to how they're going to accomplish implementing a new application, a new service, etc."