Overview

This is just a quick overview of cloud in general. I wasn't going to write this one, but figured I would make my AWS Cloud Security Blog Series complete by backing up and creating a Part 0 to lay out the foundation of cloud.

I will use National Institute of Standards and Technology (NIST) Special Publication (SP) 800-145 and 800-146 as the standards for cloud computing definitions.

Cloud Computing

So, the idea of a cloud isn't new.

It turns out that in the 1960s there was a computing concept called, time-sharing, which was used to share computing resources with many users. An example of this was, Compatible Time-Sharing System (CTSS), which was developed by MIT and put in use in 1961.

The concepts of time-sharing compute resources goes back to the mid-1950s. During MIT's Summer Session 1954 - Digital Computers there was a discussion topic on the, Effects of Automatic Coding Machine Design.

The session kicked off by discussing the IBM 704 versus the IBM 701, and how there will be three index registers with the IBM 704 and how size will be a problem.

Dr. Grace Hopper, John Backus, Mr. W.A. Ramshaw, Mr. J. R Belford and others go on to propose ideas of solving the computer sizing concerns. As in, there is no room physically and you reach a point of diminishing returns.

Dr. Hooper's says, "the possibility of using several small computers in parallel"

John Backus stated that, "since increased speed costs little more, a large computer is cheaper to use than a small one."

He goes onto say, "that by time sharing, a big computer could be used as several small ones; there would need to be a reading station for each user.".

If you apply, both Dr. Hopper's comment on small(er) parallel computers and John's comments about scale ("large computer" and/or "big computer") you start to have the makings of a cloud.

The irony of these comments is that in the book, The Everything Store: Jeff Bezos and the Age of Amazon. Bezo's, when discussing AWS, was quoted by an employee for saying, "He had a vision of literally tens of thousands of cheap, two-hundred-dollar machines piling up in racks, exploding. And it had to expand forever".

Jeff Bar (Chief Evangelist for the Amazon Web Services) posted the first blog entry on the Amazon Web Services blog on November 09, 2004.

Fast forward to 2006, "Amazon Web Services (AWS) began offering IT infrastructure services to businesses in the form of web services -- now commonly known as cloud computing." In comparison, "Azure was announced in October 2008 and released on February 1, 2010 as "Windows Azure" before being renamed "Microsoft Azure" on March 25, 2014."

So, what makes cloud so special today if it's existed conceptually and/or physically for decades?

Let's take a look.

Cloud Definition: NIST states it, "is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."

These are some of the characteristics that make today's cloud different from previous attempts.

• Massive Scale: Sure, data centers and large mainframes existed previously, but nothing on the massive scale they do today. With this massive scale comes more or less an unlimited amount of computing power in a relatively small footprint compared with older computing systems, and with it, insane levels of computing power. So large, that humans (including myself) really can't grasp the magnitude of it all. Oh, and it's all accessible literally a few mouse button clicks.
• Self-Service: A cloud consumer can, at anytime, for whatever reason, spin up/down compute resources. This can be accomplished, "without requiring human interaction with each service provider".
• On-demand: This also includes pay-as-you-go on-demand services. Think of on-demand pricing models with Azure and/or AWS.
• New Services: MongoDB, Artificial Intelligence (AI) and Machine Learning platforms, MapReduce/Hadoop, etc. that simply did not exist like they do today and if they did, not at the scale as they do today.
• Resource Pooling: The providers computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to cloud consumer demand
• Rapid Elasticity: Resources and services can be elastically provisioned and released. In some instances, a cloud consumer might leverage auto-scaling. A good example of this is Black Friday shopping season. Cloud provides the elasticity to auto-scale during peak times and meet the expected/unexpected demand without pre-purchasing a bunch of hardware that will sit stale until the next peak demand. This elasticity also help organizations engineer solutions for cost savings.
• Measured Service: Cloud systems automatically control and optimize resource use by leveraging a metering capability. An example of this is how Amazon charges by the second for some computing resources, or the amount of data in a storage service like S3. Not unlike how you're charged for Gas and Water in your home.

Cloud Service Models

Clouds today can be deployed in differnt service models.

There are generally three or four cloud computing service models. Starting from the lowest levels of control.

Hardware as a Service (HaaS): You're essentially given access to physical hardware and then you pay a service to rent it. Think of this as using Uber vs. buying a car. You're paying a service fee to Uber to use their hardware (the Car/Person).

Infrastructure as a Service (IaaS): Install your own software/operating systems onto hardware without having to manage the hardware.

NIST states, "The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications."

This includes technologies like; virtual machines (EC2), storage (Amazon S3), networks (VPC), etc.

Platform as a Service (PaaS): NIST states it's the, "capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider."

Examples include, AWS Elastic Beanstalk, RDS, Lambda, etc.

Software as a Service (SaaS): This is when the cloud consumer (you), leverage the cloud service providers infrastructure via applications (Ex. a Web Browser). You don't manage or control any of the cloud infrastructure.

Examples are; Gmail, Dropbox, Google Docs, etc.

Deployment Models

Private Cloud: Private to your organization served up to multiple business units. It's not always cheaper to move to AWS, Azure, etc. In instances where this is true, an organization may decide to invest in their own cloud.

Public Cloud: The cloud infrastructure that is provisioned for and used by the public. This is AWS and Azure.

Hybrid Cloud: This could be a combination of one or all of the other clouds. You could have a public cloud that's integrated into your on-site private cloud, and/or data center.

That is all I will touch on what makes cloud, cloud.

From here on out, you should assume I am talking about Public Cloud. More specifically, Amazon Web Services (AWS).

Birth of AWS

In the book, The Everything Store: Jeff Bezos and the Age of Amazon, it says that AWS, as it's known today, started to gain traction around 2003.

At the time, Amazon's internal systems were broken down into more individual components. There was a single team that strictly controlled who could access Amazon's services. Teams within Amazon had to plead for resources and as a result, it slowed people down and leadership (and employees) felt like it stifled creativity.

Amazon realized they, "needed to break their infrastructure down into the smallest, simple atomic components, and allow developers to freely access them with as much flexibility as possible."

In 2004, Chris Pinkham moved back to South Africa so he could be closer to family. In doing so, he brought with him, Chris Brown. They setup shop in Cape Town, where their efforts would become, Elastic Computer Cloud, or EC2.

The rest is history. The book is a good read if you care to read more about Bezo's and the early years of Amazon. It's not specific to AWS, but it's discussed.

One part I find kind of funny is that South Africa isn't a region you can select within AWS (as of this writing), even though it's the birth place of AWS. I guess it comes down to simple economics.

Cloud Shared Responsibility Model

The idea of the shared responsibility model is that you, the cloud consumer, as well as the cloud service provider (CSP), share the responsibility of securing the cloud.

Amazon depicts this model as the following; however you should keep in mind that it will vary depending on the services you choose.

For example, with AWS Container Services (RDS, EMR, Beanstalk), AWS manages the infrastructure, Operating Systems, Application Platforms where the cloud consumer is responsible for data encryption, identity and access management (IAM), firewall configurations.

Security in the Cloud: The the cloud consumer is responsible for. This will shift depending on the services you choose and the vendor you choose as well. Some full managed services for example will reduce the responsibility on you (the cloud consumer), and other services that are not fully managed by the CSP will increase the your requirements.

So what does "in the cloud" mean, really? Well, let's take an Amazon Elastic Compute Cloud (EC2), which is the virtual machine rental service that AWS provides. When you rent an EC2 system, let's say, Linux. You are the cloud consumer are responsible for management of that Linux machine, which includes software updates as well as security patches.

Security of the Cloud: The general rule of thumb is the CSP has the responsibility of the CSP. As in, the CSP secures the infrastructure where all of the services run, to include the data centers, physical security, placement of data centers, etc.

Controls: With the shared responsibility you have different control types. Amazon classifies them as the following. I've included a couple examples for each categorization.

• Inherited - Inherited from AWS
  • Physical security
• Hybrid - AWS provides partial implementation, customer is responsible to fully implement
  • Account management (IAM)
• Shared - AWS provides security around certain services/layers, the customer needs to provide it at other services/layers.
  • Patch management
  • Configuration management
• Customer - Responsibility of the cloud consumer.
  • Creating protection zones around PCI-DSS data

I should mention there are far fewer inherited controls, than customer (cloud consumer), hybrid, and shared controls, so if you're in AWS now and haven't done anything, and you think, "you're good", you're not.

NIST 800-53 rev 4 Control Example:

Here is an example of a control using the Security and Privacy Controls for Federal Information Systems and Organizations - NIST 800-53 rev 4. Rev 5 is in draft at the time of writing.

NIST 800-53 Definition: "This publication provides a catalog of security and privacy controls for federal information systems and organizations and a process for selecting controls to protect organizational operations (including mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile cyber attacks, natural disasters, structural failures, and human errors. The controls are customizable and implemented as part of an organization-wide process that manages information security and privacy risk."

Within NIST 800-53 you have the following IDs and Control Families.

Id - Family
AC - Access Control
MP - Media Protection
AT - Awareness and Training
PE - Physical and Environmental Protection
AU - Audit and Accountability
PL - Planning
CA - Security Assessment and Authorization
PS - Personnel Security
CM - Configuration Management
RA - Risk Assessment
CP - Contingency Planning
SA - System and Services Acquisition
IA - Identification and Authentication
SC - System and Communications Protection
IR - Incident Response
SI - System and Information Integrity
MA - Maintenance
PM - Program Management

Here is a simple control Access Control we can look at.

Account Management - AC-2(1) - The organization employs automated mechanisms to support the management of information system accounts.

This is an example of a shared responsibility control. AWS Identity and Access Management (IAM) is going to be the automated mechanism that the cloud consumer will use to fulfill this control. The cloud consumer would also then use CloudTrail as the mechanism to logging activity of said IAM users.

The cloud consumer would then own the responsibility of documenting their internal standard operations procedures (SOPs) on how it employs these automated mechanisms.

Compliance

AWS has received multiple compliance certifications for its infrastructure. So it's possible when using AWS to achieve PCI, certify against something like ISO27001, etc.

I recommend you take a look at all of the certifications they have received here

Summary

So now we all know what a cloud is.

Future blog posts for this series are maintained here.

Enjoy!

References:

NIST 800-145 - The NIST Definition of Cloud Computing
NIST 800-146 - Cloud Computing Synopsis and Recommendations
NIST 800-53 rev4 - Security and Privacy Controls for Federal Information Systems and Organizations
Amazon Compliance Page
MIT's Summer Session 1954 - Digital Computers