Jack Daniel has a blog post about logging and MSSPs, “Wait, what? Someone has to look at those logs? “. He essentially makes one point that I (and others) have made for years about Managed Security Service Providers:
…in spite of some MSSP’s theoretical threat intelligence and perspective advantages, they simply do not understand the businesses they serve well enough to provide enough value to justify their expense.
Looking at an MSSP to do something you don’t already do is one thing, but to replace an internal process (or something you *can* do internally) with an MSSP needs to have the risks weighed out. Too often an MSSP is looked at just to save money or just because the internal team isn’t perfect (an expectation that is bad to have).
An MSSP will have dedicated people with a certain level of expertise and efficiency in monitoring your (and many other client) logs. But…
– you’re just one of many clients (probably)
– they won’t know what’s really important to you or a throwaway system
– they will either require elevated rights into your systems to troubleshoot/assess
– or they will be so far removed that they burden your team more than normal with all sorts of pings/tickets on things to look at
– the only valid events will be the absolutely most painfully obvious issues; like an IDS or AV screaming about something. But anything subtle or normal-but-bad like a terminated employee VPNing in the day after they were terminated or a local system account in the DMZ suddenly trying to connect internally, is going to be missed in the noise.
– they’re not going to act on your custom/strange logs
And I can pretty much guarantee that the MSSP will raise false positives and will miss true positives. Just like an internal team. But at least an internal team can learn, but business will probably just scream at the MSSP and either leverage SLA/credit or just sever the relationship and start the whole bloody thing over with someone else.
One last thing: Having looked at SIEMs/logs for a while now (sort of a part-time duty in my current job), I’m pretty convinced they’re best used to improve knowledge of the environment and for supporting operations. But for eventing on security issues? They’re only as good as the logs you gather, and the only real benefit is sucking in IDS/AV/mail gateway logs and raising events on those (things that can already raise their own events anyway); a sort of meta-security tool. Or super-custom things you put in, like special filters on your web server logs, or whathaveyou. Still, good luck getting that all to gel properly without full time staff.
That said, watching your logs is still one of the best things you can do, but it also must be combined with other things such as regular inventory and various vulnerability/change detection (like new local admin accounts or new AD accounts)….the list is endless on what can be useful.
You raise some good concerns, but there’s a lot missing from the equation you haven’t factored in. Having spent the last 4.5 years working at a MSSP (though not in that group), I know the inner workings of that institution fairly well. We did everything we could to try and get context for the security events, including building criticality, grouping and other features into the system, reaching out multiple times to get it, and automating as much of that association as possible. The main point of what we tried to do was to get the business context of the security events, not just the raw event. Because you’re right, that’s the best way to really provide security to the business. The main hurdle to this was that the IT and Security groups typically wouldn’t provide any of this context despite repeated attempts to get it. So we built systems to try to figure it out on our own.
Why did we try so hard? Simple economics. Like you said, a normal MSSP has too many false positives and negatives. In our model, false positives meant we had to spend a lot of time digging into the event and analyzing it. False negatives meant we got fired. Both are bad situations. That’s why we invested so much time and effort to get it just right – not just technically, but for the business as well.
You touched a little on the bigger issue – IT and Security teams often outsource because they’re not good at the technical or business side. Then the MSSP at least raises the bar on the technical side. But if nobody from the client provides business context, they’re blind on one side.
Some of the most successful relationships we had were ones where the client understood they needed to integrate more to get more value. They worked with us to provide business context, processes, notification lists, custom log formats so we could turn those into alerts, thresholds that applied in their environment, etc. Those things matter just as much to a MSSP as they do to an internal security team. Without them, your effectiveness is reduced substantially. But to your point, in a single company the business can just call and yell at the security guy and convince him to do whatever is needed. In a MSSP model there are hard-and-fast processes for authentication and authorization, as well as making changes.
All excellent points, and much thanks for sharing! Having not worked for an MSSP, I really can only guess or talk to those that do for such great insight.
I think I overcompensate for my interactions with managers who think outsourcing security is a cheap fire-and-forget action.