GDI Integrated Facility Services Inc

Craig Newell, CISSP, CISA, CISM, CRISC, CDPSE, Vice President, Enterprise Information Security, GDI Integrated Facility Services Inc

The problem with feeding every log from every system into your organization’s SIEM isit gets every log from every system, creating a virtual tsunami of data. However, data itself is useless; it needs to be turned into information, which is then consumed to become knowledge. With hundreds of thousands of data points flooding your correlation engine, how can we InfoSecprofessionals filter out the chaff and get to the wheat?

It seems obvious, but aggregation, correlation, and alerting tools need tuning to get the most out of them. Too many organizations implement an SIEM, turn on every rule they can find, and wait for alerts with the mindset of ‘not wanting to miss anything.’This approachalmost always leads to data overload, burning out teams and hunting down useless incidents.

First, not all data is created equal and worthy of examination, even if automated. Some are useless and should be thrown out like yesterday’s takeout container. But since usefulnessis in the eye of the beholder, every security operations team will need to identify what should be kept or dropped based on their needs, concerns, and experience.

This is a seemingly simple statement but experienced Ops and Admin folks have nightmares at the thought of trying to wade through the data stream and pull out nuggets of gold.Many organizations have taken the ‘keep everything, just in case’ model, but if we look in the records management space, we can see keeping everything forever will ultimately lead to far more problems than spending time establishing rules and policies around filtering and retention.

Only keeping what is useful has a direct impact on your IT budget as well, especially if you’re using a SaaS SIEM like MS Sentinel or a SIEM charging on an events-per-second model. Every byte of data aggregated has a dollar value, which can add up quickly, leaving you to explain to your CFO why you need a bigger budget or have cost overruns.

A great place to start isidentifying legal or regulatory requirements around alerting. If you’re a PCI-regulated entity, PCI DSS has clear requirements around monitoring and retaining logs, both online and near. Ensuring compliance should also highlight other data elements in your logs that serve no value being ingested and can be tuned out.

“Taking IOCs and organization-specific needs into consideration will help to round out your alerting and logging implementation”

Next, lookat your critical systems and your “Crown Jewels." Are the logs coming out of those systems telling you what you need to know? Some systems are chatty, and some are almost mute. Again, limit log ingestion to only relevant data points and move on.

Duplicate data feeds are typically a problem as well. For example, there may be two or more feeds sending DNS data to the SIEM; a host-based web filtermight send it, as well as perimeter firewalls.Decide on a ‘system of record’ and push data from there. The host-based web filter might be a good choice since it also captures traffic regardless of location.

As you're doing this analysis, update your system documentation. Even if you don't need the log element, ensure your build books, run books, and BC/DR plans note which data points are available and consumed into your SIEM. Knowing whatelements can be enabled may be useful for troubleshooting, incident response, or a DR situation.

Once you’ve ensured only useful information is being aggregated, you can start looking at use cases and analytics rules in the SIEM.Only alert onthe behavior you need to investigate immediately and generate reports for everything else, such as typical access governance reviews.

For example, it might be useful to have a log of PIM usage; however, getting an alert every time a SysAdminactivates an admin role will quickly become just another thing to close. However,turning an alert on temporarily will help you understand normal usage patternssoyou can tuneout routine and expected behavior. If an admin activates the same role every day at 9:15 am, Monday to Friday, ignore it, but if they activate it at 9:15 pm on Saturday, fire off an alert.

Understanding typical behavior, network traffic flow, and routine activities is critical to quickly identifying anomalies and responding while also helping you identify any holes in your monitoring and alerting. Considering IoCs and organization-specific needs will help round out your alerting and logging implementation.

Understandthis is a time-consuming cycle, not a one-off exercise. But in the long run, it will save effort and money and increase your confidence in your ability to quickly identify and action anything weird.

The piece of mind alone is well worth the up-front effort.