“There is no such thing as a secure cloud,” according to Greg Ferro, who moderated the panel discussion in which I participated at the GigaOM Structure: Europe conference. And so began a lively conversation with Greg and other industry pros.
During this session, we discussed the importance of cloud providers sharing their security practices with customers. That exchange was the focus of an article on the GigaOM website. During the panel I described three broad categories of ongoing work in relation to cloud offerings: 1) development – how we create the software behind the service, 2) data center security – how we protect the operational environment in which services are running and, 3) incident response – how we manage services if and when, the unexpected occurs.
After the panel, I was asked a few follow on questions about Microsoft’s Security Development Lifecycle (SDL), so I want to summarize our approach to developing with security in mind. The SDL is a security assurance process that introduces security and privacy into all phases of development. It has been a mandatory policy at Microsoft since 2004. With close to a decade of experience with this process, secure software development is something we consider to be in our DNA.
There’s no question in my mind that the wholesale adoption of this approach has helped reduce the number and severity of vulnerabilities by engaging engineers in a review of the latest cyberthreats and landscape before and during development, as opposed to afterwards. It also reduces costs by discovering and addressing potential security and data privacy issues early in the design phase, where changes can be made with less disruption to the overall project.
You should also know that we freely share the SDL with the software industry and customers’ development organizations, making it a popular resource to develop more secure software. The SDL also meets or exceeds the guidance published in ISO/IEC 27034-1, an international application security standard.
Customers are interested in how we build security into our cloud services, and the SDL remains the foundation of security development at Microsoft in the cloud era. Let me briefly lay out the SDL framework:
Training: This includes training on secure design, threat modeling, secure coding, security testing, and best practices surrounding privacy.
Requirements: This stage involves the identification of key milestones and deliverables early, to ensure security and privacy requirements are met. During this stage, quality gates a.k.a. “bug bars” are defined at the outset to maintain security and privacy quality levels throughout the project. Security and Privacy risk assessments are also identified to ensure regulatory requirements and associated costs are understood in advance.
Design: Establishing design requirements helps minimize the risk of schedule disruptions and reduce project expenses. This stage includes analyzing and reducing the attack surface by disabling or restricting access to system services, applying the principle of least privilege, and employing layered defenses wherever possible. Lastly, threat modeling helps identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.
Implementation: In this stage, standard approved tools and associated security checks are used to automate and enforce security practices, saving time and money. All project functions and APIs are examined, and those to be unsafe are banned, thereby reducing potential security bugs with very little engineering cost. Source code is analyzed prior to compile, providing a scalable method of review and helping to ensure that secure coding policies are being followed.
Verification: Performing run-time verification checks software functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems. Next, fuzz testing deliberately introduces malformed or random data to an application, which helps induces program failure and reveal potential security issues prior to release. An attack surface review helps ensure that any design or implementation changes to an application or system have been taken into account, and that any new attack vectors created as a result of the changes have been reviewed and mitigated.
Release: Developing an incident response plan is crucial for addressing new threats over time. This includes identifying appropriate emergency contacts and establishing security servicing plans for code inherited from other groups or licensed from third parties. A final security review helps ensure software release readiness by examining threat models, tools outputs, and performance against the quality gates and bug bars defined during the Requirements phase. The final step is to certify the release and archive all pertinent data, which helps ensure security and privacy requirements were met, and enable post-release servicing.
Response: Implementing the Incident Response Plan developed in the Release phase helps protect customers from software security or privacy vulnerabilities that emerge.
I should note that many of these activities would provide some degree of security benefit if implemented on a standalone basis. However, practical experience at Microsoft has shown that security activities executed as part of a software development lifecycle process lead to greater security gains than activities implemented piecemeal.