LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Security As A Requirements Issue


By Adam Kolawa
March 1, 2007 — 
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.

Granted, it is possible to prevent some common security vulnerabilities if you take a general approach to security rather than treat it as a requirements issue. A requirements-based approach is not needed to prevent common vulnerabilities such as SQL injection, parameter manipulation, buffer overflows, cross-site scripting and so on.

However, the dangerous new breed of application attacks exploit application logic that was not designed with security in mind, so the only feasible way to prevent them is to consider security as a requirements issue, in the context of the specific application you are building.

For example, consider the recent attack where a retail application storing unnecessary credit card details permitted credit card counterfeiting. Or, the attack where the application gave many user accounts search privileges inappropriate for their roles; attackers managed to access accounts that had these excessive search privileges and use these accounts to potentially access hundreds of thousands of “confidential” personal records.

Running common security tests on such applications would have done nothing to stop such attacks. Preventing them would have required someone to have considered the potential for exploits, then define functional security requirements that made such exploits impossible.

For instance, let’s return to the attacks where the application gave many user accounts search privileges inappropriate for their roles, These attacks could have been prevented with functional security requirements that users in a class expected to access tens of records per year could only access tens of records per year—not thousands.

Defining, implementing and verifying functional security requirements really is the industry’s most powerful weapon against attacks on application security.

USING REQUIREMENTS APPROACH
So, how does a software development organization go about treating security as a requirements issue? First, someone needs to determine the security requirements and define them in a security policy. If the organization has designated security experts, they should be writing these requirements. If not, security consultants could be brought in to help develop appropriate requirements for the specific application under development. Obviously, this would require considerable interaction with the internal team members most familiar with the application.

Next, the development team needs to implement these security requirements as they write the code. Since most developers admittedly know little about security, it’s important to teach them about development practices for building secure software and show them how to apply those practices to their code so they can maintain it.

As soon as each security requirement is implemented, the development team should start verifying that it’s implemented correctly—just as they would verify any other requirement that they implemented. Many security requirements can be verified through custom static analysis rules. Others might require unit testing, component testing or other techniques. In any case, at least one test case should be created for each requirement, and every test created should be added to the regression test suite, which should be run automatically every 24 hours to ensure that code modifications and additions did not “break” or otherwise impact the previously verified security functionality.

In addition to verifying security requirements at the unit level, developers should be responsible for using static analysis tools to ensure that the code they write is free of common security vulnerabilities such as unvalidated inputs. As I mentioned earlier, this general automated code analysis is not, on its own, sufficient to guarantee security. However, since it’s such an easy way to eliminate some vulnerabilities, it would be a shame to ignore this low-hanging fruit.

Later, when the application can be exercised realistically (for example, when a Web interface is available for a Web application or Web service), penetration testing can be used to validate that the functionality is operating correctly at the application level. Although penetration testing is not an effective way to uncover the bugs in an application that was developed without heed for security, it is a very effective way to perform “positive tests” that can validate that attempted penetrations do not succeed.

Security needs to be built into the product from the earliest phases of development, with the support of a well-defined team workflow and an automated infrastructure.

Human intelligence is required the first time that a complex task is performed, but automation can typically be leveraged to repeat the task from that point forward. This frees team resources for the more complex and creative tasks that can’t be automated—such as anticipating additional vulnerabilities in the application logic, designing requirements that prevent them, figuring out how to implement those requirements in the code, and designing tests to validate that they are indeed safeguarding security as expected.

Adam Kolawa is chairman and CEO of Parasoft, which sells software testing products.


Share this link: http://www.sdtimes.com/link/30199
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading