Microsoft reveals operational security methodology

Microsoft has lifted the veil on how it maintains security for more than 200 cloud services, including Office 365, Windows Azure and

Microsoft has lifted the veil on how it maintains security for more than 200 cloud services, including Office 365, Windows Azure and

Just as the company uses security development lifecycle (SDL) in its production of software, Microsoft has developed an operational security assurance (OSA) methodology.

“OSA builds on Microsoft’s experience with operating cloud services at scale,” said Mike Reavey, general manager, Trustworthy Computing at Microsoft.

Like the SDL, it is a proven and scalable methodology that complements industry standards, it has clear and specific requirements, and it is updated continually, he told the RSA Europe 2013 conference in Amsterdam.

And just as SDL is mandatory for all software development, OSA is mandatory for all online services alongside SDL and is applied from the start of the design phase onwards.

Within Microsoft, OSA is supported by a team of policy creators, an OSA advisor, operations security lead, an SDL security champion, and subject matter experts in areas such as public key infrastructure (PKI).

“The OSA advisory function brings together the security leaders for operations and software, which is important for any business – large or small – that has developers for applications or services,” said Reavey.

“The trick is to get software and service development teams together with those in charge of operational security to talk about the right things and carry out threat modeling."

Although one of the most difficult things to do at scale, Reavey said threat modeling is vital to test assumptions and make the connection between development and operations.

Microsoft has learned the importance of making this connection through bitter experience. The company was forced to change its Windows update process with the discovery of the Flame malware in May 2012.

Flame exploited an assumption by the Microsoft development team that it was safe for the Windows Update client to trust newer, digitally signed versions of itself.

By working out how to exploit weaknesses in operational security to sign malware, the creators of Flame were able to bypass security controls.

“OSA is designed to catch the operational security impact of design decisions by bringing development and operational security teams together at the right time,” said Reavey.

Flame provided valuable lessons in the importance of operational security for Microsoft and the software industry as a whole, he said.

Microsoft’s OSA has multiple inputs, including the best that security standards such as ISO27001 have to offer on securing online services and feedback from security incidents.

“We believe that a crisis should never be wasted; that there is always something to be learned, which is why the OSA is tightly coupled to the Microsoft security response centre (MSRC),” said Reavey.

Security success stories across the organisation are also fed into OSA to ensure the most effective security processes are incorporated.

Inputs from security technologies, threat intelligence, industry associations, international standards, incidents and organisational learnings are continually consolidated into OSA requirements.

“This is an ongoing process that gets continually reviewed and updated,” said Reavey.

He challenged all businesses that do any in-house development of software and services to question just how well those development teams communicate with operational security teams.

“Ask if they are doing adequate threat modeling and if they are ensuring that no crises, internally or externally, are going by without lessons being drawn from them,” he said.

Reavey also challenged businesses to ask their current or prospective cloud service providers if their development decisions are based on operational security considerations and to give examples.

Read more on Application security and coding requirements