Cloud Security Automation

Prashant Priyam

• Publisher: Packt Publishing
• Year: 2018
• ISBN:
  9781788622196
• Edition: 1
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

Secure public and private cloud workloads with this comprehensive learning guide.About This Book• Take your cloud security functions to the next level by automation• Learn to automate your security functions on AWS and OpenStack• Practical approach towards securing your workloads efficientlyWho This Book Is ForThis book is targeted at DevOps Engineers, Security professionals, or any stakeholders responsible for securing cloud workloads. Prior experience with AWS or OpenStack will be an advantage.What You Will Learn• Define security for public and private cloud services• Address the security concerns of your cloud• Understand Identity and Access Management• Get acquainted with cloud storage and network security• Improve and optimize public and private cloud security• Automate cloud security• Understand the security compliance requirements of your cloudIn DetailSecurity issues are still a major concern for all IT organizations. For many enterprises, the move to cloud computing has raised concerns for security, but when applications are architected with focus on security, cloud platforms can be made just as secure as on-premises platforms. Cloud instances can be kept secure by employing security automation that helps make your data meet your organization's security policy.This book starts with the basics of why cloud security is important and how automation can be the most effective way of controlling cloud security. You will then delve deeper into the AWS cloud environment and its security services by dealing with security functions such as Identity and Access Management and will also learn how these services can be automated. Moving forward, you will come across aspects such as cloud storage and data security, automating cloud deployments, and so on. Then, you'll work with OpenStack security modules and learn how private cloud security functions can be automated for better time- and cost-effectiveness. Toward the end of the book, you will gain an understanding of the security compliance requirements for your Cloud.By the end of this book, you will have hands-on experience of automating your cloud security and governance.Style and approachThis book follows a step-by-step, practical approach to help automate and secure your cloud account structure in an Amazon Web Services (AWS) and OpenStack environment.

Private Cloud Security

In the first chapter, we learned about the different types of cloud, which are private, public, and hybrid.

A private cloud is a type of cloud that is deployed for any organization for their internal use. A private cloud is intended to enable the organization to have a self-service, elastic, and scalable model of IT infrastructure and services.

Prior to the private cloud, organizations used to host their applications either on bare metal servers or in a virtualized environment. Bare metal or virtualized environments lacked self-service features; however, scaling and elasticity could be achieved, but with great expenses in terms of human operations.

Making the environment fault tolerant and decoupled was still a challenge. For a development organization, where different technology groups are busy in development operations, it was a very difficult and a time-consuming task to provide the organization and keep track of infrastructure to run their staging and production workloads.

To deploy a private cloud, there are many popular technologies available, such as Apache CloudStack, OpenStack, and Microsoft Azure Stack.

For this chapter, our focus will be on OpenStack. As you might know, OpenStack private cloud combines different open source projects for different services, such as networking, computing, storage, and dashboards.

In this chapter, we will learn how to ensure the security of each service and layer responsible for building the private cloud.

In OpenStack, we basically secure or bridge the security of the public or user domain, management domain, and data domain. In OpenStack, components communicate with each other via APIs using a message queue service called RabbitMQ. OpenStack is the best example of a decoupled IT infrastructure.

In OpenStack, we have the following core components:

• Hypervisor: KVM/ESXi/XenServer/Hyper-V
• Database: MySQL
• Message Queue: RabbitMQ
• Network service: Neutron (in the earlier version, it was nova-network)
• IAM: Keystone
• Image store: Glance
• Block storage: Cinder
• Object storage: Swift
• Compute: Nova
• Dashboard: Horizon

Now, let's see how to enable security for each component.

Securing hypervisor

Hypervisor is a critical component for OpenStack or any private/public cloud environment. One should select a hypervisor very carefully. There are a few parameters that one should consider when selecting a hypervisor, because in any cloud, underlying virtualization technology enterprise-level capabilities are in the realms of scalability, resource efficiency, and uptime.

Let's see the parameters involved in selecting the hypervisor:

• Skills and expertise of your team: The more expertise your team has in the project and in technology, the less are the chances of mistakes. It's a very important factor when adopting any technology, this applies for the hypervisor as well. For the hypervisor, you also need to do patch management, configuration, and security management tasks. Having internal skills and expertise increases the availability of your systems, allows segregation of duties, and mitigates problems at any point in time.
• Maturity of product or project: One always adopts projects or products that are mature. It helps us to ensure the safety, security, and success of the environment. You need the right skill set to run your project and, for this, availability of skill sets is mandatory. The quality of the community has a direct impact on the timeliness of bug fixes and security updates. Let's take a look at the factors affecting the maturity of the project:
  • Availability of skills sets in the market
  • Active developer and user communities
  • Timeliness and the availability of updates
• Common criteria: Common criteria is an internationally standardized software evaluation process, used by governments and commercial companies to ensure software technologies perform as advertised. As per NSTISSP, number 11 mandates that US government agencies only procure software that has been common criteria certified. Apart from this, OpenStack evaluates the hypervisors on different sets of criteria such as audit, RBAC, mandatory access control, object reuse, security management, and storage encryption. Common criteria evaluates how the technology is developed:
  • How is the source code management performed?
  • How are users granted access to build systems?
  • Is the technology cryptographically signed before distribution?
• Certification and association: This depicts the production readiness and testing of the hypervisor platform, apart from the regulatory requirement.
• Hardware concerns: When selecting the hypervisor, you also need to concentrate on the physical hardware. Apart from this, you also need to focus on the additional features or capabilities the hardware is providing and how these can be utilized with the hypervisor.
• Other security concerns: When selecting a hypervisor platform, you should also think of the availability of specific security features. Let's see the list of security features of hypervisors:
  

  	XSM	sVirt	TXT	AppArmor	cgroups	MAC policy
  KVM		X	X	X	X	X
  Xen	X		X
  ESXi			X
  Hyper-V

  
  
  The preceding table shows the security features of a hypervisor. We have also seen the point on which OpenStack lets you choose a suitable hypervisor.

Hypervisors provide one feature called PCI passthrough. This enables the instance to have direct access to resources. However, this leads to the following two security risks:

• Direct memory access (DMA): DMA allows hardware devices to access arbitrary physical memory addresses in the host computer. Usually, video cards have this capability, but the instance should not be given such access, as it will give full access to the system and other instances running on top of it. The Physical Server vendor uses an Input Output Memory Management Unit (IOMMU) to manage the DMA.
• Hardware infection: This happens when the instance makes some malicious modification of firmware or some other part of a device. As the same machine will be running multiple VMs, it can affect other VMs as well. If this happens, the VM instance can run its code outside of the specified security domain. It's a very significant breach, which can lead to additional exposure such as access to the management network. To solve this hardware infection problem for example, one option could be to re-flash the firmware after use. Trusted Platform Module (TPM) technology is a solution that is used to unauthorize changes to firmware. However, it is always recommended to disable PCI passthrough, until and unless it is not clearly specified and the associated risk of PCI passthrough is calculated.

Securing KVM

For a KVM hypervisor, we enable security using compiler hardening. The current generation compilers come with a variety of compile-time options to improve the security of the resulting binaries.

KVM features include the following:

• Relocation read-only (RELRO): This hardens the data section of an executable. It also has two types, Full RELRO and Partial RELRO. For QEMU, Full RELRO is the best choice. This will enable the global offset table to be read-only and place various internal data sections before the program data section in the resulting executable.
• Stack measurement: This positions values on the stack and verifies their presence to help prevent buffer overflow attacks.
• Never Execute (NX): This is also known as Data Execution Prevention (DEP). It ensures that data sections of the executable cannot be executed.
• Position Independent Executable (PIE): This produces a position-independent executable.
• Address Space Layout Randomization (ASLR): This ensures that the placement of both code and data regions will be randomized. This is also enabled by the kernel, when the executable is built with PIE.

Apart from these, there is another feature to enable security in KVM called mandatory access control (MAC). Compiler hardening makes it very difficult to attack the QEMU process. In case the attacker is successful in the attack, then MAC helps to control it. MAC restricts the privileges on QEMU processes to only what is needed. This is completed using sVirt, SELinux, or AppArmor.

sVirt stands for secure virtualization, which is an application of SELinux. It is designed to apply separation control based upon labels and provides isolation between virtual machine processes, devices, data files, and system processes acting upon their behalf. sVirt implementation helps to protect hypervisor hosts and virtual machines against the following two primary threats:

• Hypervisor threat: When a virtual machine is running with a compromised application, there is a chance that it will infect the underlying physical hardware configuration and it can also expose the network configuration.
• Virtual machine threat: On hypervisor, we run multiple virtual machines. If there is a VM running with a comp...

Table of contents

• Title Page
• Copyright and Credits
• Packt Upsell
• Contributors
• Preface
• Introduction to Cloud Security
• Understanding the World of Cloud Automation
• Identity and Access Management in the Cloud
• Cloud Network Security
• Cloud Storage and Data Security
• Cloud Platform Security
• Private Cloud Security
• Automating Cloud Security
• Cloud Compliance
• Other Books You May Enjoy