Tan Choon Ngee Director, aZaaS Pte Ltd

Microsoft Cloud Day

Understanding and implementation Windows Azure platform security

Choon Ngee has more than 10 years of IT Sales, Marketing and Consulting experience with leading organizations like JP

Morgan and Crimson Logic. He has developed several businesses focussed purely on Microsoft Technologies

during this period.

This session focuses on the security challenges and recommended approaches to design and develop more

secure applications for Microsoft’s Windows Azure platform.

Understanding and implementation Windows Azure platform security

• Microsoft Corporation• Authors Andrew Marshall (Senior Security Program Manager,

Security Engineering) Michael Howard (Principal Security Program Manager, Security Engineering) Grant Bugher (Lead Security Program Manager, OSSC) Brian Harden (Security Architect, OSSC)

• Contributors Charlie Kaufman (Principal Architect) Martin Rues (Director, OSSC) Vittorio Bertocci (Senior Technical Evangelist, Developer and Platform Evangelism

Responsibility for Threat Mitigation

• There are many threats to a traditional server• There are some additional threats in the case

of cloud computing• Some threats are handled by Windows Azure;

others remain the responsibility of the customer

Windows Azure Security Certifications

• ISO/IEC 27001:2005 certification• SAS 70 Type 1 and II attestations• PCI Data Security Standard compliance• Sarbanes–Oxley Act compliance• Health Insurance Portability and

Accountability Act compliance

External Verification

• Microsoft contracted two top-tier penetration testing firms

• Conduct security assessments on different elements of the Windows Azure architecture

• Examined hardened virtualization boundaries and • Probed for side-channel or I/O thrashing attacks• Six professional penetration testers working over the

course of seven weeks were unable to mount a successful attack against this design.

Threats Handled by Azure

Windows Azure

Customer Tenant

Customer Admin Users

External Web Site

Physical AttacksOn ServersCentral Admin

Attacks against Windows Azure

• A successful attack on the infrastructure could compromise all of our customers

• Windows Azure must secure its facilities against unauthorized access

• Windows Azure must secure its interfaces against attacks over the network– Customer tenants breaking out of their VMs– Attackers successfully impersonating customer administrators or Windows

Azure administrators– Customer administrators affecting

other than their own tenants

Windows Azure

Customer Tenant

Customer Admin Users

Physical AttacksOn Servers

Abuse of Privilege by Windows Azure Administrators

• Windows Azure administrators could make unauthorized access to customer data– Procedures involving customer consent when such

access is necessary– Separation of Duty to prevent abuse by a single

rogue administrator– Auditing to assure that unauthorized access will

be discoveredWindows Azure

Customer Tenant

Central Admin

Using Windows Azure as a Platform for Attacking Others

• MS will receive complaints of misbehavior by Windows Azure tenants

• MS proactively monitor outbound access to detect common cases (port scans, spam)

• If a good customer’s tenant has been compromised (botted), MS work with the customer to resolve the problem

• If a customer intentionally attacks others, MS ban them

Windows Azure

Customer Tenant

External Web Site

Defenses Inherited by Windows Azure Tenants

Spoofing Tampering & Disclosure

Port Scanning/ Service

Enumeration

Elevation of Privilege

Load-balanced Infrastructure

Network bandwidth throttling

CiscoGuard enabled on Storage nodes

Configurable scale-out

Denial of Service

Service Definition file, Windows Firewall, VM switch packet filtering

VM switch hardening

Certificate Services

Shared-Access Signatures

HTTPS

Sidechannel protections

VLANs

Top of Rack Switches

Custom packet filtering

Partial Trust Runtime

Hypervisor custom sandboxing

Virtual Service Accounts

Windows Azure Security Layers

18

Managed Code Access Security: partial trust

Windows Account: running with least privileges

Windows FW (VM): rules based on service model

Virtual Machine: fixed CPU, memory, disk resources

Root Partition Packet Filter: defense in depth against VM “jailbreaking”

Network ACLs: dedicated VLANS for tenant nodes

How does it work?

• For Windows Azure Storage and SQL Azure, like any other shared service– Storage or SQL account owned by some customer

who sets access policy– Access policy is enforced by the code that parses

and satisfies requests• For Windows Azure Compute, MS create

customer owned VMs, isolated by a hypervisor

Underlying Hardware

• Rack mounted servers• Each rack has a collection of identical nodes• Each node (currently) has 2 CPU chips with 4

cores each– 16 Gig of memory– Disks for local storage– Network Interface to a Top of Rack Switch

Hypervisor & VM Sandbox

All Guest access to network and disk is mediated by Root VM (via the Hypervisor)

Hypervisor

Network/Disk

Root VM

Guest VM

Guest VM

Guest VM

Guest VM

Guest VM

Guest VM

Guest VM

Managing it all through the Fabric Controllers

What does the world look like to a Guest VM?

• 1, 2, 4, or 8 CPUs; up to 14 GB or memory• Three disk drives:– C:\ (for temps; initially populated with config file)– D:\ (for OS code; initially as supplied by Windows

Azure)– E:\ (for application code; initially as supplied by

customer admin)• Network connectivity to Internet via NAT and to

other VMs of same tenant• Guest agent accepts incoming HTTP/RPC

connections from Root OS

Handling Attacks by a Tenant

• Not dependent on the security of Windows• Instead, dependent on the security of the

Hypervisor and the exposed network and disk drivers

• C:\, D:\, and E:\ are not really disks. They are VHD files in the root OS’s file system.

• Attack surface is minimized by accepting few commands and supporting only a few hardware devices

Windows Azure Storage

• Runs on separate hardware with no network connectivity to compute except (logically) through Internet

• Requests run over HTTP and optionally over SSL with server authentication

• Storage is organized into storage accounts• A single customer may have many storage accounts• A single secret key controls all access to a storage

account

Access Control

• Some accommodation to more fine-grained access controls:– Some data can be marked as world-readable– Shared access signatures supports some forms of limited

delegation

• A customer wanting fine-grained access controls can implement a front end compute tenant that has full access to the storage account but mediates access to data items

Windows Azure Storage Scalability

• To reduce the need for locks when dealing with a conventional file system, Windows Azure storage implements the primitives: blobs, tables, and queues.

• For backwards compatibility, it also implements an virtual drive with disk semantics for applications that have not been converted.

• The customer is responsible for coordinating the assignment of virtual drives to VMs. A virtual drive can only be open for write from one VM at a time.

Windows Azure Storage Security

• Access to data in a specific account is only granted to entities having the secret key for that account

• Storage keys are randomly generated when the storage account is created (or later at the request of the customer)

• A storage account may have two active keys at any given time to support key rollover

• Storage keys are used to HMAC sign each access request

SQL Azure

• As with storage, runs on separate hardware with no connectivity to compute except (logically) over the Internet

• Developer portal can create databases and set an administrator password

• SQL administrator can create additional user accounts, each authenticated with a password

Threats Customer Still Must Worry About

Windows Azure

Customer Tenant

Customer Admin Users

Abuse of Privilege by a Customer Administrator

• Customer administrators are authorized to update the code and access the data belonging to any customer tenant

• Customer administrators are authenticated with cryptographic keys that the customer must protect

• Customers should implement deployment practices as carefully as they would for applications in their own data centers

Windows Azure

Customer Tenant

Customer Admin

Attacks on a Customer’s Tenant

• A tenant is much like a physical server. If there are bugs in its code, it can be compromised over the network

• MS can look for symptoms in some cases, but it is ultimately the customer’s responsibility

Windows Azure

Customer Tenant

Users

Securing the Front Door

• Identity Management and Access Control– Windows Identity Foundation – Active Directory Federation Services 2.0 – Windows Azure AppFabric Access Control Service

Authenticating Users

AppFabricACS

Service Identities

ADFS2 . WS-Trust

ADFS2 . WS-Federation

WS-Trust

OAuth WRAP/2.0

WS-Federation

SAMLSWT

SAML

SWT

Your ApplicationACSIdentityProviders

Brow

ser-

base

dRi

chCl

ient

Serv

er 2

Ser

ver

Gatekeeper Design Pattern

Multi Key Design Pattern

Example of Architecture

Queue

Input Queue (Work Items)

Web Role

Web Role

Web Role

Worker Role

Worker Role

Worker Role

Worker Role

Storage

Namespace Configuration Issues

• Avoid using *servicename*.cloudapp.net domain name - use a custom domain name instead. – cloudapp.net namespace is inherently less trusted than the

domain namespace of a single enterprise – Don’t create code that requires users to place cloudapp.net in

the trusted sites list in their web browser. • Never scope cookies or document.domain to cloudapp.net.

– Instead, scope to the service subdomain (such as contoso.cloudapp.net, for example or, better, www.contoso.com).

Data Security

• Generate Shared Access Signatures with the most restrictive set of ACLs possible that still grant the access required by the trusted party.

• Use the shortest lifetime possible. • Use HTTPS in the request URL so the token cannot be

snooped on the wire. • Remember that these tokens are only used for

temporary access to non-public blob storage – as with passwords, it’s a bad idea to use the same ones over and over

Handling Secret Information

• Encrypt data offsite then upload encrypted payload to blob storage

• Should not upload the key or any keying material to Windows Azure Storage

• Should not store private keys associated with SSL/TLS certificates in Windows Azure Storage. – Instead, upload them through the Developer Portal and access

them via thumbprint references in the Service Configuration. – Windows Azure will securely provision them into the

certificate stores of the service’s web roles upon boot

Auditing and Logging

• Events are not written to application, security, or audit event logs

• Logged to Windows Azure Storage through the Monitoring and Diagnostics Agent via trace listeners in web application code.

• Then stored long-term in Windows Azure Storage via scheduled transfers performed by the Monitoring Agent.

• Not encrypted - Do not write sensitive information to any events stored in Windows Azure Table Storage

• Choose HTTP or HTTPS to retrieve logs

Request Throttling / Input Sanitization

• Developers must do application-level throttling of incoming requests for any kind of complex, time-intensive operation.

• Fuzz test any new parsers deployed as part of a web service. – Fuzz test it to ensure the code can correctly accommodate

malformed input. – Microsoft currently applies to “boxed-product” software

fuzzing requirement : 100,000 iterations of each new format or protocol without crashing, or runs non-stop for 24 hours

Other Security Considerations

• Secure design– Attack surface reduction – Defense in depth – Principle of least privilege – Threat modeling

• Secure coding– Cross-site scripting – SQL injection – Managed code security (transparency, code access security,

assembly strong naming, etc.)

Today’s Promotion• FREE* for first 5 customers only! Email promotion code

“AZURE6M” with your contact details to sales@azaas.com to register.

• Special package worth S$3800• 6 months of Windows Azure Platform DAE• 6 months of aZaaS Cloud Application Engine subscription• 2 man-days of services to create your cloud application• Offer is only valid till 30 April 2011*Credit card required for sign-up. Any monthly usage in excess of the stated amounts will be charged at the standard rates. After 6 months, all usage will then be charged at the standard rates. Testimonial regarding services from Microsoft and aZaaS will be required.

Microsoft Cloud Day