DOMAIN 10 ::

APPLICATION SECURITY

Cloud environments, particularly public cloud environments, by virtue of their flexibility and openness challenge many fundamental assumptions about application security. Some of these assumptions are well understood, however, many are not.

This section is intended to provide guidance on how cloud computing influences security over the lifetime of an application, from design to operations to ultimate decommissioning.

This guidance is for all stakeholders (including application designers, security professionals, operations personnel, and technical management) on how to best mitigate risk and manage assurance when designing Cloud Computing applications.

Cloud Computing is a particular challenge for applications across the layers of Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). 

Cloud-based software applications require a design rigor similar to an application connecting to the raw Internet—the security must be provided by the application without any assumptions being made about the external environment.

However, the threats that applications are going to be exposed to in a cloud environment will be more than those experienced in a traditional data center. This creates the need for rigorous practices that must be followed when developing or migrating applications to the cloud.

This Application Security domain has been organized into the following areas of focus:

(I) Secure SDLC (General practices for secure Software Development Life Cycle and nuances specific to the Cloud)

(II) Authentication, Authorization, Compliance –Application Security Architecture in the Cloud

(III) Identity and the consumption of identity as it relates to Cloud Application Security

(IV) Entitlement processes and risk-based access management as it relates to cloud encryption in cloud-based applications

(V) Application authorization management (policy authoring/update, enforcement)

(VI) Application Penetration Testing for the Cloud (general practices and nuances specific to cloud-based Applications)

(VII) Monitoring Applications in the Cloud

(VIII) Application authentication, compliance, and risk management and the repercussions of multi-tenancy and shared infrastructure


(IX) The difference between avoiding malicious software and providing application security

10.1 Secure SDLC (Software Development Life Cycle)

A Secure Software Development Life Cycle (SSDLC) (also referred by a few as Secure Development Life Cycle (SDLC)) has assumed increased importance when migrating and deploying applications in the cloud. 

Organizations should ensure that the best practices of application security, identity management, data management, and privacy are integral to their development programs and throughout the lifecycle of the application.

Developing for a cloud environment is different than the traditional hosting environments in the following areas:


(A) The control over physical security is substantially reduced in public cloud scenarios.

(B) The potential incompatibility between vendors when services (for example, Storage) are migrated from one vendor to another.

(C) Protection of data through the lifecycle must be considered. This includes transit, processing and storage.

(D) The combinations of web services in the cloud environment can potentially cause security vulnerabilities to be present.

(E) The ability to access logs, especially in a shared public cloud, is more difficult and should be specified as a part of the service level agreement.

(F) Fail-over for data and data security in the cloud has to be more detailed and layered than traditional environments.


(G) Assuring (and demonstrating evidence for) compliance to relevant industry and government regulations is typically more difficult within a cloud environment.

In implementing a SSDLC, organizations must adopt best practices for development, either by having a good blend of processes, tools, and technologies of their own or adopting one of the maturity models such as these:

(I) Building Security In Maturity Model (BSIMM2)

(II) Software Assurance Maturity Model (SAMM)

(III) Systems Security Engineering Capability Maturity Model (SSE-CMM)

10.1.1 Application Security Assurance Program

Organizations should have an application security assurance program that ensures for the applications that are being migrated and/or developed and maintained in a cloud environment the following:

(A) With adequate executive support, goals and metrics are defined, implemented and tracked.


(B) A security and a privacy policy for applications in the cloud has been established to meet the legal and regulatory compliance requirements that are aligned with the business needs and regulatory obligations of the organization.

(C) Adequate capability and capacity for security assurance is available within the organization to architect, design, develop, test and deploy secure 
applications by on-boarding, training suitable resources in a timely manner.

(D) Security and privacy risk evaluations are performed for all applications to ensure the requirements are correctly defined.

(E) Processes for ensuring security and privacy requirements for the development and maintenance process in the cloud are defined and implemented.

(F) Configuration and change management must be auditable and verifiable

(G) Physical security risk evaluations for the application and the data are performed, and the access to all cloud infrastructure components is adequate to meet those requirements.

(H) Formal coding best practices, considering the strengths and weaknesses of language used should be followed during the development phase.


(I) Privacy and security measures must be auditable and verifiable.

10.1.2 Verification and Validation

10.1.2.1 Design Review

Some functions are more security sensitive than others and may not be viable candidates for running in the cloud and should be considered when the specific application design and requirements are specified.

The following principles should be followed in order to develop a secure design for the application. Where these principles cannot be met by a cloud architecture, they should be remediated by appropriate technical and/or compensating controls. 

Failure to do this brings into question the viability of a cloud deployment.

(A) Least privilege : This principle maintains that an individual, process, or other type of entity should be given the minimum privileges and resources for the minimum period of time required to complete a task. In many cases, least privilege can only be implemented effectively using fine-grained, contextual application authorization management with security policy automation mechanisms.

(B) Segregation of duties : This is a control policy according to which no person should be given responsibility for, or access to, more than one related function.


(C) Defense in depth : This is the application of multiple layers of protection wherein a subsequent layer will provide protection if a previous layer is breached.

(D) Fail safe : If a cloud system fails it should fail to a state in which the security of the system and its data are not compromised. 

For example, to ensure the system defaults to a state in which a user or process is denied access to the system.

(E) Economy of mechanism : This promotes simple and comprehensible design and implementation of protection mechanisms, so that unintended access paths do not exist or can be readily identified and eliminated.

(F) Complete mediation : This is where every request by an entity to access an object in a computer system must be authorized.

(G) Open design : This is an open-access cloud system design that has been evaluated and peer-reviewed by a community of experts resulting in a more secure design.

(H) Least common mechanism : This states that a minimum number of mechanisms (especially protection mechanisms) should be common across multiple applications, minimizing one application’s ability to corrupt or subvert another application.

(I) Weakest link : It is important to identify the weakest mechanisms in the security chain and layers of defense and improve them, so that risks to the system are mitigated to an acceptable level.

10.1.3 Construction

10.1.3.1 Code Review


It is recommended to define and follow secure software development at the organization level. The guidelines spelled out in the Fundamental Practices for Secure Software Development from SAFECode, CERT (SEI) or ISO Standards could be followed.

Dynamic code analysis examines the code as it executes in a running cloud application, with the tester tracing the external interfaces in the source code to the corresponding interactions in the executing code, so that any vulnerabilities or anomalies that arise in the executing interfaces are simultaneously located in the source code, where they can then be fixed.

Unlike static analysis, dynamic analysis enables the tester to exercise the software in ways that expose vulnerabilities introduced by interactions with users and changes in the configuration or behavior of environment components.

Some of the best practices for writing a secure code and reviewing are listed below:

(A) The minimum necessary information should be included in cloud server code. Comments should be stripped from operational code, and names and other personal information should be avoided.

(B) Utilize source code analysis tools to check for typical programming errors such as Buffer Overflows, Format String Attacks, Race Conditions, etc.

(C) Verify and validate all inputs, user, computer and inter-system. Content injection and several other attacks are possible when the cloud infrastructure takes any input and applies the content of that input into commands or SQL statements.


(D) When using object code (binaries), for example, where 3rd party libraries are being used, utilize a testing service capable of static vulnerability testing on object code.

10.1.3.2 Security Testing

Penetration test is a security testing methodology that gives the tester insight into the strength of the target’s network security by simulating an attack from a malicious source. 

The process involves an active analysis of the cloud system for any potential vulnerability that may result from poor or improper system configuration, known and/or unknown hardware or software flaws, or operational weaknesses in process or technical countermeasures.

This analysis is carried out from the position of a potential attacker, and can involve active exploitation of security vulnerabilities.

The type of cloud model has a huge impact on the penetration testing or in deciding if penetration test is possible. Generally, Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) clouds are likely to permit penetration testing. 

However, Software as a Service (SaaS) providers are not likely to allow customers to penetration test their applications and infrastructure, with the exception of third parties performing the cloud providers’ own penetration tests for compliance or security best practices.

Penetration testing is typically carried out within a “black box” scenario, that is, with no prior knowledge of the infrastructure to be tested. At its simplest level, the penetration test involves three phases:

(1) Preparation : This is where a formal contract is executed containing non-disclosure of the client’s data and legal protection for the tester. At a minimum, it lists the IP addresses to be tested.

(2) Execution : In this phase the penetration test is executed, with the tester looking for potential vulnerabilities.


(3) Delivery : The results of the evaluation are communicated to the tester’s contact in the organization, and corrective action is advised.

Whether the penetration test is a full knowledge (white box) test, a partial knowledge (gray box) test, or a zero knowledge (black box) test, after the report and results are obtained, mitigation techniques have to be applied to reduce the risk of compromise to an acceptable or tolerable level.

The test should have the widest possible scope to address vulnerabilities and corresponding risks to such areas as applications, remote access systems and other related IT assets.

10.1.3.3 Interoperability Testing

Interoperability testing evaluates whether a cloud application can exchange data (interoperate) with other components or applications. 

Interoperability testing activities determine the capability of applications to exchange data via a common set of exchange formats, to read and write the same file formats, and to communicate using the same protocols.

A major goal of interoperability testing is to detect interoperability problems between cloud software applications before these applications are put into operation. Interoperability testing requires the majority of the application to be completed before testing can occur.

As well as testing for interoperability, these tests should confirm that all data exchanges, protocols and interfaces used are using secure transfers of information.

Interoperability testing typically takes one of three approaches:

(1) Testing all pairs : This is often conducted by a third-party independent group of testers who are knowledgeable about the interoperability characteristics across software products and between software vendors.


(2) Testing some of the combinations : This involves testing only part of the combinations and assuming the untested combinations will also interoperate.

(3) Testing against a reference implementation : This establishes a reference implementation, e.g., using the accepted standard, and testing all products against this reference.

10.1.4 Quantitative Improvement

10.1.4.1 Metrics

Any application security assurance program should collect metrics, which can be analyzed and used to report the status of secure development on a periodic basis. The metrics collection and reporting could be enhanced as any application security program attains more maturity.

Some of the metrics recommended are:

(A) Percentage of applications and data assets in the cloud evaluated for risk classification in the past quarter and/or year

(B) Costs of the Application Security Assurance program in a quarter and/or in a year in a project/program for cloud-based applications


(C) Estimates of past loss due to security issues, if any, in the applications being developed and/or deployed in the cloud

10.1.4.2 Use of Automated SDLC Security Technology Tools and Features

People-centric SDLC activities (processes, training, and testing) are necessary but often not sufficient or viable for good application security. Where feasible, automated tools should be used to construct secure applications and automatically build security into applications.

Such tools that automatically generate technical security features are often tied into development and integration/orchestration tools. 

For example, technical authorization policy rules can be automatically generated (at development/integration/mash-up time) from security requirement specifications by tools that analyze applications and their interactions.

Similarly, some automated testing can be done at the development/integration stage, and information assurance evidence can be generated.

For cloud, this can be done at the subscriber end during development or mash-up (especially for IaaS), or the cloud provider can provide the technology (the subscriber can configure if necessary), especially in the cloud application platform for PaaS.

For SaaS, it is likely that most security automation will be built-in, configured, and operated by the cloud provider.

10.2 Authentication, Authorization, and Compliance – Application Security Architecture in the Cloud

10.2.1 Cloud Services/Applications Development and Business Challenges

There are new potential risks associated with access to sensitive data and systems. A clear understanding of the following security risks within the application and business environment is critical for addressing the full scope of security and privacy issues in reference to the Cloud services/applications:

(A) Lack of control : This is where cloud subscribers typically lack control over cloud security policies and controls.

(B) Lack of visibility : This is where cloud subscribers typically lack visibility into cloud security policy enforcement and controls effectiveness.

(C) Lack of manageability : This is where cloud subscribers are often not sufficiently able to manage cloud application security, especially access and audit policies.

(D) Loss of governance : This is where the organization may not have direct control of the infrastructure; here trust in the provider (sometimes a naive trust) and its own ability to provide proper security is paramount.

(E) Compliance risk : This is where the cloud provider impacts the organization's ability to comply with regulations, privacy expectations, and industry standards, because data and systems may exist outside the organization's direct control.

(F) Isolation failure : This is where multi-tenancy and resource sharing are defining characteristics of the cloud. Thus it is entirely likely for competing companies to be using the same cloud services, in effect, running their workloads shoulder-to-shoulder. Keeping memory, storage, and network access isolated is essential.

(G) Data protection : This is where the organization relinquishes direct control over data; it relies on the provider to keep that data secure, and when it is deleted, the provider should ensure (or be able to prove) that it is permanently destroyed.


(H) Management interfaces and access configuration : Cloud applications are accessed and managed through the Internet, and potentially involve complex and control requirements. The risk associated with a security breach is therefore increased and proper access authorization must be carefully considered.

10.2.2 Technical Risks and Solutions

Most Cloud service providers include some form of Identity, Entitlement, and Access Management (IdEA) in the cloud service’s design. Often user authentication and authorization is delegated to the customer’s user management system using a federation standard.

Support for Identity, Entitlement and Access Management impacts the customer in that integration in constrained by the credential passing mechanism. Infrastructure such as billing and metering that depend on identity management also present integration and migration risks.

Support for Identity, Entitlement, and Access management has integration implications for the customer. 

These implications include securely passing credentials and attributes, provisioning additional users, etc. 

Business operations within the cloud service provider are also affected; these operations include billing and accounting resource utilization. As a result, it is important to consider Identity, Entitlement, and Access management integration as an integral part of the design.

The application’s IdEA capabilities (or lack thereof), such as an application’s ability to accept a SAML assertion, will impact the cloud service governance, integration, and user experience, thus understanding the IdEA requirements of the particular cloud application is a critical part of the requirements definition.

Typical IdEA requirements in a cloud application design include:

(A) Understanding how the cloud application will provision accounts to users, power users, and administrators – triggers for these could be links to internal HR systems or cloud-based HR platforms

(B) Provisioning of cloud services for service-to-service integration, e.g., internal applications to cloud-based services

(C) The ability to accept claim and assertions (identifiers and attributes) from a variety of sources, and entities based on federation standards (e.g., SAML, WS FED, etc.)

(D) The ability to make risk-based entitlement decisions about access to (and within) the cloud application, based on the identity and attributes of all the entities (users, devices, code, organization, agents) in the chain.

(E) A rich, risk-based entitlement language leading to access management (authoring/distribution/update, etc.) for protected resources (i.e., what is allowed for each resource)

(F) Support for internal security and regulatory-policy compliance requirements, such as claims-based authentication, or at a minimum role-based access control


(G) User activity monitoring, logging, and reporting dictated by internal policies and regulatory compliance, such as SOX, PCI, and HIPAA.

A variety of Identity providers or Service providers may generate tokens such as SAML, OpenID, or OAuth tokens for session caching allowing a pass-through sign-on capability. 

Applications to be deployed in cloud should have capability to integrate with these claims/assertion services and Applications/services should be designed to support the open standards for Federation, i.e. SAML, OAuth, OpenID.

SAML - Security Assertion Markup Language, an XML-based OASIS open standard for exchanging authentication and authorization data between security domains

OpenID - an open standard permitting users to be authenticated in a decentralized manner


OAuth - Open Authorization, an open standard for authorization, allowing users to share their private resources with tokens instead of credentials

The Entitlement management process will require the ability for defining, managing, and accessing the access control rules for the cloud-based applications through a centralized interface.

Such an interface/service could itself be hosted on the cloud or internally and can leverage standards such as XACML.

The main challenge here is manageability: With increasing security policy and compliance complexity, IT complexity, and IT agility, the task of translating security policies into security implementation gets more time-consuming, repetitive, expensive, and error-prone and easily can amount to the bulk of security costs for end-user organizations as traditional users are managed into and out of access control lists for role-based access control, while expensive engines process these lists to ensure segregation-of-duties have not been breached.

Instead, defining a set of rules into an entitlement layer, fed by the claims, (assertions,) and attributes of the entities in the transaction significantly simplifies and enhances the control an organization has over its applications leading to the end subscriber organizations (and cloud providers) lowering their cost and improving policy implementation accuracy.

To integrate application security controls, data security and privacy protection, the services should use auditable industry standards, e.g. ISAE 3402/SSAE 16 (replaces SAS 70), PCI, HIPAA and ISO 27002. 

Each one comes with controls in a variety of categories that govern operation of a cloud provider’s data center as well as the applications that can be hosted in such an environment.

It is important to evaluate the different security claims and make a sound decision on which standards apply for the applications and services being hosted in a cloud environment.

A thorough analysis based on requirements should be done to identify service level objectives upfront to avoid major code changes to application code, deployment, and support tools for both the customers as well as the cloud provider organizations.

XACML- eXtensible Access Control Markup Language, an OASIS standard

10.2.3 Compliance Building Blocks

Irrespective of which standards are used, achieving compliance to run an application in a cloud has some basic building blocks and the foundation of all standards is provided by the cloud provider’s physical infrastructure.

Infrastructure controls include things like protecting the facility from natural disasters, assuring reliable electrical power in the event of outages, and backing up data in the event of a hardware failure.

They also include controls governing the cloud provider’s processes and policies such as system administrative auditing, access and authorization to access the data center, and methods used for internal security reviews and how they are performed and reported.

The next layer on top of the infrastructure controls is a collection of application controls. Multiple levels of security are required, such as the transport layer that must be secure; when data leaves the data center, it must be encrypted with encryption keys under enterprise control.

Some applications may need message layer security, digital signing, and other added security features in order to be compliant with some standards for storing or transmitting Personally identifiable information in order to meet privacy requirements.

All such application controls for the service/application to be moved to Cloud should be identified during the design phase so they can be appropriately integrated into the architecture design and developed as per requirements. Notable standards are PCI –DSS, SOX, ISAE 3402/SSAE 16,HIPAA, and other privacy standards.

10.3 Identity, Entitlement, & Access Management for Cloud Application Security

Traditional in house enterprise applications could be protected with traditional edge security controls like firewalls, proxies, etc.

This could very well meet the risk level and security requirements of the enterprise as the applications are running on trusted networks, trusted hardware, etc.

The enterprise could also leverage their enterprise directory infrastructure for authenticating its users to these applications and maintain all access decisions within the applications. The perimeter for the enterprise is well defined in this case.

When the user moves these applications to the cloud, all these traditional controls are no longer effective enough to protect as these applications are running on un-trusted networks (de-parameterization).

Applications could be residing with other co-tenants of same service provider (resource pooling) and could be accessed from anywhere through any type of device. This changes the very nature of security requirements for the cloud applications. As per www.rationalsurvivability.com cloud anatomy is referred as the following:

To the above referenced structure the user can now add the ways he/she can access these applications. This anatomy can then be viewed as:

From the anatomy above, you can clearly see that your application is a window to your data, and the new perimeter is the content (data) and context by which the user tries to access that data.

This makes applying security controls to the cloud applications critical. The context of accessing the data becomes very important and needs a rich collection of identifiers and attributes with which to make access decisions. 

With consumerization of IT, enterprises are now faced with the reality of “Bring Your Own Device” (BYOD). So device identification and the attributes of that device also become an important factor for determining the access control.

Identity should not just be viewed as a reference for authenticating the entity but also gathers more information about the user for making access decisions.

Identity also includes the identities of the devices that applications run on (VM image identity), privileged users that manage that VM image (could be both enterprise users as well as service provider users), identities for other applications and services that application needs to interact with, identities of administrative users to manage the application, and external identities outside of the enterprise that need access to the application like B2B, B2C, etc.

Also note that access decisions will be based on attributes that are not identity-related, and policy authoring/management tools need to support such non-identity attributes (see “Authorization management & policy automation” below).

In this section we will look into how Identity, Entitlement, and Access management affects the cloud application security. 

IdEA can be divided broadly into five main components:

1. Authentication
2. Authorization
3. Administration
4. Audit & Compliance
5. Policy

10.3.1 Authentication

Authentication refers to establishing/asserting the identity to the application. This is usually done in two phases. The first phase is disambiguating the identity and the second phase is validating the credential already provided to the user. 

Some of the main drivers for authentication to cloud applications are device independence, common and simple UI, and single protocol universal across the devices. Also, many service providers expose their services in form of API’s, and these API’s are designed for accepting tokens rather than the passwords.

In a regular enterprise application, the authentication is done against the enterprise user store (Active Directory or LDAP), and the authenticating credential is typically userID/Password. 

For cloud-based application, authenticating using the enterprise credentials gets trickier. Some enterprises establish VPN tunnel from the service provider to the enterprise network so that they can authenticate against the enterprise user directory. Even though this solution might work, enterprise should take into consideration latency issues, connectivity issues, and BCP/DR planning etc., and this solution should not be used or designed into new cloud applications.

Enterprises should plan for using open standards like SAML and WS-Federation.

There is also increase in use of enterprise applications by partners and customers of the enterprise. This is also true for cloud applications. These users rarely want to maintain separate identities for their 3rd party access (but today often have no choice). 

So enterprises should plan for “Bring Your Own Identity” (BYOI), and the cloud application needs to be designed to consume Identity and attributes from multiple organizations.

Since the cloud applications are accessible widely through various devices, authenticating with simple userID/password should be deprecated as a solution.

Enterprises should plan for using stronger authentication. Consumers should consider strong authentication for the original identity confirmation and determine the type of credential that meets their risk requirement (RSA token, OTP over SMS or phone, Smartcard/PKI, Biometrics etc.). 

This then will enable identifiers and attributes with a strong level of authentication to be passed to the cloud application and better risk decisions to be made about access management by the entitlement layer.

Enterprises should plan for using risk-based authentication for their cloud applications. This type of authentication is based on device identifier, geolocation, ISP, heuristic information, etc. 

Cloud application should not only perform authentication during the initial connection but should also perform risk-based authentication based on the transactions being performed within the application.

Cloud applications should also leverage convergence of standards where applicable, such as SAML and OAuth. 

As mentioned earlier in this section, cloud service API’s are designed to accept tokens and not passwords, so a user trying to access cloud services from their mobile device first has to authenticate to their Identity Provider (today, probably their enterprise), and a SAML assertion is generated and passed on to cloud service provider. 

Upon successful validation of the SAML assertion, an OAuth token is generated and passed on to the mobile device. The mobile device then passes on these tokens to access cloud services REST based API’s.

REST - Representational state transfer, a style of software architecture for distributed hypermedia systems

10.3.2 Authorization and Access Control

Authorization in broadest terms refers to enforcing the rules by which access is granted to the resources. The Entitlement process implements business policies that in turn translate to access into enterprise resources.

For cloud-based applications, authorization should not only be performed based on the content but also by the context.

For user-centric authorization model, the user is the Policy Decision Point (PDP). The user determines the access for their resources, and the service provider acts as Policy Enforcement Point (PEP). OAuth is widely used for this model, and User Managed Access (UMA) is also an emerging standard in this space.

For an enterprise-centric authorization model, the enterprise is the PDP or Policy Access Point (PAP), and the service provider acts as PEP. In some cases, enterprises implement cloud security gateways for PEP. The enterprise customer should consider use of XACML and centralized policy management.

Cloud applications could be leveraging multiple types of services. Some services could be legacy applications exposed as web services utilizing middleware, or the web services could be native cloud web services. 

The diversity of the delivery supply chain, although abstracted by the web service interface, may complicate the governance process. Design time governance includes defining the services, developing the services, registering the services, and implementing policy requirement for accessing these services.

Runtime governance includes discovering the services, implementing security restrictions for calling the services, enforcing security restrictions for accessing the service, and auditing all access. 

Use open standards like W3C WS-policy for defining security and management policy assertions, WS-security for enforcing access restrictions, WS-trust for implementing Secure Token Service (STS) to validate and issue tokens, and exchange token formats, etc.

WS - Web Service

There are different types of authorization models namely Role-based, Rule-based, Attribute-based access, Claims-based, and Authorization-based access control (such as ZBAC). Enterprises that already own Web Access Management (WAM)solution should leverage these solutions to seamlessly protect cloud applications as well. Most of WAM products support Rule and Role-based access controls.

ZBAC Described in publications by Alan Karp, HP Labs
Application architects and designers should plan to migrate to Rule-based using claims and attributes as the source for those rules via the Entitlement process described above, and depreciate other legacy solutions.

When using attribute-based access control, the Identity Provider (IdP) passes attributes to the Cloud Service Provider for enforcement. Identity Providers should ensure:

(A) Attributes attached to the identity need not strictly refer to the user identity such as first name, last name, email address, etc. It could also include IP address, location information, group affiliation, phone number, etc.

(B) Care should be taken for sharing attributes that directly identify the user as it raises privacy issues.


(C) Enterprises should also plan for the attribute complexity for making access control decisions. They should know which attribute provider to contact for a particular attribute-based on authoritativeness. There are attribute aggregators that enterprise can leverage. This could either complicate or simplify the trust. Enterprises should take into account conflict resolution complexities, handling incomplete data, etc.

(D) Enterprises should also take into account attribute extensibility like validation (verifiability), terms of use, date, etc.

(E) Enterprises should take into consideration privacy, attribute release policies, and consent. 

  Examples include EU privacy directives, State and local laws, etc. Location of the IdP, CSP, and user (jurisdictional issues) should also be factored into this decision.

(F) Only minimal information required for the access control should be released.

(G) Enterprises should ensure attributes that are not identity-centric are also supported.

(H) Enterprises should ensure that access policies and entitlement policies are manageable in addition to being technically enforceable. Potential solutions include the use of policy automation technologies (maybe tied into the PaaS application mash-up tools).


The main goal of Claims-based access control is controlled sharing of the information. The claims are based on the context of the transaction. When planning to use claims-based authorization, an enterprise should consider:

(A) Usage of meaningful claims (verified email address instead of just email address)

(B) Type, surety, freshness, and quality of the claim (if the claim is cached outside of claims provider then the freshness of the claim is lost).

(C) Appropriate authority of the claims based on the context, e.g., a telecom company having authority to verify your phone number, an email provider having authority to verify your email address, etc.

(D) Utilization of claim brokers where possible as they could be used for abstraction from various claims providers, e.g., they could create a package of claims at desired confidence levels and create a central point for user permission

(E) Minimal release of claim as required by the transaction

The cloud application could also be a mash-up of other cloud applications running on the same or different service providers. The enterprise should plan for how the users are authenticated seamlessly across all these cloud applications and how the users’ profiles such as group association, entitlements, roles, etc. are shared across these cloud applications for granular access controls. Enterprises are recommended to use open standards for this use case (SAML, OAuth, XACML, etc.).

10.3.3 Administration/Management

Identity Management (IDM) within the enterprise is mainly focused on managing users (provisioning) and managing access policies (for enterprise applications). 

IDM is a very important component of IdEA for not only providing timely access to the users but also timely revocation of access when the user leaves or timely management of access when the user moves to a different role.

Within the enterprise, identity management is usually tightly integrated and is directly connected to the data stores (users, policies, etc.); in most deployments, it is also heavily customized. 

Due to the distributed nature of cloud applications applying the same principle becomes a non- starter, as IDM might not have direct access to the data stores on the service provider. 

Moreover, there are no standard API’s for provisioning. Many service providers have not adopted Service Provisioning Mark-up Language (SPML).

IDM in the context of cloud computing should not only manage the user identities. It should extend this to manage cloud application/services identities, access control policies for these cloud applications/services, privileged identities for the applications/services, etc.

Current federated provisioning is implemented with proprietary API’s exposed by the service provider. The PUSH model that is followed by the enterprise IDM will not work with cloud applications as it might overload the service providers.

The new emerging standard is Simple Cloud Identity Management (SCIM) with the main goal of this standard to make the management of identities cheaper with easier and faster implementation. 

The secondary goal is to ease the migration of user identities into and out of the cloud. SCIM is simple because it uses well defined core schema, cloud-friendly because it uses RESTful API as supported by many cloud service providers, and supports identity management because it works with existing protocols such as SAML, OpenID connect etc. 

Based on these facts (at the time of writing), SCIM might get adopted as an industry standard for identity provisioning.

Some of the challenges that enterprises consider for identity management are:

(A) How to sync changes about identities/access between enterprise -> cloud, cloud -> cloud, cloud -> enterprise

(B) How to de-provision identities and access across the enterprise and cloud

(C) How to author/update/manage access policies in a manageable, scalable, low-maintenance, low-cost way.

The current solution for many enterprises is the adoption of a hybrid IDM solution that spans both enterprise and cloud.

Access policy management is a major application security challenge and often requires maximum security automation as a solution: Security policy automation is particularly important for cloud computing because cloud users will demand support for regulatory compliance policy management from cloud providers, but will at the same time judge the financial ROI by the same measures as they do for cloud computing in general, i.e., by how much it cuts their up-front capital expenditure and their in-house manual maintenance cost.

10.3.4 Audit/Compliance

Enterprises using cloud services should answer three fundamental questions:

1. What cloud resources does a user have access to ?

2. What cloud resources does a user actually access ?

3. Which access policy rules were used as a basis for a decision ?

With current cloud deployments, enterprise customers have very limited visibility into cloud service providers for audit data. An enterprise needs access to this data not only for meeting the business driven compliance but also to meet industry regulations and also deal with fraud disputes.

Currently the IDM market is moving towards Identity and Access Governance (IAG) market. Enterprises should also consider use of SIEM (Security Incident & Event Management) tools to correlate cloud application access log data and your policy data to generate policy compliance reports as well as use of auditable industry standards such as ISAE 3402/SSAE 16, HIPPA, DSS PCI, ISO27002, etc.

General IdEA considerations for cloud application security are:

Identity, Entitlement, and Access management should not be an afterthought; rather, it should be integrated into an application’s SDLC starting with the requirements gathering.

(A) During the design phase consider how to control access to the application using a Claims-based access whenever possible.

(B) Consider using tools like SAPM (Shared Account Password Management) for managing highly privileged accounts within the application. This allows for segregation of duties and least privilege.

(C) If the enterprise already has web access management tools, ensure that those tools can be extended into a cloud environment, i.e., by adding a SAML capability.

(D) Cloud applications might need to leverage services offered by service providers such as logging, database connectivity, etc. Most service providers expose these as web services or API. Access to these services could be controlled by OAuth tokens. Thus cloud applications should take into consideration supporting various token types like OAuth, API keys, etc.

(E) Ensure that you follow an agile development process and that the application is built into modularized components. This allows the application to leverage new emerging standards in the future like Mozilla’s browserID, Microsoft’s U-Prove, and Kantara Initiative’s UMA (User Managed Access).

Be aware of the threats for cloud applications, which include:

(I) Spoofing : Assuming the identity of another user

(II) Tampering : Modifying the data on transit

(III) Repudiation : Denying the origin of transaction (request or response)

(IV) Information disclosure : Unauthorized disclosure of data

(V) Denial of Service : Affecting the availability

(VI) Elevation of Privilege : Assuming the role or entitlement

These threats could be addressed by IdEA as follows:

(I) Spoofing. Authentication (strong authentication)

(II) Tampering. Digital Signature or Hash (As used in SAML assertions)

(III) Repudiation. Digital signature (as used in SAML assertions), audit logging

(IV) Information disclosure : SSL, encryption (Strictly not IdEA specific)

(V) Denial of Service : Security Gateways (Web Services security gateways)

(VI) Elevation of Privilege : Authorization (OAuth)

10.3.5 Policy Management

Access policy management (often called “authorization management” when done entitlement-centric) is the process of specifying and maintaining access policies to resources in access policies, based on attributes including caller-related identities and related attributes (e.g. caller authentication), context attributes (e.g. environment/business/IT related), and target-related attributes (e.g. throttling or QoS access policies)

Entitlement management forms part of authorization and access management, which additionally includes authoring and maintaining policies for attributes that are not identity-related but are required (in addition to identity and its attributes) to make a meaningful access decision.

Entitlement/Authorization also takes attributes into account that are not related to an identity, e.g.:

(A) General state of the IT landscape, business/business process, interconnection of IT systems or business processes, or environment, etc. (e.g. crisis level, emergency situation)

(B) Other decisions made by other entities (e.g. approvals, prior decisions)

(C) Attributes related to the protected target resource (e.g. QoS or throttling policies)

Typically the authorization management, decisioning, and enforcement process is performed in one of three places:

1. Using a central/external Policy Enforcement point / Policy Server / Policy-as-a-Service

2. Embedded as part of the Cloud application

3. Using an Identity-aaS or Persona-aaS (an entities Persona is its Identity with selected attributes).

10.3.5.1 Cloud Issues vs. Policy Management

Authorization/entitlement management for cloud faces several issues.

Firstly, entitlement management for cloud has the specific issue that cloud subscribers often do not have sufficient control over technical access policy decision-making and enforcement in the cloud infrastructure.

Most cloud providers today do not offer subscriber-configurable policy enforcement points (e.g. based on the OASIS XACML standard), and cloud providers naturally cannot pre-configure subscriber-specific policies for subscribers (because they are subscriber-specific).

Secondly, an entitlement management complexity for interconnected clouds (mash-ups) is that access needs to be controlled for the interconnected cloud mash-ups, and not only for each individual cloud node. This means that policies need to be authored for service chains and delegation across the interconnected cloud mash-up in mind.

10.3.5.2 Authorization Management Best Practice

(A) Establish whether an identity/entitlement-centric perspective is the best way for your organization to author and maintain access policies; in many cases a protected-resource-centric perspective may be easier to author and maintain because the goal is often to protect resources, and policies are often distributed to the protected end-systems for automatic policy enforcement (e.g. in entitlement/authorization management systems). In those cases identity is merely one attribute in an access policy that is written with the goal of enforcement at the protected end-system in mind.

(B) Make sure that policies are specified in a manageable form. This includes specifying policies that are generic, specified at a sufficiently high level of abstraction, and expressed close to the understanding of the relevant organization/business/humans. Mechanisms and tools are available to generate the detailed technical access policy rules from such a manageable form (e.g. using model-driven security policy automation).

10.3.5.3 Architectures for Interfacing to Access Policy Providers

Policy Decision/Enforcement Points (PEP’s/PDP’s) using standard protocols (e.g. XACML) or proprietary protocols (e.g. direct web service or other middleware calls) can access policy servers (which contain the rules for an interconnected cloud mash-ups). 

The architecture is usually one (server) to many (PDP/PEP’s) if the policy covers a single trust domain (e.g. an enterprise intranet). 

However, in more large-scale deployments, there can be several federated policy servers that service many different PDP/PEP’s. Several access management products now support authorization management rules (e.g. in XACML) that can be used to express entitlements for identities. 

In addition, several authorization management products are available that can be used to author authorization policies from a more target-resource-centric perspective.

10.3.5.4 Provisioning of Access Policies

In addition to identity + attribute provisioning, access policies need to be provisioned (see above “10.3.5.3 Architectures for Interfacing to Access Policy Providers”). Moreover, non-identity attributes need to be provisioned, e.g., from directory services or other attribute sources. Both need to be provisioned to the PDP/PEP’s, and timeliness and correctness play a critical role.

10.3.5.5 Managing Access Policies for Cloud

Making authoring and maintaining access policies manageable is a major challenge; there are typically simply too many technical rules to manage, used policy languages and attributes that do not match the understanding of human administrators, technical rules that need to be updated frequently to remain correct after each time systems change (e.g. for agile cloud mash-ups), and it is hard to establish that the level of confidence/assurance of the technical policy enforcement matches the intent of the human administrator. 

As a consequence, it is critical to carefully plan the tools and processes to make this access policy authoring/updating process manageable through automation.

Current solutions include automated approaches to turn high-level security policies into (low-level) technical access rules, including:

(A) Model-driven security (NIST IR 7628), the tool-supported process of modeling security requirements at a high level of abstraction, and using other information sources available about the system (produced by other stakeholders). 

These inputs, which are expressed in Domain Specific Languages (DSL), are then transformed into enforceable security rules with as little human intervention as possible. 

It also includes the run-time security management (e.g. entitlements / authorizations), i.e., run-time enforcement of the policy on the protected IT systems, dynamic policy updates, and the monitoring of policy violations.

(B) Clustering technical access rules into similar groups to reduce the complexity

(C) Visual attempts to make technical policies easier to understand

10.3.5.6 Authorization in the Cloud Best Practice

(A) Carefully consider whether a protected-resource-centric perspective to authoring access policies may be more suitable for your environment than an identity-centric perspective. 

(B) Ensure manageability of access policies, especially for dynamically changing cloud mash-ups. This includes consistency of policy authoring, policy distribution, enforcement, and update. 

Consider the use of automated tools and approaches (e.g. model-driven security) to generate the technical access rules needed for policy enforcement.

(C) Designate clear responsibilities for policy management and policy auditing.

(D) Ensure your cloud provider offers authorization management PEP’s/PDP’s that can be configured with the subscriber-specific authorization policy, and that your policy server can interface correctly with the policy selected.

(E) Consider the use of “policy-as-a-service” as the policy server if you need a central policy server for a cloud mash-up.

Current best practices for selecting authorization services:

(A) The most important authorization management services feature is cloud subscriber policy manageability, because managing access policies is the biggest challenge around authorization.

(B) Services should allow for as-automatic-as-possible technical policy generation (and update!) from human-intuitive, generic security policy requirements.

(C) If politically viable for your organization, and if available for you, “policy-as-a-service” should be considered as an option of outsourcing the policy authoring and updating. Most likely this will be acceptable within community clouds where the “policy-as-a-service” is offered to a closed community.

(D) Ensure services have an import and/or export function into standards such as OASIS XACML.

(E) Ensure services can interface with PEP/PDP’s installed in the cloud infrastructure and with Policy Monitoring Points for incident monitoring/auditing.

10.4 Application Penetration Testing for the Cloud

A penetration test involves the process of evaluating the residual vulnerabilities present in the application or system layer that can be potentially exploited by an external or internal hacker with malicious intent. The test would typically involve active analysis of the surfaces of the application or system as a "black box" and attempts to identify typical vulnerabilities that can be prevalent as a result of bad programming or hardening practices.

Open Web Application Security Project (OWASP) in its OWASP Testing Guide V3.0 recommends nine types of Active Security Testing categories as follows:

1. Configuration Management Testing

2. Business Logic Testing

3. Authentication Testing

4. Authorization testing

5. Session Management Testing

6. Data Validation Testing

7. Denial of Service Testing

8. Web Services Testing

9. Ajax Testing (RIA Security Testing)

The above categories of Security testing will be equally applicable for an application that is going to be deployed on the Cloud as the nature of Application Vulnerabilities from a technical perspective is not going to change. 

However, depending upon the type of Cloud Deployment Model additional threats vectors (that would have not come into the equation for a non-cloud deployment) could be induced.

An example of such a threat vector in a SAAS deployment would be induced by multi-tenancy when the same application run time is being used to service multiple tenants and their segregated data.

Additional classes of testing will need to be developed and included to address threats that arise as a result of the deployment model of the Application in the Cloud. An illustration of the same is provided in the table below.

10.5 Monitoring Applications in the Cloud

As with other aspects of cloud security, what and how one monitors a cloud-based system varies with the type of cloud under consideration. What it means to monitor applications in the cloud and how to monitor different types of cloud applications are explained in detail below.

10.5.1 Application Monitoring in the Cloud: Give and Take

For this document, we are limiting “monitoring” to focus on application security monitoring. In particular, the following categories of metrics should be addressed:

(I) Log monitoring : It is not just to archive logs for compliance purposes. Understand the potential output that could be sent to these logs, and monitor for actionable events. An application logging errors is of zero use unless a process exists to detect and respond to those errors.

(II) Performance monitoring : This plays a large factor in shared computing. A significant change in the performance of one application could be the symptom of another customer using more than their fair share of a limited resource (e.g., CPU, memory, SAN storage), or it could be the symptom of malicious activity either with the application being monitored or with another application in the shared infrastructure.

(III) Monitoring for malicious use : This is a blend of auditing and monitoring required to be successful. The enterprise must understand what happens when a malicious user attempts to gain access, or use permissions that they do not have. Audit logs must log failed (and successful) login attempts. Do data-validation functions log anything? If an application experiences a significant increase in traffic load, is an alert created anywhere?

(IV) Monitoring for compromise : Here the key is how quickly and efficiently an organization responds to the compromise. Depending on the complexity of the application, determining compromise might be relatively easy (e.g., “User A is logged in twice”) or may require more effort (e.g., developing heuristic algorithms to monitor data usage). This is a good example of an item that, when addressed earlier in the SDLC, can be easier to manage.

(V) Monitoring for policy violations (especially access control) : It is also important to monitor and audit how a Policy Decision Point came to a decision, i.e., which policy rules were applied to make a specific access decision. This is in line with a general policy-driven monitoring approach that avoids the typical monitoring problems of false-positives and incident overload.

These are some of the key concepts behind log monitoring – the “take” side of the equation. Equally important, the developer of an application is responsible for the “give” side: His application must provide a solid logging subsystem to allow the monitoring system to efficiently do its job:

1. Easily parsable : Logs should be written in a format that can be easily parsed by a separate system. A good example would be using a well-known and accepted format such as XML. A bad example would be writing log entries of non-delineated, multi-line text output.

2. Easily readable : Unless writing logs in a binary format that will, without a doubt, never be directly read by a human, a log entry should be understandable by a person with a technical background, familiar with the application.

3. Well documented : It is not enough to just write logs to a file. Error codes need to be documented and should be unique. If a particular log entry has a known path to resolution, document the resolution, or provide a reference to it.

10.5.2 Monitoring Applications in Different Cloud Types

With an IAAS-based application, monitoring the application is almost “normal,” compared to “legacy” applications deployed in non-shared environments. The customer needs to monitor issues with the shared infrastructure or with attempted unauthorized access to an application by a malicious co-tenant.

Monitoring applications deployed in platform-clouds requires additional work. Unless the platform provider also provides a monitoring solution capable of monitoring the deployed application, the customer has two choices: Either write additional application logic to perform the monitoring tasks within the platform or send logs to a remote monitoring system, be that the customer’s in-house monitoring system, or a third party service.

As SAAS-based applications provide the least flexibility, it should not come as a surprise that monitoring the security of these types of applications is the most difficult. Before using a SAAS product, customers must have a thorough understanding of:

(A) How does the provider monitor their applications?

(B) What type of audit, log, or alert information will the provider send to the customer? Does the customer have the ability to select what information they will receive?

(C) How will the provider transmit this information to the customer? (Twitter? Email? Custom API?)

One final point when considering application security monitoring in the cloud: While providers (or 3rd party cloud monitoring services) may have built a monitoring system to monitor a customer’s applications, those monitoring systems are monitoring hundreds, if not thousands, of customers. 

The provider, as a business, wants this monitoring system to work “well enough.” If the customer has the resources, running his/her own monitoring system that monitors just his/her applications will almost always be more responsive and more informative than that of a cloud provider.

10.6 Recommendations

10.6.1 Security Assurance Recommendations

(A) Functional and regulatory security and privacy requirements are defined that meet the needs of cloud development and/or deployment.

(B) A detailed assessment of the attack vectors and risks in the cloud environment are understood, and the mitigations strategies are integrated into the requirements.

(C) An impact assessment for all risks and attack vectors is undertaken, and documented, together with the potential for loss or damage from each scenario.

(D) Security and privacy requirements and efforts should be prioritized on likelihood and impact.

10.6.2 Risk Analysis Recommendations

(A) Risk analysis of the applications for security and privacy (confidentiality, integrity and availability) are undertaken, and threat models should be built and maintained.

(B) Risks from the perspective of development and deployment in the cloud should be analyzed and related threat models maintained.

(C) Attack vectors and impact analysis specific to cloud architectures should be catalogued and maintained.

(D) Traceability between security assurance features and all identified risks / threats should be maintained.

10.6.3 Architecture Recommendations

(A) Secure software architecture frameworks should be developed and maintained.

(B) Cloud computing architecture patterns that explicitly mitigate threats (for example, from “Open Security Architecture” or TOGAF/SABSA) should be used.

(C) Reusable building blocks in the application architecture are available for mitigating commonly known security and breach scenarios.

(D) Cloud-specific secure data architectures should be used to enhance the chosen security architectural framework, which will address cloud specific issues and threats, such as:

  (I) The monitoring of dynamic database servers

  (II) Understanding where the database is exactly hosted at any point in time

  (III) Centrally logging all activity, across disparate (potentially global) systems to provide a holistic view of the application and flag suspicious events

  (IV) Define where encryption must be used (see Domain 12)

  (V) Provide adequate segregation of duties within the system, the data, and all privileged activities by third parties, capable of being monitored by staff of the organization that owns the data 

10.6.4 Penetration Testing Applications on Cloud Recommendations

(A) Carry out regular Web Application Penetration Testing to check for OWASP Top 10 vulnerabilities

(B) Categorize vulnerabilities based on criticality / Impact and have a process for remediation.

(C) Carry out manual tests from a multi-tenancy perspective to validate that privileges cannot be escalated or data segregated based on lack of session enforcement.

(D) For applications being migrated to an IAAS or PAAS environment, a security assessment needs to be carried out to ensure that the underlying security controls such as VM zoning and segregation, virtualization security, etc. has been effectively put in place and does not pose a risk to the application ecosystem.

--== || END || ==--