domain 10: guidance for application security v2 performance characteristics and ... •...

Domain 10: Guidance for

Application Security V2.1

Prepared by the

Cloud Security Alliance

July 2010

Domain 10: Guidance for Application Security V2.1

Copyright © 2010 Cloud Security Alliance 2

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

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



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 APPLICATION SECURITY ARCHITECTURE ..................................................................................................15 SECURING MESSAGE-LEVEL COMMUNICATION .........................................................................................16 ADDITIONAL REQUIREMENTS FOR HANDLING SENSITIVE INFORMATION ..................................................16 MANAGING APPLICATION KEYS ................................................................................................................16 SOFTWARE DEVELOPMENT LIFECYCLE .....................................................................................................16 TOOLS AND SERVICES ...............................................................................................................................17

SOFTWARE AS A SERVICE (SAAS) SPECIFICS ................................................................................17 APPLICATION SECURITY ARCHITECTURE ..................................................................................................17 SOFTWARE DEVELOPMENT LIFECYCLE .....................................................................................................18

SOLUTIONS AND RECOMMENDATIONS...........................................................................................18 APPLICATION SECURITY ARCHITECTURE ..................................................................................................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 Application Security Architecture ........................................................................................................23 Software Development Lifecycle ..........................................................................................................23 Multi-tenancy and the Application’s Threat Model .............................................................................23

SOFTWARE AS A SERVICE (SAAS) SPECIFICS .............................................................................................23 Application Security Architecture ........................................................................................................23 Software Development Lifecycle ..........................................................................................................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 Lifecycle

Security Risks from Cloud Computing

Economic Benefits from Cloud Computing

Economic Impact

Business Requirements and Project Justification

Risks relate to the criticality of the application to the business, and the sensitivity of the data to be processed. Risks from cloud computing result from issues relating to data protection and system availability.

Cloud computing might offer faster “time to value,” lower development and testing costs and lower computing costs during full production.

Cloud computing may result in a significant reduction in costs of developing and testing applications and of running the system in production. These savings need to be offset against the costs of ensuring an acceptable level of security and availability.

Functional Specifications and Design

When specifying what specific applications will actually be doing, systems analysts must consider that some functions are more security sensitive than others and may not be viable candidates for running in the cloud.

Often the most critical applications, handling the most sensitive data, are more cheaply run in the cloud. For example, for many organizations, the biggest resource hogs are precisely those applications that process sensitive information.

The cost reductions need to be balanced against any vulnerability increases with respect to security and availability. The risks may be mitigated by increasing security measures, but the costs of doing so must be deducted from processing cost savings.

Development (Coding) and Testing

There is a risk in the cloud, as in other environments, that proprietary information and intellectual property might be stolen, even without customers’ knowledge.

While there is usually policy against using live data for testing, realistic data must often be used, raising security

Because of the compelling financial benefits of using cloud resources, particularly when computing resource requirements may exhibit extreme peaks and valleys, there are often big economic incentives to use cloud computing for development.

Sometimes there is a benefit in

Cloud service providers offer security services, such as access management, multiple copies of systems and data, and encryption, which the customer can invoke in order to raise the security level and reduce risks of data compromises and exploitation for fraudulent purposes. There are additional costs related to invoking these



issues. The risk of data compromise and the cost of potential security incidents, encourages customers to not use live data for testing purposes.

developing applications in-house, but using cloud resources for testing, particularly if large volumes of data and significant computing resources are needed to conduct the tests.

services and the customer has to determine whether any particular security measure is worthwhile or whether the cost of increased security outweighs the economic benefits of cloud computing.

Implement-ation and Production

The bulk of cloud computing is for running production systems, which involves the transference of intellectual property (such as the application code and the operational procedures) as well as the use of live data. There are risks that the systems and procedures might be hijacked by the service provider or other organizations and that sensitive data are compromised. There are also risks related to availability of systems and networks and the relative performance, including network latency, of running applications in the cloud versus internally.

One of the biggest benefits of running production applications in the cloud is lower costs. Large cloud services providers can use economies of scale and purchasing power to lower their costs, and they may pass on some of those savings to customers in the form of lower prices. Also, the pay-as-you-use charging model allows customers to avoid excess capacity and reduce financial commitments usually required in setting up and running internal data centers. In this way, capital expenses are converted into operational expenses, which is beneficial when capital markets are tight.

The overall economic impact sought in the use of cloud computing is to reduce costs and increase flexibility in use and payment for resources. However, organizations need to be aware that the above goals may not always be realized. For example, it may be more costly to incur communications costs between cloud service providers and their customers, and to the customers’ customers, business partners and suppliers, than from in-house facilities, so that other cost reductions may be negated. In some cases, the use of a hybrid cloud, with some functions performed in the cloud and others in-house, may be the most cost-effective approach.



Application Retirement or Transfer

Planning for the decommissioning or retiring of applications and systems is often neglected. It is important to realize that, when a system or an application has outlived its usefulness and is being replaced by another system, the program code and data, which may reside somewhere in the cloud, should be disposed of through a formal process, which was preferably predetermined and included in the services agreement..

Similarly, customers may wish to transfer applications or entire systems from one cloud service to another, to an in-house facility, or to a combination hybrid cloud. In such cases, there should be predetermined procedures for the transfer of the applications, systems and networks and the retirement of those resources held with the original provider.

It is possible that applications running in the cloud have better demarcation than internally run and managed applications, if for no other reason than specific resource usage is monitored and charged for by the service provider.

In addition, the customer does not usually have to be concerned with the disposal or redeployment of dedicated resources, as they might with internal systems and networks.

Furthermore, it is likely that, for the transfer costs, the time to convert and costs of parallel operations may be less for transferring from cloud computing, although this very much depends on particular circumstances.

The degree to which economic benefits can be realized for retiring systems or transferring them is very much a function of the type and complexity of the system and the degree of customer lock-in, which is sometimes termed “stickiness.” The provider usually has strong incentives to make the service as sticky as possible so that customers will continue with the provider. This works against customers if they wish to transfer the system or if the provider goes out of business or otherwise ends the service.

The issues that arise include contractual terms as well as portability and interoperability issues, the latter two of which are addressed in Chapter … Portability is the ease with which an application can be moved from one platform to another without the need for significant reworking. Interoperability relates to the degree to which 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 Application Security Architecture 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.



Software Development Lifecycle 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 Application Security Architecture 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.

Software Development Lifecycle 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 Application Security Architecture 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.

Software Development Lifecycle 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 Application Security Architecture 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 Application Security Architecture

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.

Software Development Lifecycle

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 Application Security Architecture

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 Application Security Architecture

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

http://docs.amazonwebservices.com/AWSEC2/2009-03-01/DeveloperGuide/�

http://docs.amazonwebservices.com/AWSEC2/2009-03-01/DeveloperGuide/�

http://docs.amazonwebservices.com/AmazonS3/2006-03-01/�

http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/�

http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/�

http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-01-01/SQSDeveloperGuide/�

http://docs.amazonwebservices.com/AWSSimpleQueueService/2008-01-01/SQSDeveloperGuide/�

http://msdn.microsoft.com/en-us/library/dd163896.aspx�




http://www.savvis.net/en-US/infrastructure-services/Cloud/Pages/Home.aspx�

http://www.savvis.net/en-US/infrastructure-services/Cloud/Pages/Home.aspx�

http://code.google.com/appengine/docs/�

http://www.salesforce.com/us/developer/docs/api/index.htm�

http://wiki.developerforce.com/index.php/Forcedotcomworkbook�

http://www.sas70.com/�

http://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_Service_Organizations�

http://en.wikipedia.org/wiki/Statement_on_Auditing_Standards_No._70:_Service_Organizations�

http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project�

http://www.bsi-mm.com/�

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html�

http://csrc.nist.gov/groups/SNS/cloud-computing/index.html�

http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary�

http://sites.google.com/site/cloudcomputingwiki/Home/cloud-computing-vocabulary�

http://www.scribd.com/doc/17929394/Cloud-Computing-Use-Cases-Whitepaper�

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_Security_Metrics

• [CPMC] ClearPoint Metric Catalog, 2009 [Online] Available: http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPackage.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_strategies_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/

http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html�

http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html�

http://www.csoonline.com/article/220462/A_Few_Good_Information_Security_Metrics�

http://www.csoonline.com/article/220462/A_Few_Good_Information_Security_Metrics�

http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPackage.aspx�

http://www.clearpointmetrics.com/newdev_v3/catalog/MetricApplicationPackage.aspx�

http://logic.stanford.edu/POEM/externalpapers/grcdoc.pdf�

http://blog.ca-grc.com/2009/07/does-every-cloud-have-a-silver-compliance-lining/�

http://blog.ca-grc.com/2009/07/does-every-cloud-have-a-silver-compliance-lining/�

https://wiki.caudit.edu.au/confluence/display/CTSCIdMWG/Business+case�

http://fedoraproject.org/wiki/Infrastructure/Metrics�

http://www.first.org/cvss/cvss-guide.html�

http://csrc.nist.gov/publications/drafts/nistir-7502/Draft-NISTIR-7502.pdf�

http://www.oracle.com/technology/architect/entarch/pdf/architectural_strategies_for_cloud_computing.pdf�

http://www.oracle.com/technology/architect/entarch/pdf/architectural_strategies_for_cloud_computing.pdf�

http://www.snort.org/assets/144/Snort_EC2_QuickStart.pdf�

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

http://www.binarysec.com/cms/pdf/datasheet_saas.pdf�

http://www.microsoft.com/security/sdl/�

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml�

http://www.cloudsecurityalliance.org/csaguide.pdf�

https://www.opengroup.org/jericho/index.htm�

domain 10: guidance for application security v2 performance characteristics and ... •...

Documents