How to apply cloud security controls in the network
Implementing cloud security controls in the network requires a careful balance between protecting points of connectivity while still making it easy for users to access services.
The following is an excerpt from The Official (ISC)2 Guide to the CCSP CBK, Second Edition, by Adam Gordon, CISSP-ISSAP, ISSMP, SSCP. This section from Domain 1 reviews different types of cloud security controls and practices that are recommended for protecting cloud networks. Concepts covered include encryption, data in transit, data at rest and key management.
Network security looks to cover all relevant security components of the underlying physical environment and the logical security controls that are inherent in the service or available to be consumed as a service (SaaS, PaaS, and laaS). Two key elements need to be drawn out at this point:
- Physical environment security ensures that access to the cloud service is adequately distributed, monitored, and protected by underlying physical resources within which the service is built.
- Logical cloud security controls for the network consist of link, protocol, and application layer services.
As a cloud customer and a CSP, both data and systems security are of utmost importance. The goal from both sides is to ensure the ongoing availability, integrity, and confidentiality of all systems and resources. Failure to do so has a negative impact from a customer, confidence, brand awareness, and overall security posture standpoint.
Taking into account that cloud computing requires a high volume of constant connections to and from the network devices, the always on and always available elements are necessary and essential. In the cloud environments, the classic definition of a network perimeter takes on different meanings under different guises and deployment models.
For many cloud networks, the perimeter is clearly the demarcation point. For other cloud networks, the perimeter transforms into a series of highly dynamic micro-borders around individual customer solutions or services (to the level of certain data sets and flows within a solution) within the same cloud, consisting of virtual network components.
In other cloud networks, there is no clear perimeter at all. Although the network may be typically viewed as a perimeter and a number of devices within those perimeters communicating both internally and externally, this may be somewhat less clear and segregated in cloud computing networks.
Next, we'll look at some of the add-on components that strengthen and enhance the overall security posture of cloud-based networks. You will see how to utilize these cloud security controls and learn why they play a fundamental function in technology deployments today.
The need for the use of cryptography and encryption is universal for the provisioning and protection of confidentiality services in the enterprise. In support of that goal, the CCSP should ensure that he understands how to deploy and use cryptography services in a cloud environment. In addition, it's important to integrate strong key management services and a secure key management lifecycle into the cryptography solution.
The need for confidentiality along with the requirement to apply additional cloud security controls and mechanisms to protect information and communications is great. Whether it is encryption to a military standard or simply the use of self-signed certificates, everyone has different requirements and definitions of what a secure communications and cryptography-based infrastructure looks like. As with many areas of security, encryption can be subjective when you drill down into the algorithms, strengths, ciphers, implementation methods, and so on.
As a general rule of thumb, encryption mechanisms should be selected based on the information and data they protect, while taking into account requirements for access and general functions. The critical success factor for encryption is to enable secure and legitimate access to resources, while protecting and enforcing controls against unauthorized access.
The cloud architect and administrator should explore the appropriate encryption and access measures to ensure that proper separation of tenants' information and access is deployed within public cloud environments. Additionally, encryption and relevant controls need to be applied to private and hybrid cloud deployments to adequately and sufficiently protect communications between hosts and services across various network components and systems.
Data in transit (data in motion)
Also described or termed data in motion, data in transit focuses on information or data while in transmission across systems and components typically across internal and external (untrusted) networks. Where information is crossing or traversing trusted and untrusted networks, the opportunity for interception, sniffing, or unauthorized access is heightened -- driving the need for strong cloud security controls.
Data in transit can include the following scenarios:
Data transiting from an end user endpoint (laptop, desktop, smart device, and so on) on the Internet to a web-facing service in the cloud;
Data moving between machines within the cloud (including between different cloud services), such as between a web virtual machine (VM) and a database; and
Data traversing trusted and untrusted networks (cloud- and non-cloud-based environments).
Typically, the cloud architect is responsible for reviewing the way data in transit will be protected or secured at the design phase. Special consideration should be focused on how the cloud will integrate, communicate, and allow for interoperability across boundaries and hybrid technologies. Once implemented, the ongoing management and responsibility of data in transit resides in the correct application of security controls, including the relevant cryptography processes to handle key management.
Perhaps the best-known use of cryptography for the data in transit scenario is secure sockets layer (SSL) and transport layer security (TLS). TLS provides a transport layer -- encrypted "tunnel" between email servers or message transfer agents (MTAs), whereas SSL certificates encrypt private communications over the Internet using private and public keys.
These cryptographic protocols have been in use for many years in the form of hypertext transfer protocol secure (HTTPS), typically to provide communication security over the Internet, but it has now become the standard and de facto encryption approach for browser-to-web host and host-to-host communications in both cloud and non-cloud environments.
Recent increases show a number of cloud-based providers using multiple factors of encryption, coupled with the ability for users to encrypt their own data at rest within the cloud environment. The use of symmetric cryptography for key exchange followed by symmetric encryption for content confidentiality is also increasing.
This approach looks to bolster and enhance standard encryption levels and strengths of encryption. Additionally, IP security (IPSec), which has been used extensively, is a transit encryption protocol widely used and adopted for virtual private network (VPN) tunnels; it makes use of cryptography algorithms such as Triple DES (3DES) and Advanced Encryption Standard (AES).
Data at Rest
Data at rest focuses on information or data while stagnant or at rest (typically not in use) within systems, networks, or storage volumes. When data is at rest, appropriate and suitable security controls need to be applied to ensure the ongoing confidentiality and integrity of information.
Encryption of stored data, or data at rest, continues to gain traction for both cloud-based and non-cloud-based environments. The cloud architect is typically responsible for the design and assessment of encryption algorithms for use within cloud environments.
Of key importance for both security and performance is the deployment and implementation of encryption on the target hosts and platforms.
When establishing cloud security controls, the selection and testing of encryption form an essential component prior to ensuring performance impacts. In some cases, encryption can affect performance.
User interface (UI) response times and processor capabilities are up to a quarter or even half of the processor in an unencrypted environment. This varies depending on the type, strength, and algorithm. In high-performing environments with significant processor and utilization requirements, encryption of data at rest may not be included or utilized as standard.
Encryption of data at rest provides, assists, and assures organizations that opportunities for unauthorized access or viewing of data through information spills or residual data are further reduced.
Note that when information is encrypted on the CSP side and in the event of discrepancies or disputes with the providers, it may prove challenging to obtain or extract your data.
In the old traditional banking environments, two people with keys were required to open the safe; this led to a reduced number of thefts, crimes, and bank robberies. Encryption, as with bank processes, should never be handled or addressed by a single person.
Encryption and segregation of duties should always go hand in hand. Key management should be separated from the provider hosting the data, and the data owners should be positioned to make decisions (these may be in line with organizational policies) but ultimately should be in a position to apply encryption, control, and manage key management processes, select the storage location for the encryption keys (on-premises in an isolated location is typically the best security option), and retain ownership and responsibilities for key management.
Why key management is vital
From a security perspective, you remove the dependency or assumption that the CSP is handling the encryption processes and cloud security controls correctly.
Also, you are not bound or restricted by shared keys or data spillage within the cloud environments because you have a unique and separate encryption mechanism to apply an additional level of security and confidentiality at a data and transport level.
Common approaches to key management
For cloud computing key management services, the following two approaches are most commonly utilized:
Remote Key Management Service (KMS): This is where the customer maintains the KMS on-premises. Ideally, the customer will own, operate, and maintain the KMS. This way the customer can control the information confidentiality, and the CSP can focus on the hosting, processing, and availability of services.
Note that hybrid connectivity is required between the CSP and the cloud customer for the encryption and decryption to function.
Client-Side Key Management: Similarly to the remote KMS approach, the client-side approach looks to put the customer or cloud user in complete control of the encryption and decryption keys.
The main difference here is that most of the processing and control is done on the customer side. The CSP provides the KMS; however, the KMS resides on the customer's premises, where the customer generates, holds, and retains the keys.
Note that this approach is typically utilized for SaaS environment and cloud deployments.
CCSP® is a registered mark of (ISC)².