"Good enough" ArcSight/Use Cases

There have been a couple articles that have popped up here and there that seem to have had their base in Duncan Hoopes’ FUDsec article relative to things being “good enough” – well if not their base then a similar theme.

Last week I took some time to drill into several Win2k8 failed login events and how ArcSight was parsing them. For event 4625 (which replaced 10 Win2k3 events) I was surprised to find a rather key piece of data - sub status code – stuck in a field you can’t query on and isn’t consistent with where the same data was parsed and dumped in the corresponding Win2k3 events. What is key about these codes is it lets the reader know WHAT the condition was surrounding this particular login failure – user account doesn’t exist, account was locked out, account is currently disabled, etc. It would be easy to question why hasn’t ArcSight “fixed” this issue. The better thing to ask though to me is why hasn’t anyone over the last 2 years plus that the OS been out actually brought the issue up to ArcSight in the first place?

Maybe I look at our service contract different than others and honestly you can make an override relatively easy; bypass the issue and move on. Why not bring it up and try to get the thing fixed at a macro level….unless people don’t have content that involves that data and aren’t looking at it anyway? Is this a case of simply getting the ball on the green and wrapping your arms around just the event is good enough? Don’t get me wrong I don’t have a ton of content built around each of the sub messages but I do throw them into the Trend that is tracking failed logins where they eventually show up in multiple reports. I mean wouldn’t you want to differentiate between 600 failed login attempts but that they were because some idiot used his domain credentials on a service account and didn’t change the password vs 600 failed login attempts for an account that didn’t exist?