Conditions are evaluated facts that are used when creating Policies or Profiles. When all conditions within a single Profile or Policy are true, the Profile or Policy is applied.
There are five condition categories:
- Device – Attributes associated to the device including type, location of the device, and browser attributes
- Network – IP address attribute
- User and Accounts – Attributes of the user as passed in by you (the Kount customer)
- Velocities – Counts of different activities
- Velocities: Comparative – Comparing a velocity to another
Assigned Trust State
Assigned Trust State is dependent on integration with the trusted device API. This condition evaluates the device trust state for the user logging in.
The condition may be evaluated as is or is not one or more of the following:
- Banned – Trust state for the user’s device that was assigned by the Kount customer either with API or the Kount Portal
- Trusted – Trust state for the user’s device that was assigned by the Kount customer either with API or the Kount Portal
- Unassigned – Trust state has been removed from the user’s device, but the date history is kept
- Unknown – Indicator that there is no trust-state record for this user’s device
NOTE: This only applies to the trust state record – it does not indicate that there is no record of this specific device.
Ability to match on the country that the device being logged in from is currently located (geo-fencing). This condition allows is in or is not in to allow a condition to include or exclude one or more countries.
Device Data Collection
Ability to create a condition based on whether the device data collection was successful. In some cases, this is unsuccessful when the browser is intentionally blocking collection.
Allows geo-fencing by region.
Device Region Use Cases:
- A company has regulatory requirements and cannot operate in certain U.S. states.
- A company has regulatory requirements and can only operate in one Canton in Switzerland.
Mobile device is a true/false flag indicating if the user is using a mobile device. In some instances, this would be used in conjunction with other rules or would be used for business policy, rather than an identification of risk.
Friendly Name is a text match that looks for the friendly name of the device if the device has a trust relationship with the user. The logic for this functionality is as follows:
- Does the userID and the deviceID for this login have a trust relationship? If no, then this condition evaluates as false. If yes, proceed to step two below.
- Does the Friendly Name for the device in this trust relationship meet the logical condition of this rule? If no, the condition evaluates as false. If yes, the condition evaluates as true.
This rule is only useful when used in conjunction with Trusted Device Functionality. It is useful when the Friendly Name is set using a codified methodology – especially useful when a client is using trusted device for different use cases.
The customer has a single clientID but manages multiple sites that share userIDs. They wish to manage trust relationships on a per-site basis, but they also want to know when the device is trusted for a user on the other site. By adding a site identifier into the Friendly Name, conditions can be created to tag the Login API response with all of the sites that the user has trusted relationships for. Additionally, the customer can identify when a user has a banned trust relationship on one or more of their sites.
Text match field against the browser. Some browsers are either designed for hiding location or other information while other browsers might be indicators of scripted logins.
Examples of browsers that might indicate a level of risk:
- YaBrowser (Yandex)
- Ice Dragon (Comodo)
True of false if the mobile SDK is used.
In the device collection, if the sdkType is not NULL, then the condition is true or false.
Text match for identifying the operating system being used. Some operating systems may indicate higher risk of an event being scripted.
Proxy Service allows rule creation on if a proxy is used during device data collection.
The condition will be held TRUE if i) cpeIpType = "Proxy" OR ii) proxyType = "service" OR "tor" OR "http" else FALSE.
Device First Seen
Device First Seen allows rule creation on the first capture date of the device.
Days old calculation
If the device ID is null, then device first seen date is <TODAY>.
If the device ID has a value, then there will be a dateFirstSeen in the device payload with the following path: days old is the difference in device first seen day minus today's date (rounded down to the nearest whole number).
Boolean evaluation if the login came from a hosting facility.
Hosting Facility Use Cases:
- It is rare that a user will be browsing the internet as a hosting facility. Even more rare if the device is a mobile device. This combination likely means that the device is not mobile but rather a simulator.
- Logins from a Hosting facility contain a high amount of credential stuffing traffic, so a company challenges every login from a hosting facility.
IP Address Mismatch
Evaluation of the IP address passed in with the login request to the IP address collected by the device collector.
When someone logs in via a web browser, a device collection occurs (including capturing the IP address) and a sessionID is created. An attacker can take that sessionID and use it in a headless browser session to make it look legitimate. Since the IP address differs from when the initial device collection occurred, it can indicate fraud.
IP Address Range
Evaluation of the device during login against a range of IPs – the range can only be within the final octet. For example: nnn.nnn.nnn.035 through nnn.nnn.nnn.200. The range can be a maximum of 255 values (001-255).
IP Address Value
Evaluation of the IP address of the device during login.
IP Address Value (and Range) Use Cases:
- A fraud agent notices a single IP address is going nuts on the failed attempts. She tries to get a hold of Ops, but it is National Curling Day and they are probably watching the finals. She sets a condition to block the IP address until they can come help.
- A company wants to reduce friction for its call center when logging into the portal – so it sets a Profile based on the IP addresses from the call center.
Boolean evaluation if IP addresses that show anomalous behavior or have been associated with fraud.
IP Anomaly Use Cases:
- A company has a low risk tolerance – any IP anomalies are challenged.
IP Registering Org
Text match to the organization responsible for registering the IP Address.
IP Registering Org Use Cases:
A company has a credential stuffing attack and sees that a specific IP Registering Org is causing the attack. The company then blocks all traffic from that Organization regardless of IP Address.
IP Risk is a true/false flag. A high IP Risk is determined by a number of properties that are used within a machine learning model. Some of these properties include:
- Anonymous proxies
- Intentional obfuscation
- Type of internet provider
- Anomalous IP attributes
A true/false flag indicating the use of a TOR network. If the TOR network is being used, the location of the user has been highly anonymized, and there is no reliable way to use attributes to identify device authenticity.
True or false if a proxy has been identified during the login process.
User and Account Conditions
Account age is determined on the account creation date sent with the Login request. If no account creation date is passed with the login request, this rule will not evaluate. If an account creation date is passed with the login request, the number of days old are calculated and the Account age is determined.
The following operators may be used to evaluate against the number of days entered.
The filter for user type is dependent on the value passed in the Login API. This is a client generated text field that may be up to 128 characters.
When the Login API is passed to count userType is an optional field. If no value is passed in the Login API, the user type rule will not evaluate as true.
Login URL is a text match to the optional LoginURL field that can be passed with a Login API call. Since Login URL is a text match, it can be used as a user-defined field similar with userType. The logic for this functionality is as follows:
- Was text passed in the login API call for the LoginURL field? If no, this condition evaluates as false. If yes, proceed to step two below.
- Does the text within LoginURL meet the logical condition of this rule? If no, the condition evaluates as false. If yes, the condition evaluates as true.
- Client has multiple LoginURLs and different restrictions based on the URL. Profiles are set up to match URL.
- Client has text that needs to be passed into the login API for evaluation. The client maps the text to LoginURL and then creates conditions to match the inbound text.
Device Login Attempts
Ability to set the number of login attempts with different userIDs for a single device. This is a velocity that count when a single device is attempting (or succeeding) in logging in with many different user accounts. While this behavior might be normal in some situations, it can also be an indication of a single person trying to use many different accounts when not authorized to do so.
The number of different users tried from a single device may be set as well as the time frame. The available time frames are:
- 1 minute (typically used to stop rapid brute force attacks)
- 1 hour
- 1 day
- 1 week
- 1 month (typically used to identify slow-drip attacks, or account creation abuse)
Counts the number of failed attempts for all users in a specified time window.
Failed Attempts Use Cases:
A company wants to limit the number of failed attempts in a certain amount of time so SecOps or a fraud team is notified.
IP Address Failed Attempts
Counts the number of failed attempts for a single IP Address.
IP Address Failed Attempts Use Case:
Company wants to stop a single IP address from brute force attacking one or many different usernames.
IP Login Attempts
Counts the number of unique usernames for successful and failed login from a single IP address.
IP Login attempts Use Case:
A company wants to limit usage to a certain number of logins per day.
IP Org Failed Attempts
Counts the number of failed attempts from the IP Registering organization.
IP Org Failed Attempts Use Case:
A company wants to stop IP orgs that enable credential stuffing and sets a rule based on failed attempts.
User Login Attempts
Ability to set the number of login attempts with different passwords for a single user. This is a velocity that will count when a single user attempts (or succeeds) in logging in with many different passwords on a single account. While this behavior may be normal in some situations, it may also be an indication of a brute force attack.
The number of different passwords tried from a single account may be set as well as the time frame. The available time frames are:
- 1 minute (typically used to stop rapid brute force attacks)
- 1 hour
- 1 day
- 1 week
- 1 month (typically used to identify slow-drip attacks)
Velocity: Comparative Conditions
Username with no UserID from single IP
A review of the percentage of certain events as a ratio of some other event.
Our first comparison velocity is to look at the percentage of failed attempts with no user ID from a single IP Address per the total successful and unsuccessful logins from that IP address. The result of this will be a percentage of bad login attempts from a single IP.
A high percentage with a significant volume is an indicator that the IP address is involved in a credential stuffing attack.
If there are more than 50 failed attempts with no userID from a single IP address in a day
IF 50 failed attempts is 90 percent or more of all login and failed attempt events in a day.
THEN the IP address is likely involved in a credential Stuffing attack.