4 mins to read
Least privilege. It’s like a love-hate relationship. Everyone knows it’s a best practice, but no one is achieving it at scale. Why? Because it’s hard to do. The market is constantly trying to sell you least privilege, but no solution is making it easier, attainable, or sustainable.
TL;DR: We’re going to tell you about a new strategy to least privilege, one we know will bring you better security, less strenuous policy management, and pain-free access for developers. Let’s get into the details.
How is Least Privilege Done Today?
The baseline goal: all identities have the minimum amount of privilege they need to complete their responsibilities.
There are a few players in the process: Operations Teams, Security Teams, Developers, and sometimes IAM teams (depending on their cloud maturity).
Presently, organizations need to first get a picture of what access and permissions each identity needs when they want to start a least privilege program. This is often done by enabling some sort of monitoring tool (e.g. AWS Access Analyzer). This does work, but there’s a few drawbacks. Operations need to select which identities or accounts will be monitored. Second, the data ingesting period could take up to 30 days. If you’re working with thousands of identities and tens of accounts, this might take a while.
The monitoring tool will suggest revised IAM policies according to its observation, which Operations needs to review (again, identity by identity). Whatever changes they want to make must be coordinated with the relevant teams or owners of that part of the cloud. Think of coordinating schedules, missed meetings, slow reply emails – the process drags on.
You’re also dealing with balancing priorities. CloudOps bring forth the justifications for any access removal, while DevOps is concerned with not breaking anything, not having their work interrupted, and well, just doing their job.
Finally comes implementation – this is a lot of manual work. Pushing policies through testing, staging environments, and finally actually deploying, all identity by identity (or account). Not to mention, the second these policies go live, they’re antiquated. The cloud is constantly evolving and future policy changes require repeating this process. Same goes for the new identities that are created daily or weekly.
What’s wrong?
- Developers are bogged down with provisioning securely
- Operations have a LOT of burdensome work to do
- There is no end in sight – reaching least privilege is an endless game (roughly 5 months to bring 2k identities to least privilege)
- Security goals are not met, identities are significantly overprivileged
What is the New Least Privilege Strategy?
What if you built a least privilege strategy that only focuses on the most critical and high-impact cloud permissions, and then you protected them top-down at the org or account level with a single policy?
This strategy cuts down the permissions managed to roughly 3,000 out of the 42,000 possible out there across AWS, Azure, and GCP. These sensitive permissions allow critical actions like creating, configuring, deleting, and authorizing. These are the permissions that can cause the most harm if accidentally misused by an unassuming employee or manipulated by a malicious actor.
By focusing on just these 3,000 permissions, with the right visibility, your team can implement a single global policy restricting them at the scope of your choosing.
(Note: Yes, this requires technology to monitor permission usage so these policies do not take away needed access. It also requires a good access approval process for new access needs.)
Benefits of Protecting the Most Sensitive Permissions
- Save your team time not chasing down benign permissions and maximize risk reduction. So much of achieving good security is prioritizing resources and time. How could any organization properly manage 42,000 permissions?
- Allow for sweeping changes. By categorizing permissions into two buckets – sensitive and non sensitive – you can restrict permissions at scale.
- Relieve Operations from endless policy management. So much of least privilege is building out policies and updating them. This strategy allows for one global policy.
- Reduce the amount of access requests. Developers don’t have to request for non-sensitive permissions and there is only ONE request process for all sensitive permissions.
Sonrai’s Cloud Permissions Firewall
If any of this approach interests you, you might find our Cloud Permissions Firewall helpful. We’re not here to just sell you a solution, rather share the ideology behind our product. This strategy is one you can implement within your organizations without us, but if you want a little ‘one click least privilege, zero disruption’ magic, consider a free trial.
Here’s what you’d get: The Sonrai Cloud Permissions Firewall uses sensitive permission intelligence and usage monitoring to determine who needs what permissions in your cloud. Then, with one-click policy deployment, it eliminates all unused sensitive permissions access across your entire multi-cloud estate. Restriction exceptions are granted to identities on the fly as new access needs come up so development goes uninterrupted.
Get to an achievable, yet high-impact least privilege in under 5 days.
Cloud Permissions Firewall does more than just remediate excessive permissions: you can quarantine zombie (unused) identities and disabled unused services and regions for maximum attack surface reduction.
