Inventories
For both Identity Threat Protection and Privilege Control for Cloud Entitlements, Inventories provides a centralized and comprehensive view of all identities, access privileges, assets, and activities across an organization's cloud services and applications. This visibility is essential for detecting and mitigating identity risks and active threats, ensuring compliance, and maintaining a secure access baseline.
Inventories enable organizations to:
-
Detect and Eliminate Over-Privileges: By having a detailed inventory of access privileges, organizations can identify and mitigate over-privileges based on granular usage data and AI-based recommendations.
-
Monitor for Misconfigurations and Exposed Resources: Inventories help in detecting risky misconfigurations such as exposed Git repositories and stale file access on shared drives, thereby hardening the identity security posture.
You can use inventories to do the following:
-
Gain a holistic view of all the connected applications, their users, and access.
-
Identify important issues across your organization like stale cloud service accounts and users without MFA.
-
Define Collections that can later be reused for other product features such as security rules and reports.
The inventory pages display information that was either gathered from integrated systems or entered manually and then processed.
Inventory Types
Inventories are displayed on the following pages:
-
Identities: Displays identities and accounts
-
Identity: A unique identity (human or nonhuman) that owns one or more cloud service accounts. A nonhuman identity could be a machine identity, an automatic identity, or any other identity that doesn’t belong to a human.
-
Account: A unique account (human or nonhuman) in a single application. A nonhuman account might be a service account, a workload, or even a user account that is used for automated tasks.
-
-
Groups: Displays entities that “group” permissions to multiple accounts. This could be an IdP group (like a group of engineers who use the same design tools to build their product or application) or an AWS role that grants the same permissions to similar actors. The Groups table displays the applications in which the groups are managed, not the applications to which those groups grant access.
-
Assets: Displays every object in integrated systems to which users can be granted access, like files, folders, databases, virtual machines, and applications.
-
Memberships: Displays all groups and their members. For example, if a group represents the R&D department, the Membership inventory will present all its members. You can use this page to find the relationship between groups and their members, such as all groups a specific person belongs to.
-
Access Policies: Displays effective access and effective permissions. Effective access represents the permissions an entity (for example, a user) has on another entity (for example, an asset), based on what access was granted. Effective permissions are the combination of direct and indirect permissions used when accessing an object. You can use this page to find the relationship between an entity (cloud service user or group) and an asset.
-
Privileges: Displays a list of all privileges at all levels.
-
Activities: Displays who did what, and when it was done.
Inventories User Interface
You can access inventories by clicking Inventory from the left navigation menu, then selecting one of the choices from the secondary menu such as Identities. The Identities page is shown in the screen shot.
Filter the inventory table
By default, each inventory page includes a table displaying all data relevant to the page.
You can filter the table to show only the data you are interested in, creating granular queries to understand the inventories, groups, and assets in your environment as well as their current status.
For example, you can display all the identities with admin privileges whose cloud service accounts were disabled or suspended (or are unknown).
The filter fields for each inventory are described in Inventory Filter Properties.
If you have imported custom properties (shown at the end of the list), you use those to filter. For more information on importing custom properties, see Search by custom properties.
You can use these filter methods in the inventories:
-
Basic filter (Identities, Groups, Assets, and Privileges inventories). Filter the inventory table based on that inventories’ properties.
-
Advanced filter (Memberships, Access Policies, and Activities inventories). Filter an inventory table based on a broader set of properties as well as on the interconnected relationships and paths within the system. For example, you can filter for both actor and target.
Filter lines are connected by all AND operators or by all OR operators.
To split the current filter group into separate groups (thereby enabling more complex queries), click + and select AND or OR. To remove a filter group, hover and click X.
When there are options within a filter (for example, which apps an account can access), those options are always connected by OR.
You can also enter human-readable text (such as, "show me admins without MFA"). Click then type search text, then click Ask AI.
On many inventory pages, you can choose among predefined quick filters that are commonly used for that inventory.
To filter a table:
-
To add filter fields, click + and select from the available filter fields.
-
To remove fields, hover over a field and click X.
The table is filtered on the fly.
Inventory filters support the following operands:
-
Exact matches
-
In or Not In
-
Is Empty
-
-
Mathematical matches
-
Equal to, Greater than, etc.
-
-
Date matches
-
Yesterday, Last Week, Last Year, Custom, etc.
-
-
String matches
-
Contains or Not contains
-
Ends with or Not Ends with
-
Starts with or Not Starts with
-
Regardless of how they were added, the properties can be searched in the relevant inventory.
Search by custom properties
You can search by custom application properties, such as subscriptions in Azure or public repositories in GitHub or GitLab. This enables you to better scope the results, based on your unique organizational values.
Custom properties are added by:
-
The Delinea Platform: Each built-in integration exposes a set of custom properties. While custom properties retain the naming from their source, some imported properties are “normalized” on the platform with standard names.
-
Users: You can add custom properties (when building a custom integration) that enable you to import and search by any property from the source application.
Sort the inventory table
Each inventory table has a default sort order, indicated by the dark arrow displayed in the column header:
To change the sort order, hover the pointer over a column header. When a dimmer arrow is displayed, you can click it to change the sort order.
Other views
In addition to the inventory table, most inventory items also have a single-entity view and a quick view.
Single-entity view
To see more information about an inventory item, open its single entity view by clicking either the entity name (leftmost table column) or the target name (in Access Policies, Membership, and Activities tables).
The single entity view shows much more information about the inventory entity (for example, top incidents and MITRE tactics), and you can easily investigate using the Access Explorer.
Quick view
When you hover over the entity name, a quick view is displayed. The quick view shows a short list of commonly needed information. You can also investigate in the Access Explorer, show the entity in the source app (in some cases), and show the single-entity view.
Configure table columns
You can customize the presentation of tables in the following ways:
-
Which columns are displayed
-
Column width
-
Column order
These options are available in all inventory tables. Your choices are relevant to the specific page where you made the choices and will persist through future login sessions.
To set the displayed columns:
-
From an inventory table, click Columns above the table. The list of available columns is displayed.
-
To display a column, select it. To hide a column, clear its selection. The column display adjusts immediately. If a column name is dimmed, it cannot be hidden.
To set the column width:
-
From an inventory table, point the cursor between column headings where you want to adjust the width until the cursor changes to multiple arrows.
-
Drag the cursor left or right to adjust the column width.
To set the column order:
-
From an inventory table, point the cursor at a column you wish to move. The gray column dividers on both sides are displayed.
-
Drag and drop the column.
Export the table as CSV
You can download a CSV file containing all information displayed on a page. If the download is limited, that limit is displayed when hovering the download icon. To download more entries than the limit allows, filter the table to sets with fewer than the limit of entries, then download each set separately.
Use tags
Tags are keywords (“metadata”) attached to data to enable that data to be found by browsing or searching.
Tags are displayed on the inventory tables, and in the single-entity view. Tag names are usually self-explanatory, and you can hover your cursor over system tags to read an explanation.
When an application is integrated with the platform, entities tagged in the source system are similarly tagged in the platform. In some cases, the platform also applies its own tags.
You can apply tags manually from the inventory pages (not from the Membership or Access Policies pages) or from the single-entity view. These can be existing tags or new tags that you create on the fly.
You can apply tags to one or multiple entities simultaneously.
To apply existing or new tags from an inventory page
-
Select the row to tag.
To apply the same tag to multiple rows, select multiple rows. -
Click Add Tags, then click Add tags.
-
To apply an existing tag, select the tag, then click Save.
You can search for tags by typing the first few letters. -
To create a new tag, do this:
-
Type a new tag name.
-
Click Add New.
-
To apply the new tag, click Save.
If you do not apply the tag, the new tag is created and can be applied to entities later.
-
You can apply both existing and new tags in the same step.
To create new tags
-
Select an inventory row.
-
Click Add Tags, then click Add tags.
-
Type a new tag name.
-
Click Add New.
-
To add more new tags, type a new tag name and click Add New.
Inventory Filter Properties
Identities
Category |
Property |
Description |
---|---|---|
Account |
Access To Apps |
The applications a cloud service user (or service account) can access. The access might be direct or indirect (such as federated access). |
Admin Access |
The Admin filter enables you to find cloud service user accounts with administrative privileges. You can specify the application for which you want to find users with admin access. To modify this setting, navigate to the Settings page > Authorization Configuration. |
|
Blast Radius Risk |
The blast radius presents the impact of an account to be taken over, based on the account’s access and type of access. |
|
|
Email of the cloud service user (or service account) as found in the application. |
|
First Name |
First name of the cloud service user (or service account) in an application. The First Name may vary from application to application. |
|
ID |
ID |
|
Incidents Count |
The number of incidents an account has (e.g. the incidents in the AWS account). |
|
Is External |
"Is the account external? (Yes or No) External accounts are based on the email and properties of the account being different from internal users (or as stated in the downstream application)." |
|
Is Managed |
A managed account is managed by the current system's admin, meaning that as an admin, you can disable the account. Use this filter to find all accounts your admins have full control over, or those they do not control that have access to your systems. |
|
Is MFA Enabled |
Is MFA set in this application? (Yes or No) MFA settings may be different in different accounts, so MFA might be enabled in Okta but disabled in Slack. |
|
Last Login At |
Date of the last login in a specific application |
|
Last Name |
Last name of the cloud service user or service account. The Last Name may vary from application to application. |
|
Overall Risk |
The overall risk is calculated based on the Account takeover risk (the probability for an account to be taken over) and the blast radius (the impact) |
|
Detection Rule Name |
The filter enables you to filter based on cloud service users who match a specific detection rule, for example finding all the users that matched the brute force attack. |
|
Privileged Access |
The Privileged filter enables you to find cloud service user accounts with privileged access. You can select the application to identify users with privileged access. To modify this configuration, go to the Settings page > Authorization Configuration. |
|
Shadow Admin Access |
The Shadow-Admin filter enables you to find cloud service user accounts with shadow-admin privileges across various applications. You can choose the specific application for which you want to find users with shadow-admin permissions. Shadow-admin permissions grant users administrative capabilities with a reduced set of permissions they currently possess. |
|
Source App |
The application in which the account is a registered cloud service user. For example, if a user has federated access to AWS via his IDP (e.g. Okta) then Okta is the source app, and AWS is found in the Access to app filter. |
|
Status |
The status of the account in the source application, such as Deleted, Disabled, Enabled, or Unknown. |
|
Sub Type |
The sub-type filter present all the available sub-types of non-human Identities. |
|
Tags |
Tags that are associated with the account (e.g. Admin, Privileged Access). Tags are created automatically by the AI engine, manually by the end user, or are based on tags in the source system. |
|
Take Over Risk |
The account takeover risk presents the probability that an account will be taken over by an external identity |
|
Type |
User or Service Account |
|
Collection |
Name |
The named Collection is used as a filter. All collection types can appear in the filter. If an Access-type collection is used, then the identities that matched will be returned. |
Identity |
Blast Radius Risk |
The Identity Blast Radius filter helps you identify identities based on the risk imposed by their access collection. It focuses on the highest Blast Radius among all related accounts, providing insights into the extent of potential damage in case of a security breach. With this filter, you can quickly locate critical accounts or high-risk cloud service users with extensive access permissions, enabling you to prioritize security measures and reduce the overall risk of breaches. |
Department |
The department in which the identity works (e.g. Bus Dev., Customer Support, Sales, HR…). |
|
First Name |
The first name of the identity is taken from the primary account of the identity which is often the HR system, or the IDP. |
|
Hired At |
Date hired |
|
Last Name |
The last name of the identity, taken from the identity’s primary account, which is often the HR system or the IDP. |
|
Manager |
The name of the identity’s manager. |
|
Name |
The name of the identity, which is either taken directly from the primary account of the identity (the HR system or IDP in most cases) or a combination of the First and Last name from the Primary account. |
|
Overall Risk |
The Identity Overall Risk filter allows you to evaluate the comprehensive risk of an identity by considering the combined risks of its individual accounts. It incorporates two main components: Account Takeover Risk, which gauges the vulnerability of the identity to unauthorized access, and Blast Radius, representing the highest scope of permission the identity can achieve. By utilizing this filter, you can easily search for identities with significant security concerns, prioritizing measures to mitigate potential breaches and safeguard sensitive data. |
|
Source Apps |
Source Apps represents all applications for which the identity has a registered user account. For example, if a user has federated access to AWS via his IdP (for example Okta) then only Okta will be represented as the source app and AWS will be in the access to app filter. |
|
Tags |
Tags associated with the identity (e.g. Senior Employee, Involved in Credential leak, Finance Employee). Tags are created automatically by the AI engine or manually by the end user. |
|
Take Over Risk |
The Identity Account Takeover Risk filter evaluates the ease with which an attacker could gain access to any of an identity's connected accounts. It assesses the risk level posed by each individual account, providing a comprehensive understanding of the identity's overall security vulnerability. By utilizing this filter, you can proactively identify identities with weak account security, allowing you to prioritize security enhancements and protect against potential unauthorized access and data breaches. |
|
Terminated At |
Terminated At |
|
Title |
The job title of the identity (e.g. CTO, SW Engr. for example) |
Groups
Category |
Property |
Description |
---|---|---|
Group |
Admin Access |
The Admin filter enables you to find user accounts with administrative privileges. You can specify the application for which you want to find users with admin access. To modify this setting, navigate to the Settings page > Authorization Configuration. |
Alternative Name |
The alternative name of the group is presented to users and reviewers across the platform alongside the group name and is used to provide a clearer name for of the group |
|
Collections |
The named Collection is used as a filter. Filtering is based upon the results of the Collection query in this inventory, so the results will be all the groups that matched the Collection. |
|
ID |
ID |
|
Incidents Counts |
The named Collection is used as a filter. Filtering is based upon the results of the Collection query in this inventory, so the results will be all the groups that matched the Collection. |
|
Is Empty |
Filters for empty groups or non-empty groups. |
|
Name |
The name of the group as stated in the source system. |
|
Origin Type |
The type of the group in the source application (such as “AWS role” or “Salesforce Profile”) |
|
Owner |
The name of the owner of the group, if any. |
|
Detection Rule Name |
The filter enables you to filter based on groups who matched a specific detection rule, for example finding groups that grant admin access. |
|
Privileged Access |
The Privileged filter enables you to find user accounts with privileged access. You can select the application to identify users with privileged access. To modify this configuration, go to the Settings page > Authorization Configuration. |
|
Shadow Admin Access |
The Shadow-Admin filter enables you to find user accounts with shadow-admin privileges across various applications. You can choose the specific application for which you want to find users with shadow-admin permissions. Shadow-admin permissions grant users administrative capabilities with a reduced set of permissions they currently possess. |
|
Source App |
The app on which the group is managed. |
|
Tags |
Tags associated with the group (general, birthright group for example). Tags are created automatically by the AI engine, manually by the end user, or are based on the tags in the source system. |
Assets
Category |
Property |
Description |
---|---|---|
Asset |
Created At |
Creation date of the asset, if available. |
Collections |
The named Collection is used as a filter. Filtering is based upon the results of the Collection query in this inventory, so the results will be all the Assets that matched the Collection. |
|
ID |
ID |
|
Incidents Counts |
The number of incidents associated with the asset. |
|
Last Used At |
The last time the asset was used (accessed, modified, deleted or created). This data is available mainly in Asset of Type Secret or of type applications, and is not available in most other asset types. |
|
Name |
Name of the asset. |
|
Origin Type |
The type of the asset on the source application (for example: EC2 machine in AWS, or Application in Okta). |
|
Detection Rule Name |
The filter enables you to filter based on assets that matched a specific detection rule, for example finding production assets that can be accessed by non-admins. |
|
Source App |
The app on which the asset is managed. |
|
Tags |
Tags associated with the asset (Production or Test Environment for example). |
|
Type |
Assets are "normalized" (grouped) to a minimal set of types across all applications. Consequently, assets can be filtered by their "normalized" Type (such as Virtual Machine), and they can be filtered specifically by the name of the asset in the source system (for example, EC2 machines on AWS). |
Memberships
Filter |
Entity Type |
Category |
Property |
Description |
---|---|---|---|---|
Actor |
Identity |
Account |
Same as Identities-Account |
|
Identity |
Collection |
Same as Identities-Collection |
||
Identity |
Identity |
Same as Identities-Identity |
||
Group |
Group |
Same as Groups inventory |
||
Target |
Group |
Group |
Same as Groups inventory |
|
Access |
Membership |
Added at |
Filter when this membership was created. |
|
Added by |
Filter by whom this membership was created. |
|||
Direct Access |
Direct Access |
|||
Collections |
Collections |
Access Policies
Filter |
Entity Type |
Category |
Property |
Description |
---|---|---|---|---|
Actor |
Identity |
Account |
Same as Identities-Account |
|
Identity |
Collection |
Same as Identities-Collection |
||
Identity |
Identity |
Same as Identities-Identity |
||
Group |
Group |
Same as Groups |
||
Target |
Asset |
Asset |
Created At |
Creation date of the asset, if available. |
Collections |
The named Collection is used as a filter. Filtering is based upon the results of the Collection query in this inventory, so the results will be all the Assets that matched the Collection. |
|||
ID |
ID |
|||
Incidents Count |
The number of incidents associated with the asset. |
|||
Last Used At |
The last time the asset was used (accessed, modified, deleted or created). This data is available mainly in Asset of Type Secret or of type applications, and is not available in most other asset types. |
|||
Name |
Name of the asset. |
|||
Origin Type |
The type of the asset on the source application (for example: EC2 machine in AWS, or Application in Okta). |
|||
Detection Rule Name |
The filter enables you to filter based on assets that matched a specific detection rule, for example finding production assets that can be accessed by non-admins. |
|||
Source App |
The app on which the asset is managed. |
|||
Tags |
Tags associated with the asset (Production or Test Environment for example). |
|||
Type |
Assets are "normalized" (grouped) to a minimal set of types across all applications. Consequently, assets can be filtered by their "normalized" Type (such as Virtual Machine), and they can be filtered specifically by the name of the asset in the source system (for example, EC2 machines on AWS). |
|||
Access |
Access |
Collections |
The named Collection is used as a filter. Only access-type Collections will yield results in this inventory |
|
Granted at |
Filter when this access policy was created. |
|||
Granted by |
Filter by whom this access policy was created. |
|||
Is Direct |
A direct assignment of access is any access granted to the account/group directly and not via another group. when marked as Yes only direct access will be shown and calculated in the result, if marked as not only indirect will be included, for both options remove or do not use the filter at all. |
|||
Last Used At |
Filter access policies by their last used date. |
|||
Limit Inheritance |
The filter will only include the first asset in the system that matches the query and will not return any inherited assets. For example, if you are asking to find administrative access in a file system and a user has access to a folder and the folder has a file, by applying this filter the result will only include the folder. |
|||
Privilege |
Is Role |
Filter on the privileges of a role on different assets. In other words, different users get the same privilege (through the same role) but on different assets. In the platform, this is called a "local" role. |
Privileges
Category |
Property |
Description |
---|---|---|
Privilege |
Child Privileges |
Use this filter to find a privilege that contains a specific child privilege, for example, search the privilege add MFA and find every admin or similar roles/privileges that can add MFA devices |
Is Role |
Does the privilege represent a role on the application? (Yes or No). |
|
Origin Name |
The name of the privilege in the source application. |
|
Source App |
The app on which the privilege is managed. |
|
Tags |
Tags associated with the privilege (Production or Test Environment for example). |
|
Type |
Privileges are "normalized" (grouped) to a minimal set of types across all applications. Consequently, privilege can be filtered by their "normalized" Type (such as Administrative), and they can be filtered specifically by the name of the privilege in the source system (for example, ORG.ADMIN on GitHub). |
Activities
Filter |
Entity Type |
Category |
Property |
Description |
---|---|---|---|---|
Actor |
Identity |
Account |
Same as Identities-Account |
|
Identity |
Collection |
Same as Identities-Collection |
||
Identity |
Identity |
Same as Identities-Identity |
||
Group |
Group |
Same as Groups |
||
Target |
Asset |
Asset |
Same as Access Policies Target Asset |
|
Identity |
Account |
Same as Identities-Account |
||
Identity |
Collection |
Same as Identities-Collection |
||
Identity |
Identity |
Same as Identities-Identity |
||
Group |
Group |
Same as Groups |
||
Privilege |
Privilege |
Child Privileges |
Use this filter to find a privilege that contains a specific child privilege, for example, search the privilege add MFA and find every admin or similar roles/privileges that can add MFA devices |
|
Is Role |
Does the privilege represent a role on the application? (Yes or No). |
|||
Origin Name |
The name of the privilege in the source application. |
|||
Source App |
The app on which the privilege is managed. |
|||
Tags |
Tags associated with the privilege (Production or Test Environment for example). |
|||
Type |
Privileges are "normalized" (grouped) to a minimal set of types across all applications. Consequently, privilege can be filtered by their "normalized" Type (such as Administrative), and they can be filtered specifically by the name of the privilege in the source system (for example, ORG.ADMIN on GitHub). |
|||
Activity |
Activity |
Date |
The date when the activity was performed. |
|
Is Virtual |
Virtual activities are activities that are not logged in the external system but are represented as activities in the platform, such as login events. |
|||
Success Status |
Success Status |
|||
Tags |
Tags associated with the activity. |