JULY 2024ENTERPRISE SECURITY| | 9approach almost 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 usefulness is 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 is identifying 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.Next, look at 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 filter might 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 what elements 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 on the 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 SysAdmin activates an admin role will quickly become just another thing to close. However, turning an alert on temporarily will help you understand normal usage patterns so you can tune out 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.Understand this 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. ESTAKING IOCS AND ORGANIZATION-SPECIFIC NEEDS INTO CONSIDERATION WILL HELP TO ROUND OUT YOUR ALERTING AND LOGGING IMPLEMENTATION
< Page 8 | Page 10 >