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

With the level of security concerns about security, it is interesting that there is not more concern with a holistic focus on application security. Numerous articles are citing chilling statistics about security breaches, with the majority (some use the figure of 80%) being related to applications. It is not for lack of information as to what constitutes an “application problem”. One just has to go to the OWASP web site for more than sufficient information.

The issue, as I see it, is much more than the “what” and “how”, it is the approach that needs to be defined (and understood) as well as the “top ten”. In this, and the following series of posts, a modest proposal for a logical approach that would address the issues of how to define a secure application architecture (the plan), what would be the logical framework (the organization), what would be the steps that both the supplier (the application security architect) and the consumer (the software developer) would take to implement (the direction), and how would you assess the cost and effectiveness (the controls).

The basis of any security plan is that it must consider the threat model. In elementary form, it merely states that you can determine a set of possible attacks with a probability of occurrence to a set of assets that have a value worth protecting. So one needs to build a set of countermeasures to mitigate the effects of the threat that could exploit the defined vulnerabilities. It is considered “best practice” to define a set of threat models for, in this case, an application solution, so that the larger problem is reduced to a manageable set of smaller problems. This is the approach we will take as we course our way through the road map.

Clearly, there are two ways to approach the determination, and ultimately, the use of the threat model. Only when you use both will you have confidence that you have completely address all of the threats.

The typical approach seen in organization today is that of the reactive mode (some sources might use the term adversarial). The Software Development Life Cycle (and choose any one of a number of types) grinds forward with security, more or less, part of the “development” and “design” until the test and acceptance phase. There may have been some meetings to review the risks associated with the application solution, but the real crunch comes when the code is delivered. The security group gets involved and performs a true risk assessment, with both penetration and vulnerability testing at all layers. Vulnerabilities may be detected, assessed, and, if significant (cost-justified), a process of risk mitigation is planned and completed. The question is, in my mind, whether you really did address all of the threats and applied the appropriate controls or you went through an exercise in compliance. But compliance is not security!

The alternate approach gaining acceptance in a number of organization, perhaps for the savings in development cost, is that of the defensive mode. If a good security strategy is that of “defense in depth”, then apply it to the development cycle, and address the separate layers of development specification. Rather than the “gate review” for the security “check box” as the security architect judging the development architect, view the development architect as the security architect to work within the technical specification framework. With a set of standards, guidelines, templates, and training of developers, security become part of the logical architecture, reassessed when the review of the physical architecture is done, incorporated in the detailed design, and instantiated in the software. Now the evaluation of the acceptance of the software, which would include the penetration and vulnerability testing of the traditional (reactive) approach above, but would add the additional dimension of understanding the development view.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect