How to implement a SIEM

How to implement a SIEM?

When establishing that a security information and event management (SIEM) system is appropriate for your business, there are often two questions left to ask. The first is what SIEM software should be deployed and the second is how do you implement a SIEM solution.

Within this blog article, the aim is to help identify the stages that will provide a successful deployment. Please keep in mind that these stages of deployment could vary slightly, depending on the type of business which the SIEM is being deployed within.

The first section of the implementation is to develop a good overview of why the business wants to implement a SIEM solution, such as how the business will benefit from the implementation and what the negatives are such as financial costs and resource costs (e.g. man hours/time). From here the business can extract the requirements which will help direct the project and ensure the end result of the implementation is achieving the goals set at the start. By this stage, an overview of what is needed is established, along with the more finer requirements, so as a business it's now possible to run through SIEM software solutions and aim for the one that will best fit the business in question. After the software has been chosen and technically installed, likely on a virtual machine or in a cloud environment provided by the software vendor, it's time to start doing the real implementation.

Begin sending logs from systems the business wants to monitor, to the SIEM solution. Keep in mind two things at this point. 1) If this is the only SIEM solution and logs have never been looked at before, there's likely no risk, so just do it. 2) If the system logs are currently used by other systems or processes, then the logs should be copied to the SIEM solution rather than sent directly there. From a security perspective, logs should really be copied but if as part of the implementation the logs are being changed, so they're retained for longer this will require more storage. A balance needs to be made between retention, location of storage and cost of storage.

Now with all the data going into the SIEM a review needs to be performed, which helps fine tune it's configuration. This is where one of the very important features called Correlation comes in place. Various devices in your infrastructure should be constantly generating and sending logs to your SIEM solution. A SIEM has a correlation engine where correlation rules are defined and tells SIEM which sequences of events should be altered as a high, medium and low priority for investigation and which event could indicate anomalies that may be an indication of cyber attack or security weakness in your environment. Defining these correlation rules and normalising can help to minimise false positives and helps an analyst to focus on priority alerts.

The next stage is to identify how the events are going to be handled and pushed. For example, a low priority alert has been generated by SIEM, should it be emailed over to IT or should it be shown on a display screen such as dashboard in your IT department? If it is a High priority alert it should be prioritised and notified to the IT team as soon as possible to dealt with, within defined SLA (Service Level Agreement).

Once the implementation has reached this stage, it's time to start refining the SIEM. For example, include more systems, amend the rules that have been developed (perhaps too little or too many alerts are coming through).

This is a simple guideline for a successful SIEM deployment and implementation. If you would like to know more about feel free to get in touch and we can help you for more details.