So, for a Friday the Twitterverse has been quite busy with interesting security discussions. Mostly generated by Gunnar Peterson (@oneraindrop) and Rafal Los (@Wh1t3Rabbit), the discussions are floating around why others (business, developers) are not listening to security. As part of the discussion, the old absolute truth “security must be built in, not bolt on” was repeated over and over again. Of course, isn’t it obvious?
Shouldn’t we’ve been trying to think out of the box, to question even the “absolute truths”? (That’s for @joshcorman)
So, can’t we stop and think for a while why we think security should be built in, and not bolt on? And why, even if everyone agrees with it, we are still bolting it on, over and over again?
Well, I think one of the things we should be doing is thinking about new and better ways to bolt on security! If it’s happening it’s certainly because the business wants to work this way. Ok, in ideal conditions we may never be able to achieve the same security level with it (or optimize the security/cost ratio), but if that’s the way all the other players involved want to deal with security, shouldn’t we try to optimize how to do this?
It’s just a small firestarter as I haven’t thought that through, but I think we can, in fact, do something like that. Just think about all the things that are being done based on the new virtualization technologies. Things like Fire Eye, commonIT virtual browser technology and other sandboxing products, they are all “bolt on” security. I can remember a couple of situations I dealt in the past where the best security solution found for a specific system was to encapsulate it in a security shell, something that is extremely easy to do with the current virtualization tools.
So, instead of trying to change the world, why can’t we also spend a few minutes thinking about how to improve the current “bolt security on” approaches? It may reveal being a better option than the pie in the sky we keep praising in this small and cozy echo chamber called security industry.