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
- 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
- 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
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
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-
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
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.