5 Ways MSPs Can Improve Public Cloud Security Across AWS, Azure and Google
While many organizations have moved to the cloud for added flexibility, when it comes to security a small misstep in the cloud can end up exposing the business. The greatest vulnerability for cloud computing is simple misconfigurations. As cloud systems become more complex and more flexible, operator error continues to increase risk. Combined with a general lack of visibility, this makes cloud computing environments a ready-made target for cyber-attackers.
Cloud platforms themselves are so complex, and change so frequently, it’s often difficult to understand the ramifications or consequences of misconfiguring a specific setting. Further, the inability to closely monitor exactly what an organization’s machines are doing is hugely problematic. Criminals know this and have been attacking cloud computing platforms for precisely these reasons. As such, it’s critical for MSPs to help organizations re-evaluate their cloud strategies with security top of mind.
Lack of visibility in the cloud
If you’re monitoring an on-premises environment and someone is trying to brute force their way into your customer’s network with password stuffing, the intrusion becomes very obvious. It’s not so obvious, though, in the cloud.
If an attacker tries the same tactic on your customer’s cloud environment, by default you won’t get a notification that it’s happening. AWS, Microsoft Azure and Google Cloud Platform all have the capability to notify you of activity like this, but it’s something you have to opt into. By default, cloud providers won’t provide that visibility. Without visibility, you have no idea about who may be trying to penetrate your network, let alone how, when and with what.
What’s worse is that if you don’t know you’re supposed to opt into those services ahead of time, then the cloud provider not only won’t send you these notifications, they also won’t collect data around that intrusion in the first place. Without that forensic data, there’s nothing to investigate and plan against for the future.
This whole predicament goes unnoticed until it’s too late because the team that’s responsible for building applications or migrating them to the cloud are not security experts by trade. Security isn’t their domain and it’s not their responsibility to understand how and why incidents happen, or to collect the forensic data on these incidents.
Too much access undermines cloud security
While the cloud has a better capacity than traditional on-premises environments for isolating systems – and thereby isolating an intruder’s ability to breach entire networks – this is undermined by a problem I’ve seen run amok too often: over provisioning of access privileges.
It’s very complicated to create access tokens, and permissions for those tokens, in a cloud environment, which makes it easy to make mistakes. But more than that, granting these tokens left and right means providing excessive levels of access across the board. That raises the risk of security issues like credential harvesting, which not only enables attackers to gain access across the cloud environment, but also undercuts the cloud’s built-in capabilities for isolating illicit access.
5 ways MSPs can improve cloud security
Too little visibility and too much user access make the cloud a lot less secure than many think it is – and less secure than it should be. But there are some essential IT hygiene measures that MSPs can and must undertake to shore up these vulnerabilities and deliver on expectations of cloud security for their customers:
- Zero trust. Rather than providing tokens that grant access across the network, MSPs need to take a zero-trust approach. That means explicitly granting access to users on an application-by-application basis. Your login only connects you to the apps you’ve been pre-approved to access, and nothing more. This ensures that even if your credentials are compromised, the attacker can only touch the exact applications you have access to.
- Understand each specific cloud. No two cloud environments are the same. AWS, Microsoft Azure and Google Cloud Platform are often grouped together as if they’re the same, just because they’re the most prominent public clouds. But each platform is different; the way you work on Azure won’t work with AWS. As you’re migrating workloads to the cloud and managing cloud security, it’s essential that you’re trained on the ins and outs of each specific platform.
- Cloud-native vs. lift and shift. Know the difference. If done correctly, cloud-native platforms offer a wide array of security advantages. But just lifting and shifting workloads from on-premises environments to the cloud still carries with them the same vulnerabilities they had on-premise. Making the assumption that “cloud” automatically means “cloud native” can risk opening a major security blind spot. Similarly, making the determination between cloud-native vs. lift and shift should define how you plan to build or migrate apps as part of your cloud strategy.
- Loop in your security partners and incident response teams as part of the cloud migration. Not all MSPs specialize in security, and that’s okay. Bringing your security and incident response partners into any cloud migration project ensures that security is never being overlooked.
- Cloud infrastructure monitoring is essential. In any area of the cloud where you introduce code, you bring in the potential for vulnerabilities. Cloud infrastructure that runs on Linux inherits all the vulnerabilities of Linux. Without visibility into your customer’s cloud infrastructure, you might have no idea that it actually resides somewhere else, or that the perimeters overlap into other data centers, inviting new security risks.
For real visibility and monitoring into your customer’s cloud environment, all MSPs need to:
- Have access to new monitoring tools or have the data from those tools funneled into the current ones.
- Integrate digital forensics and threat monitoring teams into the workflows for determining how information in the cloud is accessed.
- Deploy endpoint detection and response to achieve new visibility into the cloud as a default option, without having to seek the provider’s permission first.
- Make sure they’ve opened all channels for monitoring, between third-party vendors and the cloud providers who have exclusive access to certain data sets (like authentication data) to ensure that they all have all the available information on their cloud infrastructure.