TechEd North America 2014, Houston
Public Cloud Security: Surviving in a Hostile Multitenant Environment – Mark Russinovich

Day 3, 14 May 2014, 3:15PM-4:30PM (DCIM-B306)

Disclaimer: This post contains my own thoughts and notes based on attending TechEd North America 2014 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of either Microsoft, the presenters or the speakers.

Executive Summary—Sean’s takeaways

• To move to cloud, customers must trust us
• Need to follow best practices to make things secure
  • At least as good as what your customers are doing
• Makes sense to look at top threats and think about mitigating risk in each case
• Azure does a lot of work to mitigate risk in many areas
  • Often far more than you’d do in your own organization
• Top three threats
  • Data breach
  • Data loss
  • Account or service hijacking
• Encryption at rest not a panacea

Full video

Mark Russinovich – Technical Fellow, Azure, Microsoft

“There is no cloud without trust”

• Security, Availability, Reliability

Misconceptions about what it means to be secure in cloud

• Will dispel some of the myths
• Look at what’s behind some of the risks
• Mitigation of risks

The Third Computing Era

• 1^st – Mainframes
• 2^nd – PCs and Servers
• 3^rd – Cloud + Mobile
• (Lack of) Security could ruin everything

Security

• Study after study, CIOs say looking at cloud, but worried about security
• Other concerns
  • Security
  • Compliance
  • Loss of control

Goals of this Session

• Identify threats
• Discuss risk
• Mitigate

Cloud Architecture

• Canonical reference architecture
• Virtualized structure
• Datacenter facility
• Microsoft—deployment people and DevOps
• Customers of cloud—Enterprise, Consumer
• Attacker

Cloud Security Alliance

• Microsoft is a member

The Cloud Security Alliance “Notorious Nine” (what are threats to data in cloud?)

• Periodically surveys industry
• 2010 – Seven top threats
• 2013 – Nine top threats
• Mark adds 10^th threat

#10 – Shared Technology Issues: Exposed Software

• Shared code defines surface area exposed to customers
  • In public cloud, servers are homogeneous—exact same firmware
  • Hypervisor
  • Web server
  • API support libraries
• What if there’s a vulnerability?
• Stability and security are balanced against each other
  • Patching might bring down servers
• Assumes infrastructure is accessible only by trusted actors
• Corporate and legal mechanisms for dealing with attackers
• This is: Enterprise Multi-tenancy

#10 – Shared Technology Issues: The Cloud Risk

• A vulnerability in publically accessible software enables attached to puncture the cloud
  • Exposes data of other customers
  • Single incident—catastrophic loss of customer confidence
  • Potential attackers are anonymous and in diverse jurisdictions
• “Are you doing as good a job as I’d be doing if I had the data in the house”?
• Important (vs. Critical) – data not at risk, but confidence in Azure is critical
  • “Cloud critical”
• “Hostile Multi-tenancy”
• We do whatever it takes to patch immediately

#10 – Shared Technology Issues: Bottom Line

• Enterprises and clouds exposed to this risk
• Clouds at higher risk
  • Data from lots of customers
  • API surface is easy to get to
• Clouds are generally better at response
  • Azure has about 1,000,000 servers
  • Can do critical patch in just a couple hours, all servers
  • Breach detection/mitigation
• Risk matrix
  • Perceived risk—bit below average
  • Actual risk – Fairly high (Mark’s assessment)

#9 – Insufficient Due Diligence

• Moving to cloud, but side-stepping IT processes
  • Shadow IT
  • BYOIT – Bring your own IT—non-IT going to cloud
  • IT management, etc. are designed for on-premises servers
• Bottom line
  • IT must lead responsible action

#9 – Insufficient Due Diligence – Azure

• Azure API Discovery
  • Monitors access to cloud from each device
• SDL
• Cloud SDL (under development)

#8 – Abuse of Cloud Services

• Agility and scale of cloud is attractive to users
• Use of Compute as malware platform
• Use of storage to store and distributes illegal content
• Use of compute to mine digital currency
  • VMs shut down per month, due to illegal activity: 50,000-70,000
  • Bulk of it is for generating crypto currency
  • Top 3 countries that are doing this: Russia, Nigeria, Vietnam
  • Password for Vietnamese pirate: mauth123 (password123)
  • Harvard supercomputer was mining bitcoin

#8 – Abuse of Cloud Services: It’s Happening

• Attackers can use cloud and remain anonymous
• Bottom line
  • Mostly cloud provider problem
  • Hurts bottom line, drives up prices
• Using machine learning to learn how attackers are working

#7 – Malicious Insiders

• Many cloud service provider employees have access to cloud
• Malicious check-in, immediately rolls out to everybody
• Operators that deploy code
• Datacenter operations personnel
• Mitigations
  • Employee background checks
  • Limited as-needed access to production
    • No standing admin privileges
  • Controlled/monitored access to production services
• Bottom line
  • Real risk is better understood by third-party audits

Compliance is #1 concern for companies already doing stuff in cloud

#7 – Malicious Insiders – Compliance

#6 – Denial of Service

• Public cloud is public
• Amazon was at one point brought down by DDOS
• Your own app could get DDOS’d
• Cloud outage – a form of DDOS
• Redundant power from two different locations to each data center
• Blipping power to data center results in major outage—several hours
• Mitigations
  • Cloud providers invest heavily in DDOS prevention
  • Third party appliances that detect and divert traffic
  • We do this for our clients too
  • Large-scale DDOS, doesn’t catch smaller things
• Geo-available cloud providers can provide resiliency
• Azure
  • DDOS prevention
  • Geo-regions for failover

#5 – Insecure Interfaces and APIs

• Cloud is new and rapidly evolving, so lots of new API surface
• CSA – one of the biggest risks
• Examples
  • Weak TLS crypto – DiagnosticMonitor.AllowInsecure….
  • Incomplete verification of encrypted content
• Bottom line
  • Cloud providers must follow SDL
  • Customers should validate API behavior

#4 – Account or Service Traffic Hijacking

• Account hijacking: unauthorized access to an account
• Possible vectors
  • Weak passwords
  • Stolen passwords (e.g. Target breach)
  • Then you find that people use same password everywhere; so attacker can use on other services
• Not specific to cloud
  • Cloud use may result in unmanaged credentials
  • Developers are provisioning apps, hard-coding passwords, publishing them
  • Lockboxes, “secret stores”
  • Back door—someone in DevOps gets phished, then brute force
• Mitigations
  • Turned off unneeded endpoints
  • Strong passwords
  • Multifactor authentication
    • Entire world moving to multifactor
  • Breach detection
• Azure
  • Anti-malware
  • IP ACLs (with static IP addresses)
  • Point-to-Site, Site-to-Site, ExpressRoute
  • Azure Active Directory MFA

#3 – Data Loss

• Ways to lose data
  • Customer accidentally deletes data
  • Attacker deletes or modifies it
  • Cloud provider accidentally deletes or modifies it
  • Natural disaster
• Mitigations
  • Customer: do point-in-time backups
  • Customer: geo-redundant storage
  • Cloud provider: deleted resource tombstoning
    • Can’t permanently delete
    • 90 days
• Azure
  • Globally Replicated Storage
  • VM Capture
  • Storage snapshots
  • Azure Site Replica

#2 – Data Breaches

• Represents collection of threats
• Most important asset of company is the data

#2 – Data Breaches: Physical Attacks on Media

• Threat: Attacker has physical access to data/disk
• Mitigation: cloud provider physical controls
  • To get in data center, gate with guards
  • To get into room with servers, biometric controls
  • Disk leaving data center—very strict controls
  • Data scrubbing and certificate
  • SSDs never leave data center, because it’s so hard to scrub it
  • HDDs are scrubbed
• Enhanced mitigations
  • Third-party certifications (e.g. FedRamp)
  • Encryption at rest
• Azure: third-party encryption

Encryption at rest

• Two types
  • Cloud provider has keys
  • Customer has keys
• When you have keys, you’re also giving keys to cloud to decrypt

#2 – Data Breaches: Physical Attacks on Data Transfer

• Man-in-the-middle
• Mitigation
  • Encrypt data between data centers
  • APIs use TLS
  • Customer uses TLS
  • Customer encrypts outside of cloud

#2 – Data Breaches: Side-Channel Attacks

• Threat: Collocated attacker can infer secrets from processor side-effects
• Snooping on processor that they’re co-located on
• Researcher assumptions (but unlikely)
  • Attacker knows crypto code customer is using and key strength
  • Attacker can collocate on same server
  • Attacker shares same core as you
  • Customer VM continuously executes crypto code
• Not very likely
• Bottom line
  • Not currently a risk, in practice

#2 – Data Breaches: Logical Attack on Storage

• Threat: attacker gains logical access to data
• Mitigations
  • Defense-in-depth prevention
  • Monitoring/auditing
• Encryption-at-rest not a significant mitigation
  • If they can breach logical access, they can maybe get keys too
  • The keys are there in the cloud
  • Encrypt-at-rest isn’t based on real threat modeling

#2 – Data Breaches: Bottom Line

• Media breach not significant risk
• Network breach is risk
• Logical breach is a risk
  • Encrypt-at-rest doesn’t buy much

#1 – Self—Awareness

• E.g. Skynet
• People are actually worried about this