Google Data Leak Highlights the Dangers of Traditional Role-based Access Controls

Between 2018 and 2020, Google fired dozens of employees for misusing access to the company's tools or data, according to an internal company document obtained by VICE Motherboard. The document also reveals that Google fired 36 employees in 2020 for security violations, including allegations of mishandling confidential data.

This VICE story is a reminder that every company — even a company with the vast financial and technical resources of Google — faces the threat of improper access to sensitive data. When employees illegally or carelessly access data, a variety of problems can result, including

• Security threats, such as the leaking of customer records or valuable intellectual property
• Compliance violations for failing to protect the confidentiality and security of data as required by industry regulations or local and federal laws
• Crimes such as the stalking of customers or colleagues by predatory employees
• Ethical violations, including violations of terms of service agreements with customers

To be fair, the access controls at Google are probably tighter they are in most companies. According to a Google spokesperson, the company limits “access to user data to necessary individuals, requiring a justification to access such data, multi-stage review before access is granted to sensitive data, and monitoring for access anomalies and violations.”

Most organizations today rely on less stringent access controls. The most popular access model is role-based access controls, which attempt to limit data access according to an employee’s role in the company. Roles can be broken down into groups and individual users. Finance data might be limited to the finance department. Then, within the finance department, certain individuals such as the CFO or the director of accounting might be granted additional access based on their roles.

Access Rights Tend to Pile Up Despite the Obvious Security Risks

When exceptions are made to these role-based policies, the access rights tend to pile up like snow drifts. Every employee begins with the access rights due them because of their role or group. If an employee gets promoted, they may be granted access to new systems and applications as part of their larger role in the organization. Their original access rights will remain in place. When an employee needs access to resources for a special project, those access rights are added to the employee’s list of access rights.

Rarely are any of these rights rescinded. Why? It’s simply too hard for the security team in charge of access rights to keep track of all the projects all employees are working on across the organization. No amount of Gantt charts, Microsoft Project files, or Service Now tickets is ever going to provide a comprehensive view of what access rights employees need for doing their work. So security teams rely on incoming requests, which rarely involve rescinding access privileges unless an employee leaves the organization.

More Blind Spots with Role-Based Access Controls

There are two additional blind spots with role-based access controls.

The first is that the access to keep track of is much more varied and distributed as companies adopt multi-cloud strategies. It’s not just that companies are mixing on-premises and cloud applications. They’re using multiple cloud applications from multiple vendors. One department might standardize on Google, another on AWS. One data team might use Amazon RedShift, another Snowflake. The number and variety of applications, services, and platforms to keep track of is becoming unmanageable as long as security teams rely on ad hoc methods of keeping track of users and credentials.

The second problem is that security teams have little or no visibility into what privileges a user has within an application, service, or environment. The identity management team might know, for example, that Jane Smith has a Salesforce account. But what type of Salesforce account does she have? Is she a regular user or an administrator? The answer matters, because security and compliance depend not only on who has access to which applications and services. They also depend on who has access to what data and operations within a given application or service. Application managers might know this information. Security teams usually do not.

Solving the Problem of Access Rights

The Google news story highlights what’s at risk for every company when it comes to access rights for internal users. Overly broad access puts confidential data and even business operations themselves in harm’s way.

To solve his problem, organizations need to adopt a new approach that takes into account:

• The sheer number of users, user accounts, and evolving access requirements across the organization
• Actual usage patterns, so that unused credentials can be revoked to minimize the risk of insider attacks and account take-overs
• Usage pattern comparisons, so that security teams can draw on models of normal user behavior
• The need for fast, frictionless workflows for requesting, receiving, and revoking access rights

Support for existing security platforms and services, including single sign-on platforms which organizations have already invested in and rely on dailySupport for workflows is an important requirement. Whatever access solution an organization adopts, it should ideally simplify life for security teams as well as for end users and their managers.

Trustle for Needs-based Access Management

At Trustle, we’ve built a needs-based access control and government that meets these requirements and addresses the problems with “access creep” across the organization.

Our solution replaces role-based access controls with needs-based access control. Why? In our years spent in IT security and identity management, we’ve found that role-based access controls are often too broad. Not everyone in a role or department needs access to the same systems all the time. More often than not, needs vary. Two people working side by side with the same titles might routinely access different systems because of the division of labor. It’s risky to provide them both with the same access rights to all the systems both of them are accessing.

And needs vary not only by individual but by time. A user might need access to an application for a limited amount of time — for a short-term project, for example. Once the project is over, there’s no need for the access rights to persist. They can be safely revoked without reducing productivity at all.

Revoking unused rights reduces risk. Specifically, it reduces these two risks:

• The risk of the insider misusing those rights, as in the Google example.
• The risk of an attacker gaining access to those rights by breaching the user’s single-sign- on account.

To make work of granting and revoking rights manageable, Trustle applies machine learning to discover and analyze access right usage and workflow automation to streamline and accelerate access rights management work. Through workflows with easy-to-use forms and Slack messages, Trustle makes it easy for users to request access rights and for managers or security teams to approve them. When those rights stop being used, Trustle automatically detects the change and prompts users or managers to either preserve or revoke the rights, based on policies.

Security teams can connect Trustle to applications, services, and cloud platforms in 30 minutes or less. Once connected, Trustle reports not just whether a user has access to a given resource, but what level of access has been granted. Is the user an administrator? A group manager? Some other privileged role? Important details like these are critical to protecting sensitive data, but they’re invisible to single sign-on services and other access management platforms. Trustle makes these details both readily visible and manageable.

Every organization — even Google — is at risk of access rights leading to data breaches and possible regulatory sanctions. By adopting Trustle, organizations can quickly gain visibility into the access rights active across their IT resources and manage those access rights to better support user productivity and security best practices.