by Paul Caiazzo
Many companies assume cloud security for their data falls under the responsibility of their cloud service provider (CSP): That this entity has adequate tools, policies, and procedures in place for protecting the data with which they are entrusted.
While this is true to some extent - certain controls within a comprehensive cloud security program must be built into the cloud service offering itself - consumer data protection laws such as General Data Protection Regulation (GDPR) hold the owner of the data responsible if the cloud service is compromised. Additionally, companies leveraging cloud services who experience a breach still have to manage the reputation and financial fallout associated with a breach, whether it was their ‘fault’ or not.
Using cloud services does not transfer the company’s risk to the vendor: Security in the cloud is a "shared responsibility". Therefore, 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.
Users with sensitive workloads containing personally identifiable information (PII), electronic protected health information (ePHI), or other confidential data must implement extra measures to ensure their approach to security layers on top of the baseline controls the CSP provides. This underscores the importance of implementing defense in depth in the cloud.
This article explains the argument for cloud security using defense in depth, the unique challenges of implementing cloud cybersecurity, and how to comprehensively 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. That single layer ultimately can become a single point of failure in a security strategy.
Conversely, a network implementing defense in depth has multiple layers of security controls improving the probability that, if one layer is defeated, another will identify and block the attack. Ideally, these controls are layered in a manner that gives the organization the best chance of preventing exposure to risk, but also achieving the critical measure of detecting when such controls have failed.
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. These compromised systems then become a launchpad for more advanced attack strategies, now more likely to surreptitiously succeed.
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 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 and must rely upon the CSP to provide a subset of them.
Related Reading: Monitoring Telework Security with Disappearing Network Perimeters
The main challenges in implementing cloud security using defense in depth arise from the fact that “the cloud” is not under the customer’s control. The nuances of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) cloud motions complicate this further, as the set of controls a customer should expect from the CSP will vary greatly between these models.
Within a SaaS model, for instance, services run on external servers managed by the security team of the CSP, and the customer’s security team does not have the same level of access and control as with on-premises solutions. Within an IaaS model, the CSP controls and secures the cloud itself, but the customer must implement controls within their cloud workloads themselves. Therefore, data governance and security approaches that worked for traditional on-premises systems do not directly map to the cloud.
Regardless of the cloud model, it is a certainty that as organizations move data to the public cloud, enterprise control decreases, and some control 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. This may not align with an enterprise’s risk tolerance, and strategies must be developed to mitigate risk down to an acceptable level.
Cloud security is also made difficult by the fact that it does not fit into the model of perimeter-focused security used by many organizations. In today’s cloud-enabled world, the perimeter of the network is an increasingly blurry line. Defense in depth involves defining a clear separation of “inside” and “outside” network operations and building multiple lines of defense separating the two.
Leveraging cloud resources means establishing multiple layers of defense within multiple environments, and this may require different technologies to be deployed to different enclaves. This complicates management and administration, and without proper planning and care, could result in varying levels of security across segments of the enterprise environment.
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, an IaaS cloud environment such as AWS, Azure, or GCP being used to host a public website has very different requirements than environments hosting databases containing sensitive or confidential information. The security needs of each resource should be considered separately, and the controls applied to each environment must be commensurate with the level of risk associated with exposure.
Ideally, public-facing and internal resources should be kept in cloud environments completely isolated from one another unless absolutely necessary to do otherwise. If isolation is impossible, strictly defined interconnections should be utilized and can be implemented using both the tools available within the CSP’s management interface as well as third-party tools which can be integrated into the environment.
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 trusted connections. This can be done via traditional VPN tunneling technology or the more advanced Zero Trust Networking approach where user context is derived directly at the endpoint prior to brokering secure access to the requested cloud resources.
Regardless of the technology implemented, all organizations should implement strong authentication controls, including multifactor authentication. Organizations with multiple cloud presences should implement a Cloud Access Security Broker (CASB) tool to ensure Identity and Access Management controls are applied consistently across all cloud resources.
Limiting access in this way is invaluable for security since it allows cloud-based resources to enjoy the same protections as internal assets.
Related Reading: 10 Factors for Cloud Security During Selection and Implementation
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 – a very common misconfiguration enables S3 buckets, often containing sensitive information, to be accessed by anyone.
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.
Your security monitoring strategy also needs to incorporate your cloud environments. Modern security information and event management (SIEM) and endpoint detection and response (EDR) technology can be applied to cloud workloads and should reflect detection strategies applicable to the tactics, techniques, and procedures attackers use to compromise cloud environments. Utilize API integration with the CSP’s security tools, such as AWS’ Cloudtrail and Cloudwatch, Azure Event Hub, and GCP Security Command Center to capture as much relevant security information as possible.
Implementing cloud security using defense in depth involves treating the cloud as an extension of the organization’s internal network. By using secure connectivity, 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 implementing access management strategies like least privilege and need to know to decrease the impact of a potential breach.
Monitoring the cloud for potential threats will help you stay situationally aware of when your defense strategies fail so you can quickly mitigate a threat before it becomes a compromise. 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.
Avertium offers cloud security consulting to add more rigor, more relevance, and more responsiveness to your cloud-based services. Contact us to start the conversation.
SaaS solutions and the hybrid cloud improve business operations but increase security risks. Download this white paper on how to mitigate these risks.
Paul brings his wealth of cybersecurity experience to guide Avertium customers through challenging security problems while keeping business goals and objectives at the forefront. His primary focus is on business development, partner and client engagement, and other strategic initiatives.