Share via

Windows Azure Security Best Practices – Part 3: Identifying Your Security Frame

  • Article

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.

Security Frame

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:

  • Auditing and Logging
  • Authentication
  • Authorization
  • Communication
  • Configuration Management
  • Cryptography
  • Exception Management
  • Sensitive Data
  • Session Management
  • Validation

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.

image

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.

image

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).

Choosing Web Service Security Architectures

The paper explains several application scenarios that represent a set of common application implementations on the Windows Azure platform involving web based services.

  • ASP.NET to WCF. This scenario illustrates Windows Azure hosting and ASP.NET application, a WCF service and how to connect the two. It uses transport security and calls to the service are made as a single identity.
  • ASP.NET On-Site to WCF on Windows Azure. In this scenario an ASP.NET application hosted on-site calls a WCF service hosted on Windows Azure using message security, and passing the identity of the original caller.
  • ASP.NET to WCF with Claims. This scenario uses the Windows Identity Framework to connect an ASP.NET application to a WCF service while authenticating using claims in an authentication token, and maintaining the identity of the authenticated user.
  • REST Service with AppFabric Access Control. In this scenario, a web service is implemented with a RESTful interface. To authenticate access to the REST service, the AppFabric Access Control is used to obtain a Simple Web Token (SWT). Access Control works in a trust relationship with an Identity Provider such as ADFS to issue Simple Web Tokens.

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.

Choosing Data Security Architectures

The following application scenarios represent a set of common application implementations on the Windows Azure platform involving data storage security.

  • ASP.NET to Azure Storage: This scenario demonstrates securing access to Windows Azure Storage. It uses ASP.NET membership and roles, while mapping users to a single connection.
  • ASP.NET to SQL Azure: In this scenario we demonstrate SQL Azure access providing users with differing levels privileges to the data by mapping them to set roles.
  • ASP.NET On-Site to Data on Azure through WCF: This scenario illustrates Data as a Service by connecting an on-site application to data hosted in the cloud using WCF.
  • ASP.NET on Windows Azure to SQL Server On-site: In this scenario you have deployed an ASP.NET application to Windows Azure, but the data lives on-site. A WCF service is used to expose the data, and the Windows Azure Service Bus is used to expose the service through the corporate firewall to the Windows Azure Application.

The benefits and consideration for each way to store data is described for each data security architecture.

Checklists

The article provides a checklist for securing your Windows Azure application. There is a check list for each of the major buckets:

  • Architecture and Design
  • Deployment Considerations
  • Auditing and logging
  • Authentication
  • Authorization
  • Communications
  • Configuration Management
  • Cryptography
  • Exception Management
  • Input and Data Validation
  • Sensitive Data

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.

  • Cheat Sheet - Web Application Security Threats and Countermeasures at a Glance
  • Cheat Sheet - Web Service (SOAP) Security Threats and Countermeasures at a Glance
  • Cheat Sheet – Web Services (REST) Security Threats and Countermeasures at a Glance
  • Cheat Sheet - Data Security Threats and Countermeasures at a Glance

Those sheets and the other information in Windows Azure Security Notes will provide you a good place to start.

Setting the Security in Your Development Lifecycle

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.

image

 

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.

Tools and Processes

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.

References

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.

Videos

Next Up

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. KyleISV Architect Evangelist | Microsoft Corporation

image

Special thanks to J.D. Meier, the Patterns & Practices team, and the Software Development Lifecycle team.