secure development considerations for cloud/virtual environments september 2011 andrew murren...

Secure Development Considerations for Cloud/Virtual Environments

September 2011

Andrew Murren

Deloitte & Touche, LLP

[email protected]

Copyright © 2010 Deloitte Development LLC. All rights reserved.2

Introduction

Virtualization Overview

Cloud Computing Overview

Virtualization & Cloud Threats and Risks

SecureSDLC

Key Takeaways

Table of contents

This publication contains general information only and Deloitte is not, by means of this publication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor.

Deloitte shall not be responsible for any loss sustained by any person who relies on this publication.

Introduction


• SecureSDLC impacts the entire lifecycle of an application, from identification of a need to the disposal of the application and its data

• Decisions at the planning and design stages will have significant impact on the application

• In a virtualized environment design and configuration requirements for the virtual hosts can impact the security of the application and its data

• Cloud computing adds significant challenges to maintaining data integrity

• In both cloud and virtualized environments boundaries and perimeters disappear

Introduction


• Virtualization is the replacement of a physical system with a virtual version of the operating system, storage device, application, network resource, security appliances, etc

• Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources

• Virtualization enables cloud computing, but cloud computing does not require virtualization

What is Virtualization and Cloud Computing?

WAN

Virtualization

Map

Cloud Services

Business Processes

Security Layer

Virtualization Overview


Definition: Virtual version of either operating system, storage device, application, network resource, etc.

Server virtualization is the masking of server resources (including the number and identity of individual physical servers, processors, and operating systems) from server users. The intention is to spare the user from having to understand and manage complicated details of server resources while increasing resource sharing and utilization and maintaining the capacity to expand later.

Storage virtualization is the pooling of physical storage from multiple network storage devices into what appears to be a single storage device that is managed from a central console. Storage virtualization is commonly used in storage area networks (SANs).

What is virtualization?

Reference: What is.com

Network virtualization is a method of combining the available resources in a network by splitting up the available bandwidth into channels, each of which is independent from the others, and each of which can be assigned (or reassigned) to a particular server or device in real time. The idea is that virtualization disguises the true complexity of the network by separating it into manageable parts, much like your partitioned hard drive makes it easier to manage your files.


Application virtualization is an umbrella term that describes software technologies that improve portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed. The application is fooled at runtime into believing that it is directly interfacing with the original operating system and all the resources managed by it, when in reality it is not. In this context, the term "virtualization" refers to the artifact being encapsulated (application), which is quite different to its meaning in hardware virtualization, where it refers to the artifact being abstracted (physical hardware).

Technology categories that fall under application virtualization include:

What is virtualization?

Reference: wikipedia.org

Application Streaming. Pieces of the application's code, data, and settings are delivered when they're first needed, instead of the entire application being delivered before startup. Running the packaged application may require the installation of a lightweight client application.

Desktop Virtualization/Virtual Desktop Infrastructure (VDI). The application is hosted in a VM or blade PC that also includes the operating system (OS). These solutions include a management infrastructure for automating the creation of virtual desktops, and providing for access control to target virtual desktop. VDI solutions can usually fill the gaps where application streaming falls short.


Classifications that you should be aware of…

Types of virtualization

Hardware-assisted

virtualization

Virtualization support built into hardware to simulate a complete hardware environment for each Virtual Machine (VM)

• Intel X86 & x86_64• AMD AMD — V• Sun UltraSparc

Full virtualization

Recreates enough hardware system calls to simulate actual hardware to the guest OS

• VMWare ESX• Microsoft Hyper-V• Sun Virtual Box

Operating System level

virtualization

Virtualization available as a feature of the Operating System. The OS provides a separate & segregated environment to selected applications

• Sun Containers & Zones

• Unix Jail and ‘chroot’

Para-virtualization

Virtualization technique uses API to simulate system call from the guest OS to the underlying hardware

• Linux & Citrix XEN• IBM LPAR• Logical Domains


A hypervisor is a piece of software/hardware platform-virtualization software that allows multiple operating systems to run on a host computer concurrently. Also called Virtual Machine Monitor (VMM)• Type 1: A type 1 hypervisor runs directly on the computer hardware and manages all

operating systems running as guests above it. This is also known as running on ‘Bare Metal’

• Type 2: A type 2 hypervisor is a software application that runs within an operating system. This allows a user to run a standard OS and then other instances of the same OS or a different OS at the same time.

Hypervisor

Hardware

Apps

OS

Apps

OSHypervisor

Type 2Type 1

Hardware

Apps

OS

Hypervisor

Apps

OS

Apps

Console

Cloud Computing Overview


Definition of cloud computing

Cloud computing is 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. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models.

Essential Characteristics:

1. On-demand self-service.

2. Broad network access

3. Resource pooling

4. Rapid elasticity

5. Measured Service

Service Models:

6. Cloud Software as a Service (SaaS)

7. Cloud Platform as a Service (PaaS)

8. Cloud Infrastructure as a Service (IaaS)

Source: http://csrc.nist.gov/groups/SNS/cloud-computing/

Deployment Models:

1. Private cloud

2. Community cloud

3. Public cloud

4. Hybrid cloud


Cloud computing technology is deployed in different ways, with varying internal or external ownership and technical architectures

Vendor cloud (External)

Cloud computing services from vendors that can be accessed across the Internet or a private network, using one or more data centers, shared among multiple customers, with varying degrees of data privacy control. Sometimes called “public” cloud computing.

Private cloud (Internal)

Computing architectures modeled after vendor clouds, yet built, managed, and used internally by an enterprise; uses a shared services model with variable usage of a common pool of virtualized computing resources. Data is controlled within the enterprise.

Hybrid cloudA mix of vendor cloud services, internal cloud computing architectures, and classic IT infrastructure, forming a hybrid model that uses the best-of-breed technologies to meet specific needs.

Community cloud

Community clouds are used across organizations that have similar objectives and concerns, allowing for shared infrastructure and services. Community clouds can be deployed using any of the three methods outlined above, simplifying cross-functional IT governance.

Cloud computing delivery models, based on their characteristics and purpose


Software as a service(SaaS)

SaaS covers the range of application that are licensed for use as services provided to customers on demand typically across the Web.

Platform as a service(PaaS)

The PaaS model makes all of the facilities required to support the complete life cycle of building and delivering Web applications and services entirely available from the Internet.

Infrastructure as a service (IaaS)

IaaS is the delivery of computer infrastructure as a service. Rather than purchasing servers, software, data center space, or network equipment, clients instead buy those resources as a fully outsourced service.

Virtual layer

Common IT Infrastructure

Visualizing the differences

Cloud Fabric

Application

Operating System

Physical Computer

Application

Operating System

Physical Computer

Application

Operating System

VIRTUALComputer

Application

Operating System

Physical Computer

Application

Operating System

Physical Computer

Application

Operating System

VIRTUALComputer

Application

Programming Environment

ApplicationApplication

ApplicationApplicationApplication

ApplicationApplicationApplicationApplicationApplicationApplication

Virtualization

Supporting Infrastructure (Physical Hardware, Network Devices)

Virtualization and Cloud Threats and Risks


Risks created if IT operations management processes are not enhanced

Deployment Rules

• Mix of High, Medium and Low Risk applications• Segregation of Duties – who can manage VM, apps, physical & virtual

network interfaces• Application lifetime – how long from time virtualized application is started

up until it is ended• VM & application movement – vMotion

IT Operations

• Architecture Standards/Hardening Guidelines• Configuration Management • Patch Management • Capacity Planning• Incident Response• Logging and Monitoring • Disaster Recovery

Operations management


Virtualization can increase and introduce new challenges in the attack surface…

Attack Types

• Hyperjacking — Bluepill/Subvirt• Guest Hopping• Migration — potential Man in Middle type attacks• Compromise of VM templates• Exploiting weaknesses in software on the Hypervisor

Management• Protecting Virtual Center or equivalent • Ensuring appropriate privileged user access controls • Starting, moving or changing VMs outside procedural controls

Network

• Virtual network layer• Trust Zone Architecture• Physical or virtual (VLAN segmentation)• Use of API like VMSafe/tools like Trend Micro, Reflex, Altor, etc.

Virtualization presents new attack modes/surfaces


Threats - Confidentiality

Threat Description

Insider• Malicious cloud provider user • Malicious cloud customer user • Malicious third party user

External

• Remote software attack of cloud infrastructure • Remote software attack of cloud applications • Remote hardware attack against the cloud • Remote software and hardware attack against cloud user organizations'

endpoint software and hardware • Social engineering of cloud provider users, and cloud customer users

Data Leakage• Failure of security access rights across multiple domains • Failure of electronic and physical transport systems for cloud data and

backups


Threats - Integrity

Threat Description

Data Segregation• Incorrectly defined security perimeters • Incorrect configuration of virtual machines and hypervisors

User Access

• Poor identity and access management procedures • Implemented an inadequate Identity & Access Management (IAM) system• User provisioning and de-provisioning policies and procedures do not

address virtualized/cloud specific requirements• User rights not adequately segregated or defined

Data Quality• Introduction of faulty application or infrastructure components • Data input inadequately validated

Configuration Management

• Baseline VM templates are not kept up to date with patches, anti-malware signatures, system configuration changes


Threats - Availability

Threat Description

Change Management• Customer penetration testing impacting other cloud customers • Infrastructure changes upon cloud provider, customer and third party

systems impacting cloud customers

DoS Threats• Network bandwidth distributed denial of service • Network DNS denial of service • Application and data denial of service

Physical Disruption• Disruption of cloud provider IT services through physical access • Disruption of cloud customer IT services through physical access • Disruption to third party WAN providers services

Exploiting Weak Recovery Procedures

• Invocation of inadequate disaster recovery or business continuity processes• Data and VM backups protected at a lower level than running systems

SecureSDLC


• Which of the Secure Develop methodologies (MS-SDL, OWASP CLASP, Cigital’s Touch Points) or development life cycle is used does not matter, so long as all of the key points are addressed

• The Cloud Security Alliance published “Guidance for Application Security V2.1”* in July 2010 to help development teams understand developing and maintaining applications for the cloud.

• Establishment and enforcement of development governance guides design and development and should not be ignored

SecureSDLC Overview

* http://www.cloudsecurityalliance.org/guidance/csaguide-dom10-v2.10.pdf

• Leverage existing development governance and expand to cover virtual and cloud environments

• Expect older applications and systems to be ports or moved to virtualized environments and possibly to the cloud.


Secure Release ensures the conformance of SecureSDLC to other information security processes and monitors the occurrence of intended periodical software security tasks.

For our discussion we will use a 5 phase SDLCSecureSDLC Phases

Plan

Design

Develop

Test

Release

Secure Planning establishes the security requirements for the application.

Secure Design identifies security issues and provides mitigation solutions for the architecture and design aspects of the software.

Secure Development pertains to enabling software development processes with methodologies and tools to produce secure code.

Secure Testing leverages various toolkits, emerging threat intelligence information and appropriate methodologies to perform anonymous as well as user level software security testing.


• Enterprise Widget Exchange (EWE) is a new application that will be hosted in a cloud environment replacing an older internally hosted web application that has a clustered database and load balanced web front end

• Cloud service model (IaaS, PaaS) and deployment model (Hybrid, Public, Private) and number of clouds needs to determined along with responsibilities for backup, DR, compliance, security, etc.

• Will use a multi-tiered architecture

• Two known surges periods in sales, September and Late November to December

• Needs to accept credit card and purchase orders and charge applicable sales tax

• Suppliers will need access to inventory and orders management parts of the system

• Established base of over 200,000 customer that will use current credentials and need access to their sales history

• Clients are mostly based in the US and European Union (EU)

What are some virtualization and cloud specific considerations?Enterprise Widget Exchange – Sample Application


Planning Phase – Some ConsiderationsPlan Develop Test ReleaseDesign

System ClassificationWhat is the CIA sensitivity of EWE? Can EWE be on the same network segment with a lower sensitivity system? Should the EWE component systems be alone on a host or can other applications be on the same host?

Data ClassificationWhat kind of data is being processed by EWE? What data will be stored with the running app and what data will be remotely stored? How will data be safeguarded while at rest, in use, in transit? How will it be backed up?

GovernanceAre there policies, standards, & procedures in place that address features of the cloud environment EWE will be hosted in? Do they provide enough guidance? Are they enforceable and enforced?

Legal & Regulatory Have all legal & regulatory requirements for ALL jurisdictions where EWE and its data may reside on been identified? Do the requirements preclude or mandate specific functions or capabilities?

Configuration & Monitoring Tools

Based upon internal policies and legal requirements what logging, audit trails, real time monitoring is needed? What tools are available? Are tools already in place to manage EWE and its supporting systems? Do these tools support internal segregation of duty policies? Does a new tool need to be obtained/ developed to manage the EWE configuration? Are configuration & pre deployment requirements fully documented?

Identification & Access Management (IAM)

How will IAM for EWE’s different user communities be handled? How will connections from the hosting site to the IAM servers be handled? What user provisioning requirements does EWE have and how will they be met?


Design Phase – Some ConsiderationsPlan Develop Test ReleaseDesign

Encryption & Key Management

What is the key management system for encryption? What type and strength of is required? Are there legal requirements related to the use of encryption?

Trust ZonesHow are virtual systems connected (i.e. databases in a cluster)? What input/output validation is required for trusted vs. un-trusted data sources? Does EWE need to be on an isolated virtual infrastructure?

Virtual & Physical Networking

Can EWE share a virtual or physical network interface with another application or system? What network layer defenses are needed (firewalls, IDS/IPS, data protection systems)?

Threat ModelingWhat are the threats against EWE? What are the threats to the virtual environment? What are the threats to the cloud provider? Will EWE be subjected to local or remote DoS or resource exhaustion attacks?

System & Deployment Requirements

Are there specific hardware/software requirements for the various EWE components? Will VM, OS, network, Db, and others with administration responsibilities be provided configuration guidance and training?

Identity & Access Management

How will IAM for the application be handled? Will an LDAP or Active Directory server be deployed to the cloud to support the app? How will connections from the hosting site to the IAM server be handled?


Develop Phase – Some ConsiderationsPlan Develop Test ReleaseDesign

Data Confidentiality

Does EWE need to wipe stored data or can it just release/delete it when it is no longer needed? How will authorized systems be identified? What will EWE do when un-trusted or un-authorized systems attempt to connect with EWE? Will there be the ability to capture data for forensic review if needed?

Input ValidationAre all external inputs validated? Is EVERY data input validated before being used, regardless of source?

Code / Interface standardization

Does EWE use standard protocols & APIs to communicate with external systems? Are standardized features and tools being leveraged to improve the security and elasticity of EWE?

Code & Unit testingAre static and dynamic code analysis tools used throughout development? Are test plans written to find faults or just to prove success? What coding & testing standards are in place?

Code Robustness

Can EWE handle the potential latency incurred by the distributed environment? Will EWE be able to handle or make dynamic changes to its own IP address and of external components? Can EWE be rapidly stood up and torn down? Are there any hard limits or concurrency restrictions that could compromise EWE when deployed to a cloud environment?

Code RepositoryWhere is code to be stored, locally or in the cloud? What about emergency repatriation of code or recovery of code in the event of an outage? How will outages and roll-backs be handled?


Test Phase – Some ConsiderationsPlan Develop Test ReleaseDesign

Pre Deployment security testing

Have cloud/virtualization security specific requirements been documented and test plans been developed? Do tests include virtual and physical security? Will EWE’s application stack be tested in the same type of environment it will be deployed in? Are penetration and DoS tests included?

Virtual & Physical network assessment

Are EWE’s virtual network interfaces are included in test plans? Will inter-host communications (like those used in clustered databases) be tested for latency, security, robustness, and other virtual/cloud specific features?

Automated TestingAre tools used by the appropriate teams to help with static code analysis, dynamic code analysis, user interaction and security? Do the tests include cloud/virtualization specific tests?

Component Testing

Will tests for each supporting component (database, web server, storage, etc) be developed, base-lined and validated? Have all physical and virtual components been identified, and have secure configuration baselines been established for each? If there any components provided by a third party how are they tested for compliance with regulations and other requirements? Have the encryption and IAM components been tested in isolation and in a cloud environment?

Testing EnvironmentWhat testing will be performed where? What will testing will the Cloud Service Provider allow? How can meaningful Pen Testing be done?


Release Phase – Some ConsiderationsPlan Develop Test ReleaseDesign

DocumentationDoes information security policy clearly document the requirement for controls over virtual machine image files and backups? Has documentation been prepared for each of EWE’s user and maintainer communities?

Promotion into Production

Are safeguards in place to ensure only authorized instances of EWE systems or VMs are put into production? Is there a mechanism in place to ensure VMs are not moved from behind required network based security systems?

PatchingHave patches been tested in a non-production environment before release? Is the standard/baseline image for virtual deployments updated with the new patch level?

Segregation of DutiesHow are roles and responsibilities for the virtual system separated between virtualization administrators, security, administrators, and (physical server administrators)?

On-Going Vulnerability Assessments

Does the group responsible for security have adequate plans and access to test the applications? Are appropriate tests conducted on a frequent enough basis?

MonitoringHave appropriate logging capabilities and requirements been identified and implemented? Is there a system in place for monitoring when systems are instantiated, running and removed?

AuditingWhat audit trails exist for the virtual environment? Was the system configured with a benchmark or hardening guide? Is logging enabled and available for review? Are audit trails in place to document changes to the systems?


Key takeaways

Most aspects of SecureSDLC remain the same …

• There is still a need for a sound governance structure with enforced and enforceable SDLC policies and procedures

• Design flaws and bugs in the code will still be the main weaknesses in applications

• Static and dynamic code assessments are important components of a SecureSDLC

• Data encryption and validation are critical to protecting the applications and the data they process

But some there are some differences

• Boundaries and perimeters disappear, another VM on the same physical host may be an attacker

• The attack surface has increased with the introduction of the hypervisor and virtual network interfaces

• Applications in the cloud are ‘elastic’ so that resources can appear and disappear at any time and can be using dynamically allocated IPs

• There is an increased importance for secure configuration procedures and guidelines to ensure the security if the application instances

• All data exchanges, internal and external to the application, need to be validated


Contact information

For additional information, please contact:

Bruce MurphyPrincipalEnterprise Risk [email protected] +1 973 602 6020

Irfan SaifPrincipalEnterprise Risk [email protected]+1 408 704 4109

Raymond SorianoDirectorEnterprise Risk [email protected]+1 561 962 7735

Andrew MurrenManagerEnterprise Risk [email protected]+1 202 220 2121

mailto:[email protected]



About Deloitte

Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see www.deloitte.com/about for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms.

Copyright © 2010 Deloitte Development LLC. All rights reserved.Member of Deloitte Touche Tohmatsu Limited

http://www.deloitte.com/about

secure development considerations for cloud/virtual environments september 2011 andrew murren...

Documents

storage virtualization

network virtualization

server virtualization

virtualization overview

data cloud computing

deloitte development

introduction slide

network resource