You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description: Severity of the rule which indicates the level of rule importance and investigation priority.
115
+
Description: The severity of the rule which indicates the level of the rule's importance and investigation priority.
116
116
117
117
Possible Values:
118
118
-`critical` - When critical severity rules are triggered, immediate action is required. Critical rules have a very low probability of false positives, or are highly sensitive actions that must always be deconflicted.
119
-
-`high` - When high severity rules are triggered an investigation/case should be created and completed with a high priority. Low probability of false positives after minimal tuning.
120
-
-`medium` - Medium severity rules will likely require tuning in the average environment. After tuning, when medium security rules are triggered a case should be generated with medium priority.
119
+
-`high` - When high severity rules are triggered, an investigation/case should be created and completed with a high priority. Low probability of false positives after minimal tuning.
120
+
-`medium` - Medium severity rules will likely require tuning in an average environment. After tuning, when medium security rules are triggered, a case should be generated with medium priority.
121
121
-`low` - Low severity rules should be used as part of correlations, or to support triage and enrich the analysis environment. Some of these rules may be used as case generators after a significant amount of tuning.
Description: The type of the rule that indicates whether the rule is intended for threat hunting 'query' (may generate false positives) or for real-time detection 'alert' (rarely generate false positives).
132
-
Alerts will be defined as a rule that in the majority of environments will cause a low false positive or true positive - benign rate. For instance, if a rule requires for someone to add domain controllers to filter out benign events, this would NOT be considered an alert.
133
-
Queries will be defined as any rule that we anticipate will require tuning in most environments.
131
+
Description: The type of the rule that indicates whether the rule is intended as a threat hunting 'query' (may generate false positives) or a real-time detection 'alert' (rarely generates false positives).
132
+
An alert can be defined as a rule that in the majority of environments will cause a low false positive or true positive - benign rate. For instance, if a rule requires for someone to add domain controllers to filter out benign events, it would NOT be considered an alert.
133
+
A query can be defined as any rule that can be expected to require tuning in most environments.
134
134
135
135
Possible Values:
136
136
-`query`
@@ -154,7 +154,7 @@ Possible Values:
154
154
155
155
Description:
156
156
-`Exploit Rules`
157
-
These are rules meant to identify the exploitation or probing of a vulnerability (e.g. CVE, General SQL-I / XSS Rules). Many of these rules would qualify as "alerts". Example a rule built for Log4J detection. These rules are useful indefinitely.
157
+
These are rules meant to identify the exploitation or probing of a vulnerability (e.g. CVE, General SQL-I / XSS Rules). Many of these rules would qualify as "alerts". An example would be a rule built for Log4J detection. These rules are useful indefinitely.
158
158
159
159
-`Behavioral Rules`
160
160
These rules are meant to identify behaviors that may match an adversary's behavior based on known reporting. Many of these rules would qualify as "queries". An example of a behavioral rule would be a rule that identifies a remote login of a local administrator account. These rules will NOT include information specific to a campaign. These rules are useful retroactively, and on average have a 12+ month expectancy of usefulness.
@@ -166,7 +166,7 @@ Description:
166
166
These rules identify the usage of a specific tool (offensive, or living off the land). For instance, a rule meant to identify psexec specifically would be a "tool" rule. A rule meant to identify psexec and any similar tool, without explicitly identifying attributes that are unique to those tools would be considered a behavioral rule.
167
167
168
168
-`IOC Rule`
169
-
Rules that are created for urgent adversary activity that has little-to-know other detection measures (e.g. wannacry, notpetya, mass & urgent exploitation). Mostly for IOCs like domains, IPs, hashes, url.
169
+
Rules that are created for urgent adversary activity that has little to no other detection measures (e.g. wannacry, notpetya, mass & urgent exploitation). Mostly for IOCs like domains, IPs, hashes, URLs.
170
170
171
171
-`Generic Rules`
172
172
These rules are meant to identify potential weaknesses in an environment. For instance, a rule that identifies weak encryption in Kerberos (RC4_HMAC_MD5). Rules that provide only information that has a very small chance of being a true-positive but is good for customers to keep an eye on. For instance, the root user account of AWS being utilized.
Description: Has to include the name of the actor, TLP:key, and dates when behavior described in the RootA rule was used by the Actor. On the contrary to indicators of compromise, which are Actor specific, behaviors are constant while Actor is a variable. If the TLP:key is not defined, it is perceived as TLP:CLEAR. The period can be defined with two dates (first and last seen) or with one date.
210
+
Description: Has to include the name of the actor, TLP:key, and dates when the behavior described in the RootA rule was used by the Actor. On the contrary to indicators of compromise, which are Actor specific, behaviors are constant while Actor is a variable. If the TLP:key is not defined, it is perceived as TLP:CLEAR. The period can be defined with two dates (first and last seen) or with one date.
211
211
212
212
Example:
213
213
```
@@ -221,7 +221,7 @@ timeline:
221
221
222
222
Required: *optional*
223
223
224
-
Description: Section that describes needed log sources for the rule. It is optional but could be necessary in some cases when the detection logic doesn’t describe which log sources are required.
224
+
Description: This section describes log sources required for the rule. It is optional but could be necessary in some cases when the detection logic doesn’t describe which log sources are required.
Description: The section should contain a rule logic. It should be a SIEM/EDR/XDR query in the native format. The query should be in one line. In case you have a multiline query, you should join lines before adding it to the RootA rule.
353
+
Description: This section should contain the rule's logic. It should be a SIEM/EDR/XDR query in the native format. The query should be in one line. In case you have a multiline query, you should join lines before adding it to the RootA rule.
354
354
355
355
Example: `index=* source="WinEventLog:*" AND (Image="*.exe" OR Image="*.com")`
0 commit comments