Chapter 1 - Introduction to Trustle

Introduction

This guide will walk you through the setup and operation of Trustle. It’s intended for both admins and users.

This is Chapter 1! The only prerequisite to following along with the documentation is to sign up for a Trustle Teams trial.

If you have any questions about using Trustle or this document, please contact us at [email protected].

Signing up for Trustle

To sign up for Trustle, visit https://www.trustle.com/pricing. As this tutorial will cover features only available in the Teams tier (and above), sign up for the 14-day Teams Tier free trial.

Once you are able to sign in, you are ready to begin the tutorial, beginning with the Admin menu overview.

What is Trustle

Trustle is an ITDR tool. ITDR refers to a proactive security approach that focuses on identifying and responding to threats associated with user identities, providing continuous visibility and control over identities' privileges and activities, and ensuring they align with the principle of least privilege and zero standing access.

Trustle is not an IDP, nor will it create or destroy entities on the remote service side. Trustle will only add/remove permissions for a user, to/from a remote resource.

Why Use Trustle?

IT, Security, Legal, Compliance, Risk, and Management teams often struggle to answer the following questions:

• Who are my users? 
• What can they access?
• How did they obtain this access?
• Do they need this access, and how often?
• When they don’t need this access, do their identities still exist?
• Are they over, under, or properly privileged?
• Are they zero standing, f least privileged, or in possession of standing privileges?

Trustle can help you answer these questions, making your company more compliant, your resources more secure, and your staff more productive. Trustle will help you:

• Enable just-in-time, self-service access to accounts and resources in your organization.
• Create access request workflows that provide approval processes customized to the sensitivity of the accounts and resources being accessed.
• Account for, and verify ownership of every account and resource in your organization.
• Provide reporting and visibility into who approved what access for someone, when, why, and for how long.
• Evaluate if account and permissions are too broad user-wise, or permissions-wise.

Trustle Concepts

ITDR

Identity threat detection and response (ITDR) is a security procedure for identifying, reducing, and responding to potential identity-based threats, such as compromised user accounts, leaked passwords, data breaches, and fraudulent activity.

The primary aim of ITDR is to provide continuous visibility and control over identities' privileges and activities, ensuring they align with the principle of least privilege and zero standing access. When a threat is detected, the ITDR solution must provide the functionality to take actionable steps to mitigate damage.

Integrations

Trustle reads (and optionally writes) to your enterprise's tech stack via Trustle Integrations. You need to configure at least one integration to effectively use Trustle.

System

An application, service, or cloud provider utilized within your enterprise, which Trustle pulls a configuration in for, and manages via an integration. Examples of systems may include AWS Account, Github Organization, Google Workspace (and others).

Resource

An entity that exists with a system which one of your users may request an entitlement to access. For AWS, this may include a User Group, for GitHub, this may include a Team, for Okta, this may include an Application, etc.

Account

An entity that exists within a system that can be authenticated by that system (also known as a security principal). Examples of Accounts include AWS Accounts in AWS, GitUsers in GitHub, People in Okta, etc.

Zero Standing Privilege

Whereas to have “standing privilege” means to always have access to a resource (whether you need it or not), Zero Standing Privilege (ZSP) describes the principal's state of having zero access or entitlement to a resource.

If a principal has standing admin or root access to a production system, that principal can perform admin / root operations against that production system at all times.

This is fine when that entity is your staff doing their jobs, but is really bad if its a bad actor who has managed to hack their way in. In the wrong hands, a principal with standing privileged access is a serious threat.  But if an identity has zero standing access with no access permissions bound to it, it possesses no threat at all.

Least Privileged Access

Least privilege access (LPA) is the concept of giving a user exactly what they need to do their job access permission-wise – nothing more, and nothing less.

Why is LPA recommended?  With LPA, if an identity is compromised, or if a legitimate user assuming the identity makes a mistake while operating under the identity, the damage that can done with that identity is known and controlled.

JIT

JIT stands for "just in time". We use that term here mostly in the context of switching between a ZSP posture, and a LPA posture. The user has ZSP, but exactly when they need it (i.e., just in time), they can request, and be approved to gain, LPA.

In order to JIT switch between ZSP and LPA postures on a resource, the Trustle User must participate in a Request Workflow.

The Trustle Request Workflow

Access to a resource in Trustle is modeled around the "Trustle Approval and Access Duration" model; to access a resource, a Trustle User (Principal) must possess active approval and access states associated with that resource.

Approval and Access to a resource are not permanent; once granted, an expiration countdown begins for both. The Approval duration is always greater than, or equal to that of the Access duration.

The assignment of an Approval Duration serves to provide an audit trail answering the questions of "who" sanctioned or approved your access to a resource, for how long, and why.

The assignment of an Access Duration serves to provide an audit trail answering the questions of "how long may this user possess least privileged access to a resource before it's revoked, leaving them zero standing access to it." It also answers the question of "if that Trustle User's credentials ended up in the wrong hands, how long would that bad actor have LPA to that resource?"

Workflow Example

To better describe workflows, lets use a more concrete example.

The resource in this example is an AWS User Group named WEB_ASSETS_READ, which entitles members read-only to an S3 Bucket named WEB_ASSETS.

The principal in this example is named USER_1.

Let's assume an approval duration of one week, i.e., "The principal has consent to LPA to the resource for up to a week."

Let's also assume an access duration of 24 hours, i.e., "The principal will possess LPA entitlement to the resource for 24 hours at a time. After 24 hours, LPA to the resource will be removed, returning the principal to ZSA to the resource. As long as the principal's approval state is valid (unexpired) for the resource, the principal may re-request access to the resource without [management or owner] approval as often as needed."

The principal begins with no approval granted to access, and ZSP to the resource. When the principal requests JIT LPA to the resource, their manager is alerted to the request, where she approves it. Upon approval, LPA to the resource is granted. Approval and access are not permanent -- an expiration countdown begins for both. In the meantime however, the principal has LPA to the S3 WEB_ASSETS bucket via the WEB_ASSETS_READ resource.

In the below diagram, this is illustrated as transitioning from states 0 to 3.

After 12 hours, the principal needs access to the bucket once again. But because both access (now 12 hours remaining until expiration) and approval (now 6.5 days remaining until expiration) are still valid, the principal is still a member of the user group resource, which grants them LPA to the bucket. No action needs to be taken by the principal to sustain their access to the bucket.

Two days pass, and the principal needs access once again to the bucket. Access duration has since expired on the user group resource, but approval duration is still valid (now five days remaining until expiration). When access expired to the resource with approval still valid, the principal was returned to ZSA to the resource, and the principal's state with regards to the resource transitioned from 3 to 2, as depicted in the illustration below:

With ZSA to the bucket, the principal cannot carry out their work task, and must re-request JIT access to the resource. Since the approval period is still valid, they re-request LPA to the resource, and its automatically granted. This is illustrated in below as the principal's state transitions back from 2 to 3:

Within seconds, the principal resumes their work task with the JIT access grant to the bucket.

24 hours later, Trustle returns the user to ZSP to the resource, as the access duration once again expired. A long, four-day weekend transpires, and within that time, the approval duration expires as well. At this point, the principal possesses ZSP to the resource, with no approval granted for further access to it. This state is illustrated below showing the transition from 2 to 0:

The principal once again has no approval granted to access, and ZSP to the resource. The principal must once again request LPA to the resource. Upon manager approval, all duration expiration values reset, and the principal is once again able to access the bucket through the approved resource:

Sensitivity Scores

What if we wanted to create stakeholder, approval duration, and access duration "presets"? We could then re-use them across different resources, based on the resource's sensitivity classification. As a matter of fact we can, and these presets are called Sensitivity Scores (SS).

You can assign different SS to different resources in your environment, based on their classification, to rightsize your identity provisioning processes based on the classification of the resource you are provisioning access to.

Trustle comes with five builtin, customizable SS. They are identified by SS Level, where SS 0 requires no humans in the request workflow with very long approval and access durations, up to SS 5, which requires three humans to participate in the request workflow, with very short approval and access durations. They can be customized as needed depending on your own internal processes to increase or decrease stakeholders and approval/access durations.

Sensitivity Score Examples

Building off our previous example with the WEB_ASSETS bucket tied to the WEB_ASSETS_READ User Group Resource, WEB_ASSETS homes the HTML, JS, and CSS for our website. All content in this bucket is publicly available via HTTPS, and is considered non-sensitive, public data.

The marketing team prefers to browse the bucket in a read-only mode to verify product images are up to date without having to click through the website to view them. The DevOps team needs read-write access to this bucket in the rare chance there is an issue with the website deployment system.

To accommodate the needs of both teams, a second AWS User Group is created. This results in two AWS User Groups:

1. The existing WEB_ASSETS_READ_ONLY group (for Marketing)
2. The newly created WEB_ASSETS_READ_WRITE group (for DevOps)

Level 1 Sensitivity Score Example

Upon its next auto-sync, Trustle's AWS Integration pulls in the newly added WEB_ASSETS_READ_WRITE AWS User Group as a new Trustle AWS Resource. Every resource pulled in to Trustle is classified as SS 2 by default (which can be overridden). As such, both WEB_ASSETS_READ_ONLY and WEB_ASSETS_READ_WRITE are set by default to SS 2.

As risk is minimal to those who possess read-only access to the WEB_ASSETS bucket, we can override the SS of the WEB_ASSETS_READ_ONLY AWS User Group Resource to Level 1. This way, anyone who requests LPA to WEB_ASSETS_READ_ONLY can be auto-approved for it (no human stakeholder is required for the approval step). The request will be logged and notifications will be sent to the principals' managers stating that JIT access for the principal to this resource is granted.

The default approval duration for SS Level 1 is three months, so the principal will not need to re-request approval for three months to it. In addition, the default access duration for a SS Level 1 resource is also three months. This means that the user is approved to use, and kept in LPA to this resource for three months as well. At the end of three months, the user will need to re-request approval and access to this resource again, as the approval and access durations to it will have expired (both at the same time).

Level 2 Sensitivity Score Example

As risk to the organization is a bit greater to those who possess read-write access to the WEB_ASSETS bucket, we can keep the SS of the WEB_ASSETS_READ_WRITE AWS User Group Resource at Level 2. Per the rules of SS Level 2, those who request LPA to WEB_ASSETS_READ_WRITE must gain manager approval. The request, as well as the manager's decision, will be logged, and notifications of the resulting decisions will be sent to the principals' managers and principal. If approved, JIT access for the principal to this resource is now available.

The default approval duration for SS Level 2 is three months, so the principal will not need to re-request approval from their manager to it for three months. The default access duration for a SS Level 2 resource is one month. This means that the user is approved to use, and kept in LPA to this resource for one month. After one month, the principal will need to re-request LPA (access) to the resource, however, as long as they are still within the three month approval duration, manager approval will not be a required step in the workflow. At the end of the three month's approval duration, the user will need to re-request approval and access to this resource again, as the approval and access durations to it will have both expired.

Trustle Actors

Many different types of external users, or Actors, interact with the day-to-day operation of a Trustle environment. Here we'll the different types of actors and their responsibilities.

Trustle User

A Trustle User represents an identity -- a human (or computer system) within your organization which can interact with Trustle managed systems and resources.

Trustle Users have the potential to [based on user type] perform three main functions:

1. They may act as custodians for identities, systems, and resources managed by Trustle.\ \ and/or
2. They may participate in resource access request, approval, and provisioning workflows.\ \ and/or
3. Act as the authoritative identity or owner of imported system accounts. (Every account in Trustle should be linked, i.e., attributed, with exactly one Trustle User.)

You can create Trustle Users manually within Trustle, or sync them from your IDP's directory.

Once defined, Trustle Users (except for System and Customer types) can login to the Trustle web console.  What they can do once logged in varies, based on Trustle user type:

Org Owner

A superuser admin within the Trustle organization. They can administer Trustle Users and configure the entire Trustle organization. They can also view and run reports and analyses, and perform all the functions defined for other user types as described below. Only Trustle Users of type Employee can be Org Owners.

System Owner

A Trustle admin, scoped to a specific connected system, e.g., AWS.  Only Trustle Users defined as Employees can be System Owners.

Principal

The human (or computer system) entity that can authenticate as an identity within a system, and subsequently execute access on a resource under that identity.

Access Requestor

A person that requests access for themselves, or others.  This could be yourself, asking for read/write access to a Github repo, or perhaps a colleague requesting AWS staging environment admin group access for another member of their team.

Sometimes the requestor and the principal are the same (requesting for self), and sometimes they are different (requesting for someone else.)

Trustle Users defined as either Employees or Contractors can be Access Requestors.

Access Approver (Manager)

A person who is responsible for approving access requests from access requestors (their direct reports). Only Trustle Users defined as Employees can be Access Approvers.

Provisioner

When a manager approves a requestor’s access, Trustle will initiate a provisioning workflow which is either fully automated (no human interaction), or involves human interaction (fully or partially). If the workflow requires any sort of human interaction, the Provisioner is the human assigned those provisioning tasks. Only Trustle Users defined as Employees can be Provisioners.

Linking Trustle Users to Accounts

When you add an integration and bring systems and their associated accounts into Trustle, the first step in detecting an identity threat is to link them to a Trustle User. An account that cannot be linked to a Trustle User should leave you wondering "who does this account belong to, and why can't I account for it?"

Linking Examples

Lets say we've imported two Trustle Users, Alice and Bob, through Okta IDP sync.

Next, we add the AWS, Google, and GitHub integrations, to bring in system accounts from AWS, Google, and GitHub.

To mitigate the threat of rogue accounts, we'll account for, or link, each Trustle User, with one or more system accounts.

We can now account for all of Alice's accounts, and all of Bob's accounts. But one GitHub account, "niceguy", is not linked -- that is, we cannot establish the identity to link him to people or systems within our organization.

This may be a case of an accidental deprovisioning-workflow error -- maybe when "niceguy" left the organization, we missed removing him from our GitHub organization. Maybe "niceguy" is a contractor who is not in Okta, but is a valid member of the organization (if so, we can manually add him as a Trustle Contract-type user). But maybe, "niceguy" somehow infiltrated his way into our GitHub organization, and represents an immediate threat that must be removed.

This is why its critical to link all accounts, and be extremely vigilant on handling of those that are non-linked.

Now that we've walked through the basic concepts of Trustle, let's integrate our Trustle account with our Okta IDP. This will allow us to map accounts to people defined in Okta, as well as detect and respond to Okta-related identity threats.