We Need Solid and Strong Transparent Processes for the Cloud

This morning I was reading an article called Google seeks to assure customers on cloud security practices on ComputerWeekly. I had to read this – obviously . It references a paper written by the Google Security Officer called Security Whitepaper: Google Apps Messaging and Collaboration Products. So, I read through it and to me it reflects – unfortunately – the state a lot of Cloud providers are in. Google (and not only Google to be fair), shows how good their physical security to their datacenter is, how they apply access control, monitoring, patch management etc. To me, kind of the standard security practices which I expect them to follow. It is just interesting that to my knowledge Google does not hold an ISO 27001 certification yet – but this is more a side-note.

What really stroke me, is that they do not at all talk about their engineering practices. They always talk about Secure Programming or Implementation Level Security – this is not the whole story as we at Microsoft learned the hard way. It is not about the code as such and if I would have to choose between looking at the code and looking at the engineering practices, I would choose the later. A good product is “just” the outcome of a good process, something we learned in engineering at the university when I was there. So, looking into the code is just the smaller part of the story.

Bearing that in mind, I actually searched for the engineering practices they have and actually found them: Google’s Engineering organization does not require Product Development teams to follow a specific software development process; rather, teams choose and implement processes that fit the project’s needs. As such, a variety of software development processes are in use at Google, from Agile Software Development methodologies to more traditional, phased processes. If I learned one thing during my whole security career then it is that you need fairly strong processes to ensure security – being it on the network or in the design of applications.

That’s the reason we have our Security Development Lifecycle in place. Do not get me wrong, this will not lead to perfect security as there is no such thing like perfect security. However, I am definitely convinced that looking at product security makes less sense than looking into the process the product was engineered. Knowing that it is a requirement for governments, Common Criteria targets at the result and not at the process.

Therefore, statements like: Designed in-house from the ground up, Google’s production servers are based on a stripped and hardened version of Linux that has been customized to include only the components necessary to run Google applications, such as those services required to administer the system and serve user traffic. The system is designed for Google to be able to maintain control over the entire hardware and software stack and to help provide a secure application environment. would not really make me feel any better in the light of what I wrote above.

We as an industry should definitely put more emphasis into the development lifecycle rather than code security and the product as such - I am clear that secure programming as such as well as tools to do static code analysis are important as well and not to be forgotten.

Rather than re-invent the wheel, I would ask Google (and others) to join SafeCode which exactly targets the process/engineering approach.

Roger