Data protection

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 are exposing which sensitive data. This is important to know to create a robust data protection policy. As shown in the screenshot below, there were 305 users on the last one day, along with the geolocation of the users. The map in the live view shows the geographic location of the user and the number of records accessed from that 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 screenshot, gives you the details about the user accessing the data and the type of data that the user has accessed. For example, you can see that a user from tortoise.com domain has accessed 111 phone records. In addition, the user has accessed GET /userinfo/json and seven more API endpoints. The Source Information column shows the risk associated with the user, the location type of the user, and so on. In this example, the user is coming from a hosting provider and one more location. 

In-depth data analysis

If you hover the cursor over, for example, on data type or click on the + sign, the dashboard would provide you with more in-depth information. For example, if you click on the + sign to expand on a particular user, you would more detailed information. As illustrated by 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. This information also helps you understand what your expectation was with data access for a user and what the user is actually accessing.

Such in-depth analysis and information can give you indicators to create necessary controls to avoid misuse of access and stealing of sensitive data. The next section explains how to you 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.

Creating a data access policy consists of three parts, setting up the criteria for the policy, the conditions in which the policy would trigger, and finally the actions that should be taken once the policy is triggered. 

Criteria

You can create a data access policy by clicking on 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 three dots (…) as shown below. 

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

As seen in the screenshot, IP addresses that accessed the sensitive data are prepopulated. Similarly, other configuration options are also automatically added. You can retain them, or you can reconfigure those based on your requirements. In the process of 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:

• 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 email domain. All requests coming from email domain matching the regex would be allowed or blocked as per conditions of access policy.
    
  • 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 (abc.com) in the regex such that all the users coming from this domain would have access to data as defined in the policy. This is a way to enforce your zero trust 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.
• Attributes - 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.

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.

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 to suit your needs. 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 Protection → Threat Activity page. Select API abuse from the Threat Category filter and Data access 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 20 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. All these in-depth insights provide you information for further threat hunting and forensics.

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 HIPAA dataset was accessed in the last one-day by 365 users across 35 API endpoints, 10 services, and 9 domains. The users accessed the email record 353 times, phone records 269 times, and so on. When you click on the dataset, in this example on HIPAA, Traceable displays the details about the users who accessed that data set. The screenshot, below, shows a sample set of users accessing the HIPAA data set. 

The last record shows that the user has accessed the same dataset from 42 different IP addresses. This can be an attempt to exfiltrate sensitive data. Traceable in this way helps you identify such users who might be misusing their data access privileges.

Services

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/vehicle/vehilces has accessed a total of 14 sensitive records across 2 users on 2nd May 2023 at 9:30 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.