Cidaas Fraud Detection System

cidaas uses predictive factors and Big Data analytics to verify customers and detect Fraudsters. It provides built-in tools to detect anomalies and stop malicious attempts to access your application.

While user login to the business we need detect that user is real or not, even though the hackers got the user's username and password. if it is fraud entry we need to ask the 2-Factor Authentication.

The cidaas FDS check the following criteria to detect. if the user is a valid user or not:

  • IP_NOT_MATCHING or NETWORK_NOT_MATCHING
  • FINGER_PRINT_NOT_MATCHING
  • REQUESTED_INVALID_ACCEPT_LANGUAGE
  • NEW_DEVICE
  • NEW_LOCATION
  • UN_USUAL_LOGIN_TIME
  • DEVICE_UNUSED_FOR_CERTAIN_TIMEPERIOD
  • UN_EXPECTED_DISTANCE_TRAVALLED
  • UN_EXPECTED_LOGIN_LOCATION_AND_TIME `
    cidaas FDS criteria Conditions
    IP_NOT_MATCHING or NETWORK_NOT_MATCHING:
    The IP range is verified in combination with the distance travelled (so as not to create any inconvenience for the user by checking only the IP as a string). If the distance travelled is more than 3 (threshold) kilometers, 2-Factor Authentication is triggered.
    FINGER_PRINT_NOT_MATCHING:
    This is straight forward, just a string comparison between saved and the current fingerprint variable is perfomed.
    REQUESTED_INVALID_ACCEPT_LANGUAGE
    Must follow this https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
    Syntax for Accept-Language
    Accepte-Language ="Accept-Language" ":"
              1#( language-range [ ";" "q"="value ])
      language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
    

    Ex: en-US,en;q=0.8
    The Primary Language of the user’s device is: "en-US"
    The user’s device also has : "en" language (other than “en-US”) with the quality of 0.8 (here 1 is max 0 is less)
    In this the check it should tell REQUESTED_INVALID_ACCEPT_LANGUAGE if the quality level varies by .5 or if a new language is added/detected.
    NEW_DEVICE:
    It should split and evaluate the user Agent variable and ignore the version upgrade of the browser. It should not spam the user by performing only string comparison.
    NEW_LOCATION
    The lat and lon values of the user can be derived from 2 places:

    • If the user has accepted location sharing in the browser, then the lat and lon values are derived
    • If the user has not accepted location sharing, the lat long values are to be derived from the IP address for which we have a “IP to location” service, that should be used.

    Note: The distance threshold should also be considered.
    UN_USUAL_LOGIN_TIME
    The user’s login time is captured to create a Login time cluster. Whenever the user logs in, if the login time does not fall within the login times as recorded in the cluster, 2-Factor Authentication is triggered.
    DEVICE_UNUSED_FOR_CERTAIN_TIMEPERIOD
    If the user has not used the device for a minimum of 2 months to log in to the application, upon trying to login after 2 months, 2-Factor Authentication is triggered.
    UN_EXPECTED_DISTANCE_TRAVALLED
    Read the NEW_LOCATION spec,
    When a change in distance travelled is detected (i.e. a distance change beyond the set threshold distance value is detected with respect to the Location cluster created for the user), 2-Factor Authentication is triggered.
    UN_EXPECTED_LOGIN_LOCATION_AND_TIME
    The location cluster of the user along with corresponding time information is created to capture the user behavior (For e.g., on weekdays the user logs in to the business portal from his office, and on weekends from his home)
    Example: The user's normal login time and location
    From Monday to Friday from Bellandur/Wimsheim (Office)
    Saturday and Sunday from Mumbai/Stuttgart (Home)
    If this pattern changes we should ask for the 2-Factor Authentication.
    APP Profile
    Whenever the access token is validated, and the target page also passed, the App profile helps to detect if the app is accessing any unusual API.
    UN_USUAL_API_ACCESS_REQUEST:
    The received ClientID and request URL are verified against the Location vs Client ID cluster created for the user.

Cidaas Fraud Detection Flow:

When the user logs in to the business portal, cidaas FDS detects if the user is a valid user based on the above-mentioned criteria. If all the conditions are satisfied, The FDS send MFA status MFA status like Fraud=False the user is considered to be a valid user and is hence granted access to the portal.

If a mismatch is detected in any of the above criteria, cidaas FDS identifies the user as a fraudulent user and sends the status Fraud=TRUE. At the same time, in the background a webhook trigger event happens and correspondingly notifications are sent to the user (Notifications such as “Your Account was just signed in to from a new device. You are getting this email to make sure it was you”). 2-Factor Authentication is triggered to verify the identity of the user trying to access your business portal.



results matching ""

    No results matching ""