Often, when I talk to customers, product certification is one of the key themes they want to address. Especially they want to know about our commitment to Common Criteria and whether our products are certified. Typically we certify an operating system on Common Criteria EAL 4+ - the highest level, which seems achievable for multi-purpose operating systems. However, personally I do not think that product certifications are the future for different reasons:
Being an engineer, I am deeply convinced that a secure product is the result of a sound and strong process embedding security into the lifecycle from the beginning. I am convinced as well, that product certification gives you a certain level of assurance but not too much. The process would probably give you much, much more to build your risk management on.
At the Security Development Conference this week, we declared conformance with ISO 27034-1, the first part of a standard on secure software development. Here is the official statement:
Microsoft has used a risk based approach to guide software security investments through a program of continuous improvement and processes since the Security Development Lifecycle (SDL) became a company-wide mandatory policy in 2004. In 2012, Microsoft used ISO/IEC 27034-1, an international application security standard as a baseline to evaluate mandatory engineering policies, standards, and procedures along with their supporting people, processes, and tools.
All current mandatory application security related policies, standards, and procedures along with their supporting people, processes, and tools meet or exceed the guidance in ISO/IEC 27034-1 as published in 2011.
Basically, this means that we are convinced that our Security Development Lifecycle fulfills ISO 27034-1. Transparency in this context is absolutely key in my opinion – much more than any product certification or any statement along the lines of "we trust our (fill in a role), he/she is in the business for so long, he/she knows what to do". No joke, I heard this statement more than once.
In the future – and in the Cloud – transparency how software is built and ultimately run, how a company does incident response etc. gains more and more importance. Looking into the purchasing processes of our customers, they are still much too much focused on the product itself, in my humble opinion. I am convinced that this should change and should change rapidly.
If I may give you an advice: If you do not want to rely on a relatively new standard, you might just start by asking your vendors about how they develop software, how they react on incidents and product vulnerabilities, what support you get when you get compromised on their platform and – if you move to the Cloud – how they run your environment. Use your common sense before any standard when you judge their answers and see what the outcome is. I did it more than once and the answers are amazing (not to the good fairly often)