Downloaded 206 times
More Related Content
![[Toroman/Kranjac] Red Team vs. Blue Team in Microsoft Cloud](https://cdn.slidesharecdn.com/ss_thumbnails/fs0fswrr36f3q9puu3u6-signature-d4523b3bf020616e67040d2a940ba8bf9aeab187b20da49956548f98de22ea12-poli-180606121949-thumbnail.jpg?width=640&height=640&fit=bounds)
Windows Azure Security Features And Functionality
- 1. Windows Azure SecurityFeatures and FunctionalityVivek Bhatnagar WW Lead Technical Sales Windows Azure Microsoft Corporationvivekbh@live.com
- 2.
- 3. Windows Azure CombinesThree ComponentsCompute – Think Stateless CPU in the Cloud (Rented by the CPU - hour)Storage – Like a file system, but structured differently to support scalability and parallelism (Rented by the Gigabyte - Month)SQL Azure – Another form of storage, accessed with SQL queries rather than file-like operationsCan be used separately, but more commonly a Compute tenant is layered atop Storage, SQL Azure, or bothThere will likely be more components in the future
- 4. Responsibility for ThreatMitigationThere are many threats to a traditional serverThere are some additional threats in the case of cloud computingSome threats are handled by Windows Azure; others remain the responsibility of the customer
- 5. Threats We WorryAboutPhysical AttacksOn ServersCentral AdminUsersCustomer AdminWindows AzureCustomer TenantExternal Web Site
- 6. Attacks against WindowsAzureA successful attack on the infrastructure could compromise all of our customersWindows Azure must secure its facilities against unauthorized accessWindows Azure must secure its interfaces against attacks over the networkCustomer tenants breaking out of their VMsAttackers successfully impersonating customer administrators or Windows Azure administratorsCustomer administrators affecting other than their own tenantsPhysical AttacksOn ServersUsersCustomer AdminWindows AzureCustomer Tenant
- 7. Abuse of Privilegeby Windows Azure AdministratorsWindows Azure administrators could make unauthorized access to customer dataProcedures involving customer consent when such access is necessarySeparation of Duty to prevent abuse by a single rogue administratorAuditing to assure that unauthorized access will be discoveredCentral AdminWindows AzureCustomer Tenant
- 8. Using Windows Azureas a Platform for Attacking OthersWe will receive complaints of misbehavior by Windows Azure tenantsWe proactively monitor outbound access to detect common cases (port scans, spam)If a good customer’s tenant has been compromised (botted), we work with the customer to resolve the problemIf a customer intentionally attacks others, we ban themWindows AzureCustomer TenantExternal Web Site
- 9. Threats Customer StillMust Worry AboutUsersCustomer AdminWindows AzureCustomer Tenant
- 10. Attacks on aCustomer’s TenantA tenant is much like a physical server. If there are bugs in its code, it can be compromised over the networkWe can look for symptoms in some cases, but it is ultimately the customer’s responsibilityUsersWindows AzureCustomer Tenant
- 11. Abuse of Privilegeby a Customer AdministratorCustomer administrators are authorized to update the code and access the data belonging to any customer tenantCustomer administrators are authenticated with cryptographic keys that the customer must protectCustomers should implement deployment practices as carefully as they would for applications in their own data centersCustomer AdminWindows AzureCustomer Tenant
- 12. Windows Azure SecurityLayersNetwork ACLs: dedicated VLANS for tenant nodes12
- 13. How does itwork?For Windows Azure Storage and SQL Azure, like any other shared serviceStorage or SQL account owned by some customer who sets access policyAccess policy is enforced by the code that parses and satisfies requestsFor Windows Azure Compute, we create customer owned VMs, isolated by a hypervisor
- 14. Underlying HardwareRack mountedserversEach rack has a collection of identical nodesEach 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
- 15. Hypervisor & VMSandboxAll Guest access to network and disk is mediated by Root VM (via the Hypervisor)Guest VMGuest VMGuest VMGuest VMGuest VMGuest VMGuest VMRoot VMHypervisorNetwork/Disk
- 16. Managing it allthrough the Fabric Controllers
- 17. What does theworld look like to a Guest VM?1, 2, 4, or 8 CPUs; up to 14 GB or memoryThree 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 tenantGuest agent accepts incoming HTTP/RPC connections from Root OS
- 18. Handling Attacks bya TenantNot dependent on the security of WindowsInstead, dependent on the security of the Hypervisor and the exposed network and disk driversC:\, 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
- 19. Windows Azure StorageRunson separate hardware with no network connectivity to compute except (logically) through InternetRequests run over HTTP and optionally over SSL with server authenticationStorage is organized into storage accountsA single customer may have many storage accountsA single secret key controls all access to a storage account
- 20. Access ControlSome accommodationto more fine-grained access controls:Some data can be marked as world-readable
- 21. Shared access signaturessupports some forms of limited delegationA 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
- 22. Windows Azure StorageScalabilityTo 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.
- 23. Windows Azure StorageSecurityData from many customers is mixed in a single poolAccess to data in a specific account is only granted to entities having the secret key for that accountStorage 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 rolloverStorage keys are used to HMAC sign each access request
- 24. SQL AzureAs withstorage, runs on separate hardware with no connectivity to compute except (logically) over the InternetDeveloper portal can create databases and set an administrator passwordSQL administrator can create additional user accounts, each authenticated with a passwordData from many customers is pooled in a single SQL instance, but they are treated as separate and access controlled independently
- 25. Defenses Inherited byWindows Azure TenantsSpoofingTampering & DisclosureElevation of PrivilegeDenial of ServiceLoad-balanced InfrastructureNetwork bandwidth throttlingCiscoGuard enabled on Storage nodesConfigurable scale-outVM switch hardeningCertificate ServicesShared-Access SignaturesHTTPS Sidechannel protectionsVLANsTop of Rack SwitchesCustom packet filteringPartial Trust RuntimeHypervisor custom sandboxingVirtual Service AccountsPort Scanning/ Service EnumerationService Definition file, Windows Firewall, VM switch packet filtering
Editor's Notes
- #13 Services are isolated from other servicesCan only access resources declared in the service model .Local node resources – temp storageNetwork end-pointsIsolation using multiple mechanismsMuch of the traditional infrastructure security moves to the platform and application layersNetwork Access Control Lists and Firewalls become host packet filters and virtual firewallsMultiple, privileged accounts become pre-defined agent accounts controlled by the systemPlatform and network level encryption will still play a role, but the application developer becomes more responsible for defining how encryption is used end-to-endServices are isolated from other servicesCan only access resources declared in the service model .Local node resources – temp storageNetwork end-pointsIsolation using multiple mechanismsAutomatic application of windows security patchesRolling operating system image upgrades
- #25 Port Scanning/ Service EnumerationThe only ports open and addressable (internally or externally) on a Windows Azure VM are those explicitly defined in the Service Definition file. Windows Firewall is enabled on each VM in addition to enhanced VM switch packet filtering, which blocks unauthorized traffic Denial of Service Windows Azure’s load balancing will partially mitigate Denial of Service attacks from the Internet and internal networks. This mitigation is done in conjunction with the developer defining an appropriate Service Definition VM instance count scale-out. On the Internet, Windows Azure VMs are only accessible through public Virtual IP Addresses (VIPs). VIP traffic is routed through Windows Azure’s load-balancing infrastructure. Windows Azure monitors and detects internally initiated Denial of Service attacks and removes offending VMs/accounts from the network. As a further protection, the root host OS that controls guest VMs in the cloud is not directly addressable internally by other tenants on the Windows Azure network and the root host OS is not externally addressable.Windows Azure is also reviewing additional Distributed Denial of Service (DDoS) solutions available from Microsoft Global Foundation Services to help further protect against Denial of Service attacks.SpoofingVLANs are used to partition the internal network and segment it in a way that prevents compromised nodes from impersonating trusted systems such as the Fabric Controller. At the Hypervisor VM Switch, additional filters are in place to block broadcast and multicast traffic, with the exception of what is needed to maintain DHCP leases. Furthermore, the channel used by the Root OS to communicate with the Fabric Controller is encrypted and mutually authenticated over an HTTPS connection, and it provides a secure transfer path for configuration and certificate information that cannot be intercepted.Eavesdropping / Packet SniffingThe Hypervisor’s Virtual Switch prevents sniffer-based attacks against other VMs on the same physical host. Top-of-rack switches will be used to restrict which IP and MAC addresses can be used by the VMs and therefore mitigate spoofing attacks on internal networks. To sniff the wire inside the Windows Azure cloud environment, an attacker would first need to compromise a VM tenant in a way that elevated the attacker to an administrator on the VM, then use a vulnerability in the hypervisor to break into the physical machine root OS and obtain system account privileges. At that point the attacker would only be able to see traffic inbound to the compromised host destined for the dynamic IP addresses of the VM guests controlled by the hypervisor. Multi-tenant hosting and side-channel attacksInformation disclosure attacks (such as sniffing) are less severe than other forms of attack inside the Windows Azure datacenter because virtual machines are inherently untrusted by the Root OS Hypervisor. Microsoft has done a great deal of analysis to determine susceptibility to side-channel attacks. Timing attacks are the most difficult to mitigate. With timing attacks, an application carefully measures how long it takes some operations to complete and infers what is happening on another processor. By detecting cache misses, an attacker can figure out which cache lines are being accessed in code. With certain crypto implementations involving lookups from large tables, knowing the pattern of memory accesses - even at the granularity of cache lines - can reveal the key being used for encryption. While seemingly far-fetched, such attacks have been demonstrated under controlled conditions. There are a number of reasons why side-channel attacks are unlikely to succeed in Windows Azure: An attack works best in the context of hyper-threading, where the two threads share all of their caches. Many current CPUs implement fully independent cores, each with a substantial private cache. The CPU chips that Windows Azure runs on today have four cores per chip and share caches only in the third tier.Windows Azure runs on nodes containing pairs of quad-core CPUs, so there are three other CPUs sharing the cache, and seven CPUs sharing the memory bus. This level of sharing leads to a great deal of noise in any signal from one CPU to another because actions of multiple CPUs tend to obfuscate the signal.Windows Azure generally dedicates CPUs to particular VMs. Any system that takes advantage of the fact that few servers keep their CPUs busy all the time, and implements more logical CPUs than physical CPUs, might open the possibility of context switches exposing cache access patterns. Windows Azure operates differently. VMs can migrate from one CPU to another, but are unlikely to do so frequently enough to offer an attacker any information.