With the current Knowledge Base release, LogRhythm Labs will introducing the first round of changes to AI Engine™ Rule organization. This initial stage involves implementing a more intuitive naming scheme for AI Engine&trade Rules. (Note: compliance based Engine&trade Rules will not change their names)
AI Engine™ Rule Naming Conventions
LogRhythm has over 500 AI Engine™ rules, and each one detects very specific, complex activity. The rules are typically named by this complex activity, but obviously names must be kept to a reasonable length. This presents a problem—an analyst needs to be able to look at any one of these 500+ rules and immediately know what the alarm indicates without needing to read an entire paragraph. Likewise, a SIEM administrator needs to choose the rules that should be enabled when LogRhythm is deployed. When rule names are too difficult to understand, these tasks can be quite challenging.
The new naming convention addresses this problem by applying a simple and consistent template: First, rule names will begin with the most important information that an analyst needs to investigate an alarm. This means labeling the rules by broader categories, giving the analyst a solid starting point. For example, rules that detect a malware event will be in the “Malware” category, rules that detect suspicious network behavior will be in “Network Anomaly,”” rules that detect a denial of service attack will be in the “DoS” category, etc.
Our first iteration includes the following categories:
- Attack: Attempts to gain access to a system, such as brute force authentication attempts or SQL Injection, or generic attack events as generated by other deployed security devices. The source is assumed to be external to the organization’s network unless specified in the rule name.
- Compromise: A host or account has been accessed by an unauthorized user or malicious process.
- Denial of Service (DoS): A specific type of attack that attempts to disable or interrupt use of a service or host.
- Malware: Activity associated with known malware.
- Misuse: Improper use of organization resources.
- Operations (Ops): Activity related to system and network operation. For example, unusual log fluctuations, power issues, or backup failures. Operations is also subdivided into severity levels (e.g., warning, error, critical).
- Reconnaissance (Recon): Techniques to identify, fingerprint or map network devices and services.
- Vulnerability: Information regarding vulnerabilities in the network.
And three anomaly categories for suspicious behavior that might be malicious:
- Account Anomaly: anomalies related to identities
- Host Anomaly: anomalies related to endpoints
- Network Anomaly: anomalies related to network activity
Following the first part of the template, names will now take a more conventional spacing and punctuation arrangement by using a colon and space (‘: ‘) to separate the end of the rule name.
This final part of the name will be a brief description of the specific activity associated with the rule. To meet limitations of the software, several abbreviations are used. For example, ‘Auth’ for authentication or login, ‘Admin’ for administrator or privileged user, ‘Ops’ for operations, etc. For directionality (inbound, outbound, internal, etc), only unusual or critical information will be placed into the name. Otherwise, the most common directionality of the security event will be assumed and thus not be present in the rule name. For example, attacks against web servers generally come from external sources, while malware beacons come from internal hosts. Because this is fairly obvious, those names don’t need to include directionality. However, if the web server as being attacked from an internal source or malware is beaconing inside the organization’s network, that is a critical situation, and names will reflect that a possible compromise has occurred.
Here are a couple of examples of the transition from old to new format:
Acnt Susp:Abnormal File Access
-> Account Anomaly: Abnormal File Access
Ext:Host Atck:XSS Attack
-> Attack: Cross-site Scripting (XSS)
Int:Host Comp:Attack/Compromise Followed by Critical
-> Compromise: Lateral Movement then Critical Event
Int:Susp:Multiple Object Access Failures
-> Host Anomaly: Multiple Object Access Failures
Ext:Susp:LR Threat List:URL:Bot
-> Malware: Threat List Bot URL
New Documentation
Security Module documentation should now be updated to also reflect the new naming system. In the coming months, additional changes will be made to how rules are grouped together in the Knowledge Base.
Likewise, the Threat Detection Cookbook will now have an updated format. If you’re unfamiliar with the Cookbook, it’s a document maintained by LogRhythm Labs that explains the usage of a few dozen notable AI Engine™ Rules. If you want to check out the latest version, head over to the How To section of the support forum: https://logrhythm.vanillaforums.com/categories/how-to-