Mean Time to X (Detect, Alert, Respond) or MTTX metrics are frequently chosen when people want to determine a response system's ability to respond to an attack. This system will consist of tooling and people.
It is one of those cases where the gap between business needs and abilities is a chasm. If asked, most business service owners would say that MTTX should be measured in milliseconds as that is the time that an attack can take to go nuclear -- sure many attacks are long cycle in that they take weeks or even months to go from initial access to full attack, but once the attack moves to the later stages and begins exfiltrating data, or encrypting files, that most harmful portion of the attack would happen very rapidly.
When asking a response team what MTTX is reasonable, they will suggest some time measured in minutes. It takes time to get people analyzing the right thing and time for tooling to take necessary actions.
Clearly, this chasm can not be crossed by human agility alone. The approach that is needed is one that we often think about at ActZero -- it is core to our philosophy. The optimal approach is security-focused data analysis driving the decisions that are key to responding to these attacks. Instead of detecting an event, then waiting minutes to spool up an analyst, we continuously analyze data to determine when automated responses are safe to deploy. For many critical events, this means when a detection occurs, we determine if it is safe to quarantine the endpoint until the attack can be analyzed and remediated.
We have a variety of automated responses at our disposal including: process blocking, file quarantine, network quarantine, paging our SOC, or user notification. These are each applied differently depending on the type of detection.
Take for example the fairly complicated ransomware attack used in the Kaseya RMM attack. This attack involved exploiting Kaseya RMM and using it to spawn cmd.exe, which in turn was used to download and drop an older vulnerable copy of Windows Defender’s MsMpEng.exe, as well as the REvil encryptor file - Mpsvc.dll. In an unprotected environment, the attack would execute the Windows Defender MsMpEng.exe file, which would then load the malicious Mpsvc.dll file, resulting in files being encrypted.
In this case, ActZero’s process blocking would automatically terminate the spawned cmd.exe prior to the vulnerable copy of Windows Defender’s MsMpEng.exe or the malicious REvil encryptor file - Mpsvc.dll being dropped.
To explore ActZero’s automated response further, let’s consider the hypothetical cases where this malicious cmd.exe protection was not in place. With ActZero’s process blocking and file quarantine engaged, it would block MsMpEng.exe from loading the malicious REvil Mpsvc.dll file. And, if ActZero were deployed in NGAV mode, these files would also be quarantined automatically.
If we continue into this theoretical illustration of layered automated response, if for some reason, this attack continued and the Mpsvc.dll ransomware file began encrypting files, it would be blocked by our process-blocking automated response, and the endpoint would be network quarantined to ensure that no further damage was possible.
Each of these automated protection responses would be accompanied by notifications to the customer, and to our SOC of course.
Let’s move away from the clear-cut case of ransomware to a more situational case. The utilman attack is an attack often used to bypass the Windows login screen. It involves replacing utilman.exe with cmd.exe such that instead of requiring a user to login, the login prompt will give the person at the keyboard a command session to reset the user’s password, and thus access to the computer in an authenticated session.
Of course, ActZero has detection for this. The catch is that some legitimate administrators regularly use this to recover passwords for users. Without dwelling on the more robust ways an administrator could reset this user’s forgotten password and give them access to the endpoint, clearly, we can not prevent them from doing so. Nor can we determine if this attack event was done by an attacker or a legitimate administrator － we have to ask the administrator. So, we do just this － ask the admin if they meant to run this “attack.”
While these automated responses are demonstrably powerful in preventing attacks, if they are not well designed, they would be problematic in certain operating environments. Some customers may not want network quarantine on mission-critical servers for example. Because of this, we design per customer configuration into our automated responses.
Effective and safe automated responses to attack activity is another illustration of the value of the core ActZero strategy of pairing expert security engineers with seasoned data scientists to ensure data-driven decisions are applied where most effective.
For more information about the synergistic combination of security engineering and data science, check out our white paper The Hyperscale SOC and the Minds Behind It. Or, to see specific detections and responses in action, request a demo of our MDR service.