Irena Bojanova - Home
Addressing Cloud Security
Irena Bojanova
MAY 20, 2013 12:12 PM
A+ A A-
  painting of cowboy wrangling wild horses

It's the High-Tech Wild, Wild West out there!
Although the Cloud Computing marketplace is still chaotic, it is:

  • Exciting
  • Fast-growing
  • Full of opportunities

Understanding cloud security risks is related to understanding the relationships and dependencies between cloud computing models and how they are deployed. IaaS forms the foundation of the service model architecture, PaaS builds upon IaaS, and SaaS in turn builds upon PaaS; and information security issues and risks are inherited just as capabilities are.

There are significant trade-offs to each cloud computing model in terms of integrated features, complexity versus openness (extensibility), and security. The lower down the stack, the cloud service provider stops bearing responsibility, and the consumer becomes responsible for more security capabilities and management. Table 1 provides concise information in this direction.

Table 1. Cloud Service Models — Integrated features, Extensibility, and Security

Service Model Integrated Features Extensibility Security
  • Most integrated functionality built directly into the offering
  • Least consumer extensibility
  • Relatively high level of integrated security - provider responsible
  • Negotiated into contracts for service (service levels, privacy, compliance)
  • Customer ready futures
  • More extensible than SaaS
  • Less complete built-in capabilities
  • Securing the platform -- provider responsible
  • More flexibility to layer on additional security
  • Applications developed on platform and developing them securely -- consumer responsibility
  • Few if any application-like futures
  • Enormous extensibility
  • Protecting underlying infrastructure and abstraction layers -- provider responsible
  • Less integrated security capabilities and functionality beyond that
  • Reminder of stack -- OSs, applications, content -- managed/ secured by consumer

Note: CSA points that derivative classifications may yield when scope or capabilities and functionality within each model is narrowed, or functional coupling of services and capabilities across models is employed. For example, Storage as a Service is a specific IaaS sub-offering.

So, cloud computing may present different risks than traditional IT solutions, because of the cloud service models employed, the operational models, and the technologies used to enable cloud services. As discussed in previous posts, multi-tenancy allows seemingly limitless scalability and an alternative to expensive data-center infrastructure. However, it requires building adequate security into every aspect of a SaaS application, as well as for every IaaS virtual service. This can be achieved through:

  • Filtering — creation of an intermediary layer between a tenant and data source
  • Permissions — use of access control lists
  • Encryption — obscure each tenant's critical data
  • Or some combination of the above techniques.

A concise version of the discussed by NIST multi-tenancy risks is provided in Table 2.

Table 2. Multi-tenancy Risks and Mitigation

Deployment Model

Multi-tenancy Risks and Mitigation


Implications: Workloads of different consumers may reside:

  • Concurrently on same computer system and local network,
  • Separated only by access policies implemented by provider's software.

Consumers security could be compromised by flaw in:

  • Implementation or
  • Provider’s management and operational policies and procedures.

Multi-tenancy risks:

  • Reliability –  failure may occur
  • Security – attack may be perpetrated by consumer




  • General risks apply, as there could be authorized but malicious insiders
  • Different organizational functions, such as payroll, storage of sensitive personally identifiable information, or generation of intellectual property can become accessible to not authorized users and specific classes of data disclosed.

Risks mitigation:

  • Logical segregation techniques at network layer, such as VPN Routing and Forwarding (VRF)
  • Clients are restricted to members of organization or authorized guests or partners.



  • On-site private cloud risks apply.

Risks mitigation:

  • FISMA and OMB policy require external cloud providers to handle  federal information or operating information systems on behalf of the federal government meet same security requirements as federal agencies.




  • On-site private cloud risks apply, but more organizations are encompassed.

Risks mitigation:

  • Restricted number of possible attackers, but more than with private on-side cloud.



  • On-site community cloud risks apply.

Risks mitigation:

  • Restricted number of possible attackers, but more than with private cloud. 



  • Workloads of any combination of consumers may be sharing a single machine
  • Workload may be co-resident with workloads of competitors or adversaries.


  • Large collection of potential attackers, as public clouds aim scaling in consumers and resources to achieve low costs and elasticity.

Risks mitigation:

  • Limited kinds of data for computations  in the cloud
  • Data encryption (but then data needs to be unencrypted to be processed)
  • Physical separation – rent entire computer systems rather than VMs (mono-tenancy), VPNs, segmented networks, or advanced access controls.


Anyone have thoughts or sources that will help readers understand cloud security? Please share here!

Irena Bojanova

Irena Bojanova, Ph.D., is Founder of IEEE CS Cloud Computing STC, an Associate editor of IEEE Transactions on Cloud Computing, and an Editorial Board Member of IEEE CS IT Professional. She is a professor and program director, Information and Technology Systems, at University of Maryland University College, managed academic programs at Johns Hopkins University and PIsoft Ltd., and co-started OBS Ltd., (now CSC Bulgaria). Her current research interests include cloud computing, web-based systems, and educational innovations. She is a member of the IEEE and can be reached at


[%= name %]
[%= createDate %]
[%= comment %]
Share this:
Please login to enter a comment: