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|
||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.|
||Set to logon.|
||Set to true if the logon was successful, or false if it was not.|
||If the log message contains a field that indicates multi-factor authentication usage, set
||If an IP address is present in the log message,
||If a hostname is present in the log message,
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.)
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.