Auditing is broad term and could mean auditing that the SIEM is working as expected or generating reports providing detailed usage statistics. (It could mean many other things beyond these as well)
The SIEM will only be as good as the data source, so that is the first thing you should check. Ensure you have a number of defined use cases, for example low level use cases may be normal user accounts attempting to use SUDO or add jobs to cron.
One you have a collection of use cases you need to ensure they are being logged. Linux does not log all actions by default, even if it does log them by default you need to ensure that the connector to the SIEM is receiving the raw logs. Depending on the Linux system and the methodology used this will differ, but the most common setup I have seen recently usually involves using rsyslog and auditd.
Once you have the raw data being collected by the SIEM connectors you then need to ensure that the raw logs are being parsed and normalised correctly, this is something I have seen configured incorrectly before and it can cause problems down the line. Standard syslog connectors may form a basis for the normalisation process, but depending on which logs are being collected and what format they are in this probably will require a level of tweaking.
Once this is done you need ensure that the events are being generated on the SIEM by the logs, if all is OK then you should see a stream of filterable events on your SIEM solution. This doesn’t necessary mean that any of the events are going to match your use cases.
The next thing you need to do is create rules for each of the uses cases; for example you may want a rule to fire every time a normal user uses SUDO.
The next stage is testing. Testing can be tricky, because you need to be able to do something that is going to trigger the rule and in most production servers that will either involve a lot of paperwork or it will not be possible at all. This means you will need to use either a test system or replay file that will flood your system with events, you can configure either to purposely carry out activity to that will trigger a rule and an action. This action could be anything from correlation with other events, sending alerts or key to this question feed directly into a report or query for auditing.
Additionally you can write scripts that will attempt to carry out the use cases and generate log entries, this will test the entire process from the raw logs through to the SIEM rules. (Good luck getting scripts like this onto a production server though)
Once you have thoroughly tested that each of the use cases are triggering the rules/actions you require, you can start tuning out any events that are not a security issue, for example some normal users may have legitimate access to the SUDO command and you do not need the rule to fire every time they use SUDO.
One of the good things about SIEM is that in general they are very easy to audit as reporting is built in. You can configure a series of reports for each of your use cases. These can count how many times a rule fired, what times they fired, what actions were taken etc. You can dig down deeper and audit all events regardless if they fired a rule or not. Really you are only limited by your imagination or computing resources, although you should only really use the SIEM to report on security events.
These reports can be configured to provide detailed statistical analysis or general aggregated data. Once again you need to decide what you want to see, for example do you need to prove you are compliant with certain regulations? If yes; Break the regulation down into discreet provable objectives and then generate a report based on each of them, this process will be different for each environment and each regulation you need to be compliant with.
The SIEM will take time to mature, it is just the nature of the beast and things should improve over time, with continued tweaking, testing and reporting.
One thing to be very careful of though is not to out scope yourself, you may create a set of rules so tight that you end up with blind spots and miss malicious and/or anomalous activity in the environment, this is something that reporting will not help you with.
- Ensure your data source is configured correctly, i.e. the correct logs
are being forwarded to the correct place.
- Ensure the SIEM is seeing the data correctly.
- Test and tune all your rules.
- Configure reporting within the SIEM based on your unique auditing
needs, i.e each set of regulations/audit demands/environment/SIEM
will require bespoke configuration for the reporting and auditing
- In addition to this, time will be required for the baselines of the
expected events and maturity of this SIEM to be established.
Finding information sources on the detail of how to do this can be tricky. Most enterprise class SIEM solutions are propriety products and the literature is quite heavily protected, if you are a customer go to your vendor directly and ask for support. There are a few resources dotted about online, but in general I find the information to be of low quality and in many cases out of date.
SANS have a paper called Successful SIEM and Log Management Strategies for
Audit and Compliance that you can get in PDF format here.