eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.”
Determining the Threats
A key part of the SDLC is threat modeling. In a paper entitled, “Use Threat Modeling To Develop More-Secure Applications,” Gualtieri wrote that the first step in threat modeling process is to draw a data flow diagram (DFD) of the application’s architecture. The diagram should illustrate all the application’s architectural components and the data that flows through and between them, and depict “trust boundaries” such as firewalls or access to external systems.
“Your threat modeling will only be as good as the diagram you draw to represent your architecture,” he wrote. “For example, if your application stores credit card numbers and your drawing does not include a data store shape for the credit cards, then you will not be able to analyze the threats for that component.”
One of the more widely used threat modeling solutions is Microsoft’s SDL Threat Modeling Tool. While the market for such products is not especially mature, threat modeling is important nonetheless, Gualtieri said.
There are a number of inherent limitations to the tools, including their use of pre-defined situations, the inability to adapt to allow for application-specific threat scenarios and the fact they don’t relate threats to financial impact (losses), said Snyder, CISO of the New York office of temporary and disability assistance.
“The danger with any approach (to threat modeling) is performing it as a “one time task” and relying on this baseline, rather than considering it an essential component of iterative risk management integrated into the SDLC,” she said.
Still, threat modeling is necessary. At Sony Pictures Entertainment, the threat modeling process is mostly brain-storming and whiteboarding based on known vulnerabilities and replacing bad practices with best practices. The end result of its approach to SDLC has been a drop-off in bugs – though it’s not always easy to tell.
“I would say we’re definitely seeing less, although it’s a little hard to judge by the metrics because the pace of the vulnerability discovery is just so rapid,” said Jeff Cox, senior software engineer at Sony Pictures Entertainment. “But I would say overall we’re seeing classes of different types of vulnerabilities just kind of disappear…very generally, a lot of the Web application vulnerabilities are input-based, so they’re lacking basic validation. Once we were able to sort of educate our developers why you have to validate everything that’s coming into the application they really sort of knocked those categories right out.”
Perhaps the No. 1 reason why there are so many vulnerabilities is because there is so much code.
“Just think of how many SELECT statements that open access to a database you have in your application,” Gartner analyst Joseph Feiman said. “Potentially every one, every single SELECT, is a subject potentially for SQL injection. So the number of SELECT statements will not decrease; the number of databases that you should address will not scale down, therefore you cannot eliminate those entrances to the databases, therefore each of those potentially is a target for SQL injection.”
Ideally, application security needs to get to the point where teams of security auditors and pen testers are not the ones catching 95 percent of the vulnerabilities, David Grant, director of security and compliance for IBM Rational, told eWEEK.
“We got to start moving that, closing that down so that it gets to a point where security auditors become the last step and they’re a quick check box,” he said. “They’re not catching 100 issues in an application; they’re catching maybe one.”