Security – A Feature Discussion? Some Thoughts on Google’s Chrome OS

To be clear upfront: This is not a “Microsoft versus Google” post. I cannot even judge how far Google pushed security with the Chrome OS. But the following article raised quite some questions how we look at security: Inside the Google Chrome OS security model. This article, like so many when security of an Operating System is to be discussed, is completely feature driven. So, we talk about Process Sandboxing, Toolchain Hardening, Kernel Hardening etc. But how relevant is this really?

Do not get me wrong: It is. But these features have to be the result of an engineering process. These features have to be designed to reduce a certain threat vector – a possible attack scenario and they have to be laid out in a way to reduce this vector. I recently had a discussion with somebody who wanted me to convince about their security software. My very first question was: How do you develop software? The answer was: We have a great CTO and good developers which engineer our software. My next question: OK, how do you do Threat Modeling? Answer: Our CTO does this since years and knows everything in and out…

To me Threat Modeling and a transparency with regards to the development process is key! Why shall I trust features? I have to know why and how they are engineered. I need process transparency – and not necessarily code transparency. There is no way I can review code. I am not a security development specialist on the one hand side nor do I have the time to look through the code anyway. The only thing I can build my trust on is the engineering and the response processes.

So, why do we not rather raise a process discussion than a feature discussion? When we had the initial press conference about SafeCode , I was asked a pretty interesting question by an analyst: As SafeCode is about sharing best practices with regards to secure development, other vendors who do not use such processes will become a target. Yes, and now? The industry has to learn that engineering and development processes are much more important than features! We use our Security Development Lifecycle – will this lead to absolutely secure code? No, not at all but to a much, much higher bar. We have great examples where we can show that this does not only reduce the number of code defects but also to a better defense framework adopting defense in depth concepts. This is what we need. Let’s shift the discussion from features to processes!

And a final comment: This discussion is even more important in the cloud!

Roger