Stu w22 a

Session ID:

Session Classification:

Dave Shackleford IANS

CSV-T18

Intermediate

VIRTUALIZATION AND

PRIVATE CLOUD RISK

MODELING

► 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

Introduction

How Business Sees Virt &

Cloud

$$$

How Security Sees Virt &

Cloud

101010101010100100001010100101010

Components & Architecture

Virtualization Architecture

Host OS

VSwitch

Guest OS

VNIC VNIC VNIC

VM Bus

Guest OS

Physical NIC

Are management and control

channels secured?

Is the host OS locked down?

Is the hypervisor secure?

Can we see this

traffic? Can we

segment it

appropriately?

How do I

harden and

manage my

Guest OS

images?

Storage How is storage secured?

And Private Cloud…?

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

Operations Services

and Traffic

DB, Messaging,

Management

Web interfaces, APIs

Hypervisors Security

Management

Assets

► 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

Asset Criticality

► 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: Valuation

► 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

Assets: Data and Equipment

► Personnel

► Virtualization teams

► Network teams

► Developers / Operations

► Security teams

► SysAdmin teams

► Services include:

► Power

► Cooling

► Network/ISP services

► Facilities:

► Physical locations (data centers)

Asset: Personnel, Services &

Facilities

Threats

► Insiders:

► Virtualization teams

► Network teams

► Developers / Operations

► Security teams

► SysAdmin teams

► Storage teams

► Outsiders

► Partners/Affiliates

► Nature (disasters)

► Technology (failure/improper function)

Threat Agents

► 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

Undesirable Events

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?

Threat Statements

Vulnerabilities

► Administrative

► People - roles, privileges, hiring

► Technical

► Any technical flaw in software components or design

► Physical

► Focused on access control and facility weaknesses

Vulnerability Categories

► 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

Administrative 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

Technical Vulnerabilities

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

► 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

Physical Vulnerabilities

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

Creating Risk Statements

Threat:Vulnerability Event Asset

Virt Admins: Too many Privileges

Data Loss Integrity Changes Availability Loss

Data Services

DevOps: Weak Workflow/Orchestration Privileges

Integrity Changes Availability Loss

Data Services

Admins: Poor Logging and Audit Trail Monitoring

Data Loss Integrity Changes

Data Services

Insiders/Partners: Poor Identity Management and Roles in *aaS clouds

Data Loss

Data Services

Risk Scenarios: Administrative

Threat:Vulnerability Event Asset

Insiders: Missing Hypervisor or OS patches


Data Services

Insiders: Weak or Missing Access Controls

Data Loss Integrity Changes

Data Services

Insiders/Outsiders/Partners : Poor Network Segmentation

Data Loss Availability Loss

Data Services

Outsiders: System Exposure

Data Loss Availability Loss

Data Services

Insiders/Outsiders/Partners : Poor Storage Security Controls


Data Services

Risk Scenarios: Technical

► 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/

A Simple Risk Model

► Could virt admins

with too many

privileges cause

severe impact to

the organization’s

infrastructure?

► Asset:

Hypervisors and

Management

Tools

Risk Statement Example #1

Yes

Yes

Yes

Yes

No

No

► Could virt admins

with too many

privileges cause

severe impact to

the organization’s

infrastructure?

► Answer:

Absolutely. This is

a HIGH risk, a

classic insider

abuse or mistake

scenario.

Risk Statement Example #1 (2)

Yes

Yes

Yes

Yes

► Could poorly

defined and

controlled IAM

services lead to

data exposure in

*aaS services?

► Assets:

Presumed

sensitive data in

private *aaS

cloud offerings


No

No

No

Yes

Yes

Yes

► Could poorly

defined and

controlled IAM

services lead to

data exposure in

*aaS services?

► With Medium

Likelihood, but

High Impact, this

is a potentially

HIGH risk.


Yes

Yes

Yes

Yes

► Could missing

hypervisor

patches or

updates lead to

insider (or internal

attacker)

compromise?

► Assets:

Hypervisors and

virtualization

infrastructure,

VMs


Yes

No

No

No

No

No

► Could missing

hypervisor

patches or

updates lead to

insider (or internal

attacker)

compromise?

► Answer: Yes, but

with a MEDIUM

risk.


Yes

No

Yes Yes

The Rub

► 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

Assessing Virt/Cloud Risk

► Feedback, rants, thoughts:

Dave Shackleford

CTO, IANS

[email protected]

867-5309

Questions?

Documents

Stu w22 a