Threat correlation is really the secrete sauce of the SIEM. The theory goes that in today's day and age, there are so many systems of different types, that it is hard for one analyst to know them all. The SIEM is supposed to provide you this service / feature... almost like an analyst in a box. I personally feel that you still need both. You need an analyst who knows what they are doing and can spend time to understand systems and security contexts, etc. The SIEM should be a tool that a good analyst uses to get their job done, not a replacement.
Threat correlation implementations vary widely (most probably don't work as advertised either .. but what is new?).
- Risk Based Threat Correlation
Basically either takes vulnerability scanner data, or analysts configuration to assign priority to detected threats based on perceived risk.
- "Drift" reporting
Threats can be caught by detecting deviations from normal operation
- Netflow integration
The network doesn't lie. Incorporating that traffic into the threat correlation engines is invaluable (as long as it is done right).
When picking a SIEM, I would want to focus on the following things.
1) Number of threat correlation rules
2) Devices / configurations needed to achieve maximum value from the threat correlation rules
3) Frequency of threat correlation rule releases
4) Real-time correlation
I think that number 2 above is quite important. You really want to get a good understanding of what inputs are required to make the rules really work for you. You then want to map that to your environment to see if you can actually produce that level of logging. In some cases, say databases for example, the audit logging levels required for threat correlation could compromise the performance of the server.
Many SIEMs are now connecting up to "cloud" sources to get additional information. We are only as strong as the information that we share, so I do see this as a good option and something you will want to look for.
Ultimately, I think the key here is integration. You probably already have systems that can be used to assign a "risk profile". The question is how do you easily get that data into your SIEM. On the flip side of that, you probably want your SIEM to be able to integrate with your ticket management system. Although the SIEM provides one, and your analyst will probably use it, you still need a way to communicate with the other groups. There may be some automated responses that you want conducted that do not need the analyst to "vet" the request before sending.
As always, look for good integration with other tools (in your environment) and for UX. You will probably add some rules for custom applications in your environment. Probably not in the first phases of implementation, however.
No comments:
Post a Comment