Attack Complexity and Assurance Levels

 One of the challenging aspects of defining a security strategy is to define how complex an attack you need to defend against. Over the years, I've seen far too many organizations that are trying to build complex reverse engineering capabilities to dissect potential malware, while leaving 85% or more of their environment unpatched, not implementing strong 2-factor authentication, or failing to perform basic hardening. Security is very often mostly about doing the basics well. If you cannot tell the board that you know who all the global root users are - including the ones that could become global root easily - implementing a complex data loss prevention solution is probably not the item that should be at the top of your list.

One of the challenges in security is thinking through the threat environment we are facing. Typically, we can never measure anything with absolute certainty in security, and there is opinion in everything, but one thing that seems to work is bucketing things into relatively coarse buckets. It's much easier to say that the risk of something is high, medium, or low, rather than 73% probability. This same scale works well for numerous types of things we need to measure. 

As part of the foregoing multi-factor solution, there was an undercurrent, and sometimes an overt current, of attack complexity in compromising a factor. I decided it may be worth making my thinking on this a little more clear. As part of the analysis, I've been thinking about the ease with which an attacker could compromise a factor, given certain conditions. Here is an example of the analysis, relating to three different factors.

This table measures the complexity of attacking a multi-factor authentication system to establish an independent session (as opposed to hijacking an existing user session) given certain pre-conditions and when certain factors are used. These kinds of tables can be really useful and the simple scale used here of simple, moderate, high, and not possible, is easy enough to use and still provides value even though it does not measure anything with 100% accuracy.Personally, I like four point scales. Others use 5, or 3. More than that generally is too much though. 

To illustrate the use of this, let's say that the attacker has compromised the computer or device used to establish the session, or even the device used to generate the token code or the approval notification. In this case, it is relatively easy for the attacker to capture the entire session, or to obtain the TOTP codes, or to approve the push notification. If I control your phone, I can click the "Do you want to approve this login" button just as easily as you can. 

However, with WebAuthn, doing this is harder because WebAuthn, typically, would require some form of action from the user. Even with root access on the computer, the attacker could not perform the user verification in WebAuthn because that requires physically interacting with the device. Consequently, push approvals and TOTP provides a low level of assurance against a compromised platform, while WebAuthn provides a very high level of assurance. The reason it is possible still for WebAuthn to be fooled in this case is because it is possible for the user to accidentally activate the system, and for the malware to lie in wait for this to happen. 

On the other end of the spectrum, phishing WebAuthn tokens, without a compromised platform or application, is not possible unless the client application is flawed. On the other hand, phishing push approvals is very simple. If you are an attacker and you want a user to do something, all you really need to do is ask. It doesn't really matter how much anti-phishing training we give people, the pressures we put them under to do their job, and the erratic nature of the technology we give them, makes it nearly impossible for the average end user to successfully tell the trustworthy thing from the malicious thing, especially in the absence of the trustworthy thing to compare with at the time.