Application Security Architecture Review is a security activity done after the application architecture is defined and drafted and before the design starts. Most often, I get called to do an application security architecture review only to discover that people who want it done have no idea of what they wanted in the real place. This activity does not propose the security architecture but it reviews the existing architecture.
This activity cannot be done during your testing or development phase but in the initial stages. You need to do this even before you start coding because the more you delay considering security for your software, the more the cost goes up later to fix security issues coming out of the product.
You have put forth your business specification, drawn out how the functional requirements should be based on the business specification and drafted the technical specification also. For the given technical specification, how do you know that the technical controls used are fit for use with respect to security? For example, lets say that you want to use Tomcat.7.0 as the application server. How do you know that Tomcat has no security vulnerabilities? Lets say that you want users to register to your site using a registration module. Since you would be allowing anonymous users to use this form, you may also need a captcha though this is neither a business need or part of a functional specification. This captcha control is needed as part of a security need so that your form does not get abused by bots.
Now, that you know why we should be doing this activity, we need to define what we need to do this.
PRE-REQUISITES: A business specification (BSD), functional specification (FSD) and a technical specification (TS) document as inputs to you from your customer. As a security consultant, you would also need an application security architecture review checklist for the given technology so that you can go through the specification and review the security controls for every security domain.
- Get the documents first and go through it. Note down grey areas where you either don’t understand or need more clarification.
- Set up a meeting and clarify all questions. Sample meeting questions can be like what are the entry paths to the application, what will be the data validation approach, what privilege levels (roles) are being defined, nature of data used in the application (data classification) etc
- Analyze the entire specification and requirements based on the clarifications.
- Review the architecture based on application security architecture review checklists for the given technology/
- Provide your recommendation for mitigation.
- Provide the report.