Are you a startup? Get BizSpark cloud access
Got MSDN? Get up to $3,700 of cloud benefits
Don’t have MSDN? Here’s cloud access
When you are building out your cloud application, security should be front and center in your Windows Azure planning and execution. In part1 one I described the threat landscape and that your application should employ defense in depth. In part 2, I explained that security was a shared responsibility and that Windows Azure provides your application with security features that go beyond those that you need to consider in your on premises application. But then, it also exposes other vulnerabilities that you should consider.
In this part, I explore how you can examine the architecture of your application. The pattern and practices teams provide the idea of a Security Frame as a way to look at your application to determine treats and your responses, before you even begin coding.
I also describe how you can use the The Microsoft Security Development Lifecycle (SDL) in a prescribed way that you can adapt in your organization to address security in every process of your application’s lifecycle.
A Security Frame acts as a simple lens for you to look into your apps from a security viewpoint.
The concept is explained in depth in Windows Azure Security Notes. This document from the Patterns and Practices team was authored by by J.D. Meier, Principal Program Manager and Paul Enfield. It was developed with help from customers, field engineers, product teams, and industry experts provides solutions for securing common application scenarios on Windows Azure based on common principles, patterns, and practices.
The paper provides an overview of the threats, attacks, vulnerabilities, and countermeasures you can take. It provides a details set of scenarios for many of the common application types. There are paper provides a Security Frame, as a way to provide a frame for thinking about security when designing and architecting Windows Azure applications.
The paper starts with a common ASP.NET application and identifies a set of categories as a set of actionable buckets:
The approach help you to approach securing your solution by addressing key security hotspots defined by the security frame.
For your on premises application, you need to handle each of these main issues. The visual model represents a fairly typical on-premise application architecture, and then pins hotspots against it.
With a managed infrastructure we can remove some of the concerns because they are items handled by the managed infrastructure. For example, a Windows Azure application will not have permissions to create user accounts, or elevate privileges.
The paper advises you to
Represent your architecture with a base diagram, and overlay the frame on it. Once the frame is overlaid, you can evaluate each item for applicability and quickly scope out categories not needing attention.
The paper goes on to describe 28 different attacks and suggests 71 things you can do to make your application more secure. In fact, these represent coding standards you can use in your organization. (See Counter Measures Explained on page 18 for a great set of these standards that should be part of your software development).
The paper explains several application scenarios that represent a set of common application implementations on the Windows Azure platform involving web based services.
Tradeoffs for each of the architectures is described, followed by use cases for each scenario.
And it provides the criteria to select the right fit for your application.
The following application scenarios represent a set of common application implementations on the Windows Azure platform involving data storage security.
The benefits and consideration for each way to store data is described for each data security architecture.
The article provides a checklist for securing your Windows Azure application. There is a check list for each of the major buckets:
One example of the checklist, this one is for Architecture and Design, define the things you should be doing in your application architectures which highlights role-based security:
□ The application authentication code has been removed from application code, and is implemented separately. □ Instead of the application determining who the user is, identify the user by the claims they provide. □ The design identifies permissions required by the application. □ The design verifies that required permissions do not exceed Windows Azure trust policies. □ The design identifies storage requirements against storage options capabilities. □ The application doesn’t use explicit IP addresses, it uses friendly DNS names instead.
There’s a set of treats and countermeasures that you can use to specifically uses to design and implement your software for each category.
Those sheets and the other information in Windows Azure Security Notes will provide you a good place to start.
I’m often asked about how Microsoft approaches security for our own applications and for Windows Azure itself.
Microsoft requires that the The Microsoft Security Development Lifecycle (SDL) be followed for any Microsoft-developed software deployed on Windows Azure.
The Security Development Lifecycle (SDL) is a software development security assurance process consisting of security practices grouped by seven phases: training, requirements, design, implementation, verification, release, and response.
Starting with the requirements phase, the SDL process includes a number of specific activities when considered with development of applications to be hosted in the Microsoft cloud in mind:
Requirements – The primary objective in this phase is to identify key security objectives and otherwise maximize software security while minimizing disruption to customer usability, plans, and schedules. This activity may include an operational discussion when dealing with hosted applications that focuses on defining how the service will utilize network connections and message transports.
Design – Critical security steps in this phase include documenting the potential attack surface and conducting threat modeling. As with the requirements phase, environmental criteria may be identified when going through this process for a hosted application.
Implementation – Coding and testing occur in this phase. Preventing the creation of code with security vulnerabilities and taking steps to remove such issues, if present, are the key practices during implementation.
Verification – The beta phase is when new applications are considered functionally complete. During this phase, close attention is paid to determining what security risks are present when the application is deployed in a real-world scenario and what steps can be taken to eliminate or mitigate the security risks.
Release – The Final Security Review (FSR) happens during this phase. If needed, an Operational Security Review (OSR) also occurs before the new application can be released into Microsoft’s cloud environment.
Response – For Microsoft’s cloud environment, the SIM team takes the lead in responding to security incidents and works closely with product, service delivery teams, and members of the Microsoft Security Response Center to triage, research, and remediate reported incidents.
SDL includes tools and processes that you can use freely. For example, you can use:
SDL applies equally to applications built on the Windows Azure platform and any other platform. Most Windows Azure applications have been built, or will be built using agile methods. As a result, the SDL for agile process may be more applicable to applications hosted on Windows Azure than to the classic phase-based SDL. The Microsoft SDL Web site also covers SDL for Agile in detail.
Windows Azure Security Notes Many thanks to J.D. Meier and Paul Enfield of the Patterns and Practices team.
For more information about SDL, see The Microsoft Security Development Lifecycle (SDL) page.
Windows Azure Security Best Practices – Part 4: What You Need to Do. In addition to protecting your application from threats, there are additional steps you should take when you deploy your application. We provide a list of mitigations that you should employ in your application development and deployment.
Here are links to the articles in this series:
Bruce D. Kyle ISV Architect Evangelist | Microsoft Corporation
Special thanks to J.D. Meier, the Patterns & Practices team, and the Software Development Lifecycle team.