Last week we talked about Mean Time to Recovery (MTTR), which is the time it takes to go from when the breach occurs to being fully functional, and back to the normal operations. Three weeks ago we talked about Mean Time to Detect (MTTD), which refers to the time it takes from when the initial infection happens to when it actually gets detected - and how often that timeframe is significantly higher than most people realize. Today I'm talking about Mean Time Between Failures (MTBF), which is the time between when a failure occurs to when you are able to be repaired or restored. This distinction between "able to be repaired" is important, because it focuses on the effectiveness of your cybersecurity - whether or not your methodology is working properly, or if there are excessive amounts of security events that shouldn't be happening - by measuring the frequency of said events.I've talked about the Sony Hack, the Colonial Pipeline Hack, Log4j, and others - but for today I want to give an example of a situation where I was brought in to analyze an ongoing issue. The IT Security department was seeing a near daily occurrence of Ransomware, and as you know, that takes up an incredible amount of time from both the Help Desk and the Security Analysts to resolve. This was not a sustainable situation, but in this scenario the MTTR would be a low number, representing a value of maybe a day or two. In this situation, it was crystal clear there was a problem. But imagine a more likely scenario, where an MTTR was a month, or even just a two-week period. Both of those numbers are higher, but not much better, correct? How would you approach this problem and what does it mean for how to adjust your cybersecurity policies?
One of the ways we have to approach MTBF (Mean Time Between Failures) is by looking at your current security practice and how you handle the initial indicators of compromise. We would start by looking at how long it takes for us to detect these events (MTTD), and determine how we react in those situations. If your detection time is long, answering why that is can be critical.
Are you seeing too many security alerts? Too many false positives? You may have "alert fatigue", which is where you are desensitized to the severity of various alerts by the sheer number of them. This can slow or dull reaction times to critical alerts, which are simply caught up in the noise of your daily cybersecurity alerts. A fix would be to analyze what you're reporting on, opposed to what you're automatically blocking. Do you need to report every security incident 20 times? There are ways to compress your alerting, for a consolidated security view.
Policy can be a big reason why you have so many alerts daily. If you are using out of the box configurations for your cybersecurity technologies, you likely aren't getting the best picture of what is an actual threat to your organization. You wouldn't drive a car off the lot without adjusting the mirrors or fixing the seat - why would it be any different for your Cybersecurity technology? Consider looking at how your policies are configured so you have an effective process and policy tuned to what your organization needs, and how often you need to be alerted to purely anomalous events.
The next question is, are you receiving too few alerts? Do you have security threats or are you not reacting quickly enough to the alerts you're seeing? As MTTD can indicate, many security threats go unnoticed for an extended period of time before they result in a data breach or network outage. Tune policies properly so you're seeing the actionable alerts, and not ignoring potential threats at the same time. Having too few alerts can mean your configuration is ignoring areas of vulnerability, and that can set up failure as well.
If you receive an alert in the middle of the night, are you responding to it? Or expecting to handle it in the morning the next day? Sometimes that window of time can be just long enough for an attacker to get a look at your IT Organization and set up a cascade of failures.
This is where London Security Solutions saves customers hundreds of thousands of dollars, by being on call when a breach occurs, or acting as a managed service provider who handles the threat from first detection. We have repeatedly acted as the first response to security threats, and reduced the time it takes to handle security events by having a highly trained, skilled, and experienced SOC team that stands watch 24 hours a day, 7 days a week, 365 days a year. While they are assisted and backed by an AI and ML driven threat intelligence engine, the true threat hunting and response are actually performed by humans. Our analysts become experts on your unique environment so they know when there’s an anomaly and can investigate and correlate data to ensure your network remains secure and can act when action needs to be taken, or alert you when additional steps may be required.
If you’re ready to see how London Security’s MDR can help reduce your MTTD & MTTR and increase Mean Time Before Failure, start with a risk-free 15-day FREE Proof of Value. Don’t take our word for it - see for yourself. Fill out the form below to get started.
As a note - this is part 3 of a 4 part series. If you don't want to wait for all the blogs to get posted, use the form below and we'll go over it with you.