Conditions are evaluated facts that are used when creating a policy or segment. When all conditions within a single segment or policy are true, the segment or policy is then applied.
Note
Refer to Managing Segments or Managing Policies.
When creating a policy or segment, 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
-
Phone Number — Phone number associations
-
Email Address — Email address associations
-
List Type — Searches values within a customer defined list of entries associated with specific data types
-
Location — Compares location between billing address, shipping address, and device location
-
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.
Use case:
A company gets referral traffic from multiple different sites. They want to create different risk segments 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.
Use case:
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 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 customer either with API or the Kount 360
-
Trusted — Trust state for the user’s device that was assigned by the Kount customer either with API or Kount 360
-
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 there is no record of the specific device. You can change the trust state of a specified user and their device in Kount 360 or by calling our Trusted Device Endpoint.
Use case:
A company wants to reduce friction for users when they sign in with a trusted device by applying a limited policy set.
Steps to implement this condition:
-
Create a new Segment and title it 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 policies to this new Segment.
Once the Segment is created, users that login with a trusted device are subject to any Policies assigned to the Segment. If no Policies are added, then all users that log in with a trusted device are accepted. If Policies are assigned to the Segment, they're evaluated for an Accept/Block/Challenge response.
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:
-
Electron
-
Goanna
-
YaBrowser (Yandex)
-
Sentry
-
Ice Dragon (Comodo)
Use case:
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.
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.
Use case:
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.
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.
Use cases:
-
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.
Customers can create Policies and Segments based on the length of days that a deviceID has been in the Kount system.
Use case:
A company has identified that logins with devices that are less than a day old are 78 percent more likely to be fraud than other devices. In order to address this, they are setting up a condition that will challenge 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.
Device Language is a text match that looks for the browser language that the device is using. The device language can be found in Portal under Event Analysis Details or in the Export Report within Dashboard.
Use case:
The customer can create a rule with a tag and apply a No Decision action to know the number of times a particular device language is used. This will help them understand the demand for their product content in other popular languages.
Allows geo-fencing by 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.
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 not, 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 not, 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. It is useful when the Friendly Name is set using a codified methodology — especially useful 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.
Use case:
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.
Boolean evaluation if JavaScript is used by the browser during data collection. This condition evaluates as False for all requests from mobile apps where the Kount Mobile Device Data Collector SDK is integrated. If you have integrated with our mobile SDKs, it is important to use this condition coupled with Mobile SDK = False.
Use cases:
-
A company requires JavaScript for their site to run (even to be able to login). If JavaScript is not detected, it is obvious the user is trying to login outside of their normal path (programmatically).
-
A company has low-tolerance for login discrepancies — they require JavaScript so that they can get device information prior to login.
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.
Use case:
A company requires JavaScript for their website to run (even to be able to log in) but they also have a mobile application and use the Kount Mobile SDK for device collection. They add the Mobile SDK = False to their Javascript rule to make sure they are not blocking legitimate traffic from customers using the mobile app.
Text match for identifying the operating system being used. Some operating systems may indicate higher risk of an event being scripted.
Use case:
A company wants to block Windows operating systems that no longer have security patches.
User Agent is a text match against the User Agent from the login request payload.
Use case:
A company wants high assurance for the system of a user for regulatory concerns; therefore, they want to block identifying information about the User's system that hides or obfuscates location.
Location Accuracy defines the accuracy of the device location using the following criteria:
-
Pinpoint — For customers who need exact locations. This requires the Native Mobile SDKs and Location Services to be enabled. This only exists for Native Mobile SDK collections where the GPS is enabled.
-
City level — This is based on IP information and is considered accurate to the city. If there is a proxy, we pierce it in order to find the IP address closest to the customer and their internet connection.
-
Country level — Country-level accuracy happens when we know the location information is being obfuscated to the country/timezone level.
-
Unverified — The location is considered unreliable and should not be considered accurate. This could be because a known proxy was used that we could not pierce or a TOR network was involved.
Use case:
When proxy is detected and Kount pierces the proxy, the location is accurate. When proxy is detected but not pierced, the location information should not be considered as valid. Exposing the device accuracy helps analysts know when to trust the device location. If the device location is not accurate, then the transaction might be suspect.
Compares the current date with the first time that the phone number was found with the Kount Network.
Use case:
A company wants to limit the functionality for a customer when they suspect that the phone number supplied is not authentic or is disposable. They create a policy that identifies when the phone is less than 20 days old and flag this challenge. Any challenged New Account Opening (NAO) attempts must validate their phone number within seven days of opening a new account.
Identifies if the phone number and the name supplied by the customer have been associated in the Kount Network.
Use case:
A company wants a high level of assurance that the phone number being used has been associated with the person signing up (and that they have control of the email address). If it is not, they will require additional customer information before the account is opened.
When the end user enters the phone number and name, the company sends a New Account Opening request to us. If there is no association between the phone number and the name provided by the new user, a challenge is issued and the company asks for financial information that it can validate for the user.
A machine learning model that looks at the general trustworthiness of a phone number.
Use case:
A company wants to create a flag when a phone has a very low trustworthiness score to deny bonus loyalty points to the new user until they have 15 activity events within their portal.
They create a new decision policy that flags NAO events when the Phone Trustworthiness is Low or Very Low. When they receive the tagged response from us, their system flags the account and requires the added activity.
Identifies if the phone number and the physical address supplied by the customer have been associated in the Kount Network.
Use case:
A company wants assurance that the phone number is associated with the physical address before sending the customer marketing material in the mail.
They create a no decision policy to flag when association exists between the phone number and the mailing address provided by the end user at sign-up. When there is an association, we will send a tag in the NAO response and the company will know it can send physical mail to the customer.
Compares the current date with the first time that the email address was found with the Kount Network.
Use case:
A company wants to limit the functionality for a customer when they suspect that the email address supplied is not authentic or disposable. They create a policy that identifies when the email is less than 20 days old and flag this challenge. Any challenged New Account Opening (NAO) attempts must validate their email address within seven days of opening a new account.
Identifies if the email address and the name supplied by the customer have been associated in the Kount Network.
Use case:
A company wants a high level of assurance that the email address being used has been associated with the person signing up (and that they have control of the email address). If it is not, they will require additional customer information before the account is opened.
When the end user enters the email address and name, the company sends a New Account Opening request to Kount. If there is no association between the email address and the name provided by the new user, a challenge is issued and the company asks for financial information that it can validate for the user.
A machine learning model that looks at the general trustworthiness of an email address.
Use case:
A company wants to flag when an email has a very low trustworthiness score to deny bonus loyalty points to the new user until they have 15 activity events within their portal.
They create a new decision policy that flags NAO events when the Email Trustworthiness is Low or Very Low. When they receive the tagged response from Kount, their system flags the account and requires the added activity.
Identifies if the email address and the physical address supplied by the customer have been associated in the Kount Network.
Use case:
A company wants assurance that the email address is associated with the physical address before sending the customer marketing material in the mail.
They create a no decision policy to flag when association exists between the email address and the mailing address provided by the end user at signup. When there is an association, Kount will send a tag in the NAO response and the company will know it can send physical mail to the customer.
Evaluates the email address from the NAO request payload against different Melissa Data validation codes for Email Status. Refer to Melissa Data Validation Codes for a list of all the validation codes.
Use cases:
-
A company wants to validate the email address to send sign-up benefits. Using this new condition they can validate the email address real-time and make sure the benefits are not misused.
-
A company wants to send an MFA during the sign-up process. Melissa Data Email Verification can identify bad email addresses which then increases deliverability and decreases high bounce rates.
-
Carrier
-
Device Resolution
-
NAO URL
-
Login URL
-
Operating System
Session Identifier (or Session ID) is used to join device data collected with the Login or NAO API. This list type allows the customer to create a list of Session IDs that are suspicious and want to block.
Use case:
A company is seeing multiple login or new account opening requests from the same session ID, but there is no device collection against the session ID, which is why the customer wants to block it. A list can be created with a session ID and the Distinct Usernames per Session ID condition can be used to create a policy to block that bad session ID.
This evaluates the distance between:
Device Location and
-
Shipping Address
-
Billing Address
-
Phone
Phone and
-
Billing Address
-
Shipping Address
Billing Address and
-
Shipping Address
Use case:
A customer with NAO wants to know the distance from the billing and/or shipping address from the actual device location. A large distance between the billing and/or shipping address from the device is often an indicator of fraud.
Example:
If the Distance Between <Device, Phone, Billing Address> and <Shipping Address, Phone, Billing Address> is <greater than, less than> <number> of <Miles, KM>
Boolean evaluation if the login came from a hosting facility.
Use cases:
-
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.
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
-
Proxy
-
IP Anomaly
Which IP address is used, the device collection IP or the IP we pass as userIP 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 passed 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
Use case:
A script that is unable to run JavaScript is getting sessionIDs from a system that can. On the system that can run JavaScript, the fraudster runs a device collection and gets the sessionID — then uses that sessionID within the script for the attack (making it look like they have legitimate device collection).
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.
Use case:
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.
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).
Use case:
A company wants to remove friction for their call center. They create a Segment for the IP range that the call center uses and do not add Policies to it to ensure their call center employees are not blocked or challenged.
Evaluation of the IP address of the device during login.
Use cases:
-
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 Segment based on the IP addresses from the call center.
Boolean evaluation if IP addresses that show anomalous behavior or have been associated with fraud.
Use cases:
-
A company has a low risk tolerance — any IP anomalies are challenged.
-
A company has high risk tolerance — any IP Anomaly that ALSO does not have JavaScript is challenged.
Text match to the organization responsible for registering the IP Address.
Use case:
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
True or false if a proxy has been identified during the login process.
Use case:
A company has a medium tolerance for risk. They block traffic from known proxy services when there is no device collection.
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.
Use case:
A company has a medium tolerance for risk. They block all traffic from TOR.
NAO URL is a text match to the optional NewAccountOpeningURL field that can be passed with a NAO API call. Since NAO URL is a text match, it can be used as a user-defined field similar to userType. The logic for this functionality is as follows:
-
Was text passed in the NAO API call for the NewAccountOpeningURL field? If not, this condition evaluates as false. If yes, proceed to the next function.
-
Does the text within NewAccountOpeningURL meet the logical condition of this rule? If not, the condition evaluates as false. If yes, the condition evaluates as true.
Use case:
A customer has multiple NewAccountOpeningURLs and wants to apply different business logic based on the URL used. This condition will allow customers to add different policies based on the URL condition.
High Risk IP Org compares the IP org coming from a Login or NAO request with a global list of high risk IP orgs. This condition is evaluated as True or False.
Use case:
A customer had failed attempts from an IP org and we flagged that IP Org as high risk. With this condition, the customer can place that IP Org in a High Risk IP Org list. Now the customer can set the High Risk IP Org condition as True with decision block to prevent any Account Takeover (ATO) attack from that IP org.
Steps to implement:
-
Under Conditions, select High Risk IP Org.
-
Select True or False.
-
Select the list containing the high-risk IP org.
-
Select Save Segment.
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.
-
equals
-
does not equal
-
is greater than
-
is greater than or equal to
-
is less than
-
is less than or equal to
Use cases:
-
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 Segment 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.
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 to userType. The logic for this functionality is as follows:
-
Was text passed in the login API call for the LoginURL field? If not, 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 not, the condition evaluates as false. If yes, the condition evaluates as true.
Use cases:
-
Customer has multiple LoginURLs and different restrictions based on the URL. Segment are set up to match URLs.
-
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.
Note
If there are a high number of values to be compared against in LoginURL, use userType so that a single list policy can be utilized instead of creating several LoginURL policies.
NAO URL is a text match to the optional NAO URL field that can be passed with a NAO API call. Since NAO URL is a text match, it can be used as a user-defined field similar to userType. The logic for this functionality is as follows:
-
Was text passed in the NAO API call for the NAO URL field? If not, this condition evaluates as false. If yes, proceed to step two below.
-
Does the text within NAO URL meet the logical condition of this rule? If not, the condition evaluates as false. If yes, the condition evaluates as true.
Use cases:
-
Customer has multiple NAO URLs and different restrictions based on the URL. Segment are set up to match URLs.
-
Customer has text that needs to be passed into the NAO API for evaluation. The client maps the text to NAO URL and then creates conditions to match the inbound text.
Note
If there are a high number of values to be compared against in NAO URL, use userType so that a single list policy can be utilized instead of creating several NAO URL policies.
Customers can create policies and segments 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.
Use case:
A company sees an increase in fraud between 1AM and 4AM. They want to decrease the risk segment during this timeframe.
Steps to implement this condition:
-
Create a new Segment called Early Morning that looks for traffic. After 1AM for 3 hours — move this to the top of their Segment List.
-
Add the appropriate Policies to the Early Morning Segment.
-
Create new Policies to the Early Morning segment that have a lower risk threshold (decrease the velocities).
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.
Use cases:
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 Segments for userType=Login and a Segment for userType=preauth with the appropriate policies for each Segment.
Ability to set the number of login attempts with different username 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.
Use case:
A company wants to limit the number of failed attempts in a certain amount of time so SecOps or a fraud team is notified.
Note
This rule works well when paired with another rule.
Counts the number of failed attempts for a single IP Address.
Use Case:
Company wants to stop a single IP address from brute force attacking one or many different usernames.
Counts the number of distinct usernames for successful and failed login from a single IP address.
Use case:
A company wants to limit usage to a certain number of logins per day.
Counts the number of failed attempts from the IP Registering organization.
Use case:
A company wants to stop IP orgs that enable credential stuffing and sets a rule based on failed attempts.
This velocity counts all distinct User IDs from a single Device ID over time.
Use case:
If a company wants to identify if the same device is trying to use a different userId and password for signing in within a certain amount of time. If Distinct User ID per Device ID is less than or greater than in <time>
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)
This velocity counts the number of times a given username has received the decision response of blocked.
This velocity counts the number of times a given username has failed a challenge.
This velocity counts all distinct User IDs 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.
Note
This velocity should be used with caution or for alerting purposes as some legitimate corporate VPNs might have all of their traffic exiting from a single node (and therefore have a single IP address).
Use case:
A company wants a notification for potential targeted attacks. They create the following policy:
IF Device Data Collection is false
AND
THEN IP Address Velocity Unique UserIDs 5 Unique UserIDs in under 1 hour
This velocity computes distinct device country location per deviceID.
Use case:
A company wants to identify if a same device is creating new accounts or logging-in from different countries in a certain amount of time
If Unique Device Countries < > Or More in <time>
This velocity computes distinct country device location per user.
Use case:
A company wants to identify if the same user is logging in from different countries in a certain amount of time.
If Unique User’s Countries < > Or More in <time>
This velocity computes distinct usernames used for the same Session ID.
Use case:
A company wants to identify if a user is using different usernames from the same session ID in a certain amount of time.
This velocity computes missing device ID per IP Organization.
Use case:
A company wants to stop scripts from auto-creating new accounts or logging-in. They create a limit to the number of new accounts that can be created by an IP Org when there is no device collection.
If IP Org Missing Device < > or more <time>
New accounts created for this device over a specified timeframe.
Use case:
A company wants to stop scripts from auto-creating new accounts. They create a limit to the number of new accounts that can be created by a single device over a certain amount of time.
New accounts created for this IP Organization over time.
Use case:
A company wants to stop scripts from auto-creating new accounts. They create a limit to the number of new accounts that can be created by an IP Org when there is no device collection.
New accounts created for this IP Address over time.
Use case:
A company wants to stop scripts from auto-creating new accounts. They create a limit to the number of new accounts that can be created by an IP Address when there is no device collection.
Counts the number of login attempts for a given User ID.
Use case:
In Command, if you want to review a payment transaction where a user has signed in multiple times within short duration, you can add a policy to count login attempts per user ID and add a tag to the policy with outcome of No Decision. Use the Tag Match rule with outcome review in Command to review the payment process for the user trying to sign in muliple times.
Steps to implement this condition:
Select the condition and then choose <Login Attempts per User ID> <user input> or more than <outcome>
Counts the number of sign-ins that returned a guidance of Blocked for a given User ID.
Use case:
In Command, if you want to review a payment transaction where a user has been blocked multiple times in a certain interval of time during the sign-in process, you can add a policy to count blocked logins per user ID and add a tag to the policy with the outcome of No decision. Using the Tag Match rule in Command with outcome review, you can review the payment process for the user being blocked during the sign-in process.
Steps to implement this condition:
Select the condition and then choose <Blocked Attempts per User ID> <user input> or more than <outcome>
Counts the number of failed challenges for a given User ID
Use case:
In Command, if you want to review a payment transaction where a user has failed the multi-factor authentication multiple times in a certain interval of time during the sign-in process, you can add a policy to count the number of failed challenges per user ID with a tag to the policy with an outcome of No Decision. Using the Tag Match rule in Command with outcome review, you can review the payment process for the user that failed to pass MFA challenge during sign-in process.
Steps to implement this condition:
Select the condition and then choose <Blocked Attempts per User ID> <user input> or more than <outcome>
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
AND
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 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 include all login API calls from the IP Org and 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.
Use case:
A company sees 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.