1 Raindrop: Software Security Pair Architecture

James McGovern recently asked how to find and identify software security folks. The current situation in software security on the hiring side is not good: one colleague compared it to looking for Apache people in 94. I think that is accurate, but with one exception - webmasters scale pretty well. Software security practitioners don't. An Apache person can manage several instances of Apache which can then handle several projects each. Software security folks can really be on 2-3 projects at most at any given time. For enterprises with thousands of apps this ain't exactly scalable.

So if you can't find 'em what do you, grow 'em yourself. Spike Lee made the point in "He Got Game" that it was easier teaching a basketball player to act (Ray Allen) than teaching an actor to play basketball. In software security it is frequently easier to have people with software background learn security than to teach the security people (who may come from an audit or network background) about software. In the end the software security people collaborate closely with software people so a common language, understanding of how to operate in a process (or lack thereof) and way to communicate design decisions is an important factor. This is just a general statement though effort will always win: cf. Robert Deniro in Raging Bull.

Another way to approach this is to learn from "The Only Sustainable Edge", companies need the ability to dynamically specialize in different areas as systems and business models evolve. In our industry's case we spent the last 15 years connecting enterprises and consumers without worrying too much about security and now we are going back trying to secure the apps. To achieve dynamic specialization one way to do it, the authors suggest, is to bring together talented individuals with diverse backgrounds and deep specialization in different areas and give them aggressive performance targets.

The development methodology XP proposed pairing programmers, the same may be done with software security architecture. Pairing individuals who have both security and software backgrounds can potentially scale better (2 inboxes, 2 processors), you have a large knowledge base to draw from that can understand security protocols, software, and deployment logistics. Be careful to avoid the dreaded design by committee, and use the software security architecture pair to do two important things:

1) Help design and build secure software

2) Help avoid spending time and money on the wrong things. Sagans and sagans of dollars and hours are wasted on spinning around questions like is this access management or identity management? Or is it federation driving this?

Software security architects drive benefits to the companies they serve through both of these.