Although we're not in the Teutoburg Forest, as an Incident Responder, I live in a vortex of swirling data. My cases live and die based on the data we've collected. There's nothing more frustrating than asking a question, going to the logs, and finding out that the data I need to answer my question doesn't exist. It happens more than I like to tell management. And it's not that the data wasn't collected, it's that the vendor doesn't supply it so I can't look at it in my SIEM. Let me list some offenders I've encountered over the years and why the problem is so galling.
We had a spam service that re-writes URLs in e-mails in order to record clicks so that when they discover a phishing campaign after the fact, they can send us warnings about who clicked on the phishing link. The problem? When they miss a phishing campaign and we discover it manually, we have no way to access that click data. When we suspect credential theft has occurred, we need to know who clicked the link immediately. Our only recourse is going through support, which takes hours to days. Meanwhile, the attacker is happily logging into our systems. Not okay. If the data was in our SIEM, the incident would be contained within the hour.
While demoing antivirus products we spoke to a few vendors who literally asked "Why do you need the logs? We protect you." Why? Because an analyst needs to look at them. Trust but verify. When you catch stage 2 of a malware infection in the Windows directory, it means you missed stage 1 (this happens all the time). This is obvious if you're looking at the logs and we need to catch it when you miss it. Also, can you please give us the hash of the detected file? That way our analysts can look it up in our intel platform and get an understanding of what we're dealing with. Is it PUP or a RAT? Is it commodity malware, something unique, or is it a false positive for a legitimate homebrew app? Bottom line, if you can't send logs to a SIEM automatically and your response is "you can manually download a .csv from the console" you're just not ready for the enterprise space.
I love proxy logs. They're a treasure trove of data and I've done some very successful hunting looking for C2 traffic. Please, for the love of malware, include as much data from HTTP request headers as possible in your logs. Malware writers make mistakes when they craft these requests all the time. But I can't detect them if you don't give me the data. A vendor I encountered recently was trying to be helpful by analyzing the user agent strings in web traffic and returning the application the request came from. While I like that, what I didn't like was the vendor not including the raw user agent string in the log data. Why is it a problem? We could no longer detect malware using known bad user agent strings. For example, njRAT puts C2 data in the user agent string so its obvious if you're looking for it. Even if the proxy is doing its job and blocking this traffic, you still need to know about the infected computer so you can remediate it.
/rant over
Salesmen of security tools exude confidence. Their tool is going to save the world. Set it and forget it! If we buy their tool, we're safe. Period. That's what they tell us. The reality is that all security controls fail. No tool is perfect. And that's okay! Any security analyst worth their salt knows we're in a game of cat and mouse and eventually an attacker will gain the upper hand. VENDORS, even if your tool fails you can still help us! Give us the raw data! We can manually piece together what happened, what was missed, and send you back the results so you can improve your product. We win, you win. This is the kind of relationship you want between a customer and a vendor, a partnership, one that leads to better defenses for everybody. All we need is the data.
