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.
When creating a policy or profile, there are five condition categories that define the type of available condition:
- Device – Attributes associated to the device including type, location of the device, and browser attributes
- List Type – Searches values within a customer defined list of entries; associated with specific data types (Device ID, IP Address, IP Registering Org, User ID, User Type, and Username)
- Network – IP address attribute
- User and Accounts – Attributes of the user sent manually by you (the Kount customer)
- Velocities – Counts of different activities
- Velocities: Comparative – Comparing a velocity to another
When defining the equation for each condition, several operators are available, depending on the condition.
Contains/Does Not Contain
Checks for the presence (or absence) of a substring in a list. If the substring is found (or is not found) within one or more of the list entries, the condition is evaluate as true (or false), accordingly.
A company gets referral traffic from multiple different sites. They want to create different risk profiles based on the referral site. They receive the referral URL and pass it as the userType. Since their partners refer users from multiple pages on their sites, it is impossible for the company to identify a referral domain without additional coding on their side. They create a list with domains for which they want to group risk. When the company sends a login decision request, they are able to search their list using the userType contains condition. This allows them to keep a relatively small and easy to manage list, while their referral partners can continue to refer from multiple, changing pages.
Is In/Is Not In
Checks that the selected condition is in (or is not in) the list.
A company wants to geographically isolate devices found in a specific country or region.
Equals/Does Not Equal
Checks that the provided substring is equal to (or does not equal) text in the list.
Is True/Is False
Checks that the selected condition is true (or is false) in the list.
Starts With/Ends With
Checks that the condition category starts with (or ends with) the list.
Is Used/Is Not Used
Checks that the condition category is used (or is not used) in a list in another condition category.
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 is 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.
A company wants to reduce friction for users when they log in with a trusted device by applying a limited policy set.
Steps to implement this condition:
- Create a new Profile entitled Users with Trusted Devices.
- Expand Select Condition Type, and under Device, select Assigned Trust State.
- Expand Select option, and then select the operator.
- Expand Select Trust State, and then choose Trusted.
- Create or assign wanted policies to this new Profile.
Once the Profile is created, users that login with a trusted device are subject to any Policies assigned to the Profile. If no Policies are added, then all users that log in with a trusted device are accepted. If Policies are assigned to the Profile, they are evaluated for an Accept/Block/Challenge response.
Matching the country in which the device was logged in as captured by DDC (geo-fencing). If the DDC did not run, the device location is determined by the IP address passed with the API call for the event.
Available operators: is in; is not in – allows inclusion or exclusion of one or more countries.
A company wants to limit allowing logins to a specific country or region.
Steps to implement this condition:
- Expand Select Condition Type, and under Device, select Device Country.
- Expand Select option, and then select an operator.
- Expand Select Country, and then choose the country or countries to include or exclude for this condition.
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 or when a browser is not being used and the calls are coming from an automation tool, a script or a bot.
- A company wants to add friction when there is no device collection to significantly reduce scripted attacks, so they challenge all logins when there is no device collection.
- A company wants to add friction later in the customer journey (at higher risk activities) when there is no device collection. They create a tag that is sent back with the login API response and then use that as a trigger in their application.
Device First Seen
Customers can create Policies and Profiles based on the length of days that a deviceID has been in the Kount system.
A company has identified that logins with devices that are less than a day old are 78 percent more likely to be fraud devices than other devices. In order to address this, they are setting up a condition that challenges users logging into existing accounts with new devices.
Steps to implement this condition:
Create a new Policy with the Account Age condition and the Device First Seen condition.
Allows geo-fencing by region.
- 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.
Mobile SDK is a true/false flag that indicates if the end-user is using a mobile app that has integrated the Kount SDK. This can be used in conjunction with other rules or 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 condition provides the most value when used in conjunction with Trusted Device Functionality and when the Friendly Name is set using a codified methodology – especially when a customer is using a trusted device for different use cases.
For example, the friendly name could be set to identify user-preferences. If one use case for Trusted Device is for Login (the user had to select the checkbox to remember this device at login) and the other use case was for account change (allow this device to make changes to this account), the friendly name could be set to login, account-change, or login-and-account-change depending on the user’s preference. Then policies could be set for the specific use-cases while keeping the user’s preferences in mind.
The customer has a single clientID but manages multiple sites that share userIDs. They want 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)
A company wants high assurance for the location of a user for regulatory concerns; therefore, they want to block usage of browsers that hide or obfuscate location.
Text match for identifying the operating system being used. Some operating systems may indicate higher risk of an event being scripted.
A company wants to block Windows operating systems that no longer have security patches.
Boolean evaluation if the login came from a hosting facility.
- It is unusual that a legitimate user browses the internet as a hosting facility – especially on a mobile device. This combination likely means that the device is a simulator instead of a mobile device.
- 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 session ID is created. An attacker can take that session ID 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 Mismatch by itself is not a strong enough indicator of fraud to be used to block traffic – it can be used to challenge. It can also be coupled with other conditions but it would still be aggressive as a BLOCK.
Other conditions that could be added to it are as follows:
- Hosting Facility
- IP Anomaly
Which IP address is used, the device collection IP or the userIP sent during the login decision request?
The IPV4Address is the address found at the time of the device collection, which is used to lookup the IP Org and other IP attributes. If unable to get the IP Address during device collection, fall back to the userIP sent to Kount by the customer in the Login API (Kount replaces the null value of IPV4address with userIP). Then lookup the IP Org and other IP attributes from the userIP.
Why might the IP Address from the DDC be different from the IP Address passws as userIP (IP Mismatch)?
There are a number of reasons for the device collection IP address to be different from the UserIP address:
Proxy Pierced – potential risk
When initiating device collection, Kount gathers IP information. The IP address is received from the request to download our device collection SDK – this is the earliest Kount can see the end user. However, this request might be coming from a proxy so it may not give us the origin (both the IP address and location) of the machine behind the proxy.
Using a different technique during execution of our device collection, Kount is able to pierce through the proxy. If that is successful, the IP addresses from behind the proxy (the IP address from the initial request to download) is collected.
In this case, the device collection IP address would be the underlying IP, whereas the UserIP would be that of the Proxy.
SessionID re-use for scripts – high risk fraud
The script may be running from a hosting solution or somewhere different from where the device collection was run.
Mobile – low risk
The IP address gathered from device collection is a point-in-time. Our device collection lessens an incoming request within a certain time period (15 minutes) if there is already a collection for that session ID. If a Login request is made with a sessionID where the device collection was made within the last 10 days, Kount uses the information from the device collection associated with the sessionID.
Depending on how the customer’s site works with sessions and device collections, there is potential for a mismatch if the user has moved.
A user opens a site, which initiates device collection, to check the balance on a gift card. The device collection gets an IP address and Kount stores that information with the sessionID for this session. The user does not put in the gift card information to check the balance, but leaves the page open in the browser.
Later that day, the user remembers that she wanted to check the balance on the gift card. She enters the info and clicks submit. Because she left the browser window open, she is using the same sessionID and no new device collection occurs (since that happens on page load).
When the customer sends the Login request, the IP address from the current time is passed for the user. Since she is on a mobile device and connected to a different mobile tower, she is leaving a different exit node, which provides a different IP address.
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.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.
- A fraud agent notices a single IP address is going nuts on the failed attempts. She tries to contact IT, but no one is available. 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.
- 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.
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.
A company has a medium tolerance for risk. They block all traffic from TOR.
True or false if a proxy has been identified during the login process.
A company has a medium tolerance for risk. They block traffic from known proxy services when there is no device collection.
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.
- does not equal
- is greater than
- is greater than or equal to
- is less than
- is less than or equal to
- A company wants the best chance to convert new trial users to paid customers and therefore does not want to add friction for new users. They create a Profile for users with an account age less than seven days with no Policies to ensure the users do not have added friction
- A company wants added security for their long-standing users. They create a policy that challenges users when the account age is more than 365 days and the device first seen is less than ten days.
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.
A company to use the Login API to stop login fraud and to stop card testing prior to authorization. They pass userType=Login and userType=preauth with the Login API depending on the use case. They then create two Profiles for userType=Login and a Profile for userType=preauth with the appropriate policies for each Profile.
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.
- Customer has multiple LoginURLs and different restrictions based on the URL. Profiles are set up to match URL.
- Customer 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.
Time of Day
Customers can create policies and profiles based on the time of day. Customers can choose a time of day and add a range before or after that time to create a timeframe.
A company sees an increase in fraud between 1AM and 4AM. They want to decrease the risk profile during this timeframe.
Steps to implement this condition:
Create a new Profile called Early Morning that looks for traffic. After 1AM for 3 hours – move this to the top of their Profile List.
Add the appropriate Policies to the Early Morning Profile.
Create new Policies to the Early Morning profile that have a lower risk threshold (decrease the velocities).
Device Login Attempts
Ability to set the number of login attempts with different userIDs for a single device. This is a velocity that counts 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.
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.
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.
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.
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)
IP Address' Unique UserIDs
IP Address' Unique UserIDs is a velocity that counts all unique users that had valid username/password credentials from a single IP Address over time. This velocity is used to identify attacks where the attacker has a highly validated username/password combo list.
A company wants a notification for potential targeted attacks. They create the following Policy:
IF Device Data Collection is false
THEN IP Address Velocity Unique UserIDs 5 Unique UserIDs in under 1 hour
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.
Username with no User ID From Single IP Org
Username with no User ID From Single IP Org looks at the number of failed attempts with no userID divided by the total of all successful login attempts from a single IP Organization over the given time period. Total successful login attempts includes all login API calls from the IP Org and a Failed Attempts from the IP Org. The IP Org is the organization responsible for the actions and content associated with a given selection of IP addresses, such as corporate, government, or educational institutions, along with Internet Service Providers (ISPs) managing the allocation and use of network blocks.
A company see high spikes of credential stuffing traffic, and they want to identify it quickly and stop it before the threat actor has established any kind of foothold.
Card Testers and Credential Stuffers often use hosting solutions or other IP Organizations that have relaxed security policies. Using these IP Orgs, thread actors cycle through IP addresses making it difficult to block an IP Address. Blocking IP Organizations that allow their users to engage in nefarious activities can significantly reduce or stop threat actors from launching significant attacks.