SecureState was recently called in to help a client who experienced a data breach. When we arrived on site, everyone at the company was in disbelief that anything could have happened, since they hired a Managed Security Service Provider (MSSP) to keep their network and systems secure. They had never gotten issue reports from their MSSP and all of their vulnerability scans always passed, so they never guessed that something was wrong.
As we investigated the state of our client’s security to help them identify the breach, I gained a lot of insight into the topic of MSSPs – and what happens when they don’t work as well as they should.
The Calm before the Storm
In our case, the client we visited was very happy with their MSSP, which handled all of their software and hardware, from their network firewalls to the programs on their computers. It took a lot of stress off of the operations staff, and the MSSP’s employees were very helpful. Unfortunately, their very friendly and helpful MSSP did not measure up when it came to the technical aspects of keeping the client’s systems and networks secure. The MSSP did not put sufficient filtering in place for ingress or egress through the firewall, did not keep the software on the client’s various systems up to date, and their communication with our client regarding network traffic was sparse. Overall we found a lot of issues that, together, left the client vulnerable to a variety of different attacks.
This highlights what can happen when an MSSP under-performs; organizations don’t find out about problems until it’s too late. Adding insult to injury, not only did our client discover they were breached, they learned that their MSSP wasn’t really protecting them.
In Which We Discover Ignorance is Not Always Bliss
As we began investigating the breach, we found that in addition to the issues already stated, there was very little information available to us. Many systems did not have logging enabled, and the logs that were generated were not kept in a centralized location. We had to work through the MSSP to get firewall logs, which were not stored for more than a day and thus were not useful to our investigation. Configuration files were not set up in a default format or in a central location, so each system had to be accessed individually.
Not only did our client’s MSSP leave the client’s network and systems vulnerable, but they also hampered our investigation into the breach after the fact. Luckily, this particular case turned out well despite its challenges – we found the source and timeline of the breach and got the client on the road to remediation.
The MSSP was found responsible for the breach because of their control over our client’s network and system security. This is good news for our client, but makes the MSSP more akin to insurance against a breach than a safeguard to stop incidents.
A quality MSSP should be more effective in preventing incidents, as well as providing plenty of information regarding activity on the network, so that should one occur it can be quickly and easily identified.
In the next in our series of blogs on MSSPs, we will discuss what to look for in a quality vendor, and what questions you should ask them before signing any agreements.
If you are interested in reading more about what happens during investigations similar to this one, our CEO Ken Stasiak has written a blog on Responding to a Data Breach Notification.