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...
| | View blog reactionsOne 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:
- What types of knowledge are key to secure software development?
- What does this knowledge look like (with examples)?
- How can my organization build the capability to capture, distill, share and leverage this knowledge internally?
- How can I integrate this knowledge into my secure software development efforts?
- How can I procure secure software?
- How attack patterns can be used to build better software?
- How does your company or team adopt a policy that will guide and inform developers so that they do the right thing the first time?
- Why the answer isn't in anti-virus or zero-day software products but in building better software...
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...
