Cloud Security Best Practices – an implementation framework

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, 3^rd 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:

• Perform assessments of each application and data repository to determine the security posture, suitability, and priority to transition to the cloud. Match security postures to the cloud architecture, controls, and target security compliance standard.
• Work with application and business owners to determine which applications and data you can move easily to a cloud and which you should evaluate further or delay moving to a cloud. Repeat this assessment on all key applications and data repositories to develop and priority list with specific notations on the desired sensitivity, regulatory, or other security classifications.
• Determine who the consumers of the cloud services will be. If multiple departments or peer agencies will be using the cloud service, determine which security team or organization controls the standards for the overall cloud or each application workload:
  • Adopt a baseline security posture so that individual consumers or peer agencies will be more involved in settings the security standards for their unique applications and mission critical workloads.
  • Publish the security operational processes, ownership, and visibility or statistics, events, and reports to ensure acceptance of the cloud by consuming agencies and users.

 

2.2 MULTITENANCY

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

• Understand how multitenancy is configured. In Cloud Provider public cloud, the use of software-based access controls, roles-based permissions, storage, and hypervisor separation is standard.
• Implement or connect an enterprise identity management system such as Active Directory, LDAP, or SAML service.

 

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.

• Adopt the theme “relentless pursuit of automation.”
• Eliminate any legacy security processes that inhibit rapid provisioning and automation.

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 2^nd 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.

• Isolate Client’s inbound and outbound network traffic behind a third- party provider that has DoS protections, honey pots, and dark networks that can absorb an attack and effectively hide your network addresses and services from public. This DOS should be provided by the Cloud vendor, but it is the responsibility of the SI, and client to ensure that DoS defences are in depth and available.
• Have a plan for when a DoS attack against your network occurs. Perhaps deploy further traffic filters or blocks to try and redirect or block the harmful traffic. Maybe you have another network or virtual private network (VPN) that employees and partners can revert to during the attack and still access your cloud-based services. This plan should be confirmed with the Cloud Provider or the hosting firm managing the network.

 

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.