Security As A Requirements Issue

By Adam Kolawa

March 1, 2007 — (Page 1 of 4)
Software development organizations are never going to produce truly secure applications until they understand that security is not something you can begin worrying about ad hoc, after the application is written. The common response to securing applications has been to attempt to identify and remove all of the application’s security vulnerabilities at the end of the development process. However, this bug-finding approach is not only resource-intensive, but also largely ineffective.

PATHS TO DISASTER
In fact, such an approach could lead to a disaster because testing can never find all of the security vulnerabilities that might be in a piece of software. Why? Finding errors is an NP-complete problem, which means there are always an infinite number of paths through the application. You can’t guarantee that all those paths are free of vulnerabilities because it’s simply not feasible to identify them all and then test each and every one of them for every possible vulnerability.

Penetration testing is really inefficient at finding errors. What penetration testing does is try to create conditions under which an error can be discovered. This is very difficult. It needs to find the right paths to hit potential vulnerabilities, and then determine if the vulnerabilities can actually occur. This will find some errors—but is unlikely to expose all of them.

Scanning the code with static analysis security tools can also find some vulnerabilities. However, even data flow analysis, which is commonly recognized as the most sophisticated breed of static analysis, has its limits. Since only a limited number of steps are followed, some paths or path segments will be overlooked. Moreover, today’s applications lack an obvious starting point because they are data-driven and event-driven. Finding and following all paths through such applications is difficult. As with penetration testing, some problems might be exposed, but others will certainly be overlooked.

A more practical way to ensure that software is free of security vulnerabilities is to approach security from the perspective of requirements. The application behaving in a way that does not reveal confidential information or allow unauthorized actions is just as critical as its ability to provide new features or to enhance the scope of existing ones, so the application’s security requirements should receive the same consideration and treatment as its functional ones.

Pages 1 2 3 4

Share this link: http://sdt.bz/30199

Technorati

Digg

Slashdot

Facebook

Friendfeed

Twitter

del.icio.us

Cigital Develops Ready-to-Use Tools for Securing the Smart Grid Cigital Inc. announced the release of the Guide to Developing a Cyber Security and Risk Mitigation Plan.

Department of Homeland Security lays down security suggestions Common Weakness Enumeration version 2.0 highlights flaws in software development practices

Metadata Security for SharePoint Adds Security Permissions Titus Metadata Security for SharePoint allows permissions to be assigned based on the recipient's Active Directory properties

Cigital Develops Ready-to-Use Tools for Securing the Smart Grid
Cigital Inc. announced the release of the Guide to Developing a Cyber Security and Risk Mitigation Plan Read More...