Continuing from where we left off in Part 1, lets start exploring the risk management framework for a little more in this post.

III. RISK MANAGEMENT FRAMEWORK

Since the actors, outlined in Part 1 - Roles and Responsibilities, have varying degrees of ownership and influence in the cloud space, establishing security controls becomes a shared or split responsibility among the actors. From the cloud consumer’s angle, security should not be an impediment to embracing public cloud solutions. With that idea in mind, the risk management framework provides a step-by-step approach to identifying and documenting risks in general and validating as to what are acceptable risks to a consumer in relation to the compliance model, so that the cloud consumer can place a level of confidence in moving all the acceptable web applications/systems to the public cloud.

The following diagram shows the NIST’s cloud-adapted risk management framework (CRMF)[13]:

1) Categorize Information Systems

This step enables organizations to consistently map the security impact levels to the types of information and information systems. The type of information includes private, confidential, sensitive etc. The type of information systems includes mission critical, mission support etc. An information system processes one or more information types as input, output, and/or for internal needs.

The security objectives and the potential losses for information and information systems could be broadly classified in terms of the classical security goals as follows [19]:

a) Confidentiality

A loss of confidentiality is the unauthorized disclosure of information.

b) Integrity

A loss of integrity is the unauthorized modification or destruction of information.

c) Availability

A loss of availability is the disruption of access to or use of information or information systems.

Potential impact to an organization in case of a security breach could be modeled in terms of low, medium, and high ratings.

a) Low Impact

At this impact level, the loss of confidentiality, integrity, and availability would not impact the primary business objectives of the organization. There will be some degradation in mission capability and minor damage to organizational assets, but this would not stop the organization from meeting its objectives.

b) Medium Impact

At this impact level, the loss of confidentiality, integrity, and availability would impact the primary business objectives of the organization. There will be significant degradation in mission capability and significant damage to organizational assets and/or operations.

c) High Impact

At this impact level, the loss of confidentiality, integrity, and availability would severely impact the primary business objectives of the organization. There will be major degradation or loss of mission capability and major damage or loss of organizational assets and/or operations.

One way to identify information types could be based on the lines of businesses of an organization. For example, lines of businesses could include marketing, sales, manufacturing, R&D, learning & performance, dealer management etc.

Since every organization has a set of resource management areas such as information technology & management, human resources management, and financial management, care must be taken to include such resource management functions and their information types as well. For example, some of the information types within the human resources management function could be HR strategy, staff acquisition, employee performance mgmt., employee relation, benefits mgmt., and compensation mgmt., etc.

Once the information types and information systems are identified, the next step is to assign potential impact of compromises to confidentiality, integrity, and availability as outlined in the following table:

For example, the information type of an organization’s corporate website for public consumption does not have any confidentiality requirement because everything on the website is for public consumption. Therefore, the security category could be defined in terms of the C/I/A triad as follows:

$$Security Category_{public information} = \\ \{(confidentiality, not applicable), (integrity, medium), \\ (availability, medium)\}$$

After assigning security categories to all the information types that belong to a business area or a resource management function, all the information systems that support those functions must be mapped to those information types. This is a required step to aggregate the security category at the information system level. For example, a web-based contract renewal system could process two information types as follows:

$$Security Category_{contract information}= \\ \{(confidentiality,medium),(integrity,medium),(availability,low)\}$$ $$Security Category_{administrative information}= \\ \{(confidentiality,low),(integrity,low),(availability,low)\}$$

The resulting aggregate security category for the information system will be the maximum of the above two categories in each of the C/I/A triad as follows:

$$Security Category_{web contracts system}= \\ \{(confidentiality,medium),(integrity,medium),(availability,low)\}$$

When aggregating security categories, it is also beneficial to understand the context of the information system in relation to other systems – standalone, connected process flow etc. Without understanding the overall context, assignment of security categories could be erroneous.

At the end of step 1, categorization of information systems, the organization must have a spreadsheet with all the information systems that are being evaluated for the suitability of moving over to the public cloud. This spreadsheet will contain all web-based information systems and their aggregate security categories mapped to their business area or resource management functional area.

2) Identify Security Requirements

NIST defines seventeen security-related areas with regard to protecting the confidentiality, integrity, and availability of information systems and the information processed, stored, and/or transmitted by those systems [20]. Those security-related areas are access control, audit and availability, certification, configuration management, contingency planning, identification and authentication, incident response, maintenance, media protection, physical and environment protection, planning, personnel security, risk assessment, systems and services acquisition, system and communications protection, system and information integrity.

In the case of PaaS and SaaS, the majority of the selection of the security controls falls under the cloud agents such as the cloud provider, cloud broker, and cloud carrier. These cloud actors are required to address the cloud consumer’s areas of concerns as proposed by the NIST’s Security Reference Architecture [13] as follows:

• Risk Management
  • Risk analysis
  • Risk Assessments
  • Vulnerability assessment
  • Incident reporting and response
• Business Continuity
  • Disaster recovery plans
  • Recovery plans
  • Recovery Point Objective (RPO)
  • Recovery Time Objective (RTO)
• Physical Security
  • Physical and environmental security policy
  • Contingency plan
  • Emergency response plan
  • Facility layout
  • Security Infrastructure
  • Human Resources
  • Visual inspection of the facility
• User account termination procedures
• Compliance with National and International/Industry standards on security
• Transparent view of the security posture of the cloud provider, cloud broker, and the cloud carriers.

The good news is that an organization does not have to spend the time and money to create the combination of security components and how they map to responsibilities of various cloud actors from scratch. The CSA provides a comprehensive cloud control matrix based on the Trusted Cloud Initiative Reference Architecture (TCI-RA) as shown below:

This excel sheet can be downloaded from [14]. What is good about this excel sheet is that it spells out the responsibility for establishing security controls among the various cloud actors. The NIST Security Reference Architecture (SRA) has adopted the TCI-RA and has created 346 security components under three different domains such as Business Operation Support Service (BOSS), Information Technology Operation Support (ITOS), and Security and Risk Management (S&RM) and four different service layers such as infrastructure services, information services, application services, and presentation services. Therefore, this is a streamlined, transparent risk management process where the responsibilities are clearly delineated as shown in the table below:

In the above chart, “X” indicates that the respective security component has to be implemented by the actor; “A” indicates that the security component has to be implemented internally; “B” indicates that this is for “business broker only” and there is no direct association with the consumer; blank cell indicates that the security component is not needed for securing the cloud platform.

There is a mapping of security components from the TCI-RA to the NIST 800-53 family of security controls in the “800-53 Family” column in the spreadsheet. In the above example, BOSS→ Compliance→Intellectual Property Protection is mapped to Access Control (AC). Similarly, there is a mapping to Awareness and Training (AT) as well.

Using the above methods, we now have a way to map security components to cloud deployment models with an eye towards which actor is responsible for what.

The question now becomes as to what security components are absolutely needed by the consumer to have a secure move to the public cloud. This is where the combination of the last step – categorize information systems – and the security index system (SIS) comes in. SIS defines five index values from zero to four as follows [13]:

Based on security category obtained from applying step one, the cloud consumer could go on to applying security index values to all the security components as shown below:

_{* Ag = Aggregate score}

By following these steps, all the cloud actors know exactly what security components are needed for the migration and who is responsible for implementing them. This will also give an idea about choosing the right service model (PaaS or SaaS) for the web application in question.

CSA has a specific gap analysis model where the cloud actors could go about selecting the right set of security components for their cloud platform based on their compliance needs such as Health Insurance Portability and Accountability Act (HIPAA), Payment Card Industry Data Security Standard (PCI DSS), Gramm-Leach-Bliley Act (GLBA), and Sarbanes Oxley (SOX) etc.

For example, if an organization accepts, captures, stores, transmits, or processes credit/debit card data through one of its e-commerce application, the organization is expected to follow PCI DSS.

If the organization wants to migrate its application to the public cloud, all the relevant cloud agents – cloud consumer, provider, broker, carrier, and/or auditor – are expected to have all the necessary security components along with the controls in place to support the PCI DSS standard. To conform to PCI DSS standards, the cloud actors have to ensure that the following security components are implemented as follows:

_{* Merchant = Cloud Consumer; PAN = Personal Access Number}

By the same token, similar security requirements can be gathered for HIPAA, GLBA, and SOX.

At the end of step two, all the relevant cloud actors must know the baseline security controls and any supplemental controls needed due to compliance needs of the cloud consumer. The selection of controls could be based on the in-house technical expertise of the cloud consumer along with its assurance needs.

3) Select the Cloud Ecosystem Architecture

Based on the business requirements and the security requirements outlined in the previous section, a cloud consumer could make a decision to either go with a single cloud provider or a set of cloud providers with the help of a broker as shown in the diagram below:

Imagine a scenario where a consumer is in need of a web content management solution, a video encoding service so the consumer could post videos across a wide variety of social websites such as Facebook, Twitter etc. and a Web development platform based on the “Spring” framework. In order to avail all of the above services, the cloud consumer might need to seek the help of three different cloud providers as follows:

• Cloud Provider A – A SaaS-based Web Content Management Solution. E.g. SpringCM
• Cloud Provider B – A SaaS-based Video Encoding services. E.g. Brightcove
• Cloud Provider C – A PaaS-based Web development platform based on the Spring Framework. E.g. CloudFoundry.

In order to understand and implement all the security controls required to support the assurance needs, the cloud consumer has to deal with multiple Service Level Agreements (SLA) across the various cloud providers. Depending upon the technical expertise and the number of personnel supporting such efforts, the task of managing multiple SLAs could be daunting. This is where cloud brokers come in. As shown in the above figure, the cloud consumer is only signing one SLA with the broker leaving the entire responsibility of managing the business and security requirements across all of the cloud providers with the broker.

4) Assess the Cloud Services

Based on the set of security controls selected in step two and the ecosystem architecture selected in step three, the cloud consumer is well on the way to defining the service level agreement (SLA) with the intended cloud agent(s) – broker or provider(s). The SLA details the levels and types of services that are to be provided, including but not limited to the delivery time and performance parameters. A mind map of an SLA is shown below [13]:

It is the responsibility of the cloud consumer to ensure that default contracts are not accepted when setting up the master service agreements. From a provider’s perspective it may be easy, but the agreement might not capture all of the assurance needs of the consumer.

5) Authorize Cloud Services

In this step, the cloud consumer must define a set of metrics that can validate the expectations defined in the service contract as stated in the previous step. The NIST Cloud Service Metrics document [21] defines a set of metrics for cloud services. An example is as follows:

• Service Availability – Percentage of uptime of resource over a period of time where: $Service\_Uptime\_Percentage = \frac{Qualified\_Uptime\_Total}{Observation\_Time\_Total} \times 100$

  • For example, the SLA could state that the objective of the service availability metric to be: $Service\_Uptime\_Percentage=99\%$

A similar set of metrics must be defined in advance to ensure a proper delivery of services by the cloud brokers/providers. For example, “the number of concurrent users and the response time of the platform/service” could be one of the metrics.

6) Monitor the services provided

This is the crucial step to ensuring that the security controls that have been put in place as a part of securing the cloud service are functioning as intended and maintain the necessary security posture. Continuous monitoring enables the cloud agents to supplement security controls in case there is a need. A strategy for continuous monitoring could define as to how security and privacy controls will be monitored over time as follows:

• Frequency of monitoring activities
• Rigor and extent of monitoring activities
• Data feeds to be provided to the consumer

The continuous monitoring strategy allows the consumer to see whether the SLA terms are met on an ongoing basis.

Together, these six steps must be able to prepare an organization to successfully move to the public cloud for their Web application needs.

I’ll contiunue my discussion in the next post.

---

[11] OSA, “SP-011: Cloud Computing Pattern,” ed, 2013.

[12] NIST. (2011). Guidelines on Security and Privacy in Public Cloud Computing. Available: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909494

[13] NIST. (2011). NIST Cloud Computing Security Reference Architecture (DRAFT). Available: http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/CloudSecurity/
NIST_Security_Reference_Architecture_2013.05.15_v1.0.pdf

[14] CSA. (2012). Cloud Controls Matrix v1.4 : Cloud Security Alliance. Available: https://cloudsecurityalliance.org/download/cloud-controls-matrix-v1-4

[15] B. Damele. (2009). Advanced SQL injection to operating system full control. Available: https://http://www.owasp.org/images/d/dc/AppsecEU09-Damele-A-G-Advanced-SQL-injection-slides.pdf

[16] T. Shimeall. (2013). Tactics and Penetration Testing. Available: https://blackboard.andrew.cmu.edu/bbcswebdav/pid-449058-dt-content-rid-3403035_1/xid-3403035_1

[17] T. Shimeall. (2013). Web Hacking. Available: https://blackboard.andrew.cmu.edu/bbcswebdav/pid-449052-dt-content-rid-3403026_1/xid-3403026_1

[18] T. Shimeall. (2013). Strategy. Available: https://blackboard.andrew.cmu.edu/bbcswebdav/pid-449058-dt-content-rid-3403035_1/xid-3403035_1

[19] NIST. (2008). Volume I: Guide for Mapping Types of Information and Information Systems to Security Categories. Available: http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf

[20] NIST. (2006). Minimum Security Requirements for Federal Information and Information Systems Available: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

[21] NIST. (2013). NIST Cloud Computing Reference Architecture Cloud Service Metrics Description. Available: http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/RATax_CloudMetrics_WAs_Docs/RATAX-CloudServiceMetricsDescription-DRAFT-20130621.pdf

[22] SAFECode. (2012). Practical Security Stories and Security Tasks for Agile Development Environments. Available: http://www.safecode.org/publications/SAFECode_Agile_Dev_Security0712.pdf

[23] J. Rockwood, “Choose Your Weapon Wisely: A handbook for determining the right software development method best suited for your team, client, and project (Independent Study Paper). Pittsburgh, PA: School of Computer Science, Carnegie Mellon University,” 2011.

[24] H. Kniberg. (2007). Scrum and XP from the Tenches - How we do Scrum. Available: http://infoq.com/minibooks/scrum-xpfrom-the-trenches

[25] M. Hüttermann, Agile ALM : lightweight tools and Agile strategies. Shelter Island, N.Y.: Manning, 2012.

[26] SecurityNinja. (2009). Secure Development. Available: http://www.securityninja.co.uk/secure-development

[27] OWASP. (2013). Projects/OWASP Java Encoder Project - OWASP. Available: https://http://www.owasp.org/index.php/Projects/OWASP_Java_Encoder_Project

[28] OWASP, “Category:OWASP Enterprise Security API - OWASP,” ed, 2013.

[29] D. Cornell. (2013). Web application testing: The difference between black, gray and white box testing. Available: http://searchsoftwarequality.techtarget.com/tip/Web-application-testing-The-difference-between-black-gray-and-white-box-testing

What does “going to the public cloud” mean to organizations? Other than the benefits such as reduced time to market, less upfront cost, rapid elasticity in terms of hardware and software resources, there are several security implications associated with such a move.

Today’s corporations not only create and manage web applications to make their corporate presence known on the Internet, but also invite their employees, suppliers, and dealers/retailers to conduct business online. At this point, the question becomes “Where should an organization stop or draw the line when making decisions to go to the pubic cloud?” Because the case for public-facing web applications going to the public cloud has already been made. The purpose of the paper is to discuss the viability of engaging public clouds for all web applications irrespective of the user segment that they support. This paper will also outline a development process and an environment for successfully deploying secure web applications on the public cloud.

I. INTRODUCTION

Cloud is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (For example, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction [1].

Infrastructure as a Service (IaaS) – In this cloud service model, the provider offers raw computing power, storage, and network infrastructure so that the consumer can load his/her own software components such as operating systems, applications, etc. in this infrastructure.

Platform as a Service (PaaS) - PaaS builds on IaaS and adds a set of software components such as operating systems, middleware products (application servers), and Web servers so that the consumer can develop and deploy applications in this platform.

Software as a Service (SaaS) - SaaS builds on top of PaaS and adds fully developed applications such as billing, collaboration, digital asset management, web content management, customer relationship management, point of sale applications to name a few.

To keep the scope manageable, this paper will only discuss SaaS and PaaS service models that are deployed using the public deployment model as highlighted in Figure 1. In the SaaS service model, an organization does not manage or control either the underlying infrastructure or the application that is deployed in the infrastructure. In the PaaS service model, the organization does not control or manage the underlying infrastructure, but does have control over the applications and data that are deployed in the infrastructure [2] as shown below:

Public Cloud means that both the underlying platform (PaaS) and the applications (SaaS) that are hosted on the infrastructure are available to the general public and is owned and/or operated by an organization selling those cloud services.

A. Roles and responsibilities in the Cloud

In order to study the security implications of using the public cloud for the intended service models, we have to understand the roles and responsibilities of the major actors in the cloud-computing domain [3] as shown below:

1) Cloud Consumer

A cloud consumer is an organization that makes use of the services provided by the cloud providers and brokers.

2) Cloud Provider

A cloud provider is an organization or entity that offers one or more cloud service models (IaaS, PaaS, SaaS) via one or more deployment models (public, private, hybrid) to interested parties.

3) Cloud Broker

As the application needs increase, the service models could get extremely complex. At this juncture, the cloud consumer could seek the help of a broker instead of going directly to the cloud provider. The cloud broker’s prime responsibility is to aggregate, enhance, or augment the services provided by one or more cloud service providers as shown in the diagram [3] below:

In the above scenario, the cloud consumer does not need to know about the underlying cloud providers since the service level agreement (SLA) will be created between the consumer and the broker. The cloud broker in turn will have SLAs with the cloud providers to satisfy the service levels that were committed to the consumer.

4) Cloud Auditor

The other important actor from the reference model is the cloud auditor. A cloud consumer, broker, or provider could employ an auditor to verify the security controls, privacy impact, and performance of services provided by the cloud provider.

5) Cloud Carrier

A cloud carrier is an intermediary that provides connectivity and transport of cloud services from the cloud provider to the consumer.

In the above scenario [3], a cloud provider could seek the help of a cloud carrier to provide dedicated and/or encrypted connections between the provider’s services and the consumer.

II. SECURITY IMPLICATIONS

As shown in Figure 1, more control or management of components means responsibility for security controls. In the PaaS environment, since the cloud consumer is responsible for building and deploying applications, layering in an additional level of security controls at the application level falls under the cloud consumer. By the same token, the cloud provider is responsible for establishing security controls for all the other components including the middleware environment. Since there is very little extensibility option available for the consumer in the SaaS model, the provider bares responsibility for establishing security controls for the entire environment.

A. Multi-tenancy

One of the major characteristics of cloud computing is this idea of multi-tenancy. Multi-tenancy implies the use of same applications and resources by multiple cloud consumers that may belong to multiple organizations. Multi-tenancy allows cloud providers to provide economies of scale, availability, segmentation, isolation, and operational efficiency to their consumers [4]. Since PaaS builds on the infrastructure provided by IaaS and SaaS builds on PaaS, there is quite a bit of technology components that work together to enable multi-tenancy as shown in the following diagram:

In the case of IaaS, the same hardware resources are shared across multiple consumers using virtualization technologies as shown in the diagram below:

a) Virtual Machine Manager (VMM) also known as Hypervisor

VMM is the virtualization layer that runs on top of a server platform and manages CPU, memory, hard disk, network, and other hardware resources of the server host [5].

b) VM

A Virtual Machine (VM) is a software implementation of a physical computing environment in which the operating system and other application programs can be installed and run [5]. VMs emulates a physical computing environment and requests hardware resources such as CPU, memory etc. from the VMM. Some of the most common virtualization solutions in the market today include Xen, VMware, Hyper-V, and Oracle.

In the case of PaaS, middleware and other components could be installed and run within the VM. In the case of SaaS, a wide variety of applications can be installed and run on top of the middleware that is running within the VM. Therefore, the cloud consumer of PaaS or SaaS ends up in a virtual machine as shown in Figure 5. Using the virtualization technology, cloud providers could virtualize the hardware/platform, desktop, software, memory, storage, data, and network to successfully orchestrate services such as IaaS, PaaS, and SaaS.

2) Data Breaches and Shared technology threats

One of the security challenges of the virtualization technology is how isolated these individual virtual machines are from each other. In other words, ensuring sufficient isolation between VMs is the security challenge. As shown in Figure 5, a security compromise in the virtualization layer means that all the VMs running on the virtualized layer are also compromised thereby resulting in data breaches. The Cloud Security Alliance (CSA) has elevated this threat ranking from 5 to 1 in 2013 [6]. There are several articles on the Internet such as [7] that demonstrate as to how a malicious VM could extract fine-grained information from a victim’s VM running on the same physical computer. There are also vulnerabilities present in the virtualization technology that could compromise the entire fleet of VMs running on the VMMs [8]. One of the articles, [9], demonstrates the use of VASTO (Virtualization Assessment Tool) within the Metasploit framework (MSF) to compromise VMware hosts with dictionary-based brute force login, man-in-the-middle (MITM) attack etc. VASTO in conjunction with MSF could be used to compromise hosts that are running Xen, Hyper-V, and Oracle VMMs as well.

a) Controls

With the help of the cloud provider, a third-party cloud auditor could be employed to assess as to how secure or vulnerable the target virtual environment is. There are several tools such as VASTO, Netwrix, Blackbird Auditor, and VMinformer that could be successfully employed to audit the virtual environment in terms of client, hypervisor, support, management, and internal components. These tools check for the presence of misconfiguration, missing security patches, bad network scheme, weaknesses in the VMM layer, and Storage misconfiguration [9].

3) More Threats

Along with data breaches and shared technology threats as outlined in the previous section, there are several other threats such as data loss, account or service traffic hijacking, insecure interfaces and APIs by the cloud provider, denial of service, malicious insiders, and insufficient due diligence [6].

a) Controls

To combat the various threats – see previous paragraph, establishment of a proper organization-wide risk management framework is essential. This is also part of doing due diligence that a cloud consumer is expected to carry out before embarking on the journey to move to the public cloud. Along with a solid risk management framework, there is also a greater need for securing web applications against a wide variety of attacks such as cross-site scripting (XSS), thread safety, access control, hidden form field manipulation, parameter manipulation, weak session cookies, SQL injection, insecure Web services, and Fail open authentication attacks [10]. Next set of sections will discuss the risk management framework along with a model for engineering secure web applications by taking the Open Security Architecture’s cloud computing security pattern, NIST’s cloud computing documents, CSA’s security reference model, OWASP’s web application security guidelines, SAFECode guidelines for Agile process frameworks into account.

I’ll contiunue my discussion in the next post.

---

[1] NIST. (2011). The NIST Definition of Cloud Computing. Available: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf

[2] B. Lyons. (2011). Applying a Holistic Defense-in-Depth approach to the Cloud. Available: http://www.niksun.com/presentations/day1/NIKSUN_WWSMC_July25_BarryLyons.pdf

[3] NIST. (2011). NIST Cloud Computing Reference Architecture. Available: http://www.nist.gov/customcf/get_pdf.cfm?pub_id=909505

[4] CSA. (2011). Security Guidance for Critical Areas of Focus in Cloud Computing V3.0 : Cloud Security Alliance. Available: https://cloudsecurityalliance.org/download/security-guidance-for-critical-areas-of-focus-in-cloud-computing-v3

[5] A. Desai. (2011). What is virtual machine (VM)? - Definition from WhatIs.com. Available: http://searchservervirtualization.techtarget.com/definition/virtual-machine

[6] CSA. (2013). The Notorious Nine: Cloud Computing Top Threats in 2013 : Cloud Security Alliance. Available: https://cloudsecurityalliance.org/download/the-notorious-nine-cloud-computing-top-threats-in-2013

[7] Y. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart. (2012). Cross-VM side channels and their use to extract private keys. Available: http://doi.acm.org/10.1145/2382196.2382230

[8] M. Schwartz. (2012). New Virtualization Vulnerability Allows Escape To Hypervisor Attacks – InformationWeek. Available: http://www.informationweek.com/news/security/app-security/240001996

[9] S. Chauhan. (2012). Virtualization Security: Hacking VMware with VASTO. Available: http://resources.infosecinstitute.com/virtualization-security

[10] OWASP. (2013). Category:OWASP WebGoat Project - OWASP. Available: https://http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project