Threat modeling key to pro-active security |
 |
By Nitin Bharti, News Writer
01 Mar 2006 | SearchSoftwareQuality.com |
|
|
SAN JOSE, Calif. -- Build in, don't bolt on. That was the mantra chanted at this year's RSA Security conference, where industry experts and vendors emphasized the need to bake security into the software development life cycle (SDLC).
"Threat modeling at the design phase is really the only way to bake security into the SDLC," said Michael Howard, senior program manager for Security Engineering at Microsoft Corp. and co-author of the book "19 Deadly Sins of Software Security."
To mitigate security vulnerabilities, Howard encourages developers to conduct code reviews, establish secure coding baselines and leverage tools such as source code scanners.
Threat modeling is the process of describing and cataloging threats; however, as applications become increasingly "connected," the complexity and sheer volume of threats have spawned the need for advanced tooling.
Although a good portion of vendors at the RSA conference pedaled shiny hardware devices for network security, an increasing number of companies, including Microsoft, are providing tools for threat modeling, intrusion detection and identity management.
|
|
|
|
|
Threat modeling at the design phase is really the only way to bake security into the SDLC.
Michael Howard
Senior program manager for Security Engineering, Microsoft Corp.
|
|
|
|
|
|
|
|
|
|
According to Akshay Aggarwal, senior security technologist for Application Consulting & Engineering at Microsoft, threat-modeling tools are helping to bring security upstream.
"Security used to be a bolt-on feature," Aggarwal said. "That clearly does not work. Platform providers need to arm developers with security mechanisms but also the
guidance to use those things [tools] securely."
Microsoft's threat analysis and modeling tool for .NET, which Aggarwal demonstrated to a packed audience during his session, provides an intuitive interface for both developers and managers, who can each view the technical and business risks, respectively, of addressing different kinds of threats.
Aggarwal pointed to the tool's attack libraries that provide a description of the attack, why it occurs, testing options and how to implement countermeasures for it.
"Threat modeling helps transform the nebulous cloud of 'bad things' into tangible security requirements," said Herbert Thompson, chief security strategist at Wilmington, Mass.-based Security Innovation.
Although identifying security requirements and process improvements are vital, like all IT endeavors, there is an inherent cost associated with those activities, Thompson said. Without executive commitment and security mandates coming from the top down, a security strategy will lack scope and direction, he said.
"There's a cost to mitigating risk," Thompson said. "You need to identify the costs of code reviews, threat modeling and secure requirements review." Upper management needs to support a security program, which means showing them the relationship between these activities and mitigating business risk.
The burden of software security
Security accountability was an important theme at this year's RSA conference. Attendees asked the experts who should ultimately be responsible for software security?
According to Thompson, security holes should not be viewed as deficiencies in an application; instead, they are "extra functionality" that the end user never asked for.
But does that mean developers alone should be held accountable for vulnerable applications? Delivering required functionality is already a momentous task, let alone having to account for the endless scenarios associated with security breaches.
"Security moves too fast for developers to keep up with," said Caleb Sima, co-founder, chief technology officer, director of SPI Labs at SPI Dynamics during the Secure Software forum panel. "A developer's job is to think about functionality, not security."
When a code-scanning tool reveals 50,000 security vulnerabilities, a developer won't care about security anymore, Sima said. "You simply can't apply vulnerability scanning techniques to code."
Security should be provided out of the box, seamlessly fused into the IDE, and more fundamentally, baked into the language itself, according to Sima. Declarative security is already possible today through techniques such as aspect-oriented programming and various assertion languages.
However, many security experts at the conference emphasized that secure applications depend not only on tooling, but on processes as well, which puts the onus back on systems analysts, developers and testers. Some of this responsibility does extend to the end users of software, Aggarwal added.
"End users must also have a secure development process, best practices and QA procedures in place," he said. "At some point, security does boil down to the user: If you post your username and password on a sticky note and paste it on your screen, nothing can be done."
|
|
|
|
