Introduction to Infrastructure Security for

Cloud Computing
Macro Layers

A good way to think about the aspect of infrastructure security is via the macro layers.
Starting from the base infrastructure, which houses the facilities, system, and the
actual servers, there is a lot of security issues here. The base infrastructure also
includes the operating systems, and the different software components, database
systems and storages that make up the cloud.
Above that, is the virtualized infrastructure. If you have a virtual network as a cloud
consumer, you are going to configure that virtual network properly. But as a provider,
your task is to configure the virtualization properly. At the top layer, we have the
management plane, which is the glue that will tie up the cloud together.
Cloud Infrastructure Security Overview

How IaaS Works (Example)

Shown above is a simplified structure of how IaaS works. If we take a look at the
image, there are two resource pools provided: the Compute pool and the Storage
pool. The compute pool is composed of the physical servers with memory and CPU
components. And on top of that, are the hypervisors. On top of the hypervisors is
where we run our virtual machines or instances. Then we have the storage pool,
where we have the raw storage, which are virtualized using the Storage/Volume
Controller (think of it as a virtual hard drive). The Management Network links all the
controller together (Compute and Storage/Volume controllers).
If for instance, a user from the outside world request, say a Linux computer on top of
a LAMP stack, that request will go to the Compute Controller coming from the
Management Plane, and the Storage/Volume controller will determine the amount of
storage needed for the request. That information will be sent to the Compute
Controller, and the Compute Controller will assign the virtual machine to an actual
physical machine, and then everything will be wired together using that orchestration
layer. Other resources will be allocated such as the IP addresses, etc.
When all of that are up and running, and the virtual machines are booted up
successfully, that is when the Compute Controller will either return the API call in the
Management console or the virtual machine will be up and running ready for the user
to login with its credentials.
A simple request from the outside provides a lot of communications in the backend to
arrange for the resources needed for the particular request.

Public vs. Private

In private cloud, you are responsible for the security of all of these. You have to make
sure that you properly secure all the resources, facilities, and the hypervisors and
everything else. In public cloud, you only get to control what you consume, say for an
Apache that you installed in your virtual machine. You don’t get to have an access on
the underlying hypervisors and other resources.
Simplified Infrastructure Components
To make an IaaS work, you need a lot of software components. All of these
components need to be securely configured, patched, hardened, and maintained.

Securing Cloud Infrastructure

Software Defined Network
Underlying IaaS Networks
Nearly all IaaS have at least three different underlying physical networks. This is often
for performance reasons. You need to have different networks because of the volume
of traffic. This also benefits in the aspects of security.

Building Underlying Networks for Cloud

Virtual Networks

Major Virtual Network Types

Software Defined Networking is very different from the traditional type of networking
because what SDN does is to decouple the management plane from the underlying
physical infrastructure. So, if you think about how hypervisors virtualized VMs or
virtualized computers, SDN is what we used to virtualized a physical network. It allows
us to mix and match the pieces of networking without being restricted to the underlying
physical topology.
OpenFlow is an example of an enabling technology for SDN. There are other different
kinds of SDN that are out there but some cloud providers make their own type of SDN
that suits them. All SDN is essentially API-enabled that gives us a broad access, the
ability to control the network remotely from other networks. It allows customers the
flexibility to define their own networks, but it is also critical for the cloud providers
because it is the only way to build multitenancy.
Software multitenancy is a software architecture in which a single instance of software
runs on a server and serves multiple tenants. Systems designed in such manner are
"shared".
SDN Security Benefits
SDN brings a lot of benefits. One of the most obvious is easier isolation because of
the way things are encapsulated and routed around the SDN, you can have as many
of these networks running as your physical networks that can talk and see each other.
This is good for consumers
The other benefit is that your topology is not limited to your physical structure. For
example, you can put multiple overlapping virtual networks, even with the same
address ranges, on the same physical network.
On the security side, SDN Firewalls or Security Groups are programmable. They are
also Sofware defined and they are built-in. You can just program your network to drop
traffic that is not approved. They have default deny, they can be orchestrated and
automated. They have the granularity of a host firewall with the manageability of a
network firewall appliance.
SDN Firewalls / Security Groups
Cloud Network Security

Controlling Blast Radius with Virtual Networks and Cloud Account / Sub Account
/ Subscription Isolation
One of the biggest security advantages in the cloud is leveraging the inherent isolation
of the cloud environment to reduce the blast radius of an attack. We can do this in a
few different levels. One is, if you have multiple cloud accounts, if an attacker breaks
out on one of those accounts, they are not going to expand into other accounts. This
is not something we do to datacenters, because we really don’t have the funds to build
multiple datacenters and isolate them from each other.
But in the cloud, there is no cost typically for opening a new account. There is only a
cost for what you deploy to that account. It allows us to have a lot of smaller accounts
isolated from each other. Then, within the given account, we can have multiple virtual
networks. In SDN, you can have 5 networks with the same IP address range, all
running on the same account, that are allowed to talk to each other. That would control
the network blast radius.

Losing Network Visibility

One thing we really need to be aware of is that we cannot monitor virtual network the
way we monitor a physical network. A physical network has instances, machines,
servers talking to each other and we can tap on it to listen to the network traffic. We
have a lot of technology like spanning mirror port and other built in infrastructure to
enable this.
But in a virtual network, we have multiple virtual machines, multiple servers running
on top of the same physical server. And if an instance wants to talk to another instance
and they both locate to the same server, that traffic will not leave that server. We can’t
actually use the technology that we use for physical network to listen to the traffic.
However, we can use a special software agent or route that traffic to the physical
network, but this method is ineffective. What we can see here is it is much harder to
make a full packet capture on a virtual network. Gaining an isolation loses network
visibility but puts better security on a network.

Third Party Security Tools Advantages and Disadvantages

Bastion Networks / Accounts for Hybrid

Bastion Virtual Network or a transit Virtual Private Cloud (VPC) is a hybrid connection
between the data center and a dedicated account or a dedicated virtual network in
your cloud environment. Its the main connection between your data center and the
cloud.
A bastion host is a server whose purpose is to provide access to a private network
from an external network, such as the Internet. Because of its exposure to potential
attack, a bastion host must minimize the chances of penetration. For example, you
can use a bastion host to mitigate the risk of allowing SSH connections from an
external network to the Linux instances launched in a private subnet of your Amazon
Virtual Private Cloud (VPC).
In the image shown, we have three isolated account/ network up in the cloud. They
can’t talk to each other, but they have connection to talk to the Bastion Virtual Network
that connects them to the data center. Its a little bit complexity when it comes to
routing, but it allows us to manage the blast radius.

Software Defined Perimeter

The Software Defined Perimeter is a project of Cloud Security Alliance (CSA) that has
both open-source and commercial tools. If you think about a lot of isolated networks
out there, one of the problems is connecting your own employee, particularly
administrators that need to login to different kinds of servers and other resources that
are deployed in your cloud networks. Obviously, you want them to have some sort of
a VPN or an encrypted connection, and managing all of those can be complex.
Such is the concept of Software Defined Perimeter, where it uses a combination of
agents on devices, as well as gateways that are opt in on that environment. And that
can be on the cloud or your traditional data center.
The idea is being the user authenticates with their device through the Software
Defined Perimeter (SDP) controller and that controller mediates their connection using
a dynamic connection to whatever the destination is. It could be a cloud account, cloud
network, a subnet, or VPN in the traditional data center. The controller handles all the
authentication and authorization in one place and uses that to dynamically route the
user to the actual network that they are trying to connect into. This simplifies the
connection.
Provider and Consumer Responsibilities
Securing Compute Workloads

Workloads are more than Virtual Machines

Workloads in the cloud are far more than just VMs. VMs are commonly called
instances in the cloud world. Workloads also include different kinds of containers
that are deployed into the cloud. There are also serverless that are known as
function as a service where you just load up your code into the cloud and run inside
a container like it is running on top of a VM or a physical machine.
There are also other kinds of platform based execution. Think about the stored
procedure in a database. That is also a workload but doesn’t fit neatly into a VM or a
container or something like serverless.
Security controls vary a lot, but in general they are consistent. Make sure that
environment or features are properly secured. Makes sure that all applications
security are also secured.

Impact on Traditional Workload Security Controls

Running workloads in the cloud have some serious implications on some traditional
security controls.
Different Types of Workloads
Compute workloads can be broken down into three categories.
• Standard or Long Running - most traditional approach. These are the launch
VMs on your cloud environment. Commonly, we login and manage these VMs
like traditional servers.
However, as we move more into cloud, or more use of greater proliferation of
VMs, we now have some newer technology that are now deployed to help us
manage more workloads.
• Automated Configuration Management - these are tools like Chef, Puppet,
Salt or Ansible. They are the deploy agent that are able to connect to instances
and configure them based on the template.
This is our first introduction to Infrastructure as code (IaC). The template will
define exactly the configuration of the server. If somebody logs to the server
and make changes to the configuration, the next time that template runs (either
internally or externally), it will overwrite all the changes.
• Immutable - these are automatically deployed by an auto-scale group.
Typically, for this to work, they need a virtual image. Logins and remote
administrations are disabled since changes will not propagate to other
instances. To manage them, they replace the image and totally replace the
running system, that is, instead of patching/updating the old versions, they
replace them with a new version. Enables or hardens security because of its
immutable nature (for instance, disabling SSH).
Creating Immutable Images with Deployment Pipelines
Immutable images are normally created using deployment pipelines or continuous
integration. If you look at the left part of the image shown, we have three kinds of text
file, Server Configuration, Image/Container Configuration, and the Source
Code.

• Server Configuration - template for tool like chef, puppet, salt or ansible that
defines what the server is going to look like. This tool will configure the base
OS to match the server configuration.
• Image/Container Configuration - includes additional details about what you
are trying to build.
• Source Code - application codes if your are deploying an application.
• Version Control Repository - all of the configuration files are stored here. If
any file text may be changed, that updates the current version in the repository.
Also includes all the history of all changes done.
• Continuous Integration Server - any changes done in the text file will spin off
the continuous integration server and will perform security checks. It will
evaluate the text files and look at them and will run both pre and post tests on
the Master Image to make sure it complies with the security requirements. The
image can be deployed for productions once it was approved.
Provider and Consumer Responsibilities

Compute Security Recommendations

Management Plane Security

Management Plane
The Management Plane is how you access and control your cloud. It is the
metastructure and the way to administer everything in the cloud. It is how we manage
and provision our resources, stop/start the differen services, and configure various
resources in your environment.
There are three main things in the Management Plane:
• Authentication
• Access Control
• Logging/Monitoring
The management is the literal key to your private cloud and must be protected at all
times.
There are two ways to access the management plane:
• Web Console Access
o password
o federation
 o enable multi-factor authentication (MFA)
• API Level Acces
o different credentials
o HTTP signing
o Tokens
o OAuth/SAML

Make sure to use TLS.

Transport Layer Security, or TLS, is a widely adopted security protocol designed to
facilitate privacy and data security for communications over the Internet. A primary
use case of TLS is encrypting the communication between web applications and
servers, such as web browsers loading a website. TLS can also be used to encrypt
other communications such as email, messaging, and voice over IP (VoIP). In this
article we will focus on the role of TLS in web application security.
TLS was proposed by the Internet Engineering Task Force (IETF), an international
standards organization, and the first version of the protocol was published in 1999.
The most recent version is TLS 1.3, which was published in 2018.

Management Plane Security

All Management Plane are different. If you are managing private cloud, make sure to
manage the fundamental security of your Management Plane. You have to make sure
that you are using the right encryption certificate. However, no matter what type of
platform you are using, there are three typical process:
• Secure root account
• Manage non-root users
• Enable monitoring/ auditing

Root Account
The root account is the owner account. It is the first account that you have if you set
up a cloud environment and it is the most important account because if someone has
the access to that account, they have full ownership of that cloud deployment. This is
the most critical account that needs security.
Recommendations:
• Enable MFA
o store in a locked, centralized location
• Use isolated credentials - a designated email address or user account not used
for anything else
o use a name with a random seed if possible to reduce phishing
• If available, use account security questions
o record and store securely
 • Never use account except for emergencies

Cloud IAM Management

After you have created the root account, you start to manage the other user accounts
in your cloud environment. There are various ways to do this, depending on your cloud
provider. The following are the common ways:
• Role-based access control (RBAC)
• Variable granularity across providers/ platforms
• Variable granularity within product lines (cloud providers)
• Look for ability to integrate w/SSO or directory services
• Investigate third-party tools

Privileged Users
Monitoring Activities for Administrators
Business Continuity / Disaster Recovery

Rule 1: Architect for Failures

Rule 1 for cloud is architect for failures. You have to make sure that you are designing
to take advantage of the resiliency capabilities of your cloud platform. Any individual
assets in the cloud is potentially less efficient than it is on your traditional data center.
Virtual machines are not typically the same as the physical systems that you spent
years in designing and building in your traditional data center. The vast majority of
true business continuity in disaster recovery in cloud comes out for architecting for
resilency and architecting for failure.

Key Aspects of Business Continuity / Disaster Recovery

The first aspect is the continuity within the cloud provider/ platform, that is, if you
are deployed with a particular cloud provider, how do you keep things up and running
within that cloud provider assuming they are going to be up all the time.
The next is managing and preparing for cloud provider outages. This is really rare
for IaaS but has happened in SaaS. You may have to plan for this aspect.
The last one is portability, that is, if you want to move your resources from one
provider to another.

Cover the Entire Stack