Software-as-a-service (SaaS) has taken over the world because it’s easy. With just a few clicks, business units can find an application that’s suitable for a particular business process. They can subscribe to it and immediately start using it — and the IT department might never find out.
Cloud access security brokers (CASB) first emerged to help security teams track and manage their emerging shadow IT problem to gain some visibility and control. But today, according to research from Digital Ocean, 86% of companies increased their reliance on cloud services in 2021. Research from Netskope shows companies now use an average of 805 distinct cloud applications per month, 97% of which are ungoverned. The few that are governed are likely not very well controlled. We may be able to take some solace from the fact that the most mission-critical data is usually concentrated in a few of the most strategic SaaS apps (e.g., Office 365, Salesforce, GitHub, Google Workspace, etc.), limiting the need for guesswork into thousands of other SaaS apps that aren’t as well known.
That said, a lot of mission-critical data also winds up in custom applications that people write and deploy into an infrastructure-as-service (IaaS) cloud, such as Microsoft Azure, Amazon Web Services (AWS), or Google Cloud Platform (GCP). These environments are sufficiently different from the on-premises world. The kinds of tools people use to check the health of applications and infrastructures that were built on-premises don’t accommodate the cloud very well. On-premises security and monitoring tools were all built under the assumption of static existence. The infrastructure was set, and the applications and the data were static. The cloud inverts this thinking and is dynamic. The dynamism in the public cloud causes a lot of traditional security tools to break.
Multi-Cloud Challenges In-House Expertise
Almost every organization on the planet is now multi-cloud. Many will use AWS for some projects and use GCP for others and Azure for still others. In the case of mergers and acquisitions, the choice of cloud platform may even be forced upon you out of circumstance. Or sometimes, choosing a certain platform over another might be a case of suitability for a particular application or developer proficiency.
One of the challenges here is that it’s hard enough to be an expert in even one of these platforms. Each one may have hundreds of different services and the services talk among themselves in varying ways. For example, the access control model for AWS is unlike any access control model you’ve ever seen for any other service before, so being an AWS expert is difficult enough. How can you possibly also be an expert in Azure and GCP as well? It’s a struggle. The human brain just can’t easily grapple with so much at once. Nevertheless, arguing against multi-cloud isn’t a hill worth dying on. Every business is multi-cloud now.
Orient Your Teams Toward Cloud-Native Security
Most business-ready cloud services, whether IaaS, PaaS or SaaS, offer a useful set of built-in security controls sufficient to guard against common threats. When ascertaining the steps necessary to use a cloud service securely, start with these. It’s likely, though, that you’ll reach a point where the built-in controls insufficiently protect against novel threats. You might conclude that the built-ins lack the flexibility to express detailed policies. It’s also likely that you’ll notice you’re repeating work, such as configuring some DLP rules in Microsoft 365 and substantially similar rules in Amazon Macie. Who wants the boring job of manually verifying consistency for dozens of controls in hundreds of applications? The escape from this conundrum is to layer in cloud-native security controls from a third-party cloud security provider. I’ll offer a few examples.
Some built-in controls are unavoidable: You’ll almost certainly need to create person and service identities (also known as “security principals”) in the IaaS/PaaS/SaaS built-in identity management system. You’ll also need to provision access controls on resources via a built-in mechanism of expression. A third-party cloud security tool can continuously monitor the rights granted to security principals, along with permissions configured on resources, to ensure rights aren’t too broad and permissions aren’t overly-scoped. When a single tool manages entitlements across your entire cloud estate, the outcome is a degree of consistency and predictability that is otherwise essentially unobtainable.
Another domain in which third-party cloud-native security tools excel is identifying sensitive information and managing its spread. I previously mentioned the drudgery of configuring and maintaining duplicate DLP rules. Inconsistent and incomplete rules introduce real risk, creating potential targets of attack. But know this: Most SaaS applications lack any form of built-in DLP at all. I would bet that at least a sliver of your company’s sensitive information resides in a smattering of DLP-free SaaS applications. A cloud-native DLP capability — something that every good CASB offers — eliminates duplicate work and ensures consistency of policy actions across all your cloud applications and projects. Unlike the previous example where the third-party tool augments a built-in control, here the third-party tool substitutes for a built-in control or enables such control where no built-in exists.
No single “cloud security” market exists. Instead, hundreds of products in a dozen-ish sometimes-overlapping markets vie for your attention. In almost every instance, startups have identified cloud security gaps and responded with compelling offerings. Over time, the major incumbent security vendors have acquired many such startups. Levels of integration vary wildly: A platform in which capabilities share resources and configuration outperforms a portfolio of random stuff. To learn about new and emerging markets, consult your favorite industry analyst reports. Check in with your peers, who might already have experience with vendors in these markets. Favor vendors who offer integrated platforms and can work with certain parts of your existing infrastructure, like your directory service, your SIEM and your endpoint protection platform. Conduct a proof-of-concept to verify fitness for purpose.
Your data, applications and people haven’t been static for a long time. Neither should your security remain static. The best way to protect the cloud is with the cloud — always has been, always will be.
Article originally published at Forbes Tech Council.
