The principle of least privilege is a principle in security engineering that an actor in a system should be assigned the fewest privileges that are necessary to get the job done. This article will walk through some examples of what the principle of least privilege is, why it is important and how it applies to Incydr™ when using Code42’s API clients.
An example of the principle of least privilege is the valet key for your car. This key is an alternative to the regular car key (a.k.a. the master key), and is intended for you to give to a valet if you want them to park the car. The valet key is just like the master key, except for some limitations. It can lock/unlock the doors and start the car, but it should not allow someone to open the trunk. Some cars also have the ability to lock the glove box with the master key, and the valet key is not able to open the glove box. This allows you to keep your valuables secure from a valet who may be trusted to drive the car in order to park it, but not open the trunk.
In this example, the principle of least privilege applies to both the design of the system and how it is used. In designing the system, the car manufacturer created two types of keys and designed the locks so that access is limited with the valet key. Then, when using the car keys, the driver can give out keys based on their level of trust in the person. For example, if you loaned your car to your friend, you would give them the master key and ignore the valet key.
Benefits of the principle of least privilege
Let’s explore the benefits of the principle of least privilege and the value they bring to security practitioners and their organizations.
Limit data exposure
In the world of software systems, we don’t use keys and locks to secure our data, but instead, we use roles and privileges. Each principal has a specific set of roles associated with it, and the data it can access is scoped to those roles.
“The advantage of this setup is that if credentials associated with a principal are compromised, it limits data exposure.”
If an actor tries to abuse the system, their impact is limited to the authorization that was given. These are some of the benefits of having granular roles and privileges that can be assigned using the principle of least privilege.
Limit the impact of an error
Even if someone isn’t trying to abuse the system, sometimes the principle can help limit the impact of an error. For example, if I want to share a document to get review feedback, I can share it with read-only access, and I know the reviewer won’t accidentally add or delete anything if they click or type into the document while reviewing it. Another example is in the command line of both Linux and macOS. Certain commands require root access, and won’t run as a regular user unless you use the “pseudo” command in front of it, which instructs the system to check that the regular user also has root privileges. This prevents mistakes, like removing critical system files or changing system settings when you are casually using the command line.
Principle of least privilege in Code42 Incydr
Incydr has two ways to create credentials to access your Code42 environment: user accounts and API clients. User accounts are best used for individuals who access Code42 as part of their daily work and are required to tie a device running the Code42 app to your environment. API clients are new in the November 2021 cloud release and are best used for integrations.
In our blog post earlier this month, we’ve covered how API clients provide a secure and convenient way to access the API and follow the OAuth 2.0 standard for credentials tied to an access token. The main advantage of API clients is they give more control over how much access the integration has. Each API client can be created with permissions needed for the specific task.
Consider an integration that automates adding or removing users in the Departing Employee list based on an external data source. In the Create API client dialog, we have the following list of permissions:
The departing employee list is part of the Detection Lists feature, so choose the “Detection Lists – Write” permission for the API client. Now the API client can add an employee to detection lists, but can’t access other parts of the Code42 environment. The API client can be named appropriately, for example, “Detection List Sync.”
Another example is creating an API client to export the audit log results to a separate system where they can be kept for greater than the 90 day retention period. To do this, create an API client with the “Audit Log – Read” permission.
More reasons to care about API clients
API clients have additional benefits that overlap with the benefits of the principle of least privilege. First, API clients are visible. All the API clients in your Code42 environment are in one place for easy reference. Second, API clients are easy to create. You can create a separate API client for each integration, and customize the API client’s permissions appropriately. Finally, the API client page shows the redeemed time, which is the last time those credentials were used to get a token.
In addition to the above benefits, API clients can be audited with Audit Log for further investigation. The Audit Log view can be filtered to show just actions that were done by API clients. Audit Log can also show who created an API client or who changed its permissions.
Getting started with API clients
Here are some resources to help you get started using API clients to power your integrations:
Subscribe to our blog in the sidebar for future udpates.