SIEM – How to go from concept to incident ready

So, you have decided your organisation needs a SIEM. What happens next?

SIEM – How to go from concept to incident ready

So, you have decided your organisation needs a SIEM. What happens next?

As a consolidated view of security threats, a SIEM can be of great value to almost any organisation. However, a lot of organisations don’t get sufficient value from their SIEM, or it’s just a way for them to tick a box on a compliance form. Don’t you really want to get the most out of that expensive new tool?

Once deployed, a lot of organisations think the job is done, but this couldn’t be further from the truth. The SIEM will require constant and ongoing maintenance and improvements to continue to provide value. Otherwise it risks falling into disrepair and might become an even larger task to fix than the original deployment. I have seen organisations where it is easier to install a new SIEM rather than fix up the old one!

What are the first things to consider?

The first thing to consider is why the decision to use a SIEM has been made. Ensure that the business requirements are known and what goals the organisation wishes to achieve by embarking on the SIEM journey. Begin with the end in mind. Ensure that the goals of the project are aligned with the original business requirements.

Take some time to consider the best product for your needs. SIEM solutions come in many flavours. There are open source products, a multitude of vendors that offer SIEMs, or even home-grown options if you have the skills and desire in house to do this. Be careful with the home-grown option however due to increased time to value.

Review the various hosting options for your selected SIEM. Do you want to host the SIEM in-house, or does your organisation have a cloud first strategy, in which it is a requirement to use a fully hosted option?

If you have settled on a SIEM product that you will be purchasing from a vendor, review the licensing model in use, as a lot of work will go into ensuring that you have the right type, and number, of licenses for your organisation. Licensing can be complex and expensive, depending on the licensing model for the SIEM selected. Right sizing the license is important, but this can be expanded later on, providing there is budget remaining. You will need to consider your logging requirements at this stage as well since most licensing schemes work by number or size of logs being imported. I’ll talk more about determining logging requirements later on.

Remember to consider also the ongoing support and maintenance costs, as the higher the license cost, the higher the annual renewal bill that comes with it.

Review the architecture options available for your implementation. If you are hosting the SIEM in house then this will be very important, as it can mean the difference between a poorly performing SIEM and an incident ready SIEM at the end of the day. This is easier if you have decided on a cloud implementation, as less thought needs to go into the SIEM itself and more into ensuring secure, reliable and timely data transmission to the SIEM. There are many decisions to be made here and most likely the vendor you have selected will be able to offer you the best advice for your specific needs.

Which logs do I need?

Now that some of the decisions have already been made around the SIEM, its important to start thinking about what the logging requirements are. As any technology professional knows, there are a huge abundance of logs available in any organisation. Do you want all of them? I’d suggest not, or at the very least take a prioritised approach to adding logs to your SIEM. Onboarding everything in one hit is just asking for trouble.

Firstly, decide on some use cases for your SIEM. Use cases can help to prioritise which logs are going to provide you with the most value. Start with thinking about some likely attack scenarios for your organisation, from both internal and external threat actors. Then try to determine how you would detect these events, and which logs are going to be able to help you the most.

The other approach which goes hand in hand with the above is to rate servers or applications by risk, i.e. figure out which assets would be of the most value to attackers and start by collecting logs for your most critical assets.

By now you will have a pretty good idea of the order in which you want to start importing logs. Some others to think about are:

• Active Directory, Kerberos, LDAP
• Identity management and authentication data
• IDS/IPS, Web/Email filters, WAF, Anti-Virus, Anti-Malware
• DNS, DHCP, switch, router, firewall
• Database (be sure to configure auditing in the databases, as most are not enabled by default)
• Network flow data
• Cloud data
• Physical building security logs (e.g. door access)
• Vulnerability scanners
• System or policy change data

Other things to think about before installation

Make sure you consider who is going to have access to your brand new SIEM. Once the SIEM is running you might find a lot of people within the organisation want access. You need to decide up front what makes sense, and what doesn’t. For example, operations teams might want to investigate locked accounts using the SIEM, especially if they don’t have their own logging solution in place for authentication logs.

Ensure you have a plan for the permissions scheme you want to use. If you are going to have various teams other than the Security Team accessing your SIEM, you will want to have the appropriate permissions structure in place as to not allow access to data by team that don’t need it. You may not want your Operations team having access to the web browsing data for the entire organisation for example.

Also think about who is going to be responsible for the ongoing maintenance of the SIEM. Are the security staff who the primary users of the SIEM, also the ones that are going to be required to maintain it, and log support calls to the vendor when something goes wrong? Document these support requirements up-front so that when something goes wrong, you don’t have to start conversations about who is going to get it resolved.

This is also the time when you want to start thinking about which sources of threat intelligence are going to bring you the most value. There are plenty of free ones out there, and many paid ones exist as well. Something industry specific, if it is available, will likely bring you the most value. Do a web search for “threat intelligence feeds” if you aren’t sure where to start. But beware, some threat intel feeds will fire more alerts than you know what to do with, so significant tuning may be required.

Purchasing and Installation

At this stage (or possibly even slightly earlier), you can start the procurement process for the required hardware, software and licenses. Make sure you contact multiple vendors to ensure you are getting the best deal on the SIEM that you want.

OK, its crunch time. The hosting model is decided, maybe hardware has been purchased, software is ready to go, and licensing is all sorted. Time to get the thing up and running! Set up the hardware and software, or don’t if you have selected a cloud model. The point is to make sure the SIEM is ready to start accepting logs.

Now you can start working through your prioritised log source lists and start adding them one by one, or in batches if your workflow allows for this. Make sure you watch the performance of your SIEM during this time, as this is where architecture and planning issues can start to show themselves.

The Never-Ending Cycle of SIEM

Now comes the fun part, the operationalisation of continuous SIEM improvement. The following steps are not things that need to be done just once, as much as you might wish it were that way. For a SIEM to be truly effective there needs to be an ongoing cycle of evaluation and refinement.

Continuously evaluate required log sources. Log sources change all the time. New systems are added, old systems are decommissioned, log sizes grow and diminish, and sometimes just stop working altogether. Ensure that you are on the lookout for any of these events, so that the SIEM has the right log sources needed to achieve your goals.

Evaluate threat intelligence. Are you getting value from your threat intel sources? Are there some new sources of threat intel that may potentially be useful? The other thing to consider here is if you are able to contribute your own threat intelligence to help others, although this does require a certain level of maturity within your operations that you won’t have straight away.

Review your use cases on a regular basis. Are there some new ones based on new products the organisation is offering, or is the evolving threat landscape showing up new and different types of threats than in the past. Keeping on top of new use cases will help your SIEM continue to perform and meet business objectives.

Now for one of the most important tasks, without which, your SIEM will be much more difficult and onerous to operate. Write, evaluate, and tune the rules. A lot (if not all) of SIEMs come with out of the box rules you can use, which may or may not be suitable for your organisation. Apply the use cases that you have generated to ensure you have rules for each and every one of them.

This next task goes hand in hand with writing rules. Watch for and tune false positives constantly. If there has been an alert generated, and it is proven to be a false positive, then that rule should be tuned, so that you’re not spending time on the same false positives more than once.

Performance monitoring and ensuring SIEM is performing up to scratch. In order to maintain your SIEM in a good state of health, it is important to perform preventative maintenance checks on a regular basis. As above, display metrics regarding the health of your SIEM on a dashboard. Ensure that the team who is responsible for the maintenance of the SIEM can see these dashboards, and receive the required alerts to provide a quick response when something goes wrong.

Develop meaningful dashboards. Dashboards are of critical importance to any well-functioning SIEM. They can display near real time status of the operational health of the SIEM, as well as important information about the security posture and compliance level of the organisation.

Try and automate as much as possible. If you are performing a task manually every time a specific alert comes in, can that task be automated or scripted in some way to reduce the workload on your analysts?

Now it’s time to perform a review. Have you met your original goals and aligned with the business requirements?

Using the above continuous improvement cycle will allow your SIEM to be ready when the inevitable security incident arrives. Your SIEM will allow your incident response process to operate efficiently and effectively when the time comes. Ensure that your incident response processes are reflected in your SIEM processes and vice versa, and review these on a regular basis as well.

Ready for a Security Incident?

There is a lot to think about during the implementation of a SIEM, and many mistakes that can be made along the way. Hopefully this article has given you something to think about when it comes to your next SIEM implementation.

Is there anything that you think I have missed? Let me know in the comments. Good luck with your SIEM implementation!