May 23, 2017

Introducing custom security rules

For the past few years we’ve been working hard to create a plug and play adaptive risk engine. We designed our core service using a mix of best practice rules, machine learning, probabilities and third party risk or IP reputation services so that our customers could get up and running quickly with zero configuration.

As we’ve grown and encountered bigger customers we’ve come to realise that larger customers typically require more deliberate control over risk scoring. A typical conversation with a customer or prospect starts off talking about what’s available straight out of the box and then flows into how they can customize for various teams, groups or customers within their organization.

Today we’re excited to announce a custom rules engine and the first of many rules types that will give you greater control over risk scoring and access to your applications.

Rules can be created, updated and deleted via the ThisData API. They can also be scoped by source which allows fine grain control for customers that are in a multi-tenant environment or large organizations with many departments or teams.

Blacklists

This rule type will compare specific parameters of an event against a list of values that are not allowed access to your application.

If a blacklisted value is detected the risk score for the event is immediately set to the highest value of 1.0. This is particularly useful for authorization workflows when combined with our Verify API.

Common uses for the blacklist are to block out IP addresses, CIDR ranges or countries.

e.g. Create a rule to block a selection of IP addresses

POST /rules  
{
  "name": "IP Blacklist",
  "description": "Block IP addresses & ranges",
  "type": "blacklist",
  "target": "location.ip",
  "filters": ["1.1.1.1","122.56.232.0/22"]
}

With this rule in place any event that has the IP of 1.1.1.1 or is in the range of 122.56.232.0 - 122.56.235.255 will immediately get scored as high risk.

Whitelists

Use these to create exceptions to the blacklist. This is useful if you want to allow specific customers or teams access from various locations or IPs.

e.g. Allow DevOps team access from specific IP

POST /rules  
{
  "name": "DevOps Whitelist",
  "description": "Allow access for DevOps team",
  "type": "whitelist",
  "target": "location.ip",
  "filters": ["1.1.1.1"],
  "source": "dev-ops-team"
}

In this example any Events sent to ThisData with a source.id of dev-ops-team would be allowed access from IP 1.1.1.1 but all other teams would be scored as high risk.

Stay tuned for additional custom rule types that enable more control, tighter security and better user experiences.

We’re still working on adding the new rule endpoints to our client libraries but the REST API is available today. Read more about creating and managing Rules.

YOU MAY ALSO BE INTERESTED IN

The future of authentication

Today I’m excited to announce a deal that we have been working on for the past few months and how that will impact the future of contextual ...

Introducing custom security rules

For the past few years we’ve been working hard to create a plug and play adaptive risk engine. We designed our core service using a mix of b ...