A new way to threat model quickly?
So I've been experimenting with threat modeling, starting with the traditional methods like STRIDE and PASTA, building data flow diagrams, and wrapping attacker activities around them.
But I'm not really a fan of them. They're heavy and bulky, they don't lend themselves to rapid prototyping and modification. I did some thinking and came up with the following things I wanted to accomplish:
I've been playing around with a new way, and I decided on a sort of simplistic kanban/post-it note/idea graph system. But how will I know if it's any good or if it works? Well, try it out, of course.
I did it as a one-hour meeting last week, at the last blockchain security meeting, focused on crypto wallet security.
And you know what? We discovered some new and interesting things, and I found a new way to explain a security concept that I previously didn't have a good way to talk about. So first a taste, an intentionally compressed copy of the data so when I mention what we talked about and the colors of the post-its, it'll make sense. Don't worry, the full-sized image is at the end of the article.
First off, the high-level view:
White - meta information we discovered halfway through the meetingGreen - what the user/defender/victim wantsRed - what the attacker wantsOrange - parts of the landscapeLight blue - specific attacksPurple - defences/mitigations/responses to attackers
We started with two basic statements about what the user wants on green (protecting their private keys and having data backups) and two about what attackers want on red (access to private keys, backdooring the software used by users). We expanded both of these as we went through the exercise. So a lesson learned: threat modeling can be very nonlinear; we skipped back and forth several times. I think this is critical as you'll gain insights about previous things as you move forwards, so going back to add or refine them and then move forwards, possibly in new directions, is a powerful tool.
Another important lesson: the meta information; halfway through, we started to wonder, did this threat model of user-managed crypto wallets also apply to custodial wallets (e.g. exchanges)? After some discussion, we decided that yes, it did. So if you can build a threat model and then apply it to more than one thing, well, that's a two-for-one sale, value for your time and effort.
So once we had the basics of what the user and attacker wanted, I thought covering the landscape (on orange) a bit might help to give some context. In this specific case, it wasn't overly helpful, but it's also a single data point, so who knows? We then went into the attacks (light blue), and this is where things got interesting. I was aware of and suggested the DNS hijacking of exchanges/etc, and someone else pointed out that… well… why bother? Just clone the site at a similar URL and advertise it on Twitter or email the user, for example. Good point.
We then also went into defenses, and this is where things got really interesting. After some back and forth we got to biometrics (e.g. for FIDO authentication, local access, etc.) and started down an interesting rabbit hole. We quickly realized that biometrics have two interesting properties for user authentication: they're pretty easy in most cases, especially on modern mobile devices (Apple FaceID works shockingly well, even when I'm wearing a half face respirator for example), and you can't easily be phished because (drum roll) you can't really proxy the data.
So this is the third important lesson: different kinds of authentication credentials have varying abilities to be proxied. I don't just mean technically proxied like through a web proxy, but also in the real world, e.g. a username and password can be written down on a piece of paper and shared or spoken aloud over the phone to someone else. This ability to proxy data is something attackers rely on, e.g. by phoning you and convincing you to give up your password or by trucking you into typing it into a phishing site (https://blog.cloudflare.com/2022-07-sms-phishing-attacks/). This is one reason SMS codes and TOTP (the 6-digit numbers that change every minute) are not great for 2FA/MFA, you can still be tricked into telling someone or typing it into an attacker-controlled website.
This is one area where biometrics shine, especially when used with FIDO (https://fidoalliance.org/specs/biometric/requirements/). Even if I wanted to, I can't easily write down my face; even if I send you a high-resolution picture of it, you can't currently use that data to fake out the sensor on my phone (and hopefully, the phones sensors/software improve faster than the attacks). Combine this with the fact that biometrics typically don't change much or often (I have cut my thumb bad enough that I had to re-register it on my phone while it was healing), and you have a great combination of ease of use with security.
For context: I've been thinking about and dealing with website login/local application login/phone security for a solid decade now, and I still have new things to learn and a new way to explain what I know more correctly and concisely. So based on my single datum point, I won't call my new method a success yet, but I think it shows promise, and I plan to repeat it. If you're interested, you can join our calls, the easiest way is just to email me ([email protected]) and I can add you to the invite).
And as promised the full threat model (https://miro.com/app/board/uXjVPe1PDL4=/?share_link_id=88177736419)