<p>SIEM solutions have been positioned to provide visibility across multiple applications, systems, and networks. Piecing together log data from multiple sources means that you potentially identify attacks as they occur. But these solutions also come with complexity and limitations; sizing, performance, scalability, and keeping on top of a constantly changing infrastructure means that many customers fail to realize the value of a SIEM.</p><p>Many organizations look to use threat intelligence to help them prioritize, guide and add value to their SIEM. However, they then struggle to understand how to do this effectively. Frequently, customers comment about turning on threat intelligence in their SIEM, quickly followed by turning it off again due to the flood of alerts! Using a threat intelligence platform drastically improves the handling of data, integration, and ultimately derives value from the threat information. This blog post covers one approach that customers can take when looking to integrate SIEM solutions with threat intelligence, identifies common pitfalls, and highlights quick value points.</p><h3>Why Use Threat Intelligence with a SIEM?</h3><p>Usually, a SIEM is in an enviable position due to its wider view of an organization’s security posture. With a mixture of logs from a disparate set of sources, a SIEM is supposed to piece together sequence and logic to identify threats and attacks with ease. However, what usually happens is a mixture of misunderstanding, over-ambitious project planning, and a lack of ongoing maintenance. This results in a security solution that generates far too many alerts for an analyst to deal with.</p><p>Organizations have a choice to make; re-engineer everything or look at options to improve efficiency and drive better detection. Enter threat intelligence. The addition of threat intelligence usually focuses on ‘adding value’ to the alerts and helping prioritize which ones are the most important. Often seen as the easy option, adding threat intelligence with a SIEM should give added efficiency and prioritization.</p><h3>What are the issues with threat intel with a SIEM?</h3><p>When approached with an easy option, many organizations simply enable the capability that is built into their SIEM solutions. In the past, I have heard this referred to by many names, but the best I came across was ‘lights on.’ This phrase refers to shining a light on the highest threat events with ease. However, without careful consideration of the profile, type, and context of the intelligence, this is usually followed by ‘turning the lights off’ again. Why? Without this careful management all it does is create a flood of new alerts, incorrectly categorize existing alerts as high priority, or in some cases provide a multitude of false positive alerts. How does an already taxed analyst decipher what is real and what is not in this new set of alerts? Context is king in the world of security, and without any, an already bad situation is made worse.</p><p>Conversely, some organizations look to integrate intelligence data and end up with few or no alerts. This creates the perception that the data provides no additional value or advantage, and hence many organizations simply don’t see what intelligence can do.</p><h3>How can I approach integration options?</h3><p>Given that simply enabling threat intelligence within a SIEM can lead to more issues, how does one go about adding the promised efficiency and prioritization? Often it’s down to understanding the overall security goals for the organization and where the SIEM fits to best achieve those goals. This means understanding the log sources, types of data, and where they exist within the organization.</p><p>Firstly, the vast majority of intelligence data is focused around external data types, such as IP addresses, domains, and URLs. If a SIEM is only ingesting logs with limited external data there will be very few matches. The organization needs to consider what data it is collecting, focusing on logs that originate from devices positioned with visibility into ingress and egress traffic.</p><p>From there, it is the intelligence data that needs careful consideration. Where does it come from, and does it meet the organization’s particular profile and situation? While it might be great to obtain any data, it really should be optimized to the organization’s functions, locations, and relevant threats. For example, is phishing a key threat for the organization? If so, consider the integration of data that focuses on this and the surrounding infrastructure.</p><p>Finally, the organization must consider the context around their threat intelligence. Data on its own is usually of extremely limited value, and it’s almost impossible for any SIEM analyst to understand what the real threat is without context. This means that any integrated data should be backed up with additional context such as confidence scores, severity information, and its history and associated threats.</p><h3>What are the best practice guidelines for integration?</h3><p>Unfortunately, there are no hard and fixed rules, but there are a number of guiding principles to follow that assist in the selection and integration of threat intelligence data into your SIEM:</p><p>1) What are your log sources? While fairly obvious, make sure you have data that will match to your intelligence. It should also be possible to limit the data you don’t need; if your logs don’t have file hashes in them, don’t integrate file hash intelligence.</p><p>2) What are your highest threats? This is not a defined set of criteria, but understanding where the gaps are, what the threats are, and what are your critical risks. Do you suffer phishing attacks the most? What about your industry vertical? Are you a target for a nation state? Do you have a large population of users who keep clicking bad links?</p><p>3) Where does the intelligence come from and does it match your requirements? A lot is said about open source vs closed source vs premium data. There are no rules around this, but make sure you know the data’s sources, its curation, and its timeliness. Knowing the details makes the difference.</p><p>4) Is there a portal you can use to look at more details? So you get a match - that’s great - but where can you find out more? Is it a manual process, or can you automate this? How can you optimize the time taken from identification of a threat to understanding the context of it?</p><p>5) Can you get additional context into your SIEM? Getting data into a SIEM is usually very simple, but it helps to have more context that you can use and refer to in your correlation rules. What about additional data such as source, type, and even what actor/group is involved? Is there a score you can use to assess criticality? It all helps in the decision making process, and can be used for automation in your SIEM!</p><p>6) How can you optimize the data and focus it on your requirements? Can you filter, control, and update the data that is the most relevant for you? Millions of individual pieces of threat intelligence might look good, but if you only ever see less than 1% of this, how can you make it optimized, targeted, and useful?</p><p>7) What are the customization options to drive your processes? Does your SIEM have rules to utilize the intelligence and, if not, can you get them (free package, downloadable etc). Additionally, can you customize this to fit your requirements and needs? Can you integrate these rules with your workflows, SOC processes and automation tools?</p><h3>Summary</h3><p>Can threat intelligence add value to a SIEM? Absolutely - when carefully planned and implemented. Blindly integrating threat intelligence into your SIEM can often lead to more issues than it solves. The volume of intelligence doesn’t always mean better detection. Optimizing the data to the threats and risks that an organization is facing means it is more focused, resulting in greater efficiency and detection. Mapping this to workflow processes, automation, and analyst interaction ensures that you can drive considerable value with threat intelligence; just don’t turn it on blindly as this makes it very difficult to use. Plan, consider and use with caution and it will work for any organization.</p>