Along with the rapid deployment of new environments and cloud services, there’s been an explosion of identity-based permissions created – many of which go overlooked. The problem is that in an effort to get employees up and running quickly, access privileges can unintentionally be over-permissioned in an attempt to lessen the disruption.
This leads to two problems. The first is potentially giving someone too much permission, enabling them to access things they shouldn’t. This could open the door for mistakes to happen or potential misuse.
A recent survey from research firm ESG found over-permissioned accounts and roles as the top-ranked cloud service misconfiguration. Not surprisingly, attackers have taken notice: the same survey ranked overly permissive privileges as the most common attack vector against cloud applications.
Here lies the second problem. Through the eyes of an attacker, each cloud identity represents a potential opportunity and first step toward a company’s most valuable assets. If not properly configured or managed, these identities create a pathway for attackers to gain privileged access and ultimately compromise an entire cloud environment.
It’s time to take back control of cloud security by transforming how these permissions are secured and managed, while also delivering unprecedented time to value and operational efficiency.
Assigning the right permissions
Adoption of public cloud services, SaaS applications and remote access have dissolved the traditional network perimeter. This establishes identity as the key line of defence for most organisations and the defacto ‘new perimeter.’ As zero trust models take hold, authentication and authorisation of all identities become paramount.
Any human or machine identity can be configured with thousands of identity and access management (IAM) permissions to access cloud services containing sensitive information. User, group and role identities are assigned permissions depending on their job functions.
Excessive permissions pose a major challenge for organisations as they move toward zero trust security frameworks, which demand that every identity attempting to access corporate resources be verified and their access intelligently limited.
Instead, implementing least privilege, in which all identities have only the minimum necessary entitlements to perform their ongoing responsibilities, is an established best practice for any zero trust and cloud journey.
It also limits the number of entities that can grant or configure new permissions, making it difficult for attackers to escalate privileges and reach their goals.
Focus on limiting privilege
There are four key reasons to introduce or extend least privilege to your cloud environments:
1. Data breaches increasingly linked to cloud identities
The 2020 Verizon Data Breach Investigations Report (DBIR) found that identities remain the weakest link in most organisations, as credential theft was employed in 77 percent of cloud breaches. This reinforces the case for least privilege access.
Organisations can proactively protect themselves from insider threats, while greatly limiting potential damage from external attacks. A compromised identity can’t immediately access resources outside of its standard job responsibilities. This constricts attacker movement and protects critical workloads, buying valuable time to detect and respond to an attack.
2. Reduces attack surface
More cloud services and identities means greater risk. There are several aspects of cloud environments that make proper configuration of privileges and permissions a challenge.
Cloud IAM roles for certain application services can be provided with a wide range of permissions to limit possible developer friction. A thorough entitlements audit process may identify such excessive permissions and limit them to the least privilege required for the service to work properly. Other organisations fail to account for outdated permissions, such as failing to remove developer access to storage buckets and container pods at the close of a project.
Both scenarios are equally dangerous, as an attacker compromising either of these identities can increase their chances of escalating privileges or reaching important data undetected. Establishing and continuously validating least privilege is a critical step to shrinking the attack surface, lowering risk by dissuading insider threat actors and impeding external attackers.
3. Multiplying misconfiguration risks
Leading infrastructure as a service (IaaS) platforms are constantly introducing new services to differentiate from others. This innovation boosts business productivity, as powerful tools for specialised needs like data streaming, blockchain networking and IoT analytics are more accessible than ever before.
But that accessibility can come at a price. Configuration of cloud services is challenging for any organisation, and one simple misconfiguration can open doors for attackers.
Least privilege models place emphasis on managing permissions to identify potential misconfigurations that result in excessive, unauthorised access to key cloud services. This mitigates risk while enabling necessary access to advanced workloads.
4. Recommended by industry
Recognising the dangers of over-permissioned identities, leading IaaS providers all specify least privilege access as a security best practice. In addition, consortiums like Cloud Security Alliance’s Cloud Control Matrix stress the importance of continuously reviewing permissions.
Meanwhile, highly regulated organisations can even face financial penalties if breached for failing to establish least privilege. Organisations should continuously verify least privilege across their on-premises and cloud workloads to ensure compliance.
Least privilege is recognised as a security best practice for a reason. But it can’t come at the expense of end-user productivity or overburden IT teams. Effective enforcement brings the right mix of privileged access management practices together with flexible controls, to balance security and compliance requirements with operational and end-user needs.
About the author
Andrew Slavkovic is a solutions engineering manager of ANZ for CyberArk. More information is here.