How CISOs must adapt their mental models to cloud security

Security leaders often go into the cloud with a lot of tools, practices, and skills. They also have mental models that are based on the premise. This can lead to efficiency and cost problems. It is possible to map their mental models to the cloud.

It is helpful to look at the types of threats that each cybersecurity model is trying to detect or block when trying to understand the differences between cloud and on-premises models.

On-premise threats were traditionally focused on data theft from corporate databases and file storage. These resources are best protected with layers of network, endpoint and sometimes application security controls. The corporate data crown jewels, or “crown jewels”, were not accessible via an API to the outside world. They were stored in publicly-accessible storage buckets. Other threats were also created to disrupt operations and deploy malware for different purposes. These could include outright theft or holding ransom data.

Some threats are specific to the cloud. Bad actors will always try to exploit the cloud’s ubiquitous nature. They scan IP addresses for open storage buckets and internet-exposed compute resources.

Gartner explains that cloud security requires major changes in strategy compared to how we protect on-prem data centres. To protect critical cloud deployments, processes, tools, and architectures must be developed using cloud-native methods. It is important to understand the security responsibilities of your cloud service provider and your company when you start cloud adoption. This will make you less vulnerable to attacks on cloud resources.

Cloud security transformations are a great way to better prepare CISOs for today’s threats, tomorrow and beyond. But they require more than a plan and a few projects. Cybersecurity team leaders and CISOs need to create new mental models to think about security. This will require you to translate your existing security knowledge into cloud realities.

To set the stage for this discussion, let’s define what “cloud native” is. Cloud native architecture is one that makes the most of the flexibility, distributed, scalable and flexible nature of public clouds. Although the term implies that one must be born in the cloud, we are not trying to be exclusive. A better term might be “cloud-focused” which means doing security “the cloudy’ way.

However we define it, adopting cloud is a way to maximize your focus on writing code, creating business value, and keeping your customers happy while taking advantage of cloud-native inherent properties–including security. It is possible to transfer legacy errors, which predate cloud by decades, into future cloud environments by simply lifting-and-shifting your existing security tools and practices to the cloud.

Cloud-native refers to removing layers of infrastructure such as network servers, security appliances, and operating systems. It is about modern tools that are cloud-native and designed for cloud computing. Another way to look at it is that you won’t have to worry about these things as you build code to make your life easier. This is the key to success. Security will follow the DevOps and SRE revolutions in IT.

This thinking can be extended to cloud native security. In this scenario, some of your existing tools are combined with solutions offered by cloud service providers. You can take advantage of cloud-native architecture to protect what’s built in the cloud. We’ve already discussed the differences between targeted threats on-prem and those targeting cloud infrastructure. Here are some other important areas that you should reevaluate when considering a cloud security mental model.

Network security

Some companies treat the cloud like a rented data centre for network security. Many of the traditional methods that worked well for decades on-premise are not suitable for cloud computing.

Concepts like a Demilitarized Zone (DMZ), can be adapted for today’s cloud environments. A modern approach to DMZ could use microsegmentation to control access for identity within context. You have strong control by ensuring that the right identity has access to the right resource in the right context. Even if you make a mistake, microsegmentation is able to limit the breach blast radius.

Cloud native organizations also encourage the use of new approaches to enterprise network security such as BeyondProd. Organizations also benefit from it because they can focus on who and what has access to your services, rather than where the requests originated.

Cloud adoption can have a profound impact on network security, but not all areas will change in the same manner.

Endpoint security

The concept of security endpoints changes in the cloud. It’s like a virtual server. What about containers? What about microservices? Software as a Service cloud model doesn’t have an end point. Users only need to be aware of what happens where along the cloud security path.

This mental model can be helpful: An API can be thought of as a type of endpoint. Cloud APIs can also benefit from some of the security thinking that was developed for endpoints. While the concepts of access security, permissions and privileged access can be transferred, they cannot be used for maintenance of an endpoint operating system.

Insecure agents can pose a risk to their clients even if they have been automated to work on virtual machines in a cloud environment. Example: The Microsoft Azure cross-tenant vulnerability highlighted an entirely new type of risk. It was not even known to many customers.

This is why, among the many endpoint security options, some vanish (such patching operating system for SaaS or PaaS), others survive (such the need to secure privilege access), and still others are transformed.

Response and detection

A move to the cloud will bring changes in the threat landscape and the way you respond to them. It is possible to use on-prem detection technology and methods as a foundation for future developments. It won’t help reduce risk in the way most cloud-first companies will require.

The cloud offers the chance to rethink your security goals, including availability, reliability, confidentiality, integrity, and integrity.

Cloud is distributed, immutable, API-driven and automatically scalable. It also focuses on the identity layer. There are often ephemeral workloads that were created for a specific task. These factors all impact how you manage cloud threat detection and require new detection methods.

Six domains are the best for detecting cloud threats: API, managed services and network. These cover network, identity and compute as well as container infrastructure. These devices also have specific detection mechanisms that allow for API access logs, network traffic captures, and API access logs.

Some approaches are less important than others (e.g. network IDS on encrypted connections), while others can increase in importance (such detecting access anomalies), and others transform (such detecting threats from backplane providers).

Data security

The cloud is changing the way we think about data security.

Cloud adoption will put you on the path to what Google calls “autonomic security .” This means that security has been integrated into all aspects of data lifecycles and is continuously improving. It makes it easier for users to use the cloud, removing them from having a multitude of rules about who, what, when and with which data. It allows you to keep up with ever-changing cyberthreats, business changes, and makes it easier for you to make business decisions quicker.

Like other categories, certain data security methods lose their importance or disappear. For example, manual data classification at the cloud scale. However, some approaches to data security remain important from on-prem and cloud, while others transform (e.g. pervasive encryption with secure key management).

Management of access and identity

Your cloud data center is not the same environment for access and identity management (IAM). Every person and every service in the cloud has their own identity. You want to be able control access.

IAM allows you to centrally manage cloud resources with fine-grained access control. Administrators can give you permission to access specific resources. This gives you complete control over and visibility to centrally manage your cloud resources. IAM provides a single view of security policy across all your organization, regardless of whether you have complex organizational structures or hundreds of workgroups and multiple projects.

You can grant cloud access at fine-grained levels with access management tools. This is far beyond the project-level. You can also create access control policies for resources that are more specific based on attributes such as device security status, IP address and resource type. These policies ensure that appropriate security controls are in effect when accessing cloud resources.

This is where Zero trust plays a strong role. Implicit trust in any one component of a complex interconnected system can pose significant security risks. Trust must be established through multiple mechanisms and continually verified. A zero trust security framework is required to protect cloud-native environments. All users must be authenticated, authorized and validated for security configurations and postures before they are granted access to cloud-based apps and data.

This means that IAM mental model from on-premise security generally survives, but many underlying technologies change dramatically and IAM’s importance in security increases significantly.

Cloud security: Shared destiny for more trust

Cloud is more than just “someone else’s computer.” Trust is a crucial component of your relationship to cloud service providers. Cloud service providers often acknowledge that you share responsibility. This means they provide the infrastructure, but you are responsible for many seemingly complex security tasks.

Google Cloud operates in a shared fate model to manage risk with our customers. It is our responsibility to ensure that our customers are able to deploy securely on the platform. We don’t want to be delineators as to where our responsibility ends. We are there to help you with the best practices for safe migrations to trusted clouds and operation.

Leave a Reply

Your email address will not be published. Required fields are marked *