Mean Time to Breach and Security Planning

The concept of risk acceptance forms the foundation for business decisions and budgeting of information technology security. If you understand the risk, accept that incidents could and will occur, the amount of resources and money spent to minimize threats becomes justifiable and quantifiable. Spending more money and resources, however, does not necessarily mean that the risks will linearly, or even exponentially, decrease. There is an inflection point where decisions are made and you may state, “I can accept that risk,” or “I do not have enough budget to do so.” There is, however, another philosophy to help offset resources and budget, and it is called the Mean Time to Breach.

Similar to MTTR (Mean Time to Repair) or MTBF (Mean Time Between Failures), the concept documents the average time it takes a threat actor to breach the environment. If the known risks are critical, and the exploitation method trivial, the MTTB (Mean Time To Breach) is very small. This means that any detection and prevention solutions in your security arsenal will have to alert quickly, and teams will have to respond in an extremely timely manner to mitigate the threat. If the risks are difficult, complex to exploit, but known, then the MTTB should increase.

Controls can be placed around the known risks and teams have a little more luxury, in terms of time, to respond and mitigate the threat. If security teams can quantify the risks in terms of criticality and ease of exploitation, then MTTB is something that can be used to help in cost and risk assessments. The problem is, that is not always a trivial task to accomplish due to complex architectures and unknown risks—organizations have plenty of them. While vulnerability management solutions can help build some of that foundation, another empirical approach may help as well; penetration testing.

Consider how you perform penetration testing on your organization today. Do you employ red test teams, hire outside consultants, or even look for the cream of the crop in the form of hacker mercenaries who get paid bounties based on how deep they can penetrate your organization (the latter is a relatively new contractual approach that has incentives for ethical hackers based on their findings).

For all methods, results can be measured in the form of a MTTB and they should report a timeline based on each successful or thwarted attempt in their mission. Why? Because a successful mitigation strategy can map to these attacks as if they were real, ensure controls are in place to stop movement and malware, and that alarms, prevention, and workflow are responding at each step to increase the MTTB to as much as possible. This ensures that security teams can be notified and react to the threat in a timely manner versus a quick smash and run scenario. The end goal, make the MTTB as long as possible with as many alarms necessary for security teams to understand the breach and to respond accordingly. This approach balances a real-world attack “test” with the known risks covered during vulnerability and configuration assessments.

An extended MTTB with security alarms is desirable and replicable using penetrating testing and can help determine how much money is spent based on a successful attack vector to mitigate the threat. Some threats, are just too costly to mitigate, which means you should make sure they are extremely difficult to exploit. This category could include end-of-life servers and applications with known and unpatchable vulnerabilities.

While MTTB is a relatively new cybersecurity term, its meaning has been well established and is generally thought of in terms of when detection (and a breach) has actually occurred within an organization. It should also be considered from the opposite perspective. For instance--how long did it take a threat actor to successfully breach the environment, and could my business detect the steps and techniques they used along the way? If I can detect the intrusion, and make the MTTB relatively long, then I have found a good balance for risk assessments, budget, and future security spending that leverages my existing solutions and time to respond.

We should all assume a breach will happen. Just make sure you have plenty of time to detect and respond to it. And using this concept as a cost, risk, and response measurement can help.