Secure Development Considerations for Cloud/Virtual Environments September 2011 Andrew Murren Deloitte & Touche, LLP [email protected] Table of contents Introduction Virtualization Overview Cloud Computing Overview Virtualization & Cloud Threats and Risks SecureSDLC Key.

Transcript Secure Development Considerations for Cloud/Virtual Environments September 2011 Andrew Murren Deloitte & Touche, LLP [email protected] Table of contents Introduction Virtualization Overview Cloud Computing Overview Virtualization & Cloud Threats and Risks SecureSDLC Key.

Secure Development Considerations for Cloud/Virtual Environments

September 2011 Andrew Murren Deloitte & Touche, LLP [email protected]

Table of contents Introduction Virtualization Overview Cloud Computing Overview Virtualization & Cloud Threats and Risks SecureSDLC Key Takeaways

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

What is Virtualization and Cloud Computing?

•

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

Business Processes Security Layer Cloud Services Virtualization Map WAN

Virtualization Overview

What is virtualization?

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).

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.

What is virtualization?

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:

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.

Reference: wikipedia.org

Types of virtualization

Classifications that you should be aware of …

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

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’

Full virtualization

Recreates enough hardware system calls to simulate actual hardware to the guest OS • VMWare ESX • Microsoft Hyper-V • Sun Virtual Box

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 Copyright © 2010 Deloitte Development LLC. All rights reserved.

Hypervisor

• • 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:

operating systems running as guests above it. This is also known as running on Metal’ A type 1 hypervisor runs directly on the computer hardware and manages all ‘Bare

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.

Apps OS Apps OS Hypervisor Hardware Type 1 Apps Console Apps Hardware Type 2 Apps OS OS Hypervisor

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

Deployment Models:

1. Private cloud 2. Community cloud 3. Public cloud 4. Hybrid cloud

Service Models:

1. Cloud Software as a Service (SaaS) 2. Cloud Platform as a Service (PaaS) 3. Cloud Infrastructure as a Service (IaaS) Source: http://csrc.nist.gov/groups/SNS/cloud-computing/

Cloud computing delivery models, based on their characteristics and purpose

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 cloud

A 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.

Visualizing the differences

Application Application Application Application Cloud Fabric Applicatio n Application Applicatio n Application Programming Environment Application Operating Operating System Physical VIRTUAL Computer Application Application Application Operating Operating System Physical VIRTUAL Computer Virtualization

Supporting Infrastructure (Physical Hardware, Network Devices)

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

Virtualization and Cloud Threats and Risks

Operations management

Risks created if IT operations management processes are not enhanced

Deployment Rules IT Operations

• 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 • Architecture Standards/Hardening Guidelines • Configuration Management • Patch Management • Capacity Planning • Incident Response • Logging and Monitoring • Disaster Recovery

Virtualization presents new attack modes/surfaces

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

Attack Types Management Network

• Hyperjacking — Bluepill/Subvirt • Guest Hopping • Migration — potential Man in Middle type attacks • Compromise of VM templates • Exploiting weaknesses in software on the Hypervisor • Protecting Virtual Center or equivalent • Ensuring appropriate privileged user access controls • Starting, moving or changing VMs outside procedural controls • Virtual network layer • Trust Zone Architecture • Physical or virtual (VLAN segmentation) • Use of API like VMSafe/tools like Trend Micro, Reflex, Altor, etc.

Threats - Confidentiality

Threat Insider External Data Leakage Description

• Malicious cloud provider user • Malicious cloud customer user • Malicious third party user • 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 • Failure of security access rights across multiple domains • Failure of electronic and physical transport systems for cloud data and backups

Threats - Integrity

Threat Data Segregation User Access Data Quality Configuration Management Description

• Incorrectly defined security perimeters • Incorrect configuration of virtual machines and hypervisors • 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 • Introduction of faulty application or infrastructure components • Data input inadequately validated • Baseline VM templates are not kept up to date with patches, anti-malware signatures, system configuration changes

Threats - Availability

Threat Change Management DoS Threats Physical Disruption Description

• Customer penetration testing impacting other cloud customers • Infrastructure changes upon cloud provider, customer and third party systems impacting cloud customers • Network bandwidth distributed denial of service • Network DNS denial of service • Application and data denial of service • 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

SecureSDLC Overview

• 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 • 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.

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

SecureSDLC Phases For our discussion we will use a 5 phase SDLC Plan

Secure Planning establishes the security requirements for the application.

Design

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

Develop

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

Test Release

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

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

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

• 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) Copyright © 2010 Deloitte Development LLC. All rights reserved.

Planning Phase – Some Considerations

Plan Design Develop Test Release System Classification Data Classification Governance

What 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?

What 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?

Are 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 mandate specific functions or capabilities?

preclude or

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 Considerations

Plan Design Develop Test Release Encryption & Key Management Trust Zones

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?

How 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 Modeling 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

What 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?

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 Considerations

Plan Design Develop Test Release 26 Data Confidentiality Input Validation Code / Interface standardization Code & Unit testing Code Robustness Code Repository

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?

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

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?

Are 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?

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?

Where 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 Considerations

Plan Design Develop Test Release Pre Deployment security testing Virtual & Physical network assessment Automated Testing Component Testing Testing Environment

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?

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?

Are 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?

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?

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

Release Phase – Some Considerations

Plan Design Develop Test Release Documentation Promotion into Production Patching

Does 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?

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?

Have 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 Duties 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?

Monitoring

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

Auditing

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

What 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 Copyright © 2010 Deloitte Development LLC. All rights reserved.

Contact information For additional information, please contact:

Bruce Murphy

Principal Enterprise Risk Services [email protected]

+1 973 602 6020

Irfan Saif

Principal Enterprise Risk Services [email protected]

+1 408 704 4109

Raymond Soriano

Director Enterprise Risk Services [email protected]

+1 561 962 7735

Andrew Murren

Manager Enterprise Risk Services [email protected]

+1 202 220 2121

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.

Member of Deloitte Touche Tohmatsu Limited