From the viewpoint of focusing test effort and resources, one of the most useful outputs from thread modelling is its picture of the product's Attack Surface. This is based on the set of places where vulnerabilities might be exposed, and in some sense, the "cross-sectional exposure" of each to attackers.
The most obvious of these places is the vicinity of the UI. However, many other weak spots can often be identified by modelling the data flows present. The full set of loci appearing on any attack surface will depend upon the nature of the product, but might include such items as:
- all UI controls;
- file entry points;
- registry entry points;
- database accesses;
- web interfaces;
- interprocess calls;
- remote process calls;
- networking ports;
A Word About Targeting
The significance of each depends not only on the nature of possible related vulnerabilities, but also on who can access each of these locations. For example, a TCP port might be sniffed by anyone, anywhere, while a named pipe may be accessible only to local administrators. That's what makes the term attack surface so apposite. Conceptually, the size of each site is multiplied by its accessibility, and the resulting areas summed into your security metrics.
Your time and resources are limited. Ideally, your test efforts should focus preferentially on the larger areas of this surface. That means knowing how to identify, measure and compare vulnerability exposures. Practice and real-world experience are the best teachers of these skills.
Exercise
Take a product you have worked on before, or are otherwise familiar with. Draw a diagram, showing all the points where data can cross "trust boundaries". Then for each of these, run down the STRIDE list, looking for potential vulnerabilities of each type:
Do that, and you've done (an admittedly quick-and-dirty) threat modelling. This is a hugely valuable process. Often just thinking about one particular vulnerability or threat will set you off on a voyage of discovery to more. Just remember, that's also exactly what your attackers are doing.
For Example...
We recently brainstormed the login UI of our flagship product, looking for credible spoofing, tampering, repudiation and elevation of privilege threats. But what we found instead, via the security "lock-out" feature (where a user's login would be disabled after three incorrect passwords), was a nifty denial of service attack. With that feature enabled, all I have to do is guess your password incorrectly three times (assuming your login name is in-the-clear), and presto, you are locked out: DoS, QED.
In mitigation: "But all I have to do is ask my administrator to reinstate me." Sure, your administrator. When she gets back from that meeting. By the way, what's her login name? It's "admin", isn't it? And that can't be changed, right? Wow, we're not exactly making it hard to guess!
SDL Resources (from MSDN Magazine Security Briefs)
Threat Models Improve Your Security Process - Michael HowardPreviously:
Reinvigorate your Threat Modeling Process - Adam Shostack
Part 1 - Overview
Part 2 - Lab Work
No comments:
Post a Comment