You cannot deploy into the cloud unless the security model is a part of the original design.  Using Agile and other mature approaches to deployment, the security details might well change as the project moves from conceptual phases, into proof of concepts and pre-production environments.  Nevertheless, security must be a key principle around which the platform is created and implemented. All layers from network to application data security management, must be identified and understood, even if they are deemed not applicable for the project under consideration.

 

Cloud Security has many layers.  For any deployment to a public, private or hybrid-cloud platform, these layers in their entirety need to be considered.  A convenient set of frameworks is given in figure one which firms should use to help structure their approach to cloud security:

 

Figure 1:  Security frameworks

 

There exist many different security frameworks and certifications, all roughly based on the above.  COBIT is useful to align security with business strategy and objectives.  ISO provides a set of checklists (some relevant, many not), to assess if you are being operationally thorough in your security considerations.  NIST (National Institute for Science and Technology), can offer utility around tactical or network-level topological security, but as was with COBIT and ISO, you need to temper the NIST framework with reality and discard its more academic demands.  Cloud Security Best Practices (CSBP) will fall out of these frameworks and reality which will be based on real-world projects including proof of concepts which are targeted, audited, hacked and then iteratively improved.

 

Table 1 summarizes these best practices based on NIST and Cloud Security Best Practices.

 

Table 1: Cloud Security Best Practices

CSBP-Cloud Security Best Practices

Main Areas

Sub-Categories

NIST Category

Primary Owner

CSBP-PL

Planning

By application

Sensitive Data ranking

Security processes published

HA, DR, Security designs

Identity

-Business Environment

-Governance

 

Protect

-Access

-Data

 

Client

SI to help with CA, Auditor

CSBP-MT

Multi-Tenancy

Understand configurations

Configure AD, SAML or SSO (if being used), understand log-in, Key Management, Encryption, Masking

Identity

-Risk Assessment

Protect

-Protective

 

Client/Cloud Provider

CSBP-AC

Controlled Access by Role, Need

Least Privilege

Role based

Authentication, Authorization

Logging, Privilege Access Management

 

Identity

Protect

Detect

Client, SI

CSBP-DA

Data

At rest, in transit encryption

Masking, PAM

Logging

 

Protect

-Data

SI, Client

CSBP-AU

Automation

Pre-certify AMIs, patches upgrades

HA, DR, differences between complex/simple apps, Encryption, Masking

 

Protect

-Processes

-Maintenance

-Protective

SI, Client

CSBP-NE

Network

VPCs and proper subnets

Pre-certify configurations

Lock down instances access

Root Admin, Key Management

DNS

Identity

-BE

Protect

-Processes

-Maintenance

Detect

 

Client &Security partners

CSBP-AS

Asset Management

Integrate services with logs

Automate updates to logs

Approval and provisioning automated

Identity

-Asset

Detect

-Anomalies

-Monitoring

 

Client, SI integrate Logs/Monitoring

CSBP-MO

Monitoring

Network Provider filters

Perimeter security and logging

Secure DNS

Aggregate, continual monitoring

DOS provider, isolate traffic

 

Protect

Detect

Client, Network partners, CMDB

CSBP-GT

Global Threat Monitoring

Use reputable tool and service, Zero Day alerts

Protect

Detect

Sometimes necessary, External Party, Owner is Client

 

CSBP-CC

Change Control

Manual processes removed

All information to a config db

All Cloud services registered

Protect

Client, SI process of CR

 

CSBPs are based on projects which have used patterns from the Open Security Alliance organization outlined in Figure 2 amongst other reference architectures.  As mentioned there are various actors who will interact with Client’s platform and who will have different security concerns.  Table 1 above addresses those concerns.  Actors are given below.

 

Figure 2: SP-011 Cloud Security Pattern Open Security Alliance  

 

The above figure gives a comprehensive overview of security areas (perimeter, devops, mobile, cloud providers, configuration, provisioning, 3rd party integration), along with security roles for key actors. 

 

CSBP adhere to NIST as well.  NIST categories ‘Respond’ (planning, communications and analysis); and ‘Recover’ (Recovery, including DR); are built into the CSBP layers.  NIST makes these 2 processes more explicit, and usually they are manual – committee based.  The next sections explain the ideas behind the CSBP.

 

2.1 CSBP PLANNING

From a security standpoint, we need to consider what IT systems, applications, and data should or must remain within a legacy enterprise datacenter. Here are some considerations:

 

2.2 MULTITENANCY

Software-based access controls and permissions to isolate customers from one another in a multitenant cloud environment.

 

2.3 AUTOMATION IN A CLOUD

The first rule in an automated cloud is to plan and design a cloud system with as few manual processes as possible.

Pre-certify everything to allow automated deployment—avoid forcing any manual security assessments in the provisioning process.

  1. Pre-certify all “gold images” or templates that can be launched within new VMs. Certification of gold images is not just an initial step when using or deploying a new cloud.
  2. Perform scans and assessments of every new or modified gold image before loading it into the cloud management plat- form and presenting it for customers to order.
  3. Understand that when a new gold image is accepted and added to , the cloud operational personnel (provider or support contractor, depending on contractual terms) might now be responsible for all future patches, upgrades, and support of the template.
  4. Pre-certify all applications and future updates that will be available on the cloud. Additional packages for upgrades and patching of the OS and apps will also be deployed in an automated fashion to ensure efficiency, consistency, and configuration management.
  5. More complex multitiered applications (e.g., multitiered PaaS applications) will require significantly more security assessment and involvement during the initial application design.

 

2.4 NETWORK CONFIGURATION

It is common to have requests for additional network configurations or opening of firewall ports. An example for Client is port 22 for SSH access to EC2 instances and RDP port 3389 for the same.  These can be handled through a manual vetting, approval, and configuration process.  Here are some things to keep in mind:

  1. VPC(s) is/are mandatory.
  2. Applications that need to be Internet-facing should be further segmented and firewalled from the rest of the production cloud VMs and applications.
  3. Consider pre-certifying a pool of additional VLANs, firewall port rules, load balancers, and storage options and make these available to cloud consumers via the self-service control panel.

 

2.5 ASSET AND CONFIGURATION MANAGEMENT

The key to success is to also automate the updating of asset and configuration databases. This means that you configure the cloud management platform, which controls and initiates automation, to immediately log the new VM, application, or software upgrade into the asset and configuration databases. Here are some considerations:

  1. Reconsider all manual approval processes and committees that are contrary to cloud automation and rapid provisioning (which includes routine software updates).
  2. Update the legacy change control process by preapproving new application patches, upgrades, gold images, and so on so that the cloud automation system can perform rapid provisioning.
  3. Integrate the cloud management system to automatically update the configuration log/database in real-time as any new systems are provisioned and launched. These automated configuration changes, which are based on preapproved packages or configurations, should be marked as “automatically approved” in the change control log

 

2.6 MONITORING AND DETECTION OUTSIDE YOUR NETWORK PERIMETER (To be assessed 1,2 below)

We need to increase the radius of monitoring and detection to find threats before they even find or hit the Client Cloud network. Here are some areas:

  1. Third-party network hosting service in which all data traffic to the Client cloud infrastructure first goes through the provider’s network and filters. In addition, all outbound traffic from the Client cloud can be masked hiding all network addresses and services from the public Internet.
  2. Third-party provider of secure DNS services that has the necessary security and denial-of-service protections in place.  probably fulfils this 2nd role.  Ensure internal DNS servers are not in the attack vector as a DNS provider should take the brunt of an attack and forward only legitimate traffic.

 

2.7 CONSOLIDATED DATA IN THE CLOUD

A concentration of expertise and security tools is a benefit from having a Cloud platform, versus a widely distributed group of legacy or mediocre tools and skillsets. Here are some considerations:

  1. Continuous monitoring is the key to good security. Continuous monitoring in the cloud might mean protecting and monitoring multiple cloud service providers, network zones and segments, and applications.
  2. Focus monitoring and protections not only at the network or cloud perimeter, but before your perimeter begins.
  3. Focus on zero-day attacks and potential threats rather than relying solely on pattern or signature-based security that only contains past threats. Sophisticated attackers know that the best chance of success is to find a new vector into your network, not an older vulnerability that you’ve probably already remedied.

 

2.8 CONTINUOUS MONITORING

As soon as new systems are brought online and added to the asset and configuration management databases, the security management systems should immediately be triggered to launch any system scans and start routine monitoring. Here are some considerations:

  1. All new applications, servers/virtual servers, network segments, etc., should be automatically registered to a universal configuration database and trigger immediate scans and monitoring.
  2. Monitoring and security tools need to consolidate or aggregate statistics and system events to a centralized console, database, and support staff. In this case Splunk.

There are three key tenets of continuous monitoring:

1) Aggregate diverse data

Combine data from multiple sources generated by different products/vendors and organizations in real time.

2) Maintain real-time awareness

Utilize real-time dashboards to identify and track statistics and attacks. Use real time alerting for anomalies and system changes.

3) Create real time data searches

Develop and automate searches across unrelated datasets to identify the IP addresses from which attacks were originating. Transform data into actionable intelligence by analyzing data to identify specific IP addresses from which attacks originated and terminated hostile traffic.

 

2.9 DENIAL-OF-SERVICE PLAN

Denial-of-Service (DoS) attacks are so common it is when not if.

 

2.10 GLOBAL THREAT MONITORING

Consider implementing security tools, firewalls, and intrusion detection systems that subscribe to a reputable worldwide threat management service or matrix. These services detect new and zero-day attacks that might start somewhere across the globe and then transmit the patch, fix, or mitigation of that new threat to all worldwide subscribers immediately.

 

2.11 CHANGE CONTROL (Part of CR process)

When each new cloud service is ordered and automated provisioning is completed, an automated process should also be utilized to process change controls that can also feed or monitor be security operations. Here are some recommendations:

  1. Avoid all manual processes that might slow or inhibit the automated ordering and provisioning capabilities of the cloud platform.
  2. When new IaaS VMs are brought online they enter into the change control system as an “automatic approval.” This immediately adds the change to the database and can be used to trigger further notifications to appropriate operational staff or trigger automatic security or inventory scanning tools.
  3. Utilize preapproved VM templates, applications, and network configurations for all automatically provisioned cloud services. Avoid manual change control processes and approvals in the cloud ordering process.
  4. Record all VMs, OS, and application patching, updates and restores in the change control database.

SI's should work with Client and other vendors within the context of a Security Committee, to ensure that these 11 issues are handled by Security Best Practices, implemented, documented and reviewed during the life cycle of the project.