Is there a future for Product Certifications?

  • Article

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:

  • The certification is static. In other words, there is a configuration at a given time, with a given product build, which is certified. The next hotfix or update basically invalidates the certification and you run the product rarely in the configuration certified. We make all the policies and configuration public – if you want to use them, feel free.
  • It is slow. Even though we have plenty of experience by now, it still takes us more than 12 months to get a product certified.
  • It is expensive. I will not go into the details here but it costs us a lot of money. This is the cost of doing business, I get that but there has to be a better way to address this.
  • Typically the protection profile certified against does not completely meet the customer's requirements. This means a lot of additional energy by the customer and us to go the final mile. This leads, unfortunately, to local requirements, local certifications and accreditations. Again, cost of doing business.

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)

Roger