Best practices for Advanced Attack Detection Using SIEM

Over the past few years, security information and event management (SIEM) technologies have been criticized. Its complexity and excessive demand for professional services have led to many complaints. Many companies are disappointed with their experience in deploying SIEM for security monitoring.
But that was before, and now it is different. To be fair, technology is no longer the reason why it is difficult for enterprises to successfully deploy SIEM. The leading SIEM platform has gone through "Brain Transplantation" to migrate data to a specific target storage that provides sufficient performance and scale. Previously cumbersome and unreliable system connectors and log aggregators are now more effective, making data collection easier.
However, SIEM still faces many difficulties, as are all rules-based policy technologies. SIEM must know what it is looking. The magic SIEM product does not automatically detect attacks that exploit new methods or rare vulnerabilities.
SIEM plays an important role in attack detection. However, to successfully detect known or unknown attack types, enterprises must establish a set of policies to find attack conditions and indicators in their environments and continuously monitor these situations.
So how should we establish such a policy? Of course, it is unrealistic to wait for it to appear. Let's take a look at the simple process of establishing an effective SIEM policy.
Collect all data within a reasonable range
If sufficient data is not collected, SIEM cannot perform a comprehensive analysis. So the first step is to collect the correct data. What does this mean? Start with obvious data, such as network, security, and server device logs. This data is large and easy to obtain. Then, obtain the log information from the application infrastructure (databases and applications. Of course, SIEM also needs a variety of other data sources, including identity data, network traffic, vulnerability scan results, and configuration data.
For the SIEM system, the more data the better. If possible, collect all the data. If you need to prioritize collected data, you should first consider the data collected from the most important technical assets (devices in protected environments and devices that process regulated data. In addition, pay attention to systems that handle key intellectual property rights.
Build rules
Creating a SIEM rule repository is an iterative process. This means that the process is relatively slow and requires long-term refinement or adjustment. Many people are "analysis paralyzed" when starting this process, because there are millions of possible rules. Therefore, we recommend that you first define the rules to be defined.
In the modeling process, start from important assets. Place yourself in the role of an attacker and start to monitor the data you want to steal.
Simulated threats: If you are an attacker, how will you intrude into and steal data? Simulate this threat and list these attack vectors in the SIEM tool. Don't forget to leak out, because this provides another opportunity for enterprises to detect attacks before data is stolen. This process is carried out with a realistic attitude because the threat model is not completely accurate and may be incomplete or comprehensive. The most important thing is to simply start the threat modeling process, which is a good start.
Complete rules: launch attacks on yourself. There are many ready-made tools available to attack your environment. You can try them. Then monitor your SIEM activities. Does it send the correct alarm at the right time? Does the alert provide sufficient information to help the responder identify what happened and take action? If the answer is no, go back to Step 1 and complete the rules.
Optimization threshold: over time, you will gradually learn if SIEM alarms are too frequent or insufficient. Adjust the threshold accordingly. This is a balance. If the threshold is too tight, the alarm will be reduced, but it is easier to miss the attack. And vice versa, if the alarm is too frequent.
Cleaning, rinsing, and repetition: After the rule set for a specific attack is deployed and optimized, move to the next attack vector and repeat the process when modeling each threat.
By the way, this process will never end. There will always be new attacks that require modeling and new indicators that require monitoring. Enterprises must pay close attention to security news to find out which attacks are very popular. The latest threat Research Report (such as the Mandiant APT1 Report) contains clear indicators that each enterprise can (and should) consider adding these indicators to its SIEM. With threat intelligence and a comprehensive data collection environment, you can't find an excuse: It's time to start looking for emerging advanced attacks.
Also remember that over time, you need to add a new data type to SIEM, which will need to reconsider all the SIEM rules. For example, if network packet traffic is captured and sent to SIEM, a large amount of new information is provided for analysis. If you can view the actual network traffic, what is the impact on the search for an attack? What other rules can we add to detect attacks faster? These are not trivial issues. Each time a data source is added or deleted, SIEM rules can be checked to increase the attack detection speed.
The most important thing in this process is to maintain consistency. SIEM is not a "one-time setup, no worries for life" technology. It requires careful care and treatment-not just the present, but its entire lifecycle. If you have any luck with this, you will eventually be disappointed.