What exactly is cloud security, and why is it important for enterprises to incorporate it into their business operations?
In this video, I'm excited to take you through some key areas around cloud security, including the importance of understanding shared responsibility, security and different types of architectures, and the need to weave security directly into your DevOps pipeline.
If you enjoy this video, make sure you subscribe to our YouTube channel so that you can see the many others that we'll be releasing.
- IBM Cloud Security
- Cloud Security: An Introduction
- DevOp: An Essential Guide
- A full YouTube playlist of our lightboarding videos
What is Cloud Security?
Hi, I'm Nataraj Nagaratnam, and I'm from IBM Cloud.
Traditionally, when you deploy an application, you have the entire data center, the servers that you run—you're responsible for all of it.
In the cloud model, that's a shared responsibility between you and the cloud provider. In a shared responsibility model, you need to rethink security on what your responsibility is and what the cloud provider's responsibility is.
Shared responsibility with PaaS, IaaS, and SaaS
Let's take Platform-as-a-Service (PaaS) as an example. When you look at PaaS, you're building applications, migrating data to the cloud, and building applications and running them on the cloud. So, you're responsible for securing the applications, the workload, and the data, while the cloud provider is responsible for managing the security of the platform—so that it's compliant, it's secured from the perspective of network, the platform on down, in terms of managing the containers and the runtime and isolation so that you have your own space within the platform.
Whereas if you are adopting and migrating workloads to the cloud, and you're using Infrastructure-as-a-Service (IaaS), then the cloud provider manages the hypervisor on down, if you are using virtual servers. Or, if you are using bare metal, then you can completely control everything on up from the operating system, the virtual servers that you run, and the data you bring on.
So, it's very important to understand the adoption model, whether you're consuming IaaS, or PaaS, or if you're consuming SaaS where the cloud provider manages all the applications and the security offered, and you worry about the data that you bring in and plan accordingly.
So that's a very important thing because it's part of understanding your responsibility in ultimately managing the risk and compliance of the workloads and the data that you bring to cloud.
Security and architecture
Now let's talk about architecture. When you build applications and migrate applications and modernize your apps, let's start with data. With all the risk that you deal with—the kind of data matters. Is it confidential data, is it public data, or sensitive data that may deal with private information?
Data security architecture
Consider all those factors and make a secure design around what your data security architecture should be. Make sure you have data-at-rest encryption so that the data is always encrypted whether you use a Database-as-a-Service, Object-Store-as-a-Service, or other ways to store data, like block storage.
Encryption is for amateurs; if you think about key management, that's for professionals.
So, having more control of your keys provides you the ability—in the context of the shared responsibility model—that you own your data, you have complete control of your data.
So, as you think about key management, make sure you have an approach to think about if you are bringing confidential data, you want to bring your own keys. Maybe sensitive data—you want to keep your own keys. So, that how much control of the keys you have and the hardware security module in which the key processing—the encryption/decryption operations happen—more control you have, and more responsibility that you can take on.
So, encryption of data-at-rest, data-in-motion, as it comes from services to data stores or applications, so that as you think about data coming all the way, your requests and API requests coming all the way, data-in-motion.
And, in the new world, we need to start thinking about when the application is actually processing the data—that is going to be data in its memory.
So, you can actually start to protect data using hardware-based technologies where you can protect in-memory data as well. So that when it is in use and in memory by the applications, you can protect it.
A holistic approach to data protection
So, take a holistic approach to data protection at rest, in motion, in use, with full control of your keys. It can be bring-your-own-keys (BYOK) or, even better, push the boundary with keep-your-own-keys (KYOK).
The application that serves the data—it's not only about which application needs to have access—make sure the data access is on an only by-need basis. Do not open up your data services to the whole world—be it network access or everybody to access the data—make sure you know exactly which applications need to access or which users need to access the data to run your cloud applications.
From an application viewpoint, make sure there are no vulnerabilities in your application. So, scan your applications—so I have an App Sec application security approach so that you can do dynamic scanning or static scanning of your application before you deploy it into the production.
And in the cloud native environment, you're deploying container images—so you can scan your images, you can scan it for vulnerabilities before you deploy and set your policies so that you only have secured images in production anytime. And if there is any vulnerability in the new world, you don't need to patch these systems—you just spin up a new container and off you go.
So, that's the beauty of a cloud native approach—that you have security built-in at every step. So, at a container level and the applications that serves the business logic, you can start to protect it.
Then, when you look at the users coming in, you want to manage access, in terms of who the user is and from where they are coming from. So, identity—you need to make sure who the user is or which service it is based on the identity of those services or users so that you can manage access control to your application or data.
Also, from the perspective of network access, you want to make sure only authorized users can get in. And, if there are intruders out there, you can make sure you can set it up so that they are prevented from accessing your application and your data in the cloud, be it through Web Application Firewalling, network access control, or denial-of-service distributed, denial-of-service protection—and have intelligence built into network protection as well. So, both identity and network.
Gaining insights and actionable intelligence
In essence, you are protecting your data—you need to manage access to your apps and the workload and the data that you’ve deployed on the cloud.
You need to have a continuous security monitoring so that you know, at any point, whether you're compliant to your policies, you can watch out for threats that you need to manage. Having an approach and set of tools to manage security and complaints posture is very important.
So, gaining insights about your posture, compliance, and threats. So, from your deployment environment, you can garner information, it can be security events, audit logs, flow logs from network or system that can be fed in so that you can figure out what your posture and complaints and threats are.
And not only is it important for you to gain insight, you need to have actionable intelligence so that you can start to remediate. You may figure out there's a vulnerability—a container image that you have deployed is vulnerable—so you can re-spin the container. So you can remediate and spin up a new container.
There may be a particular access from a network that seems to be coming in from a suspicious network IP address so we can block that.
So, the ability to gain visibility and insights, and having that insights and turn it into actionable intelligence and remediate is very important.
DevOps and SecDevOps
So, let's talk about DevOps. DevOps is about development and operations. Traditionally, we think about—okay, there's an application team that is doing the design and architecture, who are building code, and then you throw it over the wall for the enterprise security team to secure it and manage it.
That should be rethought. Fundamentally, it's not just about Dev and Ops—security needs to be a forethought, not an afterthought. So, it should become SecDevOps approach to the way you build, manage, and run your applications.
So, you need to embed security into the entire lifecycle. What we call shift left—not only do you manage security, but shift left through the entire process. You need to have a secure design—so as you plan, as you design, and say "What kind of data am I going to put what level of classification, what kind of applications am I building, is it container based, is it a workload that I'm migrating?" Take that into account and what integrations you need to do so that you can plan it and architect it. Then, as you build it, embed security as part of that process.
So, you have security-aware applications. For example, you may want to encrypt data for your sensitive data, you may want to encrypt the data from your applications before you even store into a data store.
So, secure build, and you manage security. As part of SecDevOps, as you have secure design and architecture, you pass on that and build secure applications and deploy and manage security in a continuous fashion, and then you have a closed loop. So that whatever you find, you may need to remediate or rearchitect your application or reimplement certain things as threats landscape evolve.