Determining the Threats

 
 
By Brian Prince  |  Posted 2009-04-28 Email Print this article Print
 
 
 
 
 
 
 


 

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."



 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel