Road Map for an Application/Software Security Architect (Part 2)

Vulnerability testing at the acceptance stage of an application’s Software Development Life Cycle (SDLC) will not compensate for the lack of an understanding of what is being done during the software development even though you may not have control over the development efforts. You need a plan that puts those controls in place and allows that governance. Ignoring vulnerabilities will not prevent breaches.

Remembering back to building a risk assessment plan, we can build a similar plan for application security, but with the intention of engagement at predefined points in the SDLC for _every_ software solution (or application) that might also raise concern for a risk assessment. The application security plan needs to cover the same set of tasks that a risk assessment might cover and would have a similar set of assignments of a RACI (Responsible, Accountable, Consulted, Informed) matrix.

The first step is to establish the purpose and objective of the program. The program’s main purpose is to reduce the number and level of “bad” design and application programming habits. The intention is to determine the effectiveness of the plan by measuring how effective it is in avoiding mitigation efforts. This assumes that there are appropriate policies as well as “tone at the top” in place (or else this becomes the first and most significant prerequisite prior to organizing the plan). But that does not answer how to measure the effectiveness. Partially, a baseline evaluation of the history of solutions and applications previously submitted for risk assessments, and the results obtained, especially, if any further effort was required for mitigation is needed. Having never performed a defensive risk assessment before, it is easy to miss the “unknown knowns”, so part of the object of the program will be to identify what has been “missed”.

The second step is to establish the responsibilities for this plan The team that is responsible for the development of the plan may be the same team, or designates, that will be responsible for implementing the plan. While on the surface this may be a pure technical “play” (let the architect’s handle this!), in reality it is a cooperative effort that involves input from the business users (or at least the ones that are the most involved in development of the significant services), the security officer (and the team that does the current risk assessments), the audit and controls types (for advice) and the application architects. Involved in this process will be senior management since it should be fully expected that the SDLC process will be affected: you will need a Security Review Board (SRB !!) to intercede at various points (gates) of the SDLC.

The process entails the identification and classification of the assets, which need protection because they are vulnerable to threats. But in this case, we will not need to assign to the classification a priority or an impact value, but an assigned standard (or guideline) in which to measure the effectiveness in meeting the classification. In an application assessment, the primary asset is “data” to which we assign vectors that would impact the security (and privacy protection) of the data. We will evaluate the vectors in the light of the threats and the vulnerabilities that it might expose.

In this plan, we are addressing the identification of the exposure and how to handle that exposure, either through a certain set of standards and guidelines that would be from a library of information and documented experience. Obviously, this library would grow with the repeated iterations of additional projects. The intention is to drive the knowledge of the appropriate behavior of applications in regard to security to the application architects and detailed designers from the security architect and the security team.

Next post … identifying the classification of vectors

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect