Friday, March 17, 2006


Thoughts on Security Reference Architectures

Frequently, in my blog I mention the notion of Reference Architectures. Approximately two weeks ago, we finished up creation of our 1.0 version of our Security Reference Architecture that is well received. The funny thing is that while we were creating it, we found that most security-oriented practices within large enterprises seems to be infrastructure focused and never have taken the step to address the software development lifecycle. Anyway, wanted to seed the thoughts of the community as to why each enterprise should consider creating their own...

One of the greatest challenges in the widespread adoption of software security as an industry practice is the shortage of truly knowledgeable and experienced experts in the field. There simply aren’t enough experts available to disseminate expertise through the old training & apprenticeship model. Luckily, much of the key knowledge that makes an expert an expert can be captured, distilled and shared among a larger population than a single expert could effectively reach. This is one of the goals that Reference Architectures solve for.

Simply capturing Reference Architectures as a body of knowledge does not automatically elevate every practitioner to the level of expert, but it does represent the experience base of many more experts than any given practitioner would otherwise have the opportunity to learn from. Distilled knowledge such as principles, guidelines, rules, weaknesses, vulnerabilities, exploits, attack patterns and historical risks are foundational to the maturation of a secure software development capability.

The Burton Group seems to be the only industry analyst firm that appreciates security as a distinct discipline. If there are other analyst firms with deep coverage of secure software development, I would love to hear from them. Anyway, the goal of a Security Reference Architecture is to capture several key types of knowledge of significant value to the software security practitioner, an architecture showing their interrelationships and mutually supportive value, and appropriate touchpoints and methods for integrating them into the security-integrated SDLC.

Should Chief Security Architect's in the Fortune 200 enterprises have as a responsibility of their day job to create Reference Architectures? Minimally, these folks should be asking themselves the following questions:

The funny thing that also isn't much discussed or even understood is that the notion of security reference architectures could help demonstrate compliance with regulations like Sarbanes-Oxley, credit card regulations or HIPAA. I suspect many will struggle with where software policy fits in relation to IT policy, software best practices and other organizational policies.

Speaking of policies, many off the shelf policies that enterprises purchase tend to be ambiguous. A security reference architecture could make it unambiguous and most importantly testable...

Links to this post:

Create a Link

<< Home
| | View blog reactions

This page is powered by Blogger. Isn't yours?