Castle Risk Scoring

Introduction

Castle's APIs return a numerical risk score between 0.0 and 1.0, represented as 0–100 in the dashboard. Low-risk events are scored at or near zero, and high-risk events are scored at or near one.

When producing this risk score, many properties are evaluated. These properties include:

  • Whether the event is pre- or post-authentication
  • Any history of the device performing the event
  • Suspicious behavior, such as high entropy in user or device traits
  • Historical statistics for the crowd of all of your users
  • The real-time IP, ISP, and email reputation

Risk factors

Castle determines a set of risk factors that are evaluated based on the contextual data provided for an event. Summaries are provided here for evaluations of IP characteristics, device characteristics, bot behavior, location, and suspicious behavior. This is a small sample of the total number of risk factors that Castle evaluates when determining the risk score - it should not be considered a comprehensive list.

Castle allows configuration of policies to block or label events that exhibit certain risk factors. This allows an infinite amount of customization for your own Castle integration - you can block events, get webhook notifications, and create follow-up workflows based on very specific policies, looking at very specific risk factors, and applied to any number of events that you choose.

Device characteristics

Castle collects hundreds of features from the device and user interactions, and is able to reliably determine the kinds of devices, as well as individual pieces of hardware that users are using. Castle can tell when a device is trying to spoof its' true platform or browser, or if the same devices is being used to access many different accounts. See the chapter on Device Fingerprinting for a more in-depth walk-through.

Bot behavior

Castle evaluates fingerprint characteristics for telltale signs of bots. The behaviors we look for include things like straight vector mouse movements, time patterns between interactions, and some other mechanisms that we like to keep as closely-held secrets. To get an idea of what our Data Science team works on when it comes to effective detection capabilities, including our ability to spot Bézier curves, read our Blog post on Bot Mouse Movement Detection.

Location

Castle maintains an updated data store of IP locations. Castle keeps track of locations around the world where a user and device has been "seen". This means that risk factors such as "New Country" and "Fast Travel" will be evaluated and feed into risk calculation for a user. Castle also compares new locations against "expected" locations where users travel, and factors likelihood of the users being in that location when determining risk score.

Based on the labels above in combination with activity that we observe, Castle maintains a concept of an IP and ISP reputation that changes over time. Since IP addresses get reassigned, these reputations are not static. IP and ISP reputations change in real time. Castle has seen more and more attacks originate from residential network ISP's, and we tune our product to block bad activity while still allowing "good" users to access their accounts.

Suspicious behavior

Castle looks at a variety of behavioral traits of devices, ISP's, and individual IP traffic to determine suspicious circumstances. These traits include, among many others, the ratio of failed-to-successful events, as well as observations of multiple-account access attempts. As with our other models, we tune our product to be extremely fast in detecting suspicious behavior, and we label such behavior in real time.


Did this page help you?