Security Architecture

Security Reference Architecture: The Wheel Does Not Need Reinventing!

No matter the size of the companies I’ve worked for, I’ve noticed a common theme: folks often suffer from the “Not Invented Here Syndrome” (NIHS). It applies to everything from applications to processes to standards and architectures. Obviously, NIHS doesn’t strike all management and staff, but if often affects enough people to make adoption of something like an industry standard architecture more difficult.

I’ve recently had an opportunity to work with multiple companies as they establish a formal Security Reference Architecture (SRA). Since I detest reinventing wheels, my team and I advocated adoption of the Cloud Security Alliance’s (CSA’s) recommended SRA.



The Cloud Security Alliance’s Security Reference Architecture 2.0 is robust, mature, and ready to use.

While I’ve been fortunate enough to enjoy considerable support, I’ve again seen NIHS rear its ugly head. I’ve tried to understand the arguments against using a known SRA, and I think they break down into these categories:

  1. No one else can know our technology or processes: The argument seems to be that an “outsider” could never know the intricacies of our business, so why adopt their recommendation? While I sympathize with this position, I think it’s misguided. Certainly, an organization like CSA doesn’t understand my business. But why would that matter? A SRA doesn’t mandate any particular process. Rather, it distills the areas of concern for a security architecture, and then it describes the way those entities interact. For example, version 2.0 of the CSA Enterprise Architecture lays out how business, operations, application, and security concerns come together to make an SRA. These domains are the same regardless of the specifics on an individual company. An SRA isn’t even a blueprint: it’s the principles upon which a blueprint is based. The blueprint is company-specific, and it’ll define how a company implements the SRA. This is where the company-specific knowledge comes into play — not in the SRA itself.
  2. We’re highly competent professionals who know what we’re doing: This is another argument with which I sympathize, but which (for me) falls apart on even a casual examination. Building an comprehensive and complete SRA takes a huge amount of time, skill, and experience. The more of those things, the more complete the SRA will be. To see what kind of resources CSA has, I looked at their corporate sponsors page. I’ve been in the industry awhile (I still remember blaming the TRS-80 Model II‘s cassette drive for eating my BASIC programs), and I’ve had experience across a broad spectrum of technologies from hardware to software, but there’s no way I could even pretend to compare to the depth and breadth of the experience represented on the CSA sponsor page. So, why fight it? CSA makes the SRA available for free — why not take advantage of that skill and experience?
  3. I’m not doing my job if I use someone else’s work: This is, to me, a more noble variation of the first argument. As a security professional (well, today at least), I can understand feeling guilty if I use someone else’s work to get mine done. However, I think this misunderstands where the real work comes into play. Selecting an SRA is just the first and easiest step. The real hard work, and the work I’ll shoulder, is implementing the SRA. This includes everything from determining where we are now relative to the SRA to business and other drivers that’ll determine the priority for deployment to the actual deployment steps. That’s a huge amount of work; it’s not shirking to use the wheel that’s already as a means to get started!

I think it just makes sense to keep standing on the shoulders of giants. If we don’t, we’ll just keep spinning our wheels — and making far less progress than we should.

Terrance A. Crow is the Senior Security Engineer at a global library services company. He holds a CISSP and has been writing applications since the days of dBASE III and Lotus 1-2-3 2.01.