CIEM Solutions: Permissions and Privileges

December 13, 2022
by Zilla Content Team

We recently wrote a blog on Cloud infrastructure entitlement management (CIEM) and a new set of challenges it poses for organizations. Once you move applications and services to the cloud, role-based privileges aren’t as simple as they seem. In addition to users who have access to the cloud, hundreds of applications and machine identities could also have access to data and resources. Fortunately, CIEM solutions are designed to help manage the permissions and privileges of both people and things in the complex and interconnected cloud environment.

Plus, for CIEM to gain broad adoption, it needs to be convenient for developers and support a fast pace of innovation. This article will dive into organizational friction between security and development teams and ways to align their interests through simple and intuitive workflows.

Are organizations playing “red light, green light” with their future?

There’s an unhealthy dynamic in organizations today that looks a lot like the children’s game of red light, green light. (And, no, not the Squid Games version.) It happens between security teams and developers when developers try to speed up application development only to be slowed down by security teams, who want to ensure that applications are fully secure before they get deployed. Both sides have their company’s best interests at heart but don’t see eye-to-eye when it comes to security because they see the world from different points of view.

At Zilla, we believe that security and developer teams should work together toward a shared goal of secure business agility. And the best way to get these teams on the same page is to get them to speak the same language—which is where we come in. DevOps processes require human and machine identities to have privileged access across development and production environments, a multitude of CI/CD and automation tools, and thousands of cloud resources.  Zilla provides a single holistic view of access policies, identities, and permissions across the entire organization, including the DevOps pipelines and production environments. It then communicates this information in a way that makes sense to both security analysts and developers, so they can agree upon the best way to address security issues and policies within the existing DevOps processes.

Least privilege, not feast privilege, is the right approach.

Visibility is a big problem in organizations because of the disaggregated nature of today’s networked environments. Data and applications are spread across private data centers, hosted cloud providers, and multiple offices. Each sub-environment typically has its own management tool that only provides visibility into its resources. The result is multiple security views that don’t provide enough context. For example, your AWS data may tell you that only five accounts have access to cloud services, but, in reality, those five accounts may serve 500 different users.

Focusing on the big picture doesn’t mean boiling the ocean. It can start with answering fundamental security questions: Who has access to this environment? What are the entitlements for each group and role? Once your teams agree on the answers to these questions, you can begin to fine-tune access policies for different users, roles, and groups. While this approach may seem obvious, the reality is that many of your current security policies stem from earlier policies that are outdated and may no longer be relevant. Giving a new employee the same security access as a previous employee in a similar role isn’t the best practice. While It may ensure that the new employee has access to everything they need, it may also give them unnecessary access to many things they don’t need. Thus, Instead of a least privilege approach, organizations often end up with a “feast privilege” approach that allows employees to pick and choose what they can access from the entire pool of the company’s resources.

Don’t expect results automatically without automation.

As human beings, we tend to resist change. Automation, therefore, is critical to changing how organizations create, enforce, and update access policies because it takes our natural human change resistance (sometimes referred to as “laziness” or “inertia”) out of the equation. Zilla’s solutions provide not one but several layers of automation to improve security. First, our technology automates account and entitlement data collection across all environments: data centers, private and public clouds, and more. Then it automates the correlation of that data with existing identity and access tools, including Okta Universal Directory and Microsoft Active Directory, and creates a single view of identity and access. Finally, Zilla’s solutions allow automating the review process for user and API entitlements, thus preventing any future  access “creep” as new employees, roles, applications, and environments get added or deleted.

While automation is essential to driving the adoption of best practices, the other critical factor is convenience. Making things convenient introduced many current identity and access problems in organizations. (That is, until these convenient processes cause a security breach, deeming them very inconvenient.) To counter this, Zilla helps you create simple processes that would be convenient for developers to follow by working the way they’re accustomed to, through Jira tickets. With Zilla, instead of security teams creating action items that slow down developers, they can insert security policy changes into the development team’s natural workflow. This aligns the interests of security practitioners and developers, resulting in greenlighted policy requests that insert security into the middle of DevOps, just as DevSecOps intended.

In the world we live in today, security can often feel like an impediment to innovation. The challenge is to move forward safely by looking at security through the lens of innovation. Zilla is committed to creating innovative security solutions that bridge the realities of distributed and remote workforce today (e.g., disaggregated networks, disaggregated teams) with the opportunities of tomorrow. We believe that security only works when it’s everyone’s responsibility.