Csaguide Dom10 v2.10

Domain 10: Guidance for
Application Security V2.1
Prepared by the
Cloud Security Alliance

July 2010
Domain 10: Guidance for Application Security V2.1
Introduction
The permanent and official location for this Cloud Security Alliance Domain 10 Guidance
for Application Security research is:
http://www.cloudsecurityalliance.org/guidance/csaguide-dom10.pdf
© 2010 Cloud Security Alliance.
All rights reserved. You may download, store, display on your computer, view, print, and
link to the Cloud Security Alliance “Domain 10 Guidance for Application Security” at
http://www.cloudsecurityalliance.org/guidance/csaguide-dom10-v2.10.pdf subject
to the following: (a) the Guidance may be used solely for your personal, informational,
non-commercial use; (b) the Guidance may not be modified or altered in any way; (c) the
Guidance may not be redistributed; and (d) the trademark, copyright or other notices
may not be removed. You may quote portions of the Guidance as permitted by the Fair
Use provisions of the United States Copyright Act, provided that you attribute the
portions to the Cloud Security Alliance Domain 10 Guidance for Application Security
research Version 2.1 (2010).
Copyright © 2010 Cloud Security Alliance 2

Application Security
Contributors: John Arnold, Warren Axelrod, Glenn Brunette, Aradhna Chetal,
Jesus Luna Garcia, Arthur J. Hedge III, Georg Hess, Christofer Hoff, Dennis
Hurst, Scott Matsumoto, Alexander Meisel, Anish Mohammed, Scott Morrison,
Joe Stein, Michael Sutton, James Tiller, Greg Tipps, Joe Wallace, Colin Watson
INTRODUCTION ........................................................................................................................................ 2
OVERVIEW ................................................................................................................................................. 5
APPLICATION SECURITY ARCHITECTURE ..................................................................................... 7
MANAGING PLATFORM ACCOUNT TOKENS/KEYS ...................................................................................... 7
SOFTWARE DEVELOPMENT LIFECYCLE ......................................................................................... 8
ECONOMICS ............................................................................................................................................... 9
METRICS ....................................................................................................................................................11
TOOLS AND SERVICES ...........................................................................................................................12
INFRASTRUCTURE AS A SERVICE (IAAS) SPECIFICS ..................................................................13
APPLICATION SECURITY ARCHITECTURE ..................................................................................................13
SOFTWARE DEVELOPMENT LIFECYCLE .....................................................................................................14
TOOLS AND SERVICES ...............................................................................................................................14
PLATFORM AS A SERVICE (PAAS) SPECIFICS ................................................................................15
SECURING MESSAGE-LEVEL COMMUNICATION .........................................................................................16
ADDITIONAL REQUIREMENTS FOR HANDLING SENSITIVE INFORMATION ..................................................16
MANAGING APPLICATION KEYS ................................................................................................................16
TOOLS AND SERVICES ...............................................................................................................................17
SOFTWARE AS A SERVICE (SAAS) SPECIFICS ................................................................................17
SOLUTIONS AND RECOMMENDATIONS...........................................................................................18
Addressing Changes in Trust Boundaries ............................................................................................18
Metrics .................................................................................................................................................19
Tools and Services ...............................................................................................................................19
Economics ............................................................................................................................................19
INFRASTRUCTURE AS A SERVICE (IAAS) SPECIFICS ...................................................................................20
Application Security Architecture ........................................................................................................20
Trusting the Virtual Machine Image ....................................................................................................20
Hardening Hosts ..................................................................................................................................21
Securing Inter-host Communication ....................................................................................................21
Managing Application Keys .................................................................................................................21
Additional Requirements for Handling of Sensitive Information .........................................................22
Software Development Lifecycle ..........................................................................................................22

PLATFORM AS A SERVICE (PAAS) SPECIFICS .............................................................................................23

Multi-tenancy and the Application’s Threat Model .............................................................................23
SOFTWARE AS A SERVICE (SAAS) SPECIFICS .............................................................................................23
QUESTIONS FOR YOUR PROVIDER AND ASSESSMENT CHECKLIST ......................................25
ALL SERVICE MODELS ..............................................................................................................................25
INFRASTRUCTURE AS A SERVICE ...............................................................................................................25
PLATFORM AS A SERVICE ..........................................................................................................................26
SOFTWARE AS A SERVICE ..........................................................................................................................26
OUTLOOK ..................................................................................................................................................27
APPLICATION INTEGRITY ...........................................................................................................................27
APPLICATION AS ENFORCER ......................................................................................................................27
REFERENCES ............................................................................................................................................30

Overview
Organizations that plan to use cloud computing to run their in-house developed
applications need to review and potentially modify their software development
approach. Application architecture and design, programming standards and
security capabilities need to be adapted to account for the inherent multi-tenant
environment of cloud platforms, the lack of control over the physical network and
computing infrastructure and the ability of the cloud provider to monitor and
access their customers’ data in transit and at rest. At the same time, existing
standards continue to be valid and organizations that have deployed in-house
applications into Internet facing environments will find that the solutions
developed directly benefit them, as they required addressing many of the same
architectural and design challenges.
Cloud Computing infrastructures are still maturing and adding new capabilities,
but their flexibility, openness and public availability challenge many fundamental
assumptions about application security. An example: if the application processes
data of a sensitive nature, the lack of physical control over the networking
infrastructure might mandate the use of encryption in the communication
between servers of the application to ensure the confidentiality of the data
passed.
The three main layers of cloud computing relevant to application security are
Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as
a Service (SaaS). Each of these layers has the potential to add new threats to
the application’s runtime environment. Without development organizations taking
into account the changes introduced by the *aaS layers, applications will face
exposure to threats they were never designed to defend themselves against.
The remainder of this paper will focus on discussing the challenges that IaaS,
PaaS and SaaS hold for application developers.
Figure 1 – Additional Threats at All Levels of Service

Some of the challenges are well known and organizations have encountered
them before when outsourcing network infrastructure and designing and
deploying in-house applications facing the Internet in classic DMZ scenarios or in
collocated shared environments. An upfront analysis, covering the traditional
aspects of managing information confidentiality, integrity and availability, is
central to documenting the classification of data handled by the application and
will influence many of the design decisions. For existing applications, which are
migrated to the cloud, the process can be an opportunity to address outstanding
fundamental problems that have been overlooked or underrepresented during
their development. A cloud application developed using these guidelines will
often be as secure as an internal application.
The remainder of the paper will focus on the following areas and their impact on
application security:
• Application Security Architecture – Cloud Computing affects the

dependencies that most applications have on various other systems.
These include Identity and Access Management (IAM) systems, security
token services, Public Key Infrastructure (PKI) systems, and other
application tiers (such as databases). These dependencies make
configuration management significantly more complex than with traditional
deployment.
• Software Development Lifecycle (SDLC) – Cloud Computing influences

all aspects of the SDLC, spanning application architecture, design,
development, quality assurance, documentation, deployment,
management, maintenance, and de-commissioning.
• Economics – Cloud Computing’s cost model needs to be fully understood

and includes recognizing that risk management and security assurance
cannot be a one-time cost, but rather a cost continuum that must be
balanced against organizational goals.
• Metrics – Cloud Computing’s metrics are not limited to simply

understanding performance characteristics and providing for billing. They
need to also allow for monitoring of evolving security risks and lay the
foundation needed for forensic investigation.
• Tools and Services – Cloud Computing introduces a number of new

challenges around the tools and services required to build and maintain
applications. These include development and test tools, application

management utilities, the coupling to external services (such as IAM
systems, logging services, system profilers, etc.) Understanding the
ramifications of who provides, owns, operates, and assumes responsibility
for each of these is a fundamental question regarding application security.
• Vulnerabilities – Cloud Computing vulnerabilities include the well-

documented—and continuously evolving—vulnerabilities associated with
web applications, in operating systems and with tools. In addition,
organizations have to account for vulnerabilities associated with machine-
to-machine, Service Oriented Architecture (SOA) applications, which are
increasingly seeing deployment into the cloud, plus new vulnerabilities
introduced by cloud infrastructures themselves, as in the virtualization
layer and the cloud management interfaces
Application Security Architecture

The multi-tenant architecture of the cloud means that many of the infrastructure
services, such as the network and data storage technologies, are shared with
other applications. Since these applications will often be from different
organizations, the relationship between application and underlying infrastructure
changes, especially the assumption of being contained in a private environment.
These changes should be reflected in a corresponding modification to the
application's threat model.
Even basic services like local storage are affected because of the modifications
imposed on an application by a cloud platform. Cloud computing platforms
typically separate all storage resources from computing resources to gain
scalability and improve manageability and implement local storage through the
network. The implication for the application security architecture is that debug
and audit logging which typically go to local storage in non-cloud environments
need now to be considered remote. The security requirements for these
application components are further affected if these applications handle sensitive
data.
Managing Platform Account Tokens/Keys

Cloud platforms require credentials, typically either an application token or key, to
identify a valid account. These credentials must be passed on for all API calls to
the platform itself and for calls to services within the cloud environment from the
hosted application. The application credentials must be maintained and secured
along with all other credentials required by the application.

Software Development Lifecycle

Integration of security into the software development lifecycle has gained
acceptance over the last decade. For Cloud Computing, additional activities must
be added to the software development lifecycle in order to build security into the
application. Different from traditional deployment models, security vulnerabilities
within cloud-based applications cannot be fully fixed by external security controls,
since many of the external controls are under management of cloud service
providers. The increasing integration of security in the SDLC has been
documented in many different publications such as the Security Development
Lifecycle (Microsoft), various sections of the Payment Card Industry (PCI) Data
Security Standard, and other sources shown in our reference section. The
majority of the secure software development lifecycle issues for non-cloud
computing environments apply when applications are designed for or moved to a
cloud platform, but a number of new issues arise that are specific to cloud
computing applications
Applications running on cloud platforms have a different trust relationship

between the development environment and the deployment environment from
traditional enterprise applications. In a traditional enterprise application, all of the
environments are contained within the enterprise. Within the enterprise, this trust
is created by isolating secure hosts and secure networks, which are part of the
enterprise’s computing infrastructure.
Figure 2 – SDLC Trust Model for Internal Application
Cloud computing platforms change the trust boundary relationships between the
development environment and the application's runtime environment. The exact
nature of this change depends on the deployment model of the cloud computing
platform, which will be addressed later.
Cloud computing platforms are still maturing and in constant evolution. As such,
changes to the platform may occur with greater frequency than with a mature
legacy platform. Changes in the infrastructure architecture, such as the multi-
tenancy of most public clouds, can affect the trust assumptions of most traditional
applications.

Economics
There are two aspects of cloud application security that must be evaluated with
respect to their costs and benefits. One is the use of cloud service providers for
the development and/or testing of applications being built by or acquired and
modified by customers. The other is the running of cloud-based applications
which were built by or acquired by the customer organization or the service
providers to support customers’ businesses.
It is generally the customer’s responsibility to ensure that security standards are

met when using cloud computing and to absorb any costs entailed. Security
requirements apply both to the development lifecycle itself as well as to the
security of the cloud computing and services purchased as needed for various
phases in the lifecycle. The table below shows the security risks at each phase of
the lifecycle and the economic costs related to the security risks versus the
benefits from using cloud services.
Risks and Economic Impact of Cloud Computing for Phases of the SDLC
Phase of Security Risks from Cloud Economic Benefits from Cloud Economic Impact
Lifecycle Computing Computing
Business Risks relate to the criticality of Cloud computing might offer Cloud computing may result in a
Requirements the application to the faster “time to value,” lower significant reduction in costs of
and Project business, and the sensitivity development and testing costs developing and testing
Justification of the data to be processed. and lower computing costs applications and of running the
Risks from cloud computing during full production. system in production. These
result from issues relating to savings need to be offset against
data protection and system the costs of ensuring an
availability. acceptable level of security and
availability.
Functional When specifying what specific Often the most critical The cost reductions need to be
Specifications applications will actually be applications, handling the most balanced against any
and Design doing, systems analysts must sensitive data, are more cheaply vulnerability increases with
consider that some functions run in the cloud. For example, respect to security and
are more security sensitive for many organizations, the availability. The risks may be
than others and may not be biggest resource hogs are mitigated by increasing security
viable candidates for running precisely those applications that measures, but the costs of doing
in the cloud. process sensitive information. so must be deducted from
processing cost savings.
Development There is a risk in the cloud, as Because of the compelling Cloud service providers offer
(Coding) and in other environments, that financial benefits of using cloud security services, such as access
Testing proprietary information and resources, particularly when management, multiple copies of
intellectual property might be computing resource systems and data, and
stolen, even without requirements may exhibit encryption, which the customer
customers’ knowledge. extreme peaks and valleys, can invoke in order to raise the
there are often big economic security level and reduce risks of
While there is usually policy incentives to use cloud data compromises and
against using live data for computing for development. exploitation for fraudulent
testing, realistic data must purposes. There are additional
often be used, raising security Sometimes there is a benefit in costs related to invoking these

issues. The risk of data developing applications in- services and the customer has to
compromise and the cost of house, but using cloud determine whether any
potential security incidents, resources for testing, particular security measure is
encourages customers to not particularly if large volumes of worthwhile or whether the cost
use live data for testing data and significant computing of increased security outweighs
purposes. resources are needed to the economic benefits of cloud
conduct the tests. computing.
Implement- The bulk of cloud computing One of the biggest benefits of The overall economic impact
ation and is for running production running production applications sought in the use of cloud
Production systems, which involves the in the cloud is lower costs. computing is to reduce costs and
transference of intellectual Large cloud services providers increase flexibility in use and
property (such as the can use economies of scale and payment for resources. However,
application code and the purchasing power to lower their organizations need to be aware
operational procedures) as costs, and they may pass on that the above goals may not
well as the use of live data. some of those savings to always be realized. For example,
There are risks that the customers in the form of lower it may be more costly to incur
systems and procedures prices. Also, the pay-as-you-use communications costs between
might be hijacked by the charging model allows cloud service providers and their
service provider or other customers to avoid excess customers, and to the
organizations and that capacity and reduce financial customers’ customers, business
sensitive data are commitments usually required partners and suppliers, than
compromised. There are also in setting up and running from in-house facilities, so that
risks related to availability of internal data centers. In this other cost reductions may be
systems and networks and the way, capital expenses are negated. In some cases, the use
relative performance, converted into operational of a hybrid cloud, with some
including network latency, of expenses, which is beneficial functions performed in the cloud
running applications in the when capital markets are tight. and others in-house, may be the
cloud versus internally. most cost-effective approach.

Application Planning for the It is possible that applications The degree to which economic
Retirement or decommissioning or retiring running in the cloud have better benefits can be realized for
Transfer of applications and systems is demarcation than internally run retiring systems or transferring
often neglected. It is and managed applications, if for them is very much a function of
important to realize that, no other reason than specific the type and complexity of the
when a system or an resource usage is monitored system and the degree of
application has outlived its and charged for by the service customer lock-in, which is
usefulness and is being provider. sometimes termed “stickiness.”
replaced by another system, The provider usually has strong
the program code and data, In addition, the customer does incentives to make the service as
which may reside somewhere not usually have to be sticky as possible so that
in the cloud, should be concerned with the disposal or customers will continue with the
disposed of through a formal redeployment of dedicated provider. This works against
process, which was preferably resources, as they might with customers if they wish to
predetermined and included internal systems and networks. transfer the system or if the
in the services agreement.. provider goes out of business or
otherwise ends the service.
Furthermore, it is likely that, for
Similarly, customers may wish the transfer costs, the time to
to transfer applications or convert and costs of parallel The issues that arise include
entire systems from one cloud operations may be less for contractual terms as well as
service to another, to an in- transferring from cloud portability and interoperability
house facility, or to a computing, although this very issues, the latter two of which
combination hybrid cloud. In much depends on particular are addressed in Chapter …
such cases, there should be circumstances. Portability is the ease with which
predetermined procedures an application can be moved
for the transfer of the from one platform to another
applications, systems and without the need for significant
networks and the retirement reworking. Interoperability
of those resources held with relates to the degree to which
the original provider. data used by applications in one
environment can be accessed
and handled in different provider
and in-house environments.
Metrics
The four groups of metrics that apply to cloud computing and cloud application
environments are: Compliance and Governance, Identity and Access,
Vulnerabilities and Patching, and Data Security.
• Compliance and Governance Metrics: Changes to the cloud computing

environment can unknowingly whittle away at the compliance of a cloud
computing provider’s customer. Changes such as permission
modifications, new capabilities, introduction of mobile devices, and
network changes can affect compliance. Application must consider
reporting metrics around these changes to the system as well as
assessing their impact on compliance.

• Identity and Access: Identity management is “who am I” and “what can I

do”. In the cloud computing environment these questions are magnified.
“Who am I” grows from 50,000 people in a large organization to millions of
identities in a cloud environment. “What can I do” moves from the
application to vertical slices of the application. Metrics around users need
to be collected for both the provider and the provider’s customers.
• Threat and Virus Metrics: The Threat and Virus Management Metrics
are designed to detect, protect and defend the environment from external
attacks. Measurement of detection of an incident, which is captured if an
attack has occurred, is different from response time metrics, which
measure the ability to protect. Detection metrics and response time
metrics help determine the ability to fend off attacks.
• Vulnerability and Patch Metrics: The Vulnerability and Patch Metrics
enable providers to proactively analyze the effectiveness of the initiatives
designed to prevent the exploitation of critical IT assets. The assurance
that the system is available according to its SLA, through non-intrusive
patching as well as timely and effective removal of vulnerabilities must be
measured. Applications that report metrics designed around operational
availability help with risk mitigation in these environments.
• Data Security Metrics: The Data Security metrics are designed to show
the effectiveness of the organization’s controls to ensure the
confidentiality, integrity, and availability of sensitive data. These metrics
should measure the levels of protection of sensitive data while at rest, in
use, and in motion.
Tools and Services
Static and dynamic code analysis tools can add great value in cloud-based
application security by providing a security baseline. However, as with all tools,
they come with limitations. Some of the limitations that are shared by all
scanning tools are:
• False Negatives: Tools do not detect all security vulnerabilities, especially

those that are complex and exploit business logic flaws. A proper
understanding of the limitations of these assessment tools is needed to
decide if the tool will provide the desired level of accuracy in testing the
application or if additional manual verification will be needed.
• False Positives: A vulnerability assessment tool may report a vulnerability
that does not exist or does not apply to the application being tested.
Verifying that the vulnerabilities exist can be technically challenging,

requiring an advanced level of training on the proper use of the tool and
an understanding of the vulnerability and its consequences.
Infrastructure as a Service (IaaS) Specifics

In an Infrastructure as a Service (IaaS) cloud platform, the cloud vendor provides
a set of virtualized components such as virtual machines, raw storage and other
components that can be used to construct and run an application. The most
basic component is a virtual machine and the virtual OS under which the
application runs.
Figure 3 - Virtual Machine of an IaaS
In IaaS environments, the local data storage is typically not persistent across
machine restarts, so most applications use some form of external and persistent
storage. Many IaaS environments provide additional components for persistent
storage, but that storage is always remote.
Figure 4 - Cloud-based persistent storage
For distributed applications running in an enterprise many controls exist to secure

the host and the network. Comparable controls do not commonly exist for IaaS
platforms and must be added through configuration or application-level controls.


When an application runs on an IaaS platform, the application’s production
environment and some parts of the test environment run with different trust
assumptions from those of the development environment. The following diagram
shows the different environments for development, test and production.
Figure 5 - SDLC Trust Model for IaaS Hosted Application
When the test and production environments are moved to an IaaS platform, the
trust relationship between internal and external environments is similar to
operating an application at a Managed Service Provider (MSP). In both cases,
the software and data are running outside of the trusted environment created
within the enterprise and therefore additional security considerations need to be
evaluated.
Tools and Services

IaaS providers are starting to offer cloud application security specific tools and
services, such as Web Application Security Scanning, Source Code Analysis or
Web Application Firewalls and Host based Intrusion Detection/Prevention
Systems to increase security at the application layer and to support customers in
fulfilling application-specific compliance requirements. These tools and services
may either be specific to the cloud provider or can come from a third-party.

Platform as a Service (PaaS) Specifics

Platform as a Service (PaaS) providers deliver an integrated application stack as
the runtime environment for the application. PaaS provides also additional
application building blocks. For example a PaaS Enterprise Service Bus (ESB)
may provide both asynchronous messaging as well as message routing. The
Cloud Reference Model in Domain 1 of the CSA Security Guide describes these
building blocks as the Integration and Middleware layer. The relevant layers are
shown in the following excerpt of the Cloud Reference Model.
Figure 6 - Cloud Reference Model: Application Capabilities Provided by PaaS
Even though the PaaS platform’s application building blocks are similar to their
traditional enterprise counterparts, the multi-tenant nature of the cloud computing
environment requires the application’s assumption about trust to be re-
evaluated. For example, securing the messages on the ESB becomes the
responsibility of the application because controls, such as segmenting ESBs
based on data classification, may not be available in PaaS environments. PaaS
providers may also offer built-in application security controls within their
programming environment to help developers avoid known application
vulnerabilities.
The specific building blocks offered by PaaS providers are platform dependent,
but range in abstraction from the programming language to high level
components such as work flow engines.

Securing Message-level Communication

Even though the PaaS platform’s service bus is functionally and architecturally
equivalent to an ESB, the multi-tenant nature of the PaaS platform means
applications cannot make assumptions about trusting messages put on or taken
off the ESB, as the PaaS platform’s service bus will be shared. For SOAP-based
messages, standard protocols such as WS-Security can and should be used.
Additional Requirements for Handling Sensitive

Information
PaaS platforms may provide logging components as part of the platform. While
the details of these are platform specific, all share the attribute that the log
storage is external to the CPU resource. When sensitive or regulated data is
logged for debugging purposes, the data needs to be protected through the use
of application provided cryptographic controls, for example. Additionally, audit
log retention based on regulatory compliance requirements must be
implemented.
Managing Application Keys

PaaS platforms require an application key for all API calls to the platform itself,
as well as calls to services within the PaaS environment from the hosted
application. The application key must be maintained and secured along with all
other credentials required by the application.

An enterprise looking to develop an application on a PaaS platform must
evaluate the maturity of its secure software development practices. A mature,
secure software development life cycle will have a body of secure design and
coding rules, technology specific application security standards and application
security assurance tools to support the secure software development lifecycle.
These cornerstones must be updated for the specific PaaS environment because
the enterprise’s software designers, developers and testers might not be familiar
with the new security aspects of the PaaS platform.
The PaaS platform itself must be secure and the vendor must follow its own
secure software development lifecycle practices. Similar to SaaS environments,
existing certifications may not be granular enough to cover specific activities
within the software development life cycle.

Tools and Services

Each PaaS platform has its own unique security challenges and enterprises
adopting the platform will either need to develop this platform knowledge and
tools themselves, or have training and tools provided by the platform vendor or
support community. Web-based, n-Tier applications have a rich body of
knowledge about common types of vulnerabilities and their mitigation through
groups such as the Open Web Application Security Project (OWASP), but
similar knowledge bases for PaaS environments are scarce and will need time to
mature.
Software as a Service (SaaS) Specifics

Software as a Service (SaaS) provides the same management of infrastructure
and programming environment and layers in specific application capabilities.
The application’s capabilities provide end-user functions as well as becoming
part of the programming platform. The application’s capabilities can be extended
by adding custom code extensions. External applications can exchange data
through the APIs, which the SaaS platform usually provides. The following
diagram shows these integration points relative to appropriate layers of the Cloud
Reference Model.
Figure 7- SaaS platform customization
Data exchanged through the SaaS platform’s external APIs is subject to existing
security policies and standards for any type of external data exchange. The data
can either originate from, or be destined for, applications within the enterprise or
applications running on another cloud platform. The data exchange should be
secured using appropriate controls for the classification of data exchanged.
Federating identity between two sites is a common best practice. The section on
IAM describes solutions and recommendations for federating identity for a SaaS
platform. For sensitive data, the exchange should be protected using

cryptographic controls, such as a combination of encryption and secure hashing,

to assure the confidentiality and/or integrity of the data.

For SaaS applications, an enterprise must be concerned with how its internal
secure software development lifecycle practices integrate with those of SaaS
vendors. This concern is also valid for all of the other cloud delivery models, but
especially for SaaS applications, since the secure software development lifecycle
is now shared between the SaaS vendor and the enterprise.
Figure 8 – Shared Secure SDLC Between the Enterprise and SaaS Vendor
An enterprise must have a way to verify that the vendor’s development lifecycle
provides sufficient security assurance activities for the risk-level of the
application. The challenge in SaaS environments is determining which security
software development activities need to be implemented by the application owner
and which ones should be left to the cloud provider.
Solutions and Recommendations

Addressing Changes in Trust Boundaries
As cloud applications reside in an external environment in relation to the

enterprise, trust must be codified between the enterprise and the cloud platform
vendor. Additional software security controls can be implemented by the
application, either through application code or through specific security services
provided by the cloud platform.

The Service Level Agreement (SLA) negotiated with the vendor is another
mechanism for addressing changes in the trust boundaries for a cloud platform.
Application security must be represented as a clearly articulated set of actions
and guarantees within the SLA. This can include providing documentation of
security measures taken by the vendor, as well as allowing for reasonable
security testing related to ongoing activities such as logging, audit reports and
periodic validation of security controls.
Metrics
Enterprises must ensure that needed metrics are available from the cloud
platform selected. Whether they are provided directly from the cloud provider or
via a third-party solution is a choice made by the entity requiring the metrics.
Tools and Services
Web application security in the cloud should be scalable, flexible, virtual and
easy to manage. A Web Application Firewall (WAF) is commonly used to provide
additional security for web applications. In a cloud environment a WAF must not
be limited by the hardware, must dynamically scale across CPU, computer,
server rack and datacenter boundaries, and must be customizable to the
demands of individual customers. Resource consumption of the WAF must be
minimal and scalable from a small-usage scenario to highly-loaded web
applications. As clouds come in all shapes and sizes, WAFs must be adaptable
to all possible configuration scenarios.
The new type of WAF, described above, namely a distributed Web Application
Firewall (dWAF), must be able to operate in conjunction with a wide variety of
components to be effective, and must not add undue complexity for cloud service
providers. Today’s providers use a variety of traditional and virtual technologies
to operate their clouds, so an ideal dWAF should accommodate this mixed
environment either as a virtual software appliance, a plug-in, SaaS or should
integrate with existing hardware. Flexibility with minimal disruption to the existing
network is central.
Economics
The service provider has direct control over implementing application security for
the cloud applications deployed, whether developed by the cloud service provider
or by another entity. The level of security of these applications reflects providers’
beliefs that making application security changes is beneficial in both terms of
lowered risk of compromise and better quality of service.

The benefits to customers of secure applications are more direct because better
security improves the relationships of the provider’s clients with their customers,
business partners and suppliers. Better security also reduces breaches and
outages due to security events, and avoids the costs of such incident handling,
such as responding to and resolving the breach, notifying customers, and
providing ID theft assurance services. Additional costs to include are damages to
reputation, customer defections, loss of potential customers, and increased
future customer acquisition costs.
Similar reasoning applies to effective platform security. It enhances the
reputation of the cloud provider and attracts customers who care about the
platform security on which they run their applications.
The overall security of both applications and platforms is particularly important in
the cloud environment because of heavy use of virtualization and concerns about
the security of virtual machines. The concerns include the opportunity for
successful attacks on the virtualization layer which may compromise all the
applications running on the servers supporting the virtual environment.
Measures can be taken to improve virtualization security, but implementing such
measures is a maturing discipline and their implementation should be subject to
platform audits to assure correct implementation.
Infrastructure as a Service (IaaS) Specifics

The architecture for IaaS-hosted applications resembles that of normal web

applications, with a web-server based, n-Tier distributed architecture. For this
class of application running in an enterprise, there are many infrastructure
controls available to secure the host and the network connecting the distributed
hosts. Comparable controls do not exist by default in an IaaS platform and must
be added through configuration or as application-level controls.
Trusting the Virtual Machine Image
IaaS providers typically make a number of pre-configured, ready-to-run virtual

machine images available to their clients. Some of the images are provided by
the IaaS provider itself, but others come from partners and other
clients. Independent of the source of the image, enterprise users should apply
the same level of security verification and hardening as applied to traditional
hosts within the enterprise. A good alternative to auditing an external image is to
provide one’s own image which conforms to the same security policies as
internal trusted hosts. Another option is to use virtual images from a trusted third
party, possibly a service provider that offers additional services over and above
the infrastructure components provided by the IaaS provider. IaaS platform

clients must however be wary of virtual images contributed by other service

provider clients. Malicious attacks, such as uploading a compromised OS image
to Amazon EC2, have been demonstrated and are just one example of the
dangers posed by these virtual images.
Hardening Hosts
IaaS platforms provide the ability to block and filter traffic based on IP address
and port, but these facilities are not equivalent to the network security controls in
most enterprise networks. Hosts running within an IaaS infrastructure are in a
similar position as are hosts running in the DMZ of an enterprise’s network. All of
the same precautions used to harden hosts running in the DMZ should be
applied to the virtual images. If the IaaS platform does not offer the capabilities
needed, IaaS customers should look for equivalent resources on the virtual
machine/host level.
It is a best practice for DMZ and cloud-based applications to build custom
operating system implementations (i.e. installing only required OS components
when configuring the system) and application platform images which only have
the capabilities necessary to support the application stack. By limiting the
capabilities of the underlying application stack, the overall attack surface of the
host, and the number of patches necessary to keep the application stack secure
are reduced.
Securing Inter-host Communication
The majority of enterprise applications are not affected by the security of

communication between hosts of a distributed application, as long as traffic does
not traverse an untrusted network. However, cloud-based applications run in an
infrastructure that is implicitly shared with other companies and must accept the
responsibility for securing communication. Cloud-based applications should
include explicit controls to prevent disclosure, if sensitive data is passed and
processed. In addition, the IaaS platform administrators, who maintain the data
center running the physical hosts and network, frequently cannot be trusted to
the same degree as administrators of an internal data center.
Securing such communication depends on the type of messages passed. For
synchronous communication, such as point-to-point network connections,
channel level security is sufficient. For asynchronous communication, such as
using a message queue-based mechanism, message-based security is required
to protect the sensitive information while the data is in transit.
Managing Application Keys
IaaS platforms often use a “secret key” to identify a valid account. The account
key must be passed on all of the calls to make use of the services provided by
the IaaS provider, including calls to connect and communicate between

application nodes. Most application security programs have initial standards and
best practices for handling key material, but these will need modification for IaaS
application keys. This is similar to assurances that cryptographic primitives and
operations have been evaluated in trusted computing, and it is possible that a
similar approach could be used for IaaS applications.
Additional Requirements for Handling of Sensitive Information
Applications running on an IaaS platform must ensure that sensitive information

does not leak during processing. In addition to existing precautions for handling
sensitive information, additional filtering and masking is most likely needed in
areas such as operations, exception handling and audit logging. It is important to
be aware of the location where debugging information is logged; especially if the
storage for this information could be shared and managed by an outside
untrusted party.
Enterprises contemplating the use of an IaaS environment should extend their

existing secure software development lifecycle to include specific information
about the IaaS platform.
During the initial pilots and development using the IaaS cloud environment, the
application security team should focus on updating security guidance in three
areas:
1. Updating the application’s threat and trust model for the cloud environment.
• Determine how threats change when the application runs in the cloud
environment
• Add new threats by focusing on changes to the application’s security
architecture - primarily those threats inherited from the multi-tenant
environment.
2. Update application security assessment tools for the new environment
• Add additional custom rules to both static and dynamic analysis tools
• Extend existing testing environments to include a second tenant to run
with the application being tested.
3. Focus specific guidance on changes to the application’s security architecture
• Use of multi-tenant infrastructure and the impact on maintaining the
confidentiality and integrity of sensitive data during transit between
applications components and for audit and logging data
• Management of credential material (tokens or use of PKI) used to
access the Cloud environment
• Changes to access restrictions for sensitive data within development
and test environments which may now be public or multi-tenant.

Platform as a Service (PaaS) Specifics

Platform as a Service (PaaS) enables fast development and deployment of

applications without the cost of managing the underlying platform, providing all of
the facilities required to support the complete software development life cycle.
Some PaaS platforms have a specific programming language or API to allow
complete support of a particular software development lifecycle.
Enterprises contemplating the use of a PaaS environment should extend their

existing secure software development lifecycle to include specific information
about the PaaS platform. This information should be generated during the
evaluations and proof-of-concept projects using the PaaS environment.
Multi-tenancy and the Application’s Threat Model
A fundamental part of a secure software development lifecycle is an assessment

of the application’s threat model. The PaaS environment introduces additional
threats that come from the application and platform administrators working for an
external vendor. Additional threats arise because the application is running on a
shared platform. Addressing the risks associated with these additional threats
require a change in the application’s security architecture to include application
level controls, such as secure message-level communication and an update to
existing secure design, coding, and testing guidance.
Software as a Service (SaaS) Specifics

When a SaaS application handles sensitive data, part of the due diligence in
choosing a vendor should include an analysis about how enterprise’s sensitive
data is isolated from other tenants’ data. This analysis includes data at rest and
data in transit within the vendor’s SaaS environment, as well as in transit across
other untrusted networks.
If the SaaS vendor has a secure software development lifecycle, reviewing the
addressed threat model is recommended. The threat model should list the threat
actors, possible attack vectors and software, and the compensating controls

designed into the cloud application.

Part of the vendor evaluation process must include evaluation of existing
certifications and the vendor’s software development lifecycle for security related
activities.
Certifications may provide information about the controls in place within the
service organization. For some applications, a high-level certification may be
sufficient. If, however, the SaaS service will host sensitive data or integrate with
internal systems that have sensitive data, additional due diligence might be
required and the adherence to it stipulated in the SLA.

Questions for your Provider and Assessment

Checklist
Application security adds another layer of security management with a unique set
of concerns. Before selecting a vendor to host your applications, data and
services in the cloud an enterprise should incorporate these concerns into their
due diligence. Domain 9 of the CSA Guide covers the operational issues in
providing a secure operational environment for the application and Domain 10
covers security incident response. Combining the question from these two
domains with the questions below covers the layers of the Cloud Reference
Model.
The following checklist of questions helps in addressing application-layer-specific

concerns. Many of the questions that apply to IaaS vendors will apply to PaaS
vendors as well. Some of the questions which apply to PaaS vendors will also
apply to SaaS vendors.
All Service Models

• What Secure Development Lifecycle activities does the vendor practice in
developing the service’s software?
• Design and Architecture
 Threat Modeling
 Secure Design Reviews
• Coding and Implementation
 Manual Secure Code Reviews
 Static Code Analysis
 Manual security testing
 Tool-base security testing
• What software development design and coding standards does the vendor
apply during the Secure Development Lifecycle?
• How are one tenant’s application components protected from attacks from
other tenants?
Infrastructure as a Service
• What mechanisms does the platform provide against DoS and DDoS
attacks at the infrastructure and network layers?
• What threat models are addressed at the infrastructure and network

layers?
• What mechanisms does the platform provide to validate the integrity of the
virtual machine images?
• What protections are in place against BIOS and root kit level attacks? Are
there detection and response plans in place if such attacks were to occur?
Platform as a Service
• Where is the line of responsibility drawn between security of the platform
and application components?
• What facilities does the platform provide for application level logging?
• Is application log data integrated with other platform-provided logging and
reporting?
• Are there any real time intrusion detection systems deployed for detecting
issues related to security at the application layer?
• What mechanisms does the platform support for isolating message data
on the client’s service bus?
• What mechanisms does the platform support for securing communication
between two application components? What mechanisms does the
platform support for isolating data at rest and in use?
Software as a Service
• What Web application security standards (input validation, encoding
output, preventing request forgery and information disclosure) are being
followed by the vendor?
• What application and infrastructure controls are in place to isolate the
enterprise’s data from that of other tenants?
• Data at rest
• Data in transit
• Data in use

Outlook
This section examines the prospects for the future development of application
security and defines the distinction between:
• Application integrity – creating a platform that can maintain the integrity of

an application and its configuration, data and communications in the face
of attacks.
• Application as enforcer – creating applications that can properly protect
the assets (such as data, communications and configuration).
Both of these have been considered in depth by the Jericho Forum which
proposes the Collaboration Oriented Architecture as the most appropriate
response to pressures to remove perimeters, such as cloud computing. Our
description here incorporates ideas from the Collaboration Oriented Architecture.
Application Integrity
Application integrity requires the following:
• Mechanisms for deploying the application correctly.

• A means of ensuring that applications are correct (i.e. not malicious) when
they are deployed.
• Mechanisms for periodically verifying the integrity of deployed
applications.
It can be seen that a rigorous SDLC (Software Development Lifecycle) is critical

to application integrity. However, the deployment approach is usually the last
thing considered in application development. As a result it is often complex and
unreliable and therefore, difficult to do securely. .
The authors therefore propose the following for the future:
• SDLC standards should expand to cover secure application deployment to

the cloud.
• In-cloud deployment, provisioning and integrity check facilities should be
integrated with SDLC standards and tools.
Application as Enforcer
Most of the existing security approaches focus on protecting a perimeter; a

physical site protected by a fence, a network protected by a firewall, an

organizational structure protecting its employees. Cloud computing is one of the
new business and technology drivers that accelerates the removal of these
barriers between enterprises, making the perimeter obsolete or irrelevant. The
effect of breaking down the barriers is being felt widely in IT and information
security:
• More applications are being exposed directly to the Internet, which

increases the security challenges for applications.
• Data, users and organizations are becoming mobile and agile, which
makes it harder for security policies to keep up.
• Attackers are becoming more sophisticated, which increases the impact of
being insecure.
• As organizations remove perimeters, security must move from protecting
perimeters to protecting assets directly.
The Jericho Forum’s Collaboration Oriented Architecture proposes the following:
• Parties, Risk, Identity, Data and Collaborations must be managed by

processes that can pass organizational boundaries transparently and
securely.
• Collaborations are the mechanism whereby parties work together for a
common aim.
• Collaborations control access to data where either the collaboration exists
to control access to the data, or the data exists to support the
collaboration.
• Parties take part in collaborations through a generic lifecycle with well-
defined stages (searching – looking for potential partners; negotiation –
agreeing to the terms of a collaboration; fulfillment – collaborating;
termination – the collaboration is complete). Parties need to maintain
information about themselves and others (‘reputation’) which creates the
necessary trust for them to agree on collaborations.
• During the fulfillment phase of a collaboration, parties control access to
data on the basis of the contracts in place between them.
• A party’s identity consists of its reputation and the contracts (or
collaborations) that it has agreed to.
• As parties collaborate, they will update each other’s reputations, which in
turn will affect their ability to engage in future collaborations.
How will this affect application design?
• Maintaining identity (reputation plus agreed contracts) is costly and the

cost will in most cases be spread across organizations and applications,
so identity will be externalized from applications. Increasingly, both
reputation and contracts will be managed as services in the cloud. The

user directory will be seen as a contract management service and will be
unified with other contract management services such as financial
accounting systems and ERP systems.
• The relationship between a party’s agreed contracts and its resource
access are costly and will be externalized from applications wherever
possible. Increasingly, security policy will therefore be managed as a
service in the cloud.
• Applications will retain roles both as a policy enforcement point and as a
source of audit data.
• Cloud-based services for managing reputation based on audit data will
become available.
One example of future development is the generation of Governance, Risk

Management, and Compliance (GRC) platforms in the cloud. These platforms will
be used to check compliance in both cloud applications, as well as internal
deployments. GRC platforms can lessen an IT organization’s burden of
developing a governance package, as well as developing auditing initiatives.
The development of cloud GRC platforms allows a company to use a third party
GRC application to audit another third party cloud computing environment.
Cloud computing environments will sign up for the third party audit to
demonstrate to clients that they meet certain Governance, Risk levels and
Compliance levels.
Although application security will become more important, it will be increasingly

handled by externalized services rather than by secure application code.

References
• [AWS1] Amazon Elastic Compute Cloud Developer Guide,
http://docs.amazonwebservices.com/AWSEC2/2009-03-
01/DeveloperGuide/
• [AWS2] Amazon Simple Storage Service Developer Guide,
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
• [AWS3] Amazon SimpleDB Developer Guide,
http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-
07/DeveloperGuide/
• [AWS4] Amazon Simple Queue Service Developer Guide,
http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-01-
01/SQSDeveloperGuide/
• [AZURE1] Azure Services Platform, http://msdn.microsoft.com/en-
us/library/dd163896.aspx
• [AZURE2] Windows Azure SDK, http://msdn.microsoft.com/en-
us/library/dd179367.aspx
• [SAVVIS] Savvis Symphony Cloud Services, http://www.savvis.net/en-
US/infrastructure-services/Cloud/Pages/Home.aspx
• [PYT] Python Runtime Environnent,
http://code.google.com/appengine/docs/
• [FORCE1] Force.com Web Services API Developer’s Guide,
http://www.salesforce.com/us/developer/docs/api/index.htm
• [FORCE2] The Force.com Workbook,
http://wiki.developerforce.com/index.php/Forcedotcomworkbook
• [SAS70] www.sas70.com
http://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_S
ervice_Organizations
• [QWASP] OWASP Top Ten Project,
http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
• [BSIMM] Building Security In Maturity Model, http://www.bsi-mm.com/
• [NIST] P. Mell and T. Grance, "Cloud computing definition," June 2009.
[Online]. Available: http://csrc.nist.gov/groups/SNS/cloud-
computing/index.html
• [BUR] "Cloud computing vocabulary ?(cloud computing wiki)?." [Online].
Available: http://sites.google.com/site/cloudcomputingwiki/Home/cloud-
computing-vocabulary
• [USEC] "Cloud computing use cases whitepaper," August 2009. [Online].
Available: http://www.scribd.com/doc/17929394/Cloud-Computing-Use-
Cases-Whitepaper

• [AMA] "Amazon web services blog: Introducing amazon virtual private

cloud (vpc)," Amazon, August 2009. [Online]. Available:
http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-
cloud-vpc.html
• [MSIS] Balanced Scorecard for Information Security Introduction,
Published: March 06, 2007, [Online]
Available:http://technet.microsoft.com/en-us/library/bb821240.aspx
• [FGIS] A Few Good Information Security Metrics, By Scott Berinato, July
2005 [Online] Available:
http://www.csoonline.com/article/220462/A_Few_Good_Information_Secu
rity_Metrics
• [CPMC] ClearPoint Metric Catalog, 2009 [Online] Available:
http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPa
ckage.aspx
• [ORCM] Overcoming Risk And Compliance Myopia, August 2006 [Online]
Available: http://logic.stanford.edu/POEM/externalpapers/grcdoc.pdf
• [DEC]Does Every Cloud Have a Silver Compliance Lining?, Tom McHale,
July 21, 2009 [Online] Available: http://blog.ca-grc.com/2009/07/does-
every-cloud-have-a-silver-compliance-lining/
• [CAUDIT1] Business case for a comprehensive approach to identity and
access management, May 2009 [Online] Available:
https://wiki.caudit.edu.au/confluence/display/CTSCIdMWG/Business+case
• [GARTNER1] Justify Identity Management Investment with Metrics, by
Roberta J. Witty, Kris Brittain and Ant Allan, 23 Feb 2004. Gartner
Research ID number TG-22-1617.
• [FEDORA1] Fedora Infrastructure Metrics, 2008 [Online] Available:
http://fedoraproject.org/wiki/Infrastructure/Metrics
• [CVSS] A Complete Guide to the Common Vulnerability Scoring System
Version 2.0, 2007 http://www.first.org/cvss/cvss-guide.html
• [ISO 27001] ISO 27001 Information technology — Security techniques —
Information security management systems — Requirements, 2005
• [CCSS] The Common Configuration Scoring System (CCSS): Metrics for
Software Security Configuration Vulnerabilities (DRAFT), 2009 [Online]
http://csrc.nist.gov/publications/drafts/nistir-7502/Draft-NISTIR-7502.pdf
• [OEAS] An Oracle White Paper in Enterprise Architecture: Architectural
Strategies for Cloud Computing, August 2009 [Online]
http://www.oracle.com/technology/architect/entarch/pdf/architectural_strat
egies_for_cloud_computing.pdf
• [SNORTAWS] Quickstart Guide for using Sourcefire SNORT on AMAZON
EC2
http://www.snort.org/assets/144/Snort_EC2_QuickStart.pdf
• [AOD] Distributed WAF on Amazon EC2 by Art of Defence
http://aws.artofdefence.com/how-it-works/

• [BSEC] SAAS WAF by BinarySec

http://www.binarysec.com/cms/pdf/datasheet_saas.pdf
• [MSDL] Microsoft Security Development Lifecycle
http://www.microsoft.com/security/sdl/
• [PCI] PCI Security Standards Council
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml
• [CSA] Cloud Security Alliance V2 Guidance
http://www.cloudsecurityalliance.org/csaguide.pdf
• [JERICHO] Jericho Forum at the Open Group
https://www.opengroup.org/jericho/index.htm

Csaguide Dom10 v2.10

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Csaguide Dom10 v2.10

Caricato da

Copyright:

Formati disponibili

Domain 10: Guidance for

Application Security V2.1

Cloud Security Alliance

© 2010 Cloud Security Alliance.

Copyright © 2010 Cloud Security Alliance 2

Copyright © 2010 Cloud Security Alliance 3

PLATFORM AS A SERVICE (PAAS) SPECIFICS .............................................................................................23

Copyright © 2010 Cloud Security Alliance 4

Figure 1 – Additional Threats at All Levels of Service

Copyright © 2010 Cloud Security Alliance 5

• Application Security Architecture – Cloud Computing affects the

• Software Development Lifecycle (SDLC) – Cloud Computing influences

• Economics – Cloud Computing’s cost model needs to be fully understood

• Metrics – Cloud Computing’s metrics are not limited to simply

• Tools and Services – Cloud Computing introduces a number of new

applications. These include development and test tools, application

• Vulnerabilities – Cloud Computing vulnerabilities include the well-

Application Security Architecture

Managing Platform Account Tokens/Keys

Copyright © 2010 Cloud Security Alliance 7

Software Development Lifecycle

Applications running on cloud platforms have a different trust relationship

Figure 2 – SDLC Trust Model for Internal Application

Copyright © 2010 Cloud Security Alliance 8

It is generally the customer’s responsibility to ensure that security standards are

Copyright © 2010 Cloud Security Alliance 9

Copyright © 2010 Cloud Security Alliance 10

• Compliance and Governance Metrics: Changes to the cloud computing

Copyright © 2010 Cloud Security Alliance 11

• Identity and Access: Identity management is “who am I” and “what can I

Tools and Services

• False Negatives: Tools do not detect all security vulnerabilities, especially

Copyright © 2010 Cloud Security Alliance 12

Infrastructure as a Service (IaaS) Specifics

Figure 3 - Virtual Machine of an IaaS

Figure 4 - Cloud-based persistent storage

For distributed applications running in an enterprise many controls exist to secure

Copyright © 2010 Cloud Security Alliance 13

Software Development Lifecycle

Figure 5 - SDLC Trust Model for IaaS Hosted Application

Tools and Services

Copyright © 2010 Cloud Security Alliance 14

Platform as a Service (PaaS) Specifics

Figure 6 - Cloud Reference Model: Application Capabilities Provided by PaaS

Copyright © 2010 Cloud Security Alliance 15

Securing Message-level Communication

Additional Requirements for Handling Sensitive

Managing Application Keys

Software Development Lifecycle

Copyright © 2010 Cloud Security Alliance 16

Tools and Services

Software as a Service (SaaS) Specifics

Figure 7- SaaS platform customization

Copyright © 2010 Cloud Security Alliance 17

cryptographic controls, such as a combination of encryption and secure hashing,

Software Development Lifecycle

Solutions and Recommendations

Application Security Architecture

As cloud applications reside in an external environment in relation to the

Copyright © 2010 Cloud Security Alliance 18

Tools and Services

Copyright © 2010 Cloud Security Alliance 19