Every cloud user I chat with tells me that cloud security is complicated. Why is that, why is it a surprise to enterprises, and what might change things, for better or worse? It goes back to the Internet, the desire to improve customer experience (CX), and remote work and pandemic-era work from home (WFH), and a lot of the complexity relates to what the cloud does to the network.
Companies really started to use the Internet to reach customers on a large scale in the 1990s. From the very first, they realized that the Internet was a conduit for hackers as well as for prospects and customers, and so they were careful to partition their web servers and content from their primary applications and databases. The “threat boundary” remained the data center. Remember the notion of the “DMZ”, the name given to that partition? Maybe we should have used the old Dutch-boy-and-dike story as our analogy instead, because almost immediately we started drilling holes in that partition.
E-commerce is a small user-experience step from web product information, and so is offering users online information about their accounts, but they’re giant steps in terms of risk. Anything of this sort requires that we initiate access to core applications and data in response to an action taken over the Internet, so we dug into our partition. Still, these early tools for Internet-to-data-center linkage offered only a limited and easily controlled data path, so it didn’t generate a lot of problems…directly, that is.
Companies don’t open every door into their core applications for prospects and customers to pass through, but employees are another matter. Who, after all, is supposed to be running all these core applications? The decision to support remote work, collaboration, and data-sharing for people like outside sales and technicians, started off using a special VPN portal to applications, but with the pandemic it became more and more common to use the same cloud-hosted tools we were using to improve CX. That created network pressure immediately, a need to make the cloud as much a part of the VPN as the data center with tools like software-defined WAN (SD-WAN) agents and secure access service edge (SASE). With that, the network itself became a hole in our security dike.
One thing it did, the obvious thing, was to extend the “threat boundary” to the cloud. That can be addressed with conventional access control security, which SASE includes. But having the VPN extend into the cloud also makes it possible to open an accidental gateway onto it, a gateway hackers could use.
When a software component is connected to the company VPN, it’s often presumed to be trusted, but is that always true for the cloud? Cloud providers usually host your software in a private address space, one that can’t be accessed from outside the cloud. The software pieces that need to be accessed, by customers or remote workers, are “exposed” by mapping their private address to a public one. The more cloud software you have that needs external access, the more times software needs to be exposed, and every exposure is a potential hole in security. Yes, you can secure these open components, but suppose one gets exposed by accident, or suppose a cloud component that used to be externally accessed is made into an internal-only component. Do you remember to remove the address mapping that makes it visible?
Here’s the thing. A cloud workflow is usually a chain of components and a final jump onto the company VPN. If any of those components is exposed, a hacker jumping on can ride the chain to the VPN, because companies don’t usually secure components that are supposed to be accessed only by other components. These situations can leave a security hole that doesn’t get plugged, and the more you do in the cloud the more complex the question of what’s internal and what’s external gets.
Component sharing, something that’s considered a good practice in modern software development, adds to this problem, because it’s possible that one application that uses a component might expose it to external users, where another treats it as internal only. Unless the competing exposure is recognized and accommodated, the component poses an ongoing security risk. Shared components with different exposure expectations are a security time bomb.
You might wonder why these cloud security challenges are different from challenges already faced in the data center. Container deployment in data centers already uses private IP addresses that isolate within-application workflows from the VPN, and from hackers. But companies are increasingly separating cloud development teams and tools from data center development, just as “web development” has traditionally used different techniques and people versus mainstream programming. What we’ve learned in the data center may not be transferred to cloud activity.
To prevent SD-WAN or SASE from creating a back door through which hackers could enter your VPN, consider these enterprise recommendations:
- Set a policy on what cloud component addresses can be exposed to the Internet or your VPN, and establish one organization as the moderator of any changes to exposure.
- Use SASE/SD-WAN in combination to secure exposed components, rather than using SD-WAN alone and without security, and pick a single strategy and product you can support across the board. Too many hands are jiggling the cloud already.
- Don’t share components across applications if the applications have different requirements on exposing the components being shared. Where you have done that already, have the teams involved do combined maintenance.
- Regularly audit currently exposed addresses through cloud provider management tools to ensure your current exposures match policies.
The cloud is more than a hosting option, it’s also an implicit link to the Internet and a real network in itself, and the more clouds you have the more this network impact multiplies. Basic security tools can help to secure a cloud and your VPN, but only an awareness of the “cloud network” and its implications can prevent serious security problems.
This post was originally published on the 3rd party site mentioned in the title of this this site