VIRTUALIZATION AND

PRIVATE CLOUD RISK

MODELING

Dave Shackleford
IANS

Session ID: CSV-T18

Session Classification: Intermediate
 Introduction

► Security professionals need to consider the risk of

implementing and operating virtualization and cloud
technologies
► In this presentation, we’ll discuss fundamental elements
of risk to virtualization and private cloud environments
► Then we’ll break down some “risk statements” to help
you conceptualize the endgame
How Business Sees Virt &
Cloud

$$$
How Security Sees Virt &
Cloud

101010101010100100001010100101010
Components &
Architecture
Virtualization Architecture
Is the host OS locked down?
Is the hypervisor secure?

Host OS Guest OS Guest OS How do I

harden and
manage my
Guest OS
VNIC VNIC VNIC images?
Can we see this
traffic? Can we
segment it
VSwitch
appropriately?
VM Bus

Physical NIC

Are management and control

channels secured?
Storage
How is storage secured?
And Private Cloud…?
Web interfaces, APIs

Operations Services
and Traffic

DB, Messaging, Security

Management Hypervisors Management

Diagram from http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1030816

Assets
 Asset Criticality

► Critical assets: Required for business operations

► Required by critical systems
► Not wholly replaceable elsewhere
► Important assets: No short term impedance of business
function, but severely impactful long term
► Supportive assets: Affects effectiveness of day-to-day
business operations, but not catastrophic if lost
► Assets that provide convenience
► Primarily an issue for asset owner, not organization as a whole
 Assets: Valuation

► Many valuation models possible

► Most common are classification-based and cost-based
► For simplicity, easiest to use the classification model
here:
► Critical = High Value
► Important = Medium Value
► Supportive = Low Value
► This is the age-old Quantitative vs. Qualitative debate, of
course
 Assets: Data and Equipment

► Data:
► Virtual machine files (at rest)
► Virtual machine files (in transit)
► Management databases + configuration
► Hypervisor configuration and OS
► Equipment:
► Server Hardware
► Virtual appliances (ties in to Data assets)
► Storage hardware
► Network equipment
► Management terminals/endpoints
 Asset: Personnel, Services &
Facilities
► Personnel
► Virtualization teams
► Network teams
► Developers / Operations
► Security teams
► SysAdmin teams
► Services include:
► Power
► Cooling
► Network/ISP services
► Facilities:
► Physical locations (data centers)
Threats
 Threat Agents

► Insiders:
► Virtualization teams
► Network teams
► Developers / Operations
► Security teams
► SysAdmin teams
► Storage teams
► Outsiders
► Partners/Affiliates
► Nature (disasters)
► Technology (failure/improper function)
 Undesirable Events

► Integrity changes: Accidental or intentional modification

of data that results in service interruption or additional
business consequences
► Logical/Physical exposure: Exposure of data or
information that could lead to additional compromise or
technical/regulatory/business consequences
► Availability issues: Individual or aggregate asset and
resource availability failure
 Threat Statements

Threat: Insider | Outsider | Partner

Undesirable Event: Integrity modification | Physical

Exposure | Logical Exposure | Denial of Service

Asset: Data | Equipment | Personnel | Services |

Facilities

Threat Statement: Who caused an event to what?

Vulnerabilities
 Vulnerability Categories

► Administrative
► People - roles, privileges, hiring
► Technical
► Any technical flaw in software components or design
► Physical
► Focused on access control and facility weaknesses
 Administrative Vulnerabilities

► Hiring practices: Background checks

► Missing or weak skills in technical team
► Poor role design and review
► Separation of Duties and Least Privilege
► Poor audit focus on user/admin activities

► Cloud = User involvement in workloads = more chances

for accidental or purposeful harmful events
 Technical Vulnerabilities

► Lots of issues here

► Flaws in software products from VMware, Microsoft, and others
► Poor network design, segmentation
► Malware insertion in VM files
► Poor permissions/isolation
► Side-channel attacks
► Logs/orchestration

http://phys.org/news/2012-11-vm-rude-awakening-virtualization.html
 Physical Vulnerabilities

► Fundamentally an extension of DR and BCP strategies

► Virtualization and cloud has new considerations:
► Storage replication and cycle times for VMs and data
► Cloud-based DRaaS
► Hardware compatibility in backup sites
► Also includes physical access controls
Risk Statements
 Creating Risk Statements

► Defining risk statements is the crux of real, practical risk

analysis
► Every environment is different - and risks will be too
► However, there are a number of common risk scenarios
I’ve seen
► I’ll describe these, and lay out a “standard” and “agile”
risk modeling design for risk statements around them
 Risk Scenarios: Administrative
Threat:Vulnerability Event Asset
Virt Admins: Too many Data Loss Data
Privileges Integrity Changes Services
Availability Loss
DevOps: Weak Integrity Changes Data
Workflow/Orchestration Availability Loss Services
Privileges
Admins: Poor Logging and Data Loss Data
Audit Trail Monitoring Integrity Changes Services
Insiders/Partners: Poor Data Loss Data
Identity Management and Services
Roles in *aaS clouds
 Risk Scenarios: Technical
Threat:Vulnerability Event Asset
Insiders: Missing Data Loss Data
Hypervisor or OS patches Integrity Changes Services
Availability Loss
Insiders: Weak or Missing Data Loss Data
Access Controls Integrity Changes Services
Insiders/Outsiders/Partner Data Loss Data
s : Poor Network Availability Loss Services
Segmentation
Outsiders: System Data Loss Data
Exposure Availability Loss Services
Insiders/Outsiders/Partner Data Loss Data
s : Poor Storage Security Integrity Changes Services
Controls Availability Loss
 A Simple Risk Model

► Ben Sapiro developed a model called the Binary Risk

Analysis, presented at SecTor in 2011
► The goal: Reasonable risk analysis in 5 minutes.
► Is it perfect? Nope.
► Does it work for us? Yep.
► Ben’s paper, work card, and app available at:
► https://binary.protect.io/
 Risk Statement Example #1

► Could virt admins Yes

Yes
with too many
privileges cause
severe impact to No
Yes
the organization’s
infrastructure?
► Asset:
Hypervisors and
Yes
Management No
Tools
 Risk Statement Example #1 (2)
Yes
► Could virt admins Yes

with too many

privileges cause Yes
severe impact to Yes

the organization’s
infrastructure?
► Answer:
Absolutely. This is
a HIGH risk, a
classic insider
abuse or mistake
scenario.
 Risk Statement Example #2

► Could poorly No
Yes
defined and
controlled IAM
services lead to No
Yes
data exposure in
*aaS services?
► Assets:
Presumed
Yes
sensitive data in No
private *aaS
cloud offerings
 Risk Statement Example #2 (2)
Yes
► Could poorly Yes

defined and
controlled IAM Yes
services lead to Yes

data exposure in
*aaS services?
► With Medium
Likelihood, but
High Impact, this
is a potentially
HIGH risk.
 Risk Statement Example #3

► Could missing No
No
hypervisor
patches or
updates lead to No
Yes
insider (or internal
attacker)
compromise?
► Assets:
No
Hypervisors and No
virtualization
infrastructure,
VMs
 Risk Statement Example #3 (2)
Yes
► Could missing Yes

hypervisor
patches or Yes
updates lead to No

insider (or internal

attacker)
compromise?
► Answer: Yes, but
with a MEDIUM
risk.
The Rub
 Assessing Virt/Cloud Risk

► You still need:

► Assets
► Threats
► Vulnerabilities
► Place greater emphasis on:
► User interfaces and interactions
► Separation of duties and IT Ops roles
► Storage and databases
► Management interfaces and network segments
► Find a risk statement model that works for you
► Binary Risk Analysis is good, Creative Commons too
 Questions?

► Feedback, rants, thoughts:

Dave Shackleford
CTO, IANS
dshackleford@iansresearch.com
867-5309