It is less expensive and less disruptive to discover design level vulnerabilities during the design, rather than discovering them during implementation or testing, forcing a costly re-design of pieces of the application. For example, if proper authentication of administrators is not built into the program from the beginning, it is much more time consuming and risky to fix during the final QA phase.
What is involved in the testing phase for vulnerability identification?
Application testing should be conducted by QA people who understand the importance of testing security as well as functionality. QA should apply security testing processes that test that the security features are working properly. Additionally, they should perform negative testing to determine how the application handles unexpected data such as long strings, special characters, and error conditions. QA should use a problem tracking system to prioritize security issues alongside other program defects so that security issues can be fixed just like any other program flaw. Common methods to test applications include load testing tools and tools that will generate input data for cross-site scripting, SQL injection, and buffer overflows testing.
What are other threats and countermeasures for mitigating application security risks?
Threat modeling and countermeasures are important steps in the secure development lifecycle, ideally done when the application’s design is near completion. Threat modeling is an exercise in which developers identify the assets or pieces of sensitive information that the application houses which need protecting. Countermeasures can be used to test the application to ensure it does not leave private information vulnerable to potential attackers. Input filtering—one example of a countermeasure—is a technique used by programmers to protect an application from attack by limiting the size and format of input to exactly what the application is expecting. For example, if an application is designed to accept a username that is all alphabet characters and a maximum length of eight characters, the application should reject all input that is longer than eight characters. This will help protect the application from performing unintended operations from unexpected input. Developers should also closely examine bandwidth, CPU time, and disk space in order to mitigate denial of service risks.
Developers should employ a thought process in which they imagine themselves as an attacker who knows everything about what the application can do. Then they should enumerate and categorize those threats to come up with ways to mitigate the risks. If there aren’t ways to mitigate the threats, the design should be changed and re-implemented.