Create New AI Engine Rules

Similar to a Log Observed block, except that it only triggers when the selected Grouped By values of the Log are not found in the associated whitelist of the Whitelist Profile block to which it is linked. (The linked Whitelist Profile block is created automatically and cannot be separately deleted or created.) In this case, a log is observed in a metadata field that is not in the associated whitelist.

A Whitelist Rule Block enables users to record almost any behavior from a source integrated with the LogRhythm Data Filters. By comparing current logs to historical behavior, a Whitelist can be used to send an alert when behavior from a user or a system changes.

Use Case. Whitelisting processes on production servers – In this scenario, the user creates a rule that records all processes observed on production servers. The rule runs for a set amount of time called a learning period. After the learning period, any processes observed that are not on the whitelist trigger an alarm. The event triggering the alarm could be a web server that has been compromised launching a malicious process to allow attackers to gain shell access.

During runtime of the AIE Engine, a particular set of statistics will be collected. These statistics are collected within the AIE Runtime object the statistic observed. At a regular interval, a routine will be executed to collect the data from the various runtime engine components and send the information to the database for persistence.

Use Case. Look for an abnormal number of authentication failures. Statistical rules compare live data to live data. If I know that the number of successful logins to unsuccessful logins in a 10 to 1 ratio, I can create a statistical rule that looks for the ratio of successes to failures to drop below 10 to 1. For example, if the amount of unsuccessful logins increases to a 12 to 2 ratio, an alarm is triggered.

Multiple expression can be written into the rule to reflect a range, for example, there must be between 5 and 10 times as many successful logins. Also floors can be implemented, such as the ratio must be greater than a 10 to 1 ratio and there must be at least 100 successful logins so a very low log rate won’t cause false positives. This also lets you compare static data fields within the same window. You can compare the origin user to the impacted user to make sure they are different in an account modification log if your environment does not allow people to modify their own accounts.

The AIE Trending Rule Block provides for automatic base-lining of log and flow data against which various trends can be established. These trends can then be evaluated against current log and flow data to determine if a deviation has occurred. Deviations in a trend might be an indication of a security, compliance, or operations issue. In this case, a set of criteria is met comparing current log messages with recent log messages.

The Trend Rule block compares prerecorded data to live data in an attempt to identify anomalies in behavior. Unlike other rule blocks, the Trend Rule block is able to add additional data to the baseline to accommodate changes in behavior over a period of time. Comparing a baseline that is able to change over time to live data enables the Trend Rule Block to look for anomalies in behavior while accommodating normal changes in the organization.

Use Case. Look for increased traffic on the network. You can build a baseline, over a week, measuring the amount of traffic your network receives through its ports. If the traffic increases by a predetermined percentage, an alarm is triggered. This is also how rogue host detection is implemented. In this case, the MAC addresses seen on the network are recorded over a 30 day period. When a MAC address is observed that does not exist in the baseline, this means a new host is on the network. This causes an alarm to trigger.