Many companies assume their cloud vendor is responsible for and has adequate tools, policies, and procedures in place for protecting the data with which they are entrusted. While this is true to some extent, consumer data protection laws such as GDPR hold the owner of the data responsible if the cloud service is compromised.
“Using cloud services does not transfer the company’s risk to the vendor,” explains Sword & Shield Enterprise Security CEO and President John McNeely. “Security in the cloud is a ‘shared responsibility. Users need to pay close attention to their service agreements. Providers typically offer basic controls, which is helpful; but in the event of compromise the company – the data owner – is liable.”
This is why implementing defense in depth in the cloud is important. This article explains this approach, the unique challenges cloud cybersecurity faces, and how to protect your cloud environment.
Defense in Depth (DiD), also referred to as the Castle Defense, was originally a term used to define a military strategy that sought to protect critical assets by placing them behind multiple layers of defenses and less critical assets. This is similar to the way castles or citadels were constructed historically. This ensured that the most critical assets were protected despite an attacker’s success in defeating multiple defense layers. Today this term is commonly used by the United States Department of Defense for multi-layer security.
Many organizations use a perimeter-focused cybersecurity strategy that has limited-to-no visibility or control over potential malicious traffic inside the network perimeter, a single layer of defense.
Conversely, a network implementing defense in depth has multiple layers of protection, improving the probability that, if one layer is defeated, another will identify and block the attack. Additionally, attackers typically choose to target “low hanging fruit” – those that have fewer layers of defense – over “high-visibility”, or those that have numerous layers of security controls and a higher likelihood of being detected.
Defense-in-depth security controls come in many different forms but are classified into physical (like a locked door), technical (like data encryption), and administrative (policies and procedures).
With the explosion in the popularity of cloud computing, it’s important to explore implementing defense in depth in the cloud. However, information technology and security teams need to be aware this looks different than in a traditional network since the organization does not have the ability to implement all three types of security controls.
The main challenges in implementing cloud-based defense-in-depth arise from the fact that “the cloud” is not under organizational control. Since cloud-based services run on external servers managed by the security team of the cloud service provider (CSP), an organization’s security team does not have the same level of access and control as with on-premises solutions. Therefore, data governance methods that worked for traditional on-premises systems simply won’t work for the cloud.
As organizations move data to the public cloud, enterprise control decreases and more responsibility falls on the shoulders of the cloud providers. Most cloud service providers will not allow an organization to perform a security audit or penetration test of their systems, forcing cloud users to trust in the CSP to properly implement security controls that fulfill service level agreements. Organizations must shape their governance strategies to rely less on internal security and control, and more on their cloud provider’s offerings.
Cloud security is also made difficult by the fact that it does not fit into the paradigm of perimeter-focused security used by many organizations. Defense in depth involves defining a clear separation of “inside” and “outside” network operations and building multiple lines of defense separating the two. In the cloud, parts of the “inside” (the cloud) are accessible only by passing through the “outside” (the Internet) even from other parts of the inside (enterprise environment). This complicates the implementation of defense in depth since cloud-based systems are equally accessible from inside and outside the organization’s network.
While some security controls are not applicable to implementing defense in depth in the cloud, it is possible to apply a variety of requirements. While cloud consumers cannot implement physical controls (due to lack of physical access to cloud servers), they can implement both technical and administrative controls based upon the type of cloud architecture in use. Controls can be classified as external or internal to the cloud environment.
The first step in implementing cloud-based defense in depth is identifying the use of each cloud resource and the associated level of appropriate security and trust. For example, web servers hosted in the cloud have very different requirements than cloud resources storing internal customer databases. The security of each resource should be considered separately.
Ideally, public-facing and internal resources should be kept in cloud accounts completely isolated from one another unless absolutely necessary to do otherwise. If isolation is impossible, strictly defined interconnections should be utilized.
An important part of external cloud security is locking down access to the cloud systems. One of the advantages of the cloud is that it can be accessed from anywhere; however, this also presents security concerns.
Cloud-based virtual machines should be configured to only accept connections from within the organization’s network, preferably over a VPN tunnel utilizing adequate encryption (e.g. IPSec or SSL) and ideally strong access control such as a form of multi-factor authentication (MFA or 2FA).
Limiting access in this way is invaluable for security since it allows cloud-based resources to enjoy the same protections as internal assets.
Cloud resources should also have strong internal security.
“Compartmentalization” is often used to segregate data and services that do not need to be stored in the same location or accessed by the same groups of individuals. Within a virtual machine, access should be limited based upon the principles of need-to-know and least privilege to minimize the impact of a potential breach. For example, Amazon S3 buckets should always be set to private with access granted on an individual basis.
Sensitive information should be encrypted whether “at-rest” (being stored) or “in-transit” (being transmitted) with keys stored within the organizational network, not on cloud servers. All connections to cloud resources should use encrypted protocols like SSH and HTTPS or be tunneled using a VPN connection if possible.
Implementing defense in depth in the cloud involves treating the cloud as an extension of the organization’s internal network. By using a VPN and configuring cloud virtual machines to deny any other connections, an organization can apply their existing protections to their cloud infrastructure as well. Isolation of backend systems from public-facing ones and implementation of access management strategies like least privilege and need to know to decrease the impact of a potential breach. Defense in depth can be implemented in cloud ecosystems by treating the cloud as an extension of the enterprise network and configuring and securing it as such.