The perfect blog for a Friday – SIEM optimization. So by the time you’re reading this, you have already figured out that you need a SIEM and have already identified which one you will use for your environment. If you’re having trouble identifying a good siem, here’s a good reference point.
Meanwhile, if you still don’t know if you need a siem, I suggest you verify your google search. Good. Now that you have a SIEM implemented, don’t be so hell bent on “settling” for the basic out-of-the-box installation that will leave you with fancy underutilized software in exchange for less a couple thousand dollars, bogus satisfactory return on your financial investment and eventually… a broken heart. So, how does optimization further this cause you ask..
Well, for starters it addresses issues with custom configurations and integration done initially while correcting common mistakes such as:
- Zero coordination and awareness regarding incident response
- Doubling up a siem as a syslog server
- Allocating untrained human resources to manage this siem on a day to day
So here are some of the measure we can take to mitigate some of the issues resulted from lack of optimization…
1.Event/Logs threshold: You can count on any network to yield a lot of noise that you need to sift through in order to identify malicious activity. One of the things you should do is identify a baseline criterion to measure a healthy network. Monitor the events that are being generated over a period of time in order to see which events are frequent. This will help you classify what is normal and what isn’t.
- Traffic throughput: it is more relevant for the team monitoring to monitor the traffic coming through the devices such as firewalls rather than the traffic blocked from them. Traffic within your network should always precede traffic trying to get into your network. That being said,do not ignore persistent denied traffic as this could indicate a denial of service attack.
- Your SIEM solution is NOT a logger: Much less a sys logger. Yes, the mainstream suggestion is that the SIEM analyst should be responsible for monitoring logs as well. In truth, this defeats the purpose of a SIEM. Ideally, the primary reason for implementing this siem was and I want to believe still is monitoring security alerts. Do not convert your siem to a log/syslog repository. If you work in an environment where you’re required to retain a large volume of logs, then acquire hardware to support this regulation
- Avapi noise : Down to specifics. Not to sell AlienVault, but I will reference to it because it’s my SIEM of choice. Avapi (AlienVault API user) is a service account on alienvault that
One of the logs generating thousands of events was about cryptographic key—pair authentication accepted. Ansible, which is an automated engine which allows admins to automate scripts in hours such as AUTO SSH and AUTO SCP scripts. The disadvantage of this is there are too many auto-ssh events.