Here are some alternative ways to alert from the risk index that you may find useful. Later searches will be relying on the base search found in the "Capped Risk Score by Source" approach.
This is a very effective approach that looks for when a single risk object has events from multiple security data sources. With a well-defined naming scheme for your searches, you may not need to utilize a saved search to retain this information in your risk rules. Otherwise, you could run something like this somewhat infrequently as a saved search:
Which looks at the SPL of a search to determine which sourcetype to group it under. Please modify this search as you see fit for your environment. This allows you to create a Risk Incident Rule like this:
Events from Multiple Sourcetypes with Meta-Scoring¶
Sometimes, you may need more ways of distinguishing which events should have more relevance in an alert beyond a simple count or distinct count. The gist of this strategy is to declare a new variable with a value of 0, then utilize multiple eval statements to add to this value based on attributes about the event. Remember that a case() statement will only apply once and will apply the first match it finds, so you want to ensure your most important matches hit first. Don't be afraid to stack multiple eval statements, and you'll have to tweak what the threshold is depending on the values you chose.
Because sourcetypes is now a multi-valued field by risk_object, I had to create multiple eval checks so that the operation would apply more than once if events from multiple sourcetypes were found. You can also see how I pulled out severity from the risk_message earlier on with rex so I could make a distinction between higher and lower severity IDS events in the meta-scoring. This assumes only my IDS events have that particular formatting to indicate severity; you may have to use more logic to distinguish different sourcetypes and severities, it's just an example.
For the scoring threshold of 40, I chose this because of how I've structured the score additions. I will get an alert if a risk object has events from:
2 of (Endpoint / Malware / IDS High-Critical)
1 of (Endpoint / Malware) + 2 of (Web / DLP / IDS Low-Medium)
Which may remove a lot of noise from combinations which aren't as likely to be malicious. It is still worthwhile to occasionally review what doesn't pass the threshold to ensure you've crafted a method that surfaces high-fidelity alerts, or are caught with other Risk Incident Rules.
Near the beginning, we juggle some logic for counting events differently which have a lower risk score because when we aggregate on the count of MITRE Tactics/Techniques involved, we might want to treat events with a higher risk score as counting more heavily toward the overall total. This is especially true when aggregating events over longer periods like the out of the box 7 day rule, or something going as far back as 30 or 90 days.
Now in the meta-scoring, we have all sorts of ways to distinguish what might be more relevant to us. Now we incorporate:
Number of risk-score-weight-adjusted MITRE tactics
Number of risk-score-weight-adjusted MITRE techniques
Number of distinct rules firing
Rules from particular sourcetypes adding more weight
Specific user or system categories adding more weight
Which gives us more control over the types of events that might bubble up in our alerts.
@7thdrxn - Haylee Mills