Signals represent key inputs to Castle’s risk score calculation, which can also be used when building stand-alone risk logic into your application, or as part of the Castle-hosted policy configuration.
Understanding the signals present when an event was evaluated can provide insight into why Castle’s risk score is set at a particular value. Signals do not deterministically predict the numerical risk score, but they may often be correlative to high risk scores.
Castle strives to be a transparent account security and risk mitigation platform. We expose any triggered signals as part of the API response from the
/authenticate endpoint. These signals are grouped into a few categories:
- Automated activity
- Anomalous behavior
- Device data error
- Device intelligence
- Email intelligence
- IP intelligence
- Unobserved characteristics
- Unapproved characteristics
The full list of signals that we expose can be found in our Signals reference page.
Enabling in-house risk analysis
Castle’s signals from the
/authenticate response can be logged and analyzed with your available application data tools and platforms. Since Castle provides the data in the API response, this signal data can be aggregated alongside the risk score and any other user or event context data that feeds into your application and account risk management tools.
Logging signals and risk scores will allow security teams to perform internal analysis about which signals are predictive of malicious behavior within your application.
Signals lead to policies
If your internal analysis of signals and risk scores leads to high positive predictive rates of security events, then Castle policies fully support the ability to introduce
"action": "challenge" or
"action": "deny" responses alongside those signals and risk scores in our API response from
/authenticate. Our Policies tutorial will guide you in setting up policies to look for these high-risk signals and react appropriately.
Should you decide to set up policies based on signal analysis, we offer the ability to create Log-only policies in order to test the effectiveness of these policies before making them “go live” in your environment(s). Castle webhooks will still be triggered whenever a
deny action is issued for a device for the first time, allowing you full customizability when it comes to alerting and follow-up workflows.