Why test SIEM use cases?

I recently spent quite a few months working with a client who had installed QRadar as their SIEM tool. Guess what? None of their use cases worked as expected 'out of the box'.

Many use cases come with a set of predefined conditions that rely on the correct use of log sources, event timings and alert levels to work correctly, and these all need testing and fine tuning. The best way to do this is to run 'hacks' of your networks in order to trip the use case and ensure they fire when expected. For example, how do you know a bad guy is VLAN hopping or bruteforcing a specific port on an endpoint? Simple really. You get your technical assurance team or an 3rd party to run specific attacks which mimic what a real work threat actor would do.

Even then, we spent quite a while going back and forth with the client to ensure the correct log sources where being ingested into QRadar. Many times we attacked a LAN and did not see the expected alerts being raised. Most modern commercial networks are so vast that some firewall or switch logs may be missed when putting the log source list together and testing in this way ensures that all expected information is actually being gathered as required.

Finally, when all events were being raised as expected, the best thing to do is run periodic red team events, where you can continuously retest the SIEM capabilities and the SOC analysts you have monitoring the tool itself. This way you can increase the sophistication of the attacks and fine tune the use cases as appropriate.

If you have a SIEM tool that doesn't seem to be doing what it should be doing, or you want more assurance that the use cases are working, then contact us at info@infosecservices.co.uk for a quote now.

Good hunting.