Data protection
  • 11 Jun 2024
  • 9 Minutes to read
  • PDF

Data protection

  • PDF

Article summary

Traceable's Data Protection page with Live View helps you map the sensitive data to the users of the sensitive data and informs at what rate the data is being accessed. The data protection also lets you know which APIs expose sensitive data. This is important to know to create a robust data protection policy. As shown in the screenshot below, there were 3.59K users in the last week, along with the user's geolocation. The live view map shows the user's geographic location and the number of records accessed from a location.


The Summary section also shows the type of location from where the data was accessed. The location type can be:

  • An anonymous VPN

  • A bot

  • A hosting provider

  • A public proxy

  • An unknown source

All users

The All Users tab, as marked in the above screenshot, gives you the details about the user accessing the data and the type of data the user has accessed. For example, you can see that a user from domain has accessed 132 phone records. In addition, the user has accessed POST /loginservice/login and one more API endpoint. The Source information column shows the risk associated with the user, the location type of the user, and so on. In this tab, you can filter and sort data to view users according to your specified criteria. You can also click on the Actions drop-down and download the list of users as a CSV file. While downloading, you can also select the number of rows you want to download from the list.

In-depth data analysis

If you hover the cursor over, for example, the data type or click on the + sign, the dashboard will provide you with more in-depth information. For example, in the screenshot below, the user has accessed numerous sensitive data types from many IP addresses. This information is useful in understanding the level of risk associated with the user. It also helps you understand what your expectation was with data access for a user and what the user is accessing.


Such in-depth analysis and information can give you indicators to create necessary controls to avoid unauthorized access and the theft of sensitive data. The next section explains how to use this information to create an effective data protection policy.

Create a Data Loss Prevention (DLP) policy

The DLP policy enables you to control access patterns for sensitive data to an API within a given period of time. Sensitive data access is tracked per source type for sensitive data sets and types for specified APIs. After the data access limit is reached, if blocking is enabled, the policy rejects all requests by that user, thereby avoiding any exfiltrating attempts of sensitive data. Or it alerts any such further access.

You can create a data access policy by clicking the + Create Policy button. A data access policy allows you granular control over data access. A data access policy or a zero trust policy can define who can access data, what kind of data can be accessed, and at what rate the data can be accessed, among many other options. If you wish to create a specific policy using inputs from the access data of a user, click on the Create Policy button displayed after clicking on the ellipse icon (…) as shown below.


Creating a data access policy consists of three parts:

  1. Setting up the criteria for the policy

  2. Adding the conditions under which the policy would trigger

  3. Setting up the actions to take once the policy is triggered

Step 1 — Criteria

The data access policy provides many granular options to configure, for example, source of traffic, IP addresses, IP type (bot, VPN, and so on), user ID, region, attributes, and so on. Many of these fields are pre-populated when you create a policy from specific user data, as shown below:


The screenshot shows that IP addresses that accessed sensitive data are pre-populated. Similarly, other configuration options are also automatically added. You can retain or reconfigure them based on your requirements. When creating the policy, make sure that you choose the correct environment to which this policy applies, or you can choose it to apply across all the environments. For example, you can have two entirely different policies for different environments like, staging and production. Following is a list of different configuration options to create a data protection or zero trust policy:

  • Policy Type — The type of policy you want to create.

  • Environment — Environment(s) to which the policy applies.

  • Source

    • IP addresses (optional) — IP addresses that should be part of the data protection policy.

    • IP type (optional) — Type of IP address to monitor using the policy:

      • Hosting provider

      • Public proxy

      • Anonymous VPN

      • Tor exit node

      • Bot

    • Regex for email (optional) — You can add a regular expression to match the email domain. All requests from email domains matching the regex would be allowed or blocked per the access policy's conditions.

    • User ID (optional) — You can pick one or more user IDs to whom this policy should apply. Alternatively, you can specify a regex for user ID. For example, you can specify a domain name ( in the regex so that all the users coming from this domain can access data as defined in the policy. This is a way to enforce your zero-text policy.

    • Regex for user agent (optional) — You can add a regular expression to capture a specific set of user agents. For example, you can have a regex that allows data access from a specific browser.

    • Connection type (optional) — Select the type of connection from where you would like to allow data access. You can choose one or more than one type of connection type from:

      • Residential

      • Mobile

      • Corporate

      • Data center

      • Education

    • Minimum IP reputation (optional) — Choose the type of IP address based on their reputation from where you would allow data access.

    • Region (optional) — The countries to be monitored.

  • Payload — Data sets or data types to be monitored, for example, a few of the inbuilt data sets like GDPR, HIPAA, AWS Auth, Azure Auth, GCP Auth, and so on.

  • Target — The API Endpoints that need to be monitored as part of the policy. When you click on Add Endpoints, the entire catalog of APIs is presented to you. You can choose the API endpoints that you want to be part of the policy. These API endpoints in the catalog can be sorted or filtered based on the type of sensitive data they carry, the risk category they belong to, whether the APIs are authenticated or not, whether they are external, and so on.
    For example, an API endpoint that is external and authenticated would have higher priority, as authentication makes the basis of a zero trust policy. You can further select the type of authentication, for example, a basic authentication (username, password) or authentication based on bearer token. Further filtering of APIs can be done based on the types of security headers they carry, for example, CSP or HSTS, and so on. All these selections help you define the user who has access to your data, and in turn help you build a robust zero trust policy.

Click on Next after you have defined the criteria for the policy.

Step 2 — Choose conditions

In this step, define the conditions associated with the policy. A condition is a set of rules which decide when the policy would trigger. These conditions could either be a static condition or a dynamic condition.


Dynamic conditions help you adjust the rate limit intelligently based on the baseline traffic that is calculated based on the number of days that you have configured. By default, the baseline is calculated based on the traffic received in the past one day. You can have both, the static and dynamic conditions work together. For example, you would use the static condition in case of account take over, where you would want to block the access immediately. 

Click on Next to define the actions that should be taken once the policy is triggered based on the conditions that you have defined.

Step 3 — Actions

The actions' card helps you define the action that you would like to take when the data protection or zero trust policy is triggered. You can define the severity of the event as low, medium, high, or critical. As part of the actions that you can take, you can block the user indefinitely, or choose to block them for a certain period of time, or you can choose not to block them and instead generate an alert only. 

Click on Next to review and Submit the policy.

Default rules

Traceable provides a few default DLP rules that you can use out-of-the-box. Navigate to Protection Settings Custom Policy and click on the Data Loss Prevention tab.  


For example, you can click on the default rule that alerts for PCI DSS data for critical risk BOTs and anonymous VPNs and customize it according to your requirements. This default rule would help you build a trust policy that would never allow your PCI DSS data to be accessed through anonymous VPNs and BOTs. When you click on Next, you are taken through the same data access policy creation flow explained earlier.

Understand API abuse

When these policies get triggered, you can see the results by navigating to ProtectionThreat Activity page. Select API abuse from the Threat Category filter and Data loss prevention from the Threat Type filter. Traceable then displays the threat activity triggered by the data protection policies that you have created.


If you click on a threat activity, for example, the data access policy fintech in the above screenshot, Traceable displays the detailed activity by users. You further drill down into their session activity, information about payload, request, response, and the attributes.


As illustrated by the above screenshot, there are 41 contributing threat actors, one API endpoint is affected by them. If you click on the affected endpoint, Traceable would display the endpoint. You can further filter these activities based on one of the many filter options provided in the same view by clicking on Add Filter.

Datasets summary

The datasets summary tab displays the Data sets and types of data accessed by users in the selected period. It also displays the number of users who accessed each type of dataset. 


The above screenshot, for example, shows that the Material Personal Info dataset was accessed in the last one-week by 707 users across 195 API endpoints, 15 services, and 18 domains. The users accessed the email record 1647 times, full name 1374 times, and so on. When you click on the dataset, in this example on Material Personal Info, Traceable displays the details about the users who accessed that data set. Traceable in this way helps you identify such users who might be misusing their data access privileges.


The services tab lists the different types of sensitive records accessed by different services. The timeline represents which APIs are accessing the sensitive data and how many records were accessed. For example, in the screenshot below, you can see that the API endpoint GET /identity/api/v2/vehicle/vehicles has accessed a total of 664 sensitive records across 343 users on 14th May 2024 at 11:18 PM.


The timeline aggregates all the sensitive records for a service for a specific time. This would help you in understanding the data access patterns and, in turn, helps in building a better data access policies.

Was this article helpful?


Eddy, a generative AI, facilitating knowledge discovery through conversational intelligence