Cloud Security and Data
Protection
Cloud Strategy Partners, LLC
Course Presenter’s Biography
This IEEE Cloud Computing tutorial has been developed by Cloud Strategy Partners, LLC. Cloud Strategy Partners, LLC is an expert consultancy firm that specializes in Technology and Strategy relating to Cloud Computing.
Course Summary
Security is a complex domain and involves multiple aspects of the infrastructure, systems and applications operation as well as user access management. In this tutorial, we will begin with a review of some basics and next will go with cloud specific security aspects. In the basics we will cover the meanings of Security, and Trust, which are different. We will also look at a Security Services Lifecycle Management (SSLM) model. Finally, we will turn to specifics about Security in Cloud Computing. Note we will apply these via a brief analysis of the AWS and Microsoft Azure security.
Transcript
Outline
Security is a complex domain and involves multiple aspects of the infrastructure, systems and applications operation as well as user access management. We will start with some basics and next will go with cloud specific security aspects. In the basics we will cover the meanings of Security, and Trust, which are different. We will look at a Security Services Lifecycle Management (SSLM) model. Then we will turn to specifics about Security in Cloud Computing
We will apply these via a brief analysis of the AWS and Microsoft Azure security. We will not discuss access control and cloud federation issues in detail in this tutorial. This is a subject for a separate tutorial.
Responsibilities Split in IaaS, PaaS, SaaS
We have seen this illustration in previous Lessons. No let us apply this illustration to Security. This illustration contrasts the different deployment models on the left, a traditional physical server deployment packaged product, and the on the right the three deployment models for Cloud, namely, IaaS, PaaS, SaaS.
The responsibilities of the Customer and the Provider are different as one goes from
Packaged product to the various models on Cloud. As shown for packaged product the entire stack is the responsibility of the User, from the hardware to the systems software to the application. When deploying on Cloud the responsibility shifts more and more from the User to the Provider as the higher levels of abstraction are used. As one can see in the SaaS model where the User is accessing a completed application, their responsibility is reduced to looking after only their Data.
Security management responsibilities split between Customer and Provider for IaaS, PaaS, SaaS service models in a similar manner. In all cases, there is a large underlying Security obligation on the Provider. They are responsible for physical security of the Cloud
datacenters as well as Updating firmware and software for platform and for customer
management components. They are also responsible for underlying Storage and Networking security. For example Physical Network Firewalls and Intrusion Prevention is a responsibility of the cloud provider. Usually the Cloud Provider will seek certification and keep ongoing compliance of the Cloud platform itself.
Transcript
That said, Certification and compliance of the cloud platform doesn’t imply security and compliance of the customer controlled components. Following the above diagram, the components which the User is responsible for with respect to Deployment, they are also responsible for with respect to Security. It can be seen then that End to End Cloud Security is a “shared” responsibility between the Cloud Operator and the Cloud User.
Security Technologies in Cloud: Network and Service Related Security
Protocols
This diagram in the Slide illustrates the highly inter-related character of security services and mechanisms.
Please note several distinct Security mechanisms in this diagram. At the bottom there is security for Physical Resources and the Network. There is the Cloud Platform security. There is the application and data security. And across these there is the federated access and delivery infrastructure. These layers are mutually dependent and connected to each other over a variety of connectivity protocols.
The diagram shown how logically Data are transferred between cloud layers, and it also shows how Data are communicated over secure network and messaging protocols such as IPSec/VPN and HTTPS/TLS/SSL.
Authentication and Authorization is present with each inter-service and inter-device (both physical and virtual) communication, at higher layer it can use also Security Token Service (STS) and SAML based security tokens.
TCP/IP Protocol Stack and Network Security Protocols
This slide shows the larger TCP/IP Protocol Stack and Network Security protocols Cloud Computing follows this model for both networking and for security. So much of the knowledge one may have about networking and security transfers to the Cloud domain. On the other hand, Cloud introduces many complications (mostly due to virtualization) and this adds complexity to security considerations.
What Should you Know about Security
While the Password is a basis for secure access it is not enough to secure your applications and services. There is whole stack of network and infrastructure or platform security services and mechanisms which need to be applied in a consistent way to ensure high system dependability and availability.
Transcript
Dependability means the extent to which you can trust or depend on the system We have seen how much the different cloud security layers and mechanisms must communicate with each other. Much of the Basis for Cloud Security is to have secure communication and data transfers in the security protocols and security mechanisms themselves.
Security is an overloaded term and may mean different aspects Network/communication Security -Data Security – Application Security -Operation Security –System Security What kind of data to protect
Application Data –Personal Data (User ID, personal information) – Infrastructure management data
Data security must be considered for at least 3 aspects
Data in transfer (Communication) –Data in-rest (Stored) –Data at run-time (Processed) We must also understand the Relations between Security and Trust
Comment to Technical trust
-Technical trust can only Yes or No –Trusted or Not Trusted
-Social or reputation based trust may have continuous value such as from 0 to 1
Different Sides of Security and Trust
The modern paradigm of remote distributed services and online/downloadable digital content provisioning makes security and trust relations between User and Provider more complex The User and Service Provider are the two actors concerned with own Data/Content security and each other System/Platform trustworthiness
Two other aspects of security/trust Data stored vs Data accessed/processed System Idle vs Active (running User session)
Trust Relations Between Provider and Customer
Now we move to more complex picture of trust relations between the User and the Provider The illustration in the slide shows the way to think about this.
On the left we see a “Trust Domain” which is associated with the User. You can see in this Trust domain there is the User client system, the User Data, and the User Identity Credentials (which may be a password or may be more)
Transcript
On the right we see a Trust Domain which is associated with the Provider. You can see in this Trust domain there is the cloud platform, the data stored by the Provider, the Application running on the Provider cloud, and the data controlled by the application.
These two domains establish a Trust Relationship between them which is bi-lateral as shown –for example the user trusts that the Cloud is in fact the cloud which the User thinks it is, and the Cloud trusts that the User is the User which is represented to the Cloud. Usually the User trusts the Provider through mechanisms including Secure DNS and Certificates. Usually the Provider trusts the User through a Passwords mechanism.
Cloud, OS, Network and Applications Trust Layers
This slide provides even deeper insight into security relations between components and layers of the cloud based services and user system or application.
In this diagram the Provider is on the left, and the User is on the right.
The Provider (cloud platform) employs a security model known as a Trusted Computing Base (TCB)
This means it has a “root of trust” tied originally to the Hardware. All layers above the hardware including the network, the cloud software itself, and the Virtual Machine
mechanisms (hypervisors) are tied back to this root of trust. This is why it is called a Trusted Computing Base approach. The software mechanism by which this trust is asserted is usually a Certificate.
The User side (application) employs a different trust model, referred to as OSI/Internet security. TCB cant be used because the hardware –in fact the total user system –is “in the wild” and subject to any sorts of modifications or endless variety. So a system based on credentials (secrets) are used to establish trust. These are usually in the form of passwords but can be keys, biometrics, challenge/response, etc.
This bilateral trust between Provider and User domain is implemented/used in Client/server and Service Oriented Architecture and in OS and hypervisor run-time. A secure
communications channel is set up (as illustrated) using an encrypted channel. This can be done using any number of means but is usually a form of Virtual Private Network (VPN). A protocol is followed between the two domains a the bilateral trust is established for a particular “task at hand” (like running the application on the cloud). This is called a Security Context.
Transcript
Cloud Computing Security – Challenges
Cloud Computing adds a number of challenges to Security.
Cloud is different because it runs modules which are dynamically provisioned using
automation. Most often, clouds utilize virtualization –in compute, in network, and in storage, all of which add additional levels of complexity to securing a cloud.
Starting with the most basic level, Cloud security infrastructure should provide a framework for dynamically provisioned cloud security services and infrastructure. As we discussed at the last slide, these services must be based on the hardware/platform based Root of trust. This is partly realized by the SSH secret keys generation during account creation at AWS and Microsoft Azure what you should have learned from hands on labs.
More strict security bootstrapping between provider and user domains should use TCB models and mechanisms implemented in the Trusted Computing Group Architecture (TCGA) and Trusted Platform Module (TPM)
Common Cloud Security Model
In the first days of using Cloud Computing, these were no generally agreed best practices for implementing security. These were some areas of incompatibility between the expected security model on the User side (client server or SOA) and the security model on the Provider side (kernel based OS and hypervisor security mechanisms).
A Common Cloud Security Model has been developed which embodies a best practice, now that there are more commonalities in the use cases of Cloud Computing and the way that Public and Private cloud work..
First, on the Cloud side, there is a known SLA and Provider based security model SLA between provider and user defines the provider responsibility and guarantees Providers undergo certification of their cloud infrastructure The Customer/User must trust the Provider Access from the User to the Provider uses VPN and SSH keys which are generated for user infrastructure/VMs Simple access control can extended with the Federated Identity
Management There is not an easy integration with legacy customer/tenant infrastructure and physical resources
Transcript
Cloud Environment and Issues to be Addressed
Now let us take a look at the Provider (Cloud) side, and understand what issues we must address. At the root of most of the challenges is that the Cloud utilizes heavily Virtualised services and environment
There is heavily automated On-demand provisioning and dynamic scalability
There is the notion of the multi-tenant application. Here, we have organizational notions in the sharing of the applications, for example a “company” or “organization” is the “master
subscriber”, within that there are departments, then within that there are actual Users (people who are employees, or students, or members).
Actual application execution as well as actual storage is occurring in changing (uncontrolled) environments, which vary widely from one cloud implementation to another
Simply encrypting is not a solution as this will often break indexing and searching. Index-able/Searchable encryption is still a research project. Finally the whole idea of bootstrapping (Trusted Computing Base approach) all the way to include the customer trust domain is not usually possible.
General Requirements to Cloud Security Infrastructure
What do people ask for when expecting comprehensive Cloud security?• Data protection during all stages
• Access control infrastructure virtualization and dynamic provisioning • Security services lifecycle management,
• Security context management • Trust and key management • SLA management
Security Services Lifecycle Management Model (SSLM)
Both Services Lifecycle Management (SLM) and Security Services Lifecycle Management (SSLM) models are implemented as a part of cloud services provisioning platform and have most of stages automated.
Security services must be bound to the main services they protect and bootstrapped to both cloud platform and customer side security services
Registration & Runtime Binding & Synchronization specifically target such scenarios as 1) Complex multi-component services provisioning 2) Large volume of data transfer, data partitioning 3) Services or processes failure 4) Services upgrade, elasticity, re-engineering
Transcript
To avoid having to repeat a full services provisioning process to establish a Trusted Computing Base.
Relation Between SSLM/SLM Stages and Supporting General and
Security Mechanisms
This table shows what security mechanisms are required/mandatory or recommended/optional at each SSLM stage.
As we discussed on the previous slide GRI (Generic Reservation ID) is important and creates a basis for all services linking, services binding to provisioning session and runtime
environment, and the whole process traceability
SLA negotiated is done at the initial stage, needs to be monitored during operation, and it is mandatory to be checked after services are terminated.
Practical Security Services and Mechanisms Used in Cloud
There are a number of Practical Security Services and Mechanisms which are Used in Cloud The most common is the use of the Virtual Private Network (VPN) Virtual Private Cloud (VPC) for creating virtual cloud infrastructure for each customer. Within this, one can use the Secure Shell (SSH) protocol, or the HTTPS and TLS/SSL protocols for secure web access. Each of these are based on the well-known Public Key Infrastructure (PKI) that provides a basis for each of these. PKI is used to generate keys for the encryption. Higher up the stack, we use Access control, that includes Authentication and Authorization, and is supported by Identity Management. This is tied into Identity Management service for user accounts management, which could be standalone to the Cloud, or tied in with Federated Access Control and Federated Identity Management. Make sure one has Key escrow to ensure restoration of encrypted data in case key held by data owner is lost!
Data Lifecycle Management Model
Once the access issues are solved, one turns to Data protection
In the Cloud, Data Protection must be provided for the whole data lifecycle
The generalized Data Lifecycle Management (DLM) model contains the following stages that are typically present in majority of user applications:
Data collection, registration and storage Data filtering and pre-processing Data processing, data analytics Data visualization, data archiving Data delivery, data sharing
Transcript
Data Security and Data Lifecycle Management
A good Data Protection scheme pays attention to Data Security in the context of Data Lifecycle Management Data security solutions and supporting infrastructure should address a number of problems related to the Data lifecycle
These are enumerated in the Slide Data security services and mechanisms should address the following functionality related to different data management activities These are
enumerated in the Slide
Data Protection in Cloud
There are many tools to address these requirements of Data Protection in Cloud • Data transfer between data source and cloud system or cloud storage. • Data encryption
• Data replication and migration. • Data restoration.
• Data availability. • Secure data storage.
These are each described in detail on the Slide
Cryptographically Enforced Data-Centric Security
Many advocates of Data Protection suggest that aggressive use of Cryptography –for data at rest, for data in motion –is one of the only ways to ensure Security.
There are two large challenges of Cryptographically Enforced Data-Centric Security. One is that data must be decrypted to be processed. This makes it practically unfeasible to achieve full protection of data at all infrastructure layers and during the whole data lifecycle. Also, many applications want to use large footprints of the data to do indexing and search, which again requires large quantities of the data to be decrypted to be indexed or searched. Is there a way for data to remain encrypted all the time?
Recent achievement in developing research has yielded the homomorphic encryption by Boneh and Waters (2007) which made it theoretically possible to process encrypted data. There are other methods of working directly with encrypted data as well, for example performing encrypted data comparison, subset queries and arbitrary conjunction of such queries. So far, there are real challenges with encrypting as much of one’s data as is practical and realizing the times when it is unencrypted are generating risk.
Transcript
Cloud Security Standards: NIST and US Federal
A number of standards and Best Practices documents are addressing Cloud Security in general. Although primarily developed for USA, NIST standards are worldwide accepted. NIST is known for their excellent definition of Cloud Computing technology and Cloud Computing Reference Architecture specified in the documents
NIST SP 800-145, A NIST definition of cloud computing, and NIST SP 500-292, Cloud Computing Reference Architecture, v1.0.
The full set of the cloud related standards includes those detailed on the Slide.
Cloud Security and Big Data Security Standards and Business
Continuity Planning (BCP)
A number of standards and Best Practices documents are addressing Cloud Security in general. Recently with the emergence of Big Data, a number of standards are also published addressing specifically Data Security.
Cloud Security Alliance is an authoritative body with wide international membership that provides wide research and best practices collection in cloud security and currently also covering Big Data
About cloud and Big Data reports
ENISA is a European body that is recognized for their research and activity on cyber infrastructure security with focus on risk and threats analysis.
Provided analysis in 2010 and recently published report “Overview of current and emerging cyber-threats” that analyses both threats to cloud computing and use of cloud computing for new types and scales of attacks.
NIST Cloud Computing Security Reference Architecture (NIST
SP800-299 Draft)
Based on NIST Cloud Computing Reference Architecture NIST SP500-292 (CCRA). The standard provides detailed analysis of the security architecture components for each of cloud services provisioning stakeholders Cloud Consumer Cloud Provider Cloud Broker Cloud Auditor Cloud Carrier
Transcript
The security infrastructure needs to be integrated over all cooperating members/stakeholders and Includes the following steps 1 –Categorise 2 –Identify security requirements 3 – Select architecture 4 – Assess 5 – Authorise 6 – Monitor Cloud Services
CSA3.0 Security Guidance for Critical Area of Focus in Cloud
Computing
The document uses CSA Cloud Security Alliance Cloud Services Model that is used to map the security concerns to the cloud services and functional components in different cloud services models IaaS, PaaS, SaaS .
Note that CSA splits concerns into two Domains –one is Governance, one is Operational. The slide details the components of each.
CSA Top Ten Big Data Security and Privacy Challenges
Big Data motivate more detailed look at the data security and privacy protection challenges and suggested solutions which are applicable to general data protection in cloud taking into account that that due to scale of Big Data the Big Data applications are implemented in cloud and rely on cloud infrastructure and platform services.
CSA Top Ten are defined for the following functional components
1 -Big Data sources that may include sensor, devices, large industrial objects as well as web, network and human activity 2 –Data input and data provenance 3 –Data processing
environment 4 –Cloud based Big Data infrastructure 5 –Data storage (cloud based) 6 –Data output and visualization
CSA Top Ten Big Data Security Challenges by Functional Groups
CSA details their Top Ten Big Data Security Challenges by Functional GroupsInfrastructure Security Access Control and Policy Data Privacy and Confidentiality Data Management
The proposed analysis of the security and privacy challenges includes the following sections: 1. Use cases definition
2. Modeling: formalizing a threat model that covers most of the cyber-attack or data-leakage scenarios
Transcript
4. Implementation: implementing the solution in existing infrastructures
Amazon Web Services Security Model
Now we turn to look at the security model as it is implemented in Amazon Web Services. The slide illustrates the three main part of the security aspects/solutions/measures that they addressed:
Cloud infrastructure (physical facilities, compliance, and platform) Cloud Services (cloud software)
Customer applications
Security is declared as one of critical importance to AWS cloud that is targeted to protect customer information and data from integrity compromise, leakage, accidental or deliberate theft, and deletion.
The AWS cloud platform design follows best practices for secure software design and includes formal internal design review, threats analysis, risk assessment, as well as regular penetration testing. AWS obtained most of the industry security and compliance certification.
AWS Security – Shared Responsibility Model
As discussed earlier in this lesson, there is a Shared Responsibility Model that splits responsibility for the security of different layers and components between a provider and a customer or tenant.
AWS follows this approach, clearly enabling the customer to do their share in the joint responsibility of the Cloud Service Provider and customer. The Cloud Service Provider ensures the cloud infrastructure security and compliance, and provides necessary security services. The Customer/user ensures data security, applications security, correct use of the cloud platform.
In the cloud, Security is a shared responsibility, it is no longer possible to provide a platform within which one can deploy any sloppy application and rely on the platform and network to make it secure. This is because of the complexity and scale-out of cloud, security constraints would hinder the ability to construct a large scale out cloud and thus, some of the
Transcript
Example: Security Responsibility Sharing in AWS IaaS Infrastructure
Services
This slide provides an illustration of the Shared Responsibility Model that splits responsibility for the security of different layers and components between a provider and a customer or tenant – specifically for AWS. One can see the specific recommendations made by Amazon. This illustration shows the shared responsibilities in an IaaS context.
For other cloud service models PaaS and SaaS the responsibility of AWS goes up to OS, network and firewall for PaaS, and also includes the application platform and container for SaaS. However, the responsibility for data always remains with the customer.
AWS Security Recommendations: Customer Side
Now we consider the recommended security best practices at each layer Recommended security methods for customer cloud infrastructure include:
Use Virtual Private Cloud (VPC) to create a secure environment for your cloud services in AWS Use security zoning and network segmentation based on security groups, Network Access Control Lists, host based firewalls Strengthen network security and ensure secure access for users and applications. Create threats protection layer in traffic flow and ensure protection against Denial of Service (DoS) attacks. The slide details a longer list of security best practices
Security in Amazon EC2 and S3
AWS implements the following security measures to protect the main cloud platform components and services. Amazon compute (EC2) Security implements:
Multiple levels of security including Guest Operating System, Firewall, API to manage VM instances Hypervisor that is a customized version of the Xen hypervisor allows running processes in four privilege modes: host OS is executed Ring 0; guest OS runs in Ring 1, applications run in Ring 3. Instances isolation is also provided by hypervisor that forwards all communication for instances via virtual firewall that resides in the hypervisor layer. Instant SSH keys generation for individual users and groups.
Amazon Simple Storage Service (Amazon S3) Security
S3 storage is accessed via SSL protocol Data security in rest is provided by encryption and multi-layer physical security AWS adopts a secure and reliable technique for storage device decommissioning.
Transcript
AWS Identity and Access Management (IAM)
AWS Identity and Access Management IAM provides functionality to securely control access to AWS services and resources for individual users and groups by defining individual and group permissions and policies. Examples of using AWS IAM
Fine-grained access control to AWS resources Manage access control for mobile
applications with Web Identity Providers Integrate with your corporate directory Multi-Factor Authentication for highly privileged users
Example: Multi-layer Security in AWS
This slide illustrates an example of how an application works with AWS to explicitly enable security at multiple levels
We are looking at the sample application topology we worked with earlier in this Lesson, What is shown is for each of the major application tiers, eg, Load Balancer, web tier, caching tier, Database Tier, AWS needs to be specifically configured to allow certain traffic to pass (and the remainder blocked).
AWS will not automatically over-ride what gets set up in deployment. It is very easy to make wide open security groups in AWS, which is why it is a good idea to check and configure each tier.
Microsoft Azure Cloud Security
Microsoft Azure demonstrates no less advanced security than AWS.
Microsoft has long term experience in developing security applications. Microsoft Secure software Development Lifecycle is widely respected and used best practice. Azure cloud design claims to follow these practices in the cloud platform security design.
Of course Azure also assumes the Shared Responsibility Model that splits responsibility for the security of different layers and components between a provider and a customer or tenant Three components of the cloud environment security:
Cloud infrastructure security Datacenter security, trustworthy design; secure operational procedures Certification and compliance; Cloud platform security services Serving both platform security and integration with the customer applications Access control, security policies, customer controlled security services Data protection: cloud platform and user controlled; Customer/tenants applications security
Transcript
Microsoft Azure Cloud Security Services
Azure Security Services from both the customer’s and providers’ operational perspectives: Federated identity and access management based on Microsoft accounts or organizational accounts, enabled by Azure Active Directory Service (AADS) Use of mutual SSL
authentication. Component isolation through a layered environment. Virtual Machine state maintenance and configuration integrity. Storage redundancy to minimize the impact of hardware failures. Monitoring, logging, and reporting on administrative actions. Built-in data protection. Control access to customer data and applications Protect data in transit and at rest Dedicated network connectivity with Azure ExpressRoute
Microsoft Azure Cloud Security Design Principles
Microsoft has detailed several of its key Cloud Security Design Principles. It is likely that AWS implements something like this as well
1. SSL mutual authentication for internal control traffic 2. Certificate and private key management
3. Least privilege principle is applied to running customer service on cloud 4. Access control model in Microsoft Azure Storage -different levels of security. 5. Isolation of hypervisor, Root OS, and Guest VMs
6. Isolation of Fabric Controller (FC)
7. Packets filtering is implemented at the level of Hyper-V hypervisor 8. VLANs and network segmentation provides isolation between segments 9. Isolation of customer access
Transcript
Microsoft Azure Security Controls and Capabilities
Azure then can deliver a Wide spectrum of Security Controls and Capabilities • Zero standing privileges
• Isolation
• Azure Virtual Networks and Encrypted communications • Data encryption
• Identity and access
• Patching and Antivirus/Antimalware protection • Intrusion detection and prevention systems
Example: AWS Cloud Certification and Compliance
Finalizing this tutorial we will give an example of the certification and compliance of AWS and Microsoft Azure clouds. You can assume that they almost equal what give a good basis for integrating services and resources from both platforms in a variety of possible applications. This slide lists the AWS compliance guidelines and standards.
Example: Microsoft Azure Certification and Compliance
Similar to AWS, here is the Microsoft Azure certification and compliance. You can see it is basically the same as the AWS compliance guidelines and standards
Wrap Up and Take Away
Security is complex domain and Cloud Security is bringing even more complexity factors to understanding and developing secure cloud based applications and consistent cloud security services.
Knowing the basic security and trust management models is important for understanding cloud security and cloud security services Security of the cloud platform is one of key concern areas for cloud provider, first, to protect their datacenter, and second, to provide competitive quality of service to their customers Cloud Security Services Lifecycle Model (SSLM) provides a basis for consistent security services design and integration Data protection in cloud must be provided at all cloud functional layers, across multiple domains, and along the whole data lifecycle Cloud security and data protection is an active standardization area. Major standardization bodies on cloud security are NIST, CSA, ENISA followed by industry related bodies Standardization is especially important for ensuring interoperability and
Transcript
developed cloud platform with the security in-design supported by numerous security certifications and compliances Three main cloud security domains: (1) cloud infrastructure and platform security; (2) cloud security services; (3) customer applications security
