Good Read: Today's Security Matters

Is Bruce Schneier the only smart person in the world or in the security world? I ask this facetiously, but he is the only security expert who continually advocates trying to solve security problems sensibly.

In his Security Matters blog he wrote an excellent essay Lessons From the DNS Bug: Patching Isn't Enough about the flawed practice of security patching software. It's a clumsy process of trying to rush out fixes and keeping the details of the problem a secret. It's a wasteful mess.

Schneier advocates getting good security people involved in the design process from the beginning. By bringing the security mindset to the table early real security measures can be integrated into the design and the ability to efficiently and discreetly adapt to unknown threats can be built in like any other feature.

In my own experience participating in software design and development for applications that contain valuable information I know that even in these cases security is not a first class citizen. Although I make no claims of being an expert, I do try to look at systems with the mindset of someone who would try to exploit it and see how the system could be improved. I've had friends who are criminals and hustlers. From them I learned a lot about how people will exploit a system.

One of these acquaintances, a professional gambler, taught me a lot about how an opportunist's mind will work. I consider myself fortunate to learn what I did from this person. I held daily conversations with him over the course of a year. What I learned from him is he, and people like him, has absolutely no regard for rules. If he can find a way to get an advantage he will exploit it for all it's worth.

One example: he found out that Target had a generous 90 day return policy on big screen televisions. My friend purchased something like ten of them at the beginning of college football season to set up in his war room. When the return window was ready to close he returned each one of them. He had a 10 televisions for 3 months for free. He had tons of stories about exploiting a system. The stories about online gambling sites were even worse--don't be surprised if the other 7 players at your online poker table aren't on a conference call discussing how to take all of your money.

He would apply this mindset to everything he did. When it came to gambling he wouldn't place a bet unless the odds were clearly in his favor.

I don't know many people in the software industry who can think like my gambler friend besides the aforementioned Schneier. When I raise security concerns in software projects people usually look at me like I'm crazy.

When security is part of a project requirement it's usually treated like an add on or a layer to an application. Ok, we added security, what's the next feature? Many software designers think of security as a firewall, if you have that security layer then you don't need to worry about it in the rest of the design.

The way that software projects are typically set up there is no incentive up front for the participants of a project to take security into heavy consideration. Embedding security into an application adds scope and risk to a project being delivered on time. Dateality is a premium of projects.

Often times security issues become apparant during the development and testing phases of a waterfall project. Those issues are probably best fixed with a redesign, but the old patch approach really looks good to keep the project on schedule.
Until security, and the ability to efficiently adapt to changing security conditions, is perceived to be as important as the other features of a project--including delivery date, we're going to continue to follow the security patch process.