Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 6: SECURITY ARCHITECTURE AND DESIGN

Principles of Computer and Network Organizations, Architectures, and Designs

Chapter 23. Cloud Security

Terry Komperda

Introduction

Before we can assess the current state of cloud computing security and then recommend best practices and ideas on how to improve it, we need to have a common understanding of what cloud computing is, the service models employed, and the related deployment models that customers choose when deciding to use the cloud. With this background, an analysis of the current state can take place and the additional security issues that need to be addressed can be defined to give cloud computing a long-lasting and secure future for providing secure services and business models for customers across the globe.

What Is Cloud Computing?

Cloud computing is a business model where resources are shared by multiple customers (users) at the network, host, and application levels. It provides the ability to scale thousands of systems as well as enable the scaling of bandwidth and storage space. Computing resources can be rapidly increased and decreased and resources can be released when no longer needed, providing for a great degree of elasticity. This model follows a utility company model whereby customers only pay for what they use and only for the time period that they actually use it.

Cloud Computing Services

Today, there are three main services provided by cloud computing. This is known as the SPI (SaaS, PaaS, IaaS) Framework:*

A. Software as a Service (SaaS): Customers subscribe on a pay-per-use basis for software hosting and management of applications to reduce the cost of application software licensing, servers (and other infrastructure), and personnel. Applications can be accessed via a Web browser and delivered via the Internet to a firm’s firewall. The backend hardware architecture is shared across many customers but logically unique to each customer. This model offers the least amount of customer extensibility, and there is very little visibility and control for the customer. Most of the responsibilities for security management reside with the Cloud Service Provider (CSP), as storage is completely managed by the CSP and access to the Web portal is controlled through management of user identities, application level configurations, and restrictions to specific IP address ranges. Service levels, security governance, and compliance expectations for the services and CSP are contractually stipulated, managed, and enforced.

B. Platform as a Service (PaaS): This service model is basically an environment as a service for application developers. The CSP typically develops toolkits and standards for development and channels for distribution and payment. Development tools are hosted in the cloud and accessed through a browser. This is a more extensible model than SaaS as security features and capabilities are less complete, but there are provisions for the ability to layer on additional security. The customer assumes more responsibility for managing configurations and security for middleware, database software, and application runtime environments. The drawbacks here are that the customer is locked into vendor APIs, conventions, and platform behavior. The customer can extract his/her data, but applications, data structures, and any add-ons are useless outside of that particular vendor environment.

C. Infrastructure as a Service (IaaS): This model offers computing services in the same way as a utility company offers service. You pay for the amount of processing power and disk space that you actually consume. You can scale infrastructure requirements such as computing resources, memory, and storage based on usage. The customer provisions processing, storage networks, and other resources where the customer runs arbitrary software that can include OS and applications, but does not control or manage the infrastructure. This model provides an enormous amount of extensibility, but there are less integrated security capabilities and functionality beyond protecting the infrastructure itself. The customer is responsible for secure configurations, patch management, installation/removal of plug-ins, access control integration, archive security, and key management services for data encryption.

Looking across the models, SaaS builds upon PaaS and PaaS builds upon IaaS. As capabilities are inherited (as you move from SaaS to IaaS), so are the information security issues and risks.

Cloud Deployment Models

The following are the ways in which clouds are deployed:

A. Public Cloud: Also known as an external cloud. Resources are provided on a self-service basis via Web applications and services to the general public or a large industry group. It is hosted, operated, managed, and owned by a CSP that has one or more data centers. Security management and day-to-day operations are relegated to the CSP and the customer has a low degree of control and oversight of the physical and logical security aspects of the cloud.

B. Private Cloud: Also known as an internal cloud. This model basically emulates cloud computing on a private network. The cloud infrastructure is operated solely for an organization and can be managed by the organization or a third party on or off the premises. It delivers some of the benefits of cloud computing without its pitfalls, capitalizing on data security, corporate governance, and reliability concerns. Organizations buy, build, and manage the cloud and do not benefit from the lower upfront capital costs and less hands on management offered by cloud computing in general. Security management and day-to-day operation of hosts are relegated to an internal IT Department or a third party bound with service-level agreements (SLAs). The customer should have a high degree of control and oversight of the physical and logical security aspects of the infrastructure, and this makes it easier to comply with established corporate security policies, standards, and regulatory compliance. An added benefit of a private cloud over a public cloud is lower latency during peak traffic loads.

C. Hybrid Cloud: This is a model where two or more clouds remain as unique entities but are bound together by standard or proprietary technologies that enable data and application portability. The clouds can be private or public or a combination of the two. Organizations that use this model typically run noncore applications in the public cloud while running core applications and sensitive data in-house in the private cloud.

The bottom line is that an organization wants to consider selection of the cloud deployment model based on the criticality of their assets and specific requirements for security and compliance.

Security Considerations and Issues in Cloud Computing

Now that we have some background on the services that cloud computing provides as well as knowledge of how clouds are deployed, we can look at the security considerations and issues in cloud computing by certain areas of security:

Infrastructure Security

Issues

Infrastructure security can be looked at in terms of the network, host, and application levels. At the network level, the security challenges associated with cloud computing are exacerbated by the cloud, but not specifically caused by it. At the host level, there is an increased need for host perimeter security and secured virtual environments but this is also exacerbated by cloud computing and not caused by it. At the application level, there is a need for a secure software development life cycle due to the public facing nature of public cloud applications and to ensure that APIs have been thoroughly tested for security. But, application level security requirements are again exacerbated by the cloud and not caused by it.

Trust boundaries between the customer and CSPs have moved, and customers are not sure where the trust boundaries have moved to. CSPs have not done an adequate job of clearly articulating the boundaries, nor are these boundaries effectively enforced in SLAs.

The established model of network tiers and zones no longer exists. This model has been replaced with domains that are less precise and afford less protection than the long standing models of tiers and zones.

Data separation in cloud computing is logical and not physical. There are valid security concerns with logical segregation.

Data Security and Storage

Issues

The major reason for lack of effective data security is simply the limitations of current encryption capabilities.

Efforts to adequately detail data mapping are simply not possible in today’s cloud computing offerings.

There’s a lack of serious attention to customer concerns about data remnance (data residue left over and possibly becoming available to unauthorized parties).

Storage as a service is effective for nonsensitive, nonregulated data. Data can be encrypted in transit and at rest, but encrypted data cannot be processed, indexed, or sorted while encrypted. If the data is unencrypted, it becomes a security and compliance concern especially if the data in the cloud is beyond the customer’s visibility and control (difficult to locate where it is stored).

Currently, not all CSPs provide storage management data protection and disaster recovery.

Using cloud services actually decreases your protection from search of data by law enforcement. What you lose in the cloud is protection of warrant (requiring probable cause), guarantee of notice, and the ability to fight seizure beforehand. Government agencies state that they can subpoena your data from CSPs with no prior notice to you. A good CSP that directly receives legal process concerning customer or end-user data will inform the customer unless they are legally prevented from doing so.

Having data collocated with that of another organization that has a high threat profile can lead to a denial of service as an unplanned result from an attack targeted at the organization with the high threat profile.

Organizations that need to comply with HIPAA or PCI DSS must be considered. HIPAA, e.g., requires both technical and physical safeguards for controlling access to data and this may create compliance issues for some CSPs.

Identity and Access Management

Issues

Traditional network controls are no longer relevant in the cloud and need to be superseded by data security and identity based controls.

Managing access control and governance within identity and access management (IAM) to meet business needs remains one of the major hurdles for enterprise adoption of cloud services.

The proliferation of consumer technologies (like the iPhone) into the enterprise and steady dissolution of the network perimeter present greater risks in terms of protecting intellectual property (IP) and sensitive information as well as sustaining compliance.

Web 2.0 technologies (like social networking) delivered via browsers are another catalysts that are accelerating the trend to consumerize IAM services. Protecting information that is mobile, dynamic, replicated, and scattered on a variety of media is becoming increasingly problematic.

Security Management

Issues

Customers have to rely on the CSPs for service instrumentation to measure and manage security, availability, and performance of services in the cloud.

A lack of standards and weak capabilities from CSPs to help the customers place probes into the virtual environment has exacerbated cloud service management. In a virtualized environment where infrastructure is shared across multiple tenants (multitenancy), customer data is combined with that of other customers at every phase of the data life cycle (during transit, processing, and storage). Even if probes are installed at infrastructure layers available to the customer, resource bottlenecks that are visible may not be able to give the information necessary to perform root cause analysis.

Privacy

Issues

Cloud computing is facing a huge challenge in terms of how to deal with cross-border data flows. This involves a number of foreign jurisdictions and complexities developing due to conflicting rules among foreign governments (or states within the United States). An organization may be able to define where (which country) it would like to have its data stored and processed, but to determine which specific server or storage device will be used is problematic due to cloud computing’s dynamic nature.

Storage devices are not always sanitized or destroyed, especially as it relates to virtual storage devices (where storage is constantly being reused).

Multiple privacy laws and requirements such as the European Union and U.S. Safe Harbor Program require knowledge of where data is stored at all times. This requires CSPs to store data on servers in specific jurisdictions to minimize legal risk.

Data protection and privacy policies need to be applied to data and should follow through the data’s life cycle to ensure that the original commitments are met and to create accountability and knowledge of what happens to data.

Accountability for privacy protection falls on the organization that collected the information in the first place. To accomplish this, organizations must understand the privacy and security policies and the security architecture of the service that the CSP is delivering to have the right contracts in place to monitor CSP compliance.

Audit and Compliance

Issues

The question here is which compliance framework should a CSP adopt to satisfy customers and manage its own risks. There is a growing industry concept to develop an IT governance, risk, and compliance (GRC) program. The goal is to develop a uniform IT compliance framework that uses a number of tools such as ISO 27001, PCI, COBIT, ITIL, NIST, and others to automate the process. Adoption of a GRC will allow the CSP to deliver more reports to reflect standards relevant to the customer in a more timely manner.

Most SaaS vendors do not provide the level of audit logs necessary to recover from a serious breach. The customer needs to know who logged in, from where, and when. It also needs to be known what admin actions were taken and what documents/data were accessed. The other question is who can/should access log data and under what controls? Also, if cloud users can access log files, are there privacy issues to be concerned with?

Because of the lack of transparency, auditing can be difficult if not impossible. If something goes wrong or there is unauthorized access, it could be difficult to conduct a forensic investigation.

Other Issues and Considerations

In terms of vulnerability management, the patch management cycle is not in the customer’s control. This lack of control leaves the cloud customer unable to close vulnerability gaps on their own terms.

Relationships with CSPs can be short in duration and the ability to rapidly and practically verify physical controls of multiple CSPs becomes difficult to achieve.

In the cloud, a single server can host multiple applications of many different users. Any of the applications on the server are vulnerable, and it may lead to a compromise or unavailability of other applications as well. Also, a large number of ports may be open, providing a larger network level attack surface.

Using virtual machines (VMs) to run different OS instances on a single hardware platform opens up a new attack vector because VM flaws can compromise the server and therefore affect many customers.

Basically, CSPs develop and deliver services as they seem fit as there is no industry standards to guide them.

Business units, developers, and corporate departments have started using cloud services without the knowledge of the IT department. The added productivity and convenience are being realized without regard for policy, and some users do not want to wait until IT provides them with a private cloud. These moves can compromise continuity, security, and compliance.

Now that we know something about the current security issues with cloud computing, we can look at best practices and other ideas that need to be employed to deal with the issues and make the cloud more secure.

Security Best Practices and Suggestions for Securing the Cloud

The following are a number of best practices covering strategic and policy issues (governance domains) as well as tactical issues (operational domains) within the cloud environment. They are based on the Cloud Security Alliance’s Security Guidance for Critical Areas of Focus in Cloud Computing and are organized into the following domains:*

Governance and Enterprise Risk Management

This deals with the ability of the organization to govern and measure enterprise risk introduced by cloud computing. Customers must be able to assess the risk of the CSP and the responsibility to protect sensitive data when the CSP and user may be at fault.

Recommendations

There is an increased need to scrutinize the security capabilities of the CSP, application of security controls, and ongoing detailed assessments and audits to ensure that requirements are continuously met.

CSPs and customers need to collaborate on information security governance to achieve agreed-upon goals to support the business mission and information security program regardless of the service or deployment model.

The CSP’s security governance processes should be assessed for sufficiency, maturity, and consistency with the customer’s information security management processes. CSP security controls should be risk-based and support the management processes.

Collaborative governance structures and processes need to be incorporated into service agreements.

Security departments need to be engaged during the development of SLAs to ensure that security requirements are contractually enforceable.

Metrics and standards for measuring performance and effectiveness of information security management should be established before moving into the cloud. The metrics and standards should be documented and auditable.

The risk management approach should include identification and valuation of assets; identification and analysis of threats and vulnerabilities and their potential impact on assets; analysis of the likelihood of events/scenarios; management of approved risk acceptance levels and criteria; and development of risk treatment plans with the option to control, avoid, transfer, or accept the risk. Risk assessment between the customer and CSP should be consistent in terms of impact analysis criteria and the definition of likelihood.

The CSP’s incident management, business continuity, and disaster recovery policies, processes, and procedures should be assessed and should include a review of colocation and backup facilities. Facilities should be geographically dispersed and guarantee failover and redundancy in case a data center becomes unavailable.

Customer business continuity and disaster recovery plans should include scenarios for loss of CSP services and for loss of CSP third-party services and dependencies. Testing of these scenarios should be coordinated with the CSP.

Legal and Electronic Discovery

This involves protection requirements for information and computer systems, security breach disclosure laws, regulatory requirements, privacy requirements, international laws, etc.

Recommendations

Customers and CSPs must have a mutual understanding of the roles and responsibilities related to electronic discovery regarding activities such as litigation hold, discovery searches, providing testimony, etc.

Data in the custody of CSPs must receive equivalent guardianship as in the hands of the original owner.

Knowing where the CSP will host data is a prerequisite to ensure compliance with local laws that restrict cross-border flow of data.

Security issues such as data breaches must be addressed in the SLA to clarify the commitments of the CSP versus the customer.

There should be a unified process between the CSP and customer for responding to subpoenas and other legal requests.

Provisions should be detailed for recovering client data after the contractual relationship ends.

Compliance and Audit

This is concerned with maintaining and proving compliance in cloud computing. Compliance involves adherence to internal security policies as well as regulatory or legislative compliance requirements.

Recommendations

A right to audit clause is needed especially when the CSP is providing services for which the customer has regulatory compliance responsibilities. The need for this could be reduced if the CSP is certified to ISO 27001.

Customers should develop processes to collect and store compliance evidence including audit logs and activity reports, copies of system configurations, change management reports, and test procedure outputs. Depending on the deployment model, the CSP may have to provide much of this information.

If the organization has input into the selection of security auditors and assessors, it is advisable to select someone that is “cloud aware” to make sure that they are familiar with cloud and virtualization challenges.

A CSP should have a SAS 70 Type II audit statement at a minimum. Although it only ensures that controls are implemented as documented, the scope of the audit needs to be understood and it needs to utilize controls that meet customer requirements.

If a CSP has not achieved ISO 27001 certification, it should at least demonstrate alignment with ISO 27002 practices.

Information Life Cycle Management

This looks at managing data that is placed in the cloud. The focus is on identification and control of data in the cloud as well as compensating controls to be used due to loss of physical control when moving data into the cloud. It is also important to determine who is responsible for data confidentiality, integrity, and availability.

Recommendations

Customers should understand how integrity is maintained and compromise of integrity is detected and reported by the CSP. This same recommendation applies to confidentiality.

All specific controls used during the data security life cycle (create, store, use, share, archive, and destroy) need to be identified. A data security life cycle focuses on data security and not securing the database container that other database security models focus on. Focusing on securing the data minimizes reliance on security provided by the database, network, platform, or places where the data is stored. Because the customer does not always know where the infrastructure is, where the data is located, or who has access, you need to account for the security of data as it moves into and through the cloud.

Use SLAs to stipulate knowing where your data is and to know the geographic location of storage.

The data owner should maintain a default denying all policy for both the data owner and CSP employees.

Data must be encrypted at rest and in transit.

Decommissioning procedures need to be put into place to sanitize media and destroy data. DoD 5220.22-M or NIST 800-88 guidelines and techniques for decommissioning can be used, but if the hardware device cannot be decommissioned, it should be degaussed or physically destroyed in accordance with industry standard practices.* This makes sure that data residue does not remain to become available to unauthorized parties.

Identify trust boundaries throughout the IT architecture and abstraction layers. Ensure that subsystems only span trust boundaries as needed with appropriate safeguards in place to prevent unauthorized disclosure, alteration, or destruction of data.

Customers should understand what techniques CSPs use to separate or isolate customers from one another.

Customers need to understand how encryption is used on multitenant storage. Is there a system in place to make sure that different data owners do not have the same encryption key?

Strong storage encryption should be used that renders data unreadable when storage is recycled, disposed, or accessed outside of authorized applications, processes, and entities.

Regular backup and recovery tests need to be performed to ensure logical segregation and controls are effective.

CSP personnel controls need to be in place to provide for a logical separation of duties.

Portability and Interoperability

This focuses on the ability to move data/services from one provider to another or bringing it back entirely in-house. Issues surrounding interoperability between providers are also important here.

Recommendations

The customer should understand how VM images can be captured and ported to new CSPs who may use different virtualization technologies.

Customers should have access to system logs, traces and access to and billing of records from the legacy CSP.

Options should be identified to resume or extend service with the legacy CSP should the new provider prove to be less than stellar.

Customers should understand the tools available for secure data transfer, backup, and restoration.

The customer should understand how testing will be completed prior to and after migration to verify that services and applications are operating properly.

It needs to be understood what metadata can be preserved and migrated.

Traditional Security, Business Continuity, and Disaster Recovery

This looks at how cloud computing affects operational processes and procedures currently in use to implement security, business continuity, and disaster recovery.

Recommendations

CSPs should compartmentalize job duties, perform background checks, require/enforce employee nondisclosure agreements (NDAs), and limit employee knowledge of customers to that which is only needed to perform their job.

Customers should perform on-site inspections of CSP facilities whenever possible.

Recovery time objectives (RTOs) should be fully understood and defined in SLAs. This defines the maximum amount of time that loss of a critical process, resource, or function can be dealt with before it becomes a serious adverse impact.

Recovery point objectives (RPOs) should also be fully understood and covered in SLAs. This is the maximum amount of data loss that can be sustained due to an event and the ability to go back to a “last known good” configuration.

CSP business continuity programs should be certified or mapped to recognized standards such as BS 25999.

Data Center Operations

This concerns itself with how to evaluate a CSP’s data center architecture and operations. It focuses on helping users to identify common data center characteristics that could detrimentally affect ongoing services as well as fundamental characteristics that can affect long-term stability.

Recommendations

Data centers need to be designed for fault tolerance and securing data against a physical security breach, earthquake, fire, flood, loss of power, or other natural phenomenon. They should be built in clusters in various global regions and all data centers should be online and serving customers (no “cold” data centers).

Data centers should be in nondescript facilities and physical access should be controlled at the perimeter and building ingress points by professional security staff using video surveillance and other electronic means. Authorized staff should have to use two-factor authentication, and all visitors and contractors should have to present identification and be escorted through the facility at all times. Access should only be provided to those with a legitimate business need, and when there is no longer a need, access should be revoked immediately. All access to the facility should be logged and audited routinely.

Customers should understand CSP patch management policies and procedures and how these may impact their environments.

CSPs should have standard continuous improvement processes in place.

Customers should ensure that CSP support processes, procedures, tools, and support hours are compatible with their business needs.

Incident Response, Notification, and Remediation

This area is important as it looks at adequate incident detection, response, notification, and remediation. It looks to address items that should be in place at both provider and user levels to ensure proper incident handling and forensics.

Recommendations

Customers may have limited involvement with CSP incident response activities. Thus, customers must understand communication paths to the CSP’s incident response team.

CSP incident analysis and detection tools should be compatible with that of the customer’s.

Proper risk management on systems and use of defense-in-depth practices are essential to reduce the chance of a security incident in the first place.

CSPs should have the ability to deliver snapshots to customers on their entire virtual environment and should include firewalls, network switches, systems, applications, and data.

Containment approaches focused on the CIA Security Triad are necessary.

Remediation efforts need to be able to restore systems to earlier states. Remediation may also need to focus on forensic recording of incident data.

Application Security

This looks to secure application software running or being developed in the cloud. It also looks at whether to migrate or design an application to run in the cloud, and if so, on what platform (SaaS, PaaS, IaaS)?

Recommendations

Managing and protecting application credentials and key materials are critical.

Care should be taken with management of files used for application logging and debugging as the location of the files may be remote or unknown and the information may be sensitive.

Metrics should be used to assess the effectiveness of application security programs. Vulnerability scores and patch coverage should be looked at, as they can be indicative of the quality of application coding.

Customers should obtain permission to conduct remote vulnerability assessments, including network/hosts and application vulnerability assessments. Many CSPs restrict these assessments due to the CSP’s inability to distinguish them from an actual attack and to avoid potential impact on other customers.

Encryption and Key Management

This relates to identifying proper encryption usage and scalable key management.

Recommendations

Encryption should be used to separate data holding from data usage.

Key management should be segregated from the CSP hosting the data, creating a chain of separation. This protects the CSP and the customer when required to provide data due to a legal mandate.

When a CSP does perform key management, the customer should understand whether the CSP has defined processes for a key management life cycle (key generation, use, storage, backup, recovery, rotation, and deletion). It should also be determined whether each customer has his/her own key set.

Identity and Access Management

This involves managing identities and leveraging directory services for access control. The focus is on the issues that will present when extending an organization’s identity into the cloud.

Recommendations

Customers should modify or extend authoritative repositories of identity data so that it encompasses applications and processes in the cloud.

Enterprises should authenticate users via their identity provider and establish trust with their Saas vendor by federation using Security Assertion Markup Language (SAML) or OpenID standards. Otherwise, one authentication system for the internal organization system and one for the external cloud system may result and this may turn into an unworkable solution.

Especially for IaaS deployment, a dedicated and secure VPN to the corporate network or federation may be a good idea.

CSPs should consider supporting various strong authentication options such as one-time passwords, biometrics, digital certificates, and Kerberos.

Virtualization

This domain addresses the risks associated with multitenancy, VM isolation, VM coresidence, hypervisor vulnerabilities, etc.

Recommendations

Customers should identify which types of virtualization a CSP uses if any. Not all CSPs or services use virtualization, and cloud computing does not necessarily equate with virtualization.

Layered security controls should be used on virtualized operating systems to reduce dependency on the platform provider alone.

Security controls other than the built-in hypervisor isolation internal to the VM must be understood. Intrusion detection and antivirus and vulnerability scanning should be considered. Secure by default configuration must be ensured.

The integrity of any VM image originating from the CSP must be validated before using.

The feasibility of segregating VMs and creating security zones by usage (desktop versus server), production stage (development, production, or testing), and placing sensitive data on separate physical hardware like servers, storage, etc., need to be considered.

Reporting mechanisms need to be in place to provide evidence of isolation, and alerts need to be raised if isolation is breached.

Additional Security Suggestions and Best Practices for CSPs by a CSP

These are some of the security suggestions for CSPs based on one of the largest CSP’s (IBM’s) Cloud Security Guidance:*

Build and Maintain a Secure Cloud Infrastructure

A. Install and maintain firewall configurations:

There should be a formal change management process for firewalls that results in formal approvals and acceptance of firewall changes.

Firewalls should be placed at each external network interface and between each security zone.

The default setting for ports is to deny access.

There should be a quarterly assessment of firewall and router configurations and rule sets.

Firewalls should be deployed that deny access from untrusted sources or applications and log these events.

B. Do not use vendor supplied defaults for passwords and other security parameters:

Change vendor supplied passwords before activating a server or prior to creation of VM images.

Remove all unnecessary applications, scripts, or modules from the virtual system.

C. Implement a physical environment security plan:

Prevent unauthorized access to critical areas within facilities and access to physical assets and systems by unauthorized users.

Ensure adequate natural disaster protection.

D. Protect hybrid communications:

Ensure that access to corporate infrastructure is only possible through secure communications.

Ensure that communications between remote and corporate infrastructure are encrypted.

Ensure that communications can only originate from the corporate infrastructure.

Make provisions for protected out-of-band communications in event of an emergency.

Ensure Confidential Data Protection

A. Securely destroy all nonessential personally identifiable information (PII):

Mask displayed PII when appropriate (like only showing a subset of social security numbers, for example).

Render PII unreadable whenever stored.

Ensure that PII is not recorded in log or other system files.

B. Protect intellectual property (IP):

Risk assessment should include IP that may be exposed.

General counsel should ensure that SLAs cover protection of IP.

Organizations should obscure IP through encryption so that malicious users cannot reverse engineer information.

Protect Encryption Keys from Misuse or Disclosure

Keys should be periodically recycled on an annual basis.

There should be a method for destruction of old or inactive keys.

There should be prompt disposal and replacement of compromised keys.

All access to keys should be logged.

There should be split-knowledge and establishment of dual control of keys.

Implement Strong Access and Identity Management

A. Implement a least privilege model:

Regularly evaluate users’ access lists to ensure that only appropriate levels of access are granted and only personnel with authorized need have access to systems.

Restrict access based on need to know.

Verify and check identity of all users against an approved access list.

Implement multifactor authentication to all systems and administrator systems.

B. Implement federated identity management:

Ensure that federated identity management is implemented when bridging cloud environments.

Establish Application and Environment Provisioning

A. Implement a program for application provisioning:

Design and implement a program for provisioning images and applications.

Ensure that application and virtual image deprovisioning activities are logged.

Ensure that all changes to access of virtual images and applications are logged.

Destroy outdated or invalid virtual images.

Implement a Governance and Audit Management Program

A. Implement a privacy management program:

Create a program/process for notification of appropriate parties in the event of breach.

B. Implement mechanisms for audit capture and management:

Create policies for capture and retention of legal and regulatory documents.

Implement a Vulnerability and Intrusion Management Program

A. Implement and regularly update antivirus/antispyware and IDS/IPS:

Deploy antivirus software on all supported systems that could be exposed to virus or spyware attacks.

Confirm that IDS/IPS are properly configured to alert the personnel of suspected compromises.

Maintain Environmental Testing and Validation

A. Implement a change management process:

The change management process must be formal and documented.

The process should follow a configuration change management process for systems and software that includes change request logging, an impact assessment statement, and a process for rollback to a prior state.

B. Implement a program for secure application development and testing:

Validate all security patches prior to production deployment.

Ensure that test and production environments are separated.

Ensure separation of duties between test, development, and administration personnel.

Ensure that all test accounts and custom accounts are removed prior to production activation.

Ensure that trace and debug statements are removed from production code.

Ensure that audit trails are enabled for all events:

– Invalid login attempts

– Administrator access attempts

– Events involving access to confidential or PII data

– Retention of audit trail history for at least a year

– Perform pen testing at least every 90 days to detect any vulnerabilities.

Current Developments and Needs for the Future of Cloud Computing

The following are a few of the developments that need to take place or will take place to further expand cloud computing and further ensure its future success:*

A. Cloud Services Architect: This is a new IT role in the organization that looks at what applications and services will go into the cloud based on the business case and the capabilities of the cloud. This role will help businesses to curtail the business units that go directly to the cloud for services without involving the IT Department.

B. Information Authority: Today, when connecting two networks without completely merging them, you need multifactor authentication, identity brokers, and access brokers. An information authority would act as a central repository for securing data and control of applications. It makes identity management part of the application delivery network through establishment of a trust fabric. Today, each new application or service requires a new set of credentials and privileges leading to inconsistent user rights and a need to remember multiple passwords. Moving identity into a central point in the network forms the necessary trust fabric that delivers single sign-on (SSO) spanning all organizational users and resources across SaaS and IaaS environments.

C. Web Security: Today, tools used to defend against hackers are software installed on each device or appliance on the premises. For this to work, things must be constantly updated. And, it takes time to discover vulnerabilities, create signatures, and test and deploy patches, so you are always going to have a gap in security. With Web security, the thought here is that the threats are moving to the Web (directed at Web-based applications) so it makes sense that the protections are placed there. It looks at placing the protections closer to the threats to stop them before they ever reach the corporate network. It requires a Web services security package that includes antimalware, spyware, and phishing controls; Web content and URL filtering; acceptable use policies (which users can access which resources); and the ability to access using a browser without first accessing the corporate network (allowing for scaling without placing things on client machines or having to use VPNs).

D. Security-as-a-Cloud Service: This will be a growing area because there will be a continued shift in information security from in-house to outsourced work, and information security will accelerate in need and complexity to go along with the growing adoption of cloud computing. As you can see from all of the suggestions and recommendations in this chapter, this will become a monumental task for companies to handle all of the security implications of cloud computing, and they may not have all of this expertise in-house. Therefore, they will have to contract with some external firms that have the resources and expertise to deal with all of the security implications related to cloud computing.

E. Open Standards: These will be necessary to provide greater transparency to organizations so that it is clearer and agreed upon, as to who provides (organization or CSP or multiple CSPs) certain security capabilities and safeguards. And, there also needs to be some standardization across CSPs as to who provides certain security capabilities specific to certain offerings in the SPI Delivery Model. Open standards will also facilitate unified management functions across CSPs through the development of cloud resource management protocols, packaging formats, and security mechanisms to facilitate interoperability.

F. Global Privacy Standard: Today, it is a challenge for a CSP to understand international privacy laws to understand how data can be transferred from one part of the world to another. But, it is essential for them to understand these different jurisdictional laws because their customers depend on this to meet their data compliance needs. Development of a global privacy standard would help provide consistency across jurisdictions and would erase many of the challenges and guesswork that take place in terms of dealing with where data resides.

G. Uniform Compliance Framework: Today, a CSP defines many of its own processes and controls, but as CSPs connect to each other and provide cross-CSP solutions, a uniform compliance framework will become necessary to ensure that appropriate security measures are being consistently applied. The adoption of the previously mentioned GRC program is a good starting point for gaining agreement on the adequacy of security measures being consistently applied and based on standards relevant to the CSP and its customers.

H. Predicate Encryption: Predicate encryption involves the ability for various individuals to selectively decrypt data without having to decrypt all of the encrypted data. This area is still being researched but shows promise in providing data security and storage in high volume, multitenancy, cloud computing environments.

These are a few of the efforts that will make cloud computing even more appealing and more secure, compliant, and resilient for organizations looking to pursue a more affordable and scalable business model for their future needs and requirements.

Conclusion

Cloud computing is making a huge impact on how companies are conducting business as they look to serve their internal constituents while trying to drive down costs. And, cloud computing is poised to explode even more. But, the major hurdle that could prevent cloud computing from reaching its full potential is security. Organizations must make sure that the cloud is at least as secure as their own corporate networks, otherwise the cloud business model does not make sense, no matter how affordable it may be. The burden for dealing with security challenges in the cloud does not just fall on the customer; however, it requires cooperation between the customers and the CSPs and between and across CSPs. Only with proper security practices, further future developments and tightly coupled coordination between the customers and the providers can cloud computing reach its full potential and become the future blockbuster technology and business model that it can become.

Bibliography

1. Mather, T., Kumaraswamy, S., Latif, S. Cloud security and privacy. O’Reilly Media, September 2009.

2. Cloud Security Alliance. Security guidance for critical areas of focus in cloud computing. Version 2.1. December 2009.

3. Jansen, W., Grance, T. Guidelines on security and privacy in public cloud computing. National Institute of Standards and Technology. U.S. Department of Commerce. Draft Special Publication 800-144.

4. Citrix OpenCloud Access. White Paper. www.citrix.com.

5. IBM Corporation. Seeding the clouds: Key infrastructure elements for cloud computing. February 2009.

6. Dell Tech Dossier. A revolutionary approach to cloud building. June 7, 2010. www.networkworld.com/news.

7. Stratecast. Overcoming obstacles to cloud computing. February 2011. www.frost.com.

8. Kraieski, E. The hybrid enterprise data center. InformationWeek Analytics, November 2010. Analytics.informationweek.com.

9. Microsoft Global Foundation Services. Securing Microsoft’s cloud infrastructure. May 2009.

10. Google Apps for Business. www.google.com/apps/intl/en/privacy/.

11. Google, Inc. Security Whitepaper: Google Apps messaging and collaboration products. 2010.

12. Olden, E. Architecting a cloud-scale identity fabric. Symplified. Published by IEEE Computer Society.

13. Amazon Web services: Overview of security processes, August 2010. http://aws.amazon.com/security.

14. Howarth, F. Why Web security is best served in the cloud. Bloor Research, February 2010.

15. National Institute of Standards and Technology. Cloud architecture reference models. NIST CCRATWG-004.

16. Microsoft Corporation. The economics of the cloud. November 2010.

17. Babcock, C. Ready for this?: Cloud computing will force the IT organization to change. InformationWeek Analytics, November 30, 2009. www.informationweek.com.

18. Microsoft Security Development Lifecycle. Security considerations for client and cloud applications, November 4, 2010. www.microsoft.com/sdl.

19. IBM Global Technology Services. Leveraging security from the cloud: The who, what, when, why and how of cloud-based security services, 2010.

20. IBM point of view: Security and cloud computing. Cloud Computing White Paper, November 2009.

21. Buecker, A., Lodewijkx, K., Moss, H., Skapintez, K., Waidner, M. Cloud security guidance: IBM recommendations for the implementation of cloud security. IBM Corporation, 2009. Ibm.com/redbooks.

22. Red hat cloud foundations: Cloud 101. www.redhat.com.

23. Cloud Computing. en.wikipedia.org/wiki/Cloud_computing.

24. Unleashing cloud performance: Making the promise of the cloud a reality. Riverbed Technology Whitepaper, 2009.

25. Lane, A. Database lockdown in the cloud. Dark Reading, March 9, 2011.

26. Armin, J. Hacker deploys cloud to smash passwords. January 17, 2011. www.internetevolution.com.

27. IBM Corporation. Cloud services may be a game-changer for business. 2010. www.304.ibm.com/businesscenter/cpe/html0/190102.html

28. Cloud computing security. www.oyyas.com/articles/cloud-computing-security.

29. Cloud computing security.en.wikipedia.org/wiki/Cloud_computing_security.

30. Becherer, A., Stamos, A., Wilcox, N. Cloud computing security: Raining on the trendy new parade. Blackhat USA. ISEC Partners, 2009. www.isecpartners.com.

31. NIST Cloud Computing Reference Architecture and Taxonomy Working Group. A strawman model. National Institute of Standards and Technology, January 3, 2011.

32. Badger, L., Grance, T. Standards acceleration to jumpstart adoption of cloud computing (SAJACC). National Institute of Standards and Technology, May 20, 2010. cloudcomputing@nist.gov.

33. Roiter, N. Cloud services redefining rules for regulatory compliance. Dark Reading, February 17, 2011.

34. Roiter, N. RSA announces identity and compliance profiling services for the cloud. Dark Reading, February 14, 2011.

35. Lane, A. Securing databases in the cloud. Dark Reading, February 2, 2011.

36. Muzilla, C. True PaaS: What users need to succeed in the cloud. RedHat, Inc., September 22, 2010.

37. Murphy, C. FedEx CIO explains the real power of the cloud. Informationweek.com, February 14, 2011.

38. Mell, P., Grance, T. The NIST definition of cloud computing. Version 15. National Institute of Standards and Technology, October 7, 2009.

39. Knode, R. Cloud security report out. National Institute of Standards and Technology. cloudcomputing@nist.gov.

40. IBM. Effective storage management and data protection for cloud computing. IBM Software Thought Leadership White Paper, September 2010.

* Mather, T., Kumaraswamy, S., and Latif, S. Cloud security and privacy. O’Reilly Media, p. 11, September 2009.

* Cloud Security Alliance. Security guidance for critical areas of focus in cloud computing. Version 2.1. December 2009.

* Amazon Web Services: Overview of security processes, p. 9, August 2010.

* Buecker, A., et al., Cloud security guidance: IBM recommendations for the implementation of cloud security. IBM Corporation, 2009.

* Mather, T., Kumaraswamy, S., and Latif, S. Cloud security and privacy. O’Reilly Media, pp. 260–266, September 2009.