Modern organizations are keen on agility. This leads to fast adoption of public cloud, DevOps best practices like infrastructure as code, and a significant increase in the number of software releases and deployments.
With the speed at which cloud applications are deployed, security teams often find it difficult to keep pace with DevOps teams. In order to keep up, security teams are often faced with a dilemma: on one hand, they must enforce best practices like least-privileged access, while on the other hand, they must not do anything to slow down business agility and innovation.
A typical example of the dilemma described above is the deployment of a new application or service that leverages public cloud services (e.g. Azure Blob to store application data, AWS API Gateway to manage incoming API requests, GCP Cloud Functions to implement application logic) to deliver improved business value.
Developers easily spin up environments, generally granting broad entitlements to both human and non-human identities, so that access requests don’t slow them down. DevOps teams often ask for a wide set of permissions (sometimes even administrative ones) for cloud accounts and/or individual cloud services. Sometimes, as in the case of an emergency, the DevOps team or engineers are allowed extensive privileges to perform deployments and configure environments. Such privileges are rarely reviewed again. More often than not, these privileges are never removed from the role—even if the emergency is over. Keeping track of such identities, access, and their privileges presents an extraordinary and unprecedented challenge. Moreover, developers do not have the time, nor the expertise, to manage granular IAM permissions. Additionally, the fact that each cloud provider has its own way to manage permissions makes things even more complicated.
That said, one way for a security team to handle such a situation, without slowing down the application’s deployment, would be to break the permissions assignment into two phases:
During Phase 1, the security team would allow the DevOps and engineering teams to set the permissions as per their requirements and as requested by the DevOps team. This would allow initial application deployment to go smoothly.
A CIEM solution will give an accurate picture of all entitlements assigned to human and non-human entities, as well as the actual usage of those entitlements. CIEM dashboards and visualizations enable security teams to understand the access available to both human and non-human entities. Advanced analytics based on machine learning and AI will help the security officer understand permission usage. Machine learning-based algorithms help to determine and assess the risk level of unused permissions, which will enable the right-sizing of entitlement, safely remove unused permissions, and optimize permissions without any operational risk. CIEM will also help discover and remediate IAM configuration violations (for example, a non-human identity such as a VM with administrative permissions) based on a set of best practices.
During phase 2, the data collected by the CIEM solution enables the security officer to have a meaningful conversation with the DevOps team, presenting data about actual permissions usage and demonstrating data and risk involved with excessive permissions. Following such a data-based conversation, the security officer can easily get a green light from the DevOps team to narrow down the excessive permissions granted during phase one and reduce the attack surface and risk posed by excessive entitlements. In this way, the security officer can optimize security while supporting business productivity and development.
In addition to reporting on used/unused permissions, the CIEM solution can also enable interactive investigations and visualizations of current permissions granted to a human or an application, as depicted below, to eliminate excessive access and privileges based on actual access patterns and data sensitivity to enforce and maintain least privilege.
For more information about CIEM, read Entitlements: The Most Overlooked Risk in the Public Cloud