Skip to main content
Sumo Logic

Normalized Authentication Rules

CSE's Normalized Authentication Rules detect activities that compromise accounts using authentication logs from any data source that CSE parsers and mappings support.

Normalized Authentication Rules detect activities that compromise accounts using authentication logs from any data source that CSE parsers and mappings support. New authentication data sources can immediately take advantage of this rule logic without the need to customize for the specific product or vendor.  

Requirements and prerequisites

Out of the box, the Normalized Authentication Rules support a variety of data sources, ranging from cloud-based authentication services like AWS CloudTrail, VPN authentication services like Cisco ASA, and OS-based authentication like that provided by Windows and Linux. 

For the rules to support a particular product or service, the log mapping for that service must map several fields correctly.

You can check whether a given data source is already supported by reviewing its log mapping in CSE. If it is, you’re good to go. If a mapping already exists for the data source, you can update it as described in this topic. If the data source doesn’t already have a mapping, you can create one. 

The mapping requirements are:

Output field Mapping requirement
objectType This field is populated as a result of the value selected for the Record Type in the log mapping. It must be set to Authentication.
normalizedAction Set to logon.
success Set to true if the logon was successful, or false if it was not.  
mfa If the log message contains a field that indicates multi-factor authentication usage, set mfa to true if MFA is used or false if not.
user_username  user_username must be mapped to the input field that contains the user identity. If an alternative input field also contains the user identity, that field should be mapped as an alternate input field.
srcDevice_ip If an IP address is present in the log message, srcDevice_ip must be mapped to the input field that contains it.
srcDevice_hostname If a hostname is present in the log message, srcDevice_hostname must be mapped to the input field that contains it.


This log mapping for the AWS CloudTrail ConsoleSignIn event meets the requirements described above. (Note that srcDevice_hostname is not mapped because the AWS log message for that event doesn’t contain a hostname.)

auth-rule-mapping-1.png

auth-rule-mapping-1.png

Normalized Authentication Rules

  • Authentication Without MFA
    • Detects a successful login where the account did NOT use multi-factor authentication (MFA) to gain access. We strongly recommend that you require MFA to protect accounts in the event that credentials are stolen. If you don’t require MFA for a data source, we recommend you disable this rule, or that you use a Rule Tuning Expression to exclude the data source so that messages from it won’t be processed by this rule. 
  • Brute Force Attempt
    • Detects multiple failed login attempts for the same username over a 24 hour timeframe. This is designed to catch both slow and quick brute force type attacks. The threshold and time frame can be adjusted based on your environment.
  • Password Attack
    • Detects multiple failed login attempts from a single source with unique usernames over a 24 hour timeframe. This is designed to catch both slow and quick password spray type attacks. The threshold and time frame can be adjusted based on your environment.
  • Successful Brute Force
    • Detects a series of failed logins followed by a successful login. This could indicate that an attacker was successful in guessing a user's password and has compromised the user’s account.
  • Impossible Travel - Successful
    • Detects two successful logins from the same user with different country codes, indicating possible credential theft. We recommend you add filtering criteria to the rule expression to reduce false positives, such as known VPN addresses.
  • Impossible Travel - Unsuccessful
    • Detects two failed logins from the same user with different country codes, indicating a possible credential theft attempt. We recommend you use a Rule Tuning Expression to add filtering criteria to the rule to reduce false positives, such as known VPN addresses.