cloud computing

Cloud Computing
Architecture, IT Security, & Operational Perspectives
Steven R. Hunt
ARC IT Governance Manager
Ames Research Center
Matt Linton
IT Security Specialist
Matt Chew Spence
IT Security Compliance Consultant
Dell Services Federal Government
August 17, 2010

Agenda
 Introductions
» Steve Hunt
 What is cloud computing?
» Matt Chew Spence
 How can NASA benefit from cloud computing?
» Matt Chew Spence
 How is NASA implementing cloud computing?
» Matt Linton
 How does NASA secure cloud computing?
» Matt Linton
 Q&A
» Presentation Team
Extended Presentation
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
 Assessment, Authorization, & FedRAMP
» Steve Hunt

OBJECTIVE: Overview of cloud
computing and share vocabulary
OBJECTIVE: Overview of cloud
computing and share vocabulary
Agenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

Cloud Computing – NIST Definition:
“A model for enabling convenient, on-
demand network access to a shared
pool of configurable computing
resources (e.g., networks, servers,
storage, applications, and services)
that can be rapidly provisioned and
released with minimal management
effort or service provider interaction”
What is Cloud Computing?

Conventional
 Manually Provisioned
 Dedicated Hardware
 Fixed Capacity
 Pay for Capacity
 Capital & Operational
Expenses
 Managed via Sysadmins
Cloud
 Self-provisioned
 Shared Hardware
 Elastic Capacity
 Pay for Use
 Operational Expenses
 Managed via APIs
Conventional Computing
vs.
Cloud Computing

Five Key Cloud Attributes:
1. Shared / pooled resources
2. Broad network access
3. On-demand self-service
4. Scalable and elastic
5. Metered by use

Shared / Pooled Resources:
 Resources are drawn from a common pool
 Common resources build economies of scale
 Common infrastructure runs at high efficiency

Broad Network Access:
 Open standards and APIs
 Almost always IP, HTTP, and REST
 Available from anywhere with an internet
connection

On-Demand Self-Service:
 Completely automated
 Users abstracted from the implementation
 Near real-time delivery (seconds or minutes)
 Services accessed through a self-serve
web interface

Scalable and Elastic:
 Resources dynamically-allocated between
users
 Additional resources dynamically-released
when needed
 Fully automated

Metered by Use:
 Services are metered, like a utility
 Users pay only for services used
 Services can be cancelled at any time

Three Service Delivery Models
IaaS: Infrastructure as a Service
Consumer can provision computing resources within
provider's infrastructure upon which they can deploy and
run arbitrary software, including OS and applications
PaaS: Platform as Service
Consumer can create custom applications using
programming tools supported by the provider and deploy
them onto the provider's cloud infrastructure
SaaS: Software as Service
Consumer uses provider’s applications running on
provider's cloud infrastructure

SaaS
PaaS
IaaS
Amazon Google Microsoft Salesforce
Service Delivery Model Examples
Products and companies shown for illustrative purposes only and should not
be construed as an endorsement

 Cost efficiencies
 Time efficiencies
 Power efficiencies
 Improved process
control
 Improved security
 “Unlimited” capacity
Cloud efficiencies and improvements
• Burst capacity (over-
provisioning)
• Short-duration projects
• Cancelled or failed missions
• Burst capacity (over-
provisioning)
• Short-duration projects
• Cancelled or failed missions
$
• Procurement
• Network connectivity
• Procurement
• Network connectivity
• Standardized, updated base images
• Centrally auditable log servers
• Centralized authentication systems
• Improved forensics (w/ drive image)
• Standardized, updated base images
• Centrally auditable log servers
• Centralized authentication systems
• Improved forensics (w/ drive image)

OBJECTIVE: Discuss requirements,
use cases, and ROI
OBJECTIVE: Discuss requirements,
use cases, and ROI
Agenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

How can NASA benefit from cloud computing?
Current IT options for Scientists
Current Options*Requirements*
* Requirements and Options documented in over 30+ interviews
with Ames scientists as part 2009 NASA Workstation project.

Mission Objectives
Explore, Understand, and Share
Exploration Space OpsScienceAeronautics
High Compute Vast Storage
High Speed
Networking
Process
Large
Data
Sets
Scale-out for
one-time
events
Require
infrastructure
on-demand
Store
mission &
science
data
Share
information
with the
public
Run
Compute
Intensive
Workloads
Shared Resource
Mission Support
Scientists direct access to Nebula cloud computing

High-end
Compute
Vast Storage
High Speed
Networking
TARGET
COMPUTE
PLATFORM
Excellent example
of how OCIO-
sponsored
innovation can be
rapidly
transformed into
services that
address Agency
mission needs
Offer scientists services to address the gap

*15% utilization based on two reports from Gartner Group, Cost of
Traditional Data Centers (2009), and Data Center Efficiency (2010).
ROI and ARC Case Study
POWER: Computers typically require 70% of their total
power requirements to run at just 15% utilization.

 Operational Enhancements:
» Strict standardization of hardware and infrastructure
software components
» Small numbers of system administrators due to the
cookie-cutter design of cloud components and
support processes
» Failure of any single component within the Nebula
cloud will not become reason for alarm
» Application operations will realize similar efficiencies
once application developers learn how to properly
deploy applications so that they are not reliant on any
particular cloud component.
ROI and ARC Case Study

OBJECTIVE: Overview of how NASA
is implementing cloud computing
OBJECTIVE: Overview of how NASA
is implementing cloud computingAgenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

How is NASA implementing cloud computing?

Nebula Principles
 Open and Public APIs, everywhere
 Open-source platform, apps, and data
 Full transparency
» Open source code and documentation
releases
 Reference platform
» Cloud model for Federal Government

Nebula User Experience
Nebula IaaS user will have an experience
similar to Amazon EC2:
 Dedicated private VLAN for instances
 Dedicated VPN for access to private VLAN
 Public IPs to assign to instances
 Launch VM instances
 Dashboard for instance control and API access
Able to import/export bundled instances to AWS
and other clouds
Products and companies named for illustrative purposes only and should not be
construed as an endorsement

Architecture Drivers
 Reliability
 Availability
 Cost
 IT Security

Shared Nothing
 Messaging Queue
 State Discovery
 Standard Protocols
Automated
• IPMI
• PXEBoot
• Puppet

Nebula Infrastructure Components
 Cloud Node
 Network Node
 Compute Node
 Volume Node
 Object Node
 Monitoring / Metering / Logging / Scanning

Cloud Node
LDAP
Data
Store
LDAP
Data
Store
Ubuntu OSUbuntu OS
PuppetPuppet
Nova
Cloud
Node
Nova
Cloud
Node
PXEPXE
RabbitMQ
Redis KVS

Ubuntu OSUbuntu OS
PuppetPuppet
KVMKVM
LibVirtLibVirt
Nova
Compute
Node
Nova
Compute
Node
802.1(q)802.1(q)
BrctlBrctl
PXEPXE
Project VLANProject VLAN
Running InstanceRunning Instance
Compute Node

Ubuntu OSUbuntu OS
PuppetPuppet
LVMLVM
AoEAoE
Nova
Volume
Node
Nova
Volume
Node
PXEPXE
Exported VolumeExported Volume
Volume Node

Object Node
Ubuntu OSUbuntu OS
PuppetPuppet
Nova
Object
Node
Nova
Object
Node
PXEPXE
NginxNginx

Network Node
Ubuntu OSUbuntu OS
PuppetPuppet
Nova
Networ
k
Node
Nova
Networ
k
Node
802.1(q)802.1(q)
BrctlBrctl
PXEPXE
Project
VLAN
Project
VLAN
IPTablesIPTables
Public
Internet
Public
Internet

Pilot Lessons Learned
- Automate Everything
 No SysAdmin is perfect
 99% is not good enough
 NEVER make direct system changes
 When in doubt - PXEBoot

- Test Everything
 KVM + Jumbo Frames
 Grinder
 Unit Tests / Cyclometric Complexity
 TransactionID Insertion (Universal Proxy)

- Monitor Everything
 Ganglia
 Munin
 Syslog-NG + PHPSyslog-NG
 Nagios
 Custom Log Parsing (Instance-centric)

OBJECTIVE: Overview of technical
security mechanisms built into Nebula
security mechanisms built into NebulaAgenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

Technical Security Overview
• Issues with Commercial Cloud Providers
• Overview of Current Security Mechanisms
• Innovations

How does NASA secure cloud computing?
Commercial Cloud Provider Security Concerns
» IT Security not brought into decision of how & when
NASA orgs use clouds
» IT Security may not know NASA orgs are using
clouds until an incident has occurred
» Without insight into monitoring/IDS/logs, NASA
may not find out that an incident has occurred
» No assurances of sufficient cloud infrastructure
access to perform proper forensics/investigations
» These issues are less likely with a private cloud like
Nebula

IT Security is built into Nebula
 User Isolation from Nebula Infrastructure
 Users only have access to APIs and Dashboards
» No user direct access to Nebula infrastructure
 Project-based separation
» A project is a set of compute resources
accessible by one or more users
» Each project has separate:
• VLAN for project instances
• VPN for project users to launch, terminate,
and access instances
• Image library of instances

Networking
 RFC1918 address space internal to Nebula
» NAT is used for those hosts within Nebula
needing visibility outside a cluster
 Three core types of networks within Nebula:
» Customer
• Customer VLANs are isolated from each
other
» DMZ
• Services available to all Nebula such as
NTP, DNS, etc
» Administrative

Security Groups
 Combination of VLANs and Subnetting
 Can be extended to use physical
network/node separation as well (future)

C
L
O
U
D
A
P
I
S
S
M
R
Project A
(10.1.1/24)
Project B
(10.1.2/24)
Operations Console
(custom)
Security Scanners
(Nessus, Hydra, etc)
Log Aggregation,
SOC Tap
RFC1918
Space
(LAN_X)
B
R
I
D
G
E
Public IP
Space
I
N
T
E
R
N
E
T
External
Scanner
DMZ
Services
Event Correlation
Engine

Firewalls
 Multiple levels of firewalling
» Hardware firewall at site border
» Firewall on cluster network head-ends
» Host-based firewalls on key hosts
» Project based rule sets based on Amazon
security groups

Remote User Access
 Remote access is only through VPN (openVPN)
 Separate administrative VPN and user VPNs
 Each project has own VPN server

Intrusion Detection
 OSSEC on key infrastructure hosts
» Open source Host-based Intrusion Detection
 Mirror port to NASA SOC tap
 Building 10Gb/sec IDS/IPS/Forensics device
with vendor partners

Configuration Management
 Puppet used to automatically push out
configuration changes to infrastructure
 Automatic reversion of unauthorized changes
to system

Vulnerability Scanning
 Nebula uses both internal and external
vulnerability scanners
 Correlate findings between internal and
external scans

Incident Response
 Procedures for isolating individual VMs,
compute nodes, and clusters, including:
» Taking snapshot of suspect VMs, including
memory dump
» Quarantining a VM within a compute node
» Disabling VM images so new instances
can’t be launched
» Quarantining a compute node within a
cluster
» Quarantining a cluster

Role Based Access Control
 Multiple defined roles within a project
 Role determines which API calls can be
invoked
» Only network admin can request non-1918
addresses
» Only system admin can bundle new images
» etc

Innovation - Security Gates
 API calls can be intercepted and security
gates can be imposed on function being called
 When an instance is launched, it can be
scanned automatically for vulnerabilities
 Long term vision is to have a pass/fail launch
gate based on scan/monitoring results

Vision - Security as a Service
 Goal - Automate compliance through security
services provided by cloud provider
 Security APIs/tools mapped to specific controls
» Customers could subscribe to tools/services to
meet compliance requirements
 When setting up new project in cloud
» Customers assert nature of data they will use
» Cloud responds with list of APIs/tools for
customers to use
 Currently gathering requirements but funding
needed to realize vision

Vision - Security Service Bus
 Goal - FISMA compliance through continuous
real-time monitoring and situational awareness
» Security service bus with event driven
messaging engine
» Correlate events across provider and multiple
customers
» Dashboard view for security providers and
customers
» Allows customers to make risk-based security
decisions based on events experienced by
other customers
 Funding Needed to Realize Vision

Nebula Open Source Progress
 Significant progress in embracing the value of
open source software release
» Agreements with SourceForge and Github
» Open source identified as an essential component of
NASA’s open government plan
 Elements of Nebula in open source release
pipeline
» Started Feb 2010. Hope for release in June.
» Working toward continual incremental releases.
» Exploring avenues to contribute code to external
projects and to accept external contributions to the
Nebula code base.

OBJECTIVE: Overview of Nebula C&A
with Lessons Learned
OBJECTIVE: Overview of Nebula C&A
with Lessons Learned
Agenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

FISMA & Clouds
FISMA Overview
 Federal Information Security Management Act
– Requires all Gov’t computers to be under a security plan
–Mandates following NIST security guidance
–Required controls depend on FIPS-199 sensitivity level
–Requires periodic assessments of security controls
–Extremely documentation heavy
–Assumes one organization has responsibility for majority of
identified security controls
 FISMA is burdensome to cloud customers
–Customers want to outsource IT Security to cloud provider

FISMA & Clouds
FISMA Responsibilities in Clouds
 Clouds are a “Highly Dynamic Shared Management
Environment”
» Customers retain FISMA responsibilities for aspects of a
cloud under their control
» Responsibilities vary depending on level of control maintained
by customer
» Customer control varies relative to service delivery model
(SaaS, PaaS, or IaaS)
 Need to define & document responsibilities
» We parsed 800-53 Rev3 controls per service delivery model
 Nebula currently only offers IaaS
» We parsed all three service models for future planning

Identifying data types
Ensuring data appropriate to system
User/Account Management
Personnel Controls
Identifying data types
Ensuring data appropriate to system
User/Account Management
Personnel Controls
Software Licenses
Developer Testing
App Configuration Management
Software Development Lifecycle
Software Licenses
Developer Testing
App Configuration Management
Software Development Lifecycle
OS Config Mgmt
Anti-Malware
SW Install Controls
OS specific Controls
etc
OS Config Mgmt
Anti-Malware
SW Install Controls
OS specific Controls
etc
SaaS
IaaS
PaaS
Cloud
Customer
Security
Responsibility
Customer FISMA Responsibilities for Cloud
Customer FISMA
responsibilities Increase
as Customers have more
control over security
measures
62
FISMA & Clouds

FISMA & Clouds
IaaS Customer Security Plan Coverage Options
 At inception little guidance existed on cloud computing control
responsibilities & security plan coverage
 FedRAMP primarily addresses cloud provider responsibilities
» Other than control parsing definitions Customers are given little
guidance on implementing and managing FISMA requirements in a
highly dynamic shared management environment
 We have developed the following options:
Option Description Issues
Customer Owned Customer responsible for
own security plan with no
assistance from provider
• None to Providers
• Burdensome to
customers
Facilitated Customer responsible for
own security plan using
NASA template
• May still be burdensome
to customers.
• Not scalable unless
automated.
Agency Owned Agency or Center level
“Group” security plans
associated with Cloud
providers serve as
aggregation point for
customer.
• May be burdensome to
Agency or Center.
• Requires technology to
automate input and
aggregation of customer
data.

FISMA & Clouds
Current NASA Requirements/Tools may Impede
Cloud Implementation
 Default security categorization of Scientific and Space Science
data as “Moderate”
» Independent assessment required for every major change
• Currently requires 3rd
party document-centric audit
• Not scalable to cloud environments
 e-Authentication/AD integration required for all NASA Apps
» NASA implementations don’t currently support LDAP/SAML-
based federated identity management
 Function-specific stove-piped compliance tools
» STRAW/PIA tool/A&A Repository/NASA electronic forms
» Can’t easily automate compliance process for new apps
64

FISMA & Clouds
Emerging Developments in FISMA & Clouds
 Interagency Cloud Computing Security Working Group
is developing additional baseline security requirements
for cloud computing providers
 NIST Cloud Computing guidance forthcoming?
 Move towards automated risk models and security
management tools over documentation
 On the bleeding edge - changing guidance &
requirements are a key risk factor (and opportunity)
65

FISMA & Clouds
Nebula is Contributing to Cloud StandardsNebula is Contributing to Cloud Standards
 Federal Cloud Standards Working Group
 Fed Cloud Computing Security Working
Group
» Federal Risk & Authorization Management
Program (FedRAMP)
 Cloud Audit project
» Automated Audit Assertion Assessment &
Assurance API
 Providing Feedback to NIST and GAO
 GSA Cloud PMO
66

OBJECTIVE: Overview of how Nebula
concepts may integrate with FedRAMP
OBJECTIVE: Overview of how Nebula
concepts may integrate with FedRAMP
Agenda
 Introductions
» Steve Hunt
» Matt Chew Spence
» Matt Chew Spence
» Matt Linton
» Matt Linton
 Q&A
 FISMA & Clouds
» Matt Chew Spence
» Steve Hunt
» Steve Hunt

 A Federal Government-Wide program to provide
“Joint Authorizations” and Continuous Monitoring
» Unified Government-Wide risk management
» Authorizations can be leveraged throughout
Federal Government
 This is to be an optional service provided to
Agencies that does not supplant existing
Agency authority
Federal Risk and Authorization
Management Program
Federal Risk and Authorization
Management Program
FedRAMP

Independent Agency Risk Management of Cloud Services
…
Federal Agencies
Cloud Service Providers (CSP)
…
: Duplicative risk
management efforts
: Incompatible agency
policies
: Potential for inconsistent
application of Federal
security requirements
: Acquisition slowed by
lengthy compliance
processes
FedRAMP

Federated Risk Management of Cloud Systems
: Risk management cost
savings and increased
effectiveness
: Interagency vetted
approach
: Consistent
application of Federal
Federal Agencies
: Rapid acquisition
through consolidated
risk management
Cloud Service Providers (CSP)
FedRAMPFedRAMP
Risk Management
• Authorization
• Continuous
Monitoring
• Federal Security
Requirements
…
…
FedRAMP

FedRAMP Authorization process
Agency X has a need
for a new cloud based
IT system
Agency X gets
for the new IT system
from FedRAMP and
adds requirements if
necessary
Agency X releases
RFP for new IT
system and awards
contract to cloud
service provider
(CSP)
Agency X submits
request to FedRAMP
office for CSP To be
FedRAMP authorized
to operate
CSP is put into FedRAMP
priority queue
(prioritization occurs
based on factors such as
multi-agency use,
number of expected
users, etc.)
FedRAMP

FedRAMP Authorization process (cont)
FedRAMP
CSP and agency
sponsor begin
authorization
process with
FedRAMP office
CSP, agency
sponsor and
FedRAMP office
review security
requirements and
any alternative
implementations
FedRAMP office
coordinates with
CSP for creation
of system security
plan (SSP)
CSP has
independent
assessment of
security controls
and develops
appropriate
reports for
submission to
FedRAMP office
FedRAMP office
reviews and
assembles the
final authorization
package for the
JAB
JAB reviews final
certification
package and
authorizes CSP to
operate
FedRAMP office
adds CSP to
authorized system
inventory to be
reviewed and
leveraged by all
Federal agencies
FedRAMP
provides
continuous
monitoring of CSP

Issues & Concerns
 FedRAMP doesn’t provide much guidance for customer
side … e.g. Agency users of cloud services
 Current NIST guidance oriented primarily towards “Static
Single System Owner” environments
 Lack of NIST guidance for “Highly Dynamic Shared
Owner” environments … e.g. Virtualized Data Centers &
Clouds
» SSP generation & maintenance
» Application of SP 800-53 (security controls)
» Application of SP 800-37 (assessment & ATO)
» Continuous Monitoring
 Guidance may be forthcoming but NIST is resource
constrained
FedRAMP

Potential Solution
 Agency/Center level Aggregated SSPs:
» Plan per CSP … e.g. Nebula, Amazon,
Google, Microsoft … etc.
» Plan covers all customers of a specific CSP
» Technology integration may be needed with
SSP repository to dynamically update SSP
content via Web Registration site.
» Or … SSP may be able to point to dynamic
content entered and housed on Web
Registration site ... maintained in Wiki type
doc.
Presentation Title
—74—
March 5, 2010
FedRAMP

cloud computing

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Similar a cloud computing

Similar a cloud computing (20)

Último

Último (20)

cloud computing

Notas del editor