Customers often ask the following question: What is the best approach to securing my web applications? Of course, the answer to the question is what our web application security assessments are all about. But if you haven’t yet engaged in that process, this post briefly outlines some ideas that you can institute to have a greater degree of confidence that your web applications are secure.
Fundamentally, secure web applications are a result of a secure software development lifecycle. There are a number of books on the subject. I have found that a useful reference can be found through OWASP: http://www.owasp.org/index.php/CLASP_Concepts. What‘s necessary is for the software development team to have a structured set of guidelines to ensure that information security is kept as a key requirement as part of the development process. Often it is helpful to maintain an implementation guide and templates that reflect best practices. As with any endeavor related to security, I recommend a risk based approach where development effort to secure the application is guided by the risks to business.
In order to have an understanding of the risks associated with an application; developers must understand the threats that are present. A common practice is to develop a threat model that characterizes the threats and risks to the application. Microsoft has invested significant resources in formalizing this process. They recommend a step by step process of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development. To assist in this effort of threat and risk modeling Microsoft advocates a threat classification scheme known as STRIDE. This scheme aims to characterize the threats with respect to the exploit that may be employed. This clever acronym stands for:
- Spoofing Identity
- Tampering with data
- Information disclosure
- Denial of service
- Elevation of privilege
These areas provide a helpful mechanism for enumerating threats to the application. Closely associated with this process is a scoring scheme to help evaluate risk to the application. Another acronym applies to this problem as well: DREAD.
DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat. It stands for
- Damage potential
- Affected users
Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk. As always risk needs to be evaluated in terms of both probability and impact.
During the development process the team can often benefit from using tools aimed at identifying security flaws. The most prevalent approach used by security conscious developers is to employ source code analysis tools. These tools automate the process of evaluating source code for common security vulnerabilities. Many commercial tools have gained popularity and there are open source options as well, including RATS and Flawfinder.
As the application reaches the integration stage best practices call for black-box testing. Many commercial tools address this method of testing applications from a security point of view. Open source solutions exist as well including, Spike and WebScarab. I have found that one of the more effective processes calls for integration of the black-box test with the build cycle. In this fashion, when the application is built, the black box testing program is run as well. Once complete, developers can review the results and address vulnerabilities that have been identified.
The techniques described above help secure new applications, but organizations must also be aware of the risks associated with applications that are running in production. To assess these applications a different strategy must be employed. One potential approach is to run a black-box test with a suite of attacks that are known to be non-invasive and likely will not take down the application. Because this approach can miss many high impact vulnerabilities, I would recommend against it. A better option, given that the application is deployed in a virtualized environment, is to take a “snapshot” of the application to be tested. This image is then moved to a staging environment where it can be tested thoroughly. When vulnerabilities are identified the application must be fixed, tested and then released back to production under change control.
Hopefully, these notes on securing applications have generated some ideas regarding how you can go about improving your application security process.