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.
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:
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:
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:
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:
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:
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:
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.