Threat Modeling Again, STRIDE Mitigations

re: Threat Modeling Again, STRIDE Mitigations

Arno Schoedl — Thu, 06 Sep 2007 00:43:53 GMT

Hello Larry,

we recently switched to Authenticode to verify program updates that we downloaded automatically. Before, we used a proprietary private key authentication via CryptoAPI, with the self-issued certificate compiled into the program. But Authenticode certificates issued by Thawte or others expire every year or two, so instead of doing a binary compare of the certificate, we now have to use the organization string. To me, this seems to be quite prone to imposter attacks, basically someone going to Verisign pretending to be us by faking some documents. Any thoughts?

Arno

re: Threat Modeling Again, STRIDE Mitigations

Igor — Thu, 06 Sep 2007 08:57:12 GMT

Seriously, who cares?

Shame on your company Larry:

http://www.neowin.net/forum/index.php?showtopic=584427&hl=

This tool was of great help to admins of SOHO networks with slow Internet connections and now it is gone.

I already asked Raymond the same thing and now I am asking you -- do us a favor and please don't blog about security issues anymore. Your company obviously doesn't care if we update our Windows' with those latest patches or not.

re: Threat Modeling Again, STRIDE Mitigations

LarryOsterman — Thu, 06 Sep 2007 16:14:44 GMT

Igor, I care about this stuff passionately. And I blog about what I care about.

I have no idea what the deal is with autopatcher, and have no opinion one way or another.

re: Threat Modeling Again, STRIDE Mitigations

Nathan — Thu, 06 Sep 2007 16:48:39 GMT

Larry,

Will your follow-ups on STRIDE cover a bit deeper the mitigations ? One of our book-of-the-quarter choices was "19 deadly sins of Software Security". The authors really harped on some of the points you made (authentication, encryption, etc) saying: "Lots of folks say use it. The problem is everyone uses it wrong."

Meaning encryption in the wrong places, authentication that is spoofable etc. Just realizing the need is 10% of the battle. Correct implementation is where we earn our pay.

re: Threat Modeling Again, STRIDE Mitigations

LarryOsterman — Thu, 06 Sep 2007 20:12:52 GMT

A good point. If I get the bandwidth later on, I'll spend some time talking about that. I liked the 19 Deadly Sins book - IMHO it wasn't nearly as good as Writing Secure Code but it DID provide a good overview of the problem space.

You're right that a good mitigation is critically important and that a bad mitigation is sometimes worse than no mitigation.

Threat Modeling Again, What does STRIDE have to do with threat modeling?

Larry Osterman's WebLog — Fri, 07 Sep 2007 17:52:42 GMT

In my last couple of posts , I've talked about the STRIDE categories. As I mentioned, STRIDE provides

STRIDE chart

The Security Development Lifecycle — Wed, 12 Sep 2007 03:05:05 GMT

Adam Shostack here. I've been meaning to talk more about what I actually do, which is help the teams

Threat Modeling Again, Threat Modeling in Practice

Larry Osterman's WebLog — Wed, 19 Sep 2007 01:49:00 GMT

I've been writing a LOT about threat modeling recently but one of the things I haven't talked about is

Some final thoughts on Threat Modeling...

Larry Osterman's WebLog — Mon, 01 Oct 2007 19:54:09 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah,

Some final thoughts on Threat Modeling...

Noticias externas — Mon, 01 Oct 2007 19:56:01 GMT

I want to wrap up the threat modeling posts with a summary and some comments on the entire process. Yeah

re: Threat Modeling Again, STRIDE Mitigations

Thomas — Tue, 02 Oct 2007 00:13:51 GMT

(picking up from Schneier's blog, see URL)

""""Given that most windows users run as admin, this is hilarious."

If a user runs as an admin, they don't need to tamper with your data store - they can do anything that they want with the computer."""

I think I (unfairly) criticised the article for being tactical ("you might as well trust admin, cos if admin is compromised you've already lost") rather than strategic ("how can we get users to stop logging on as admin").

There were quite a few suggestions on using ACL's and admin privilege to make trust decisions. I'd be hesitant to assume that, jsut because something _looks_ secure, it is. Someone might be able to execute a limited privilege escalation to make data look trusted, and then in turn exploit this trust to further attack the system.

"""the threat modeling process I described helps to analyze security defects, not DRM breaches."""

How do they differ?

In both cases the attacker makes the system behave in a way it shouldn't. The same vulnerability that allows someone to breach the system to circumvent DRM may allow someone else to breach the system to compromise the users security; formatting bugs were just bugs until someone started using them to smash the stack.

"""I could have picked on the Apple .DMG file woes just as easily """

That's kind of my point: why pick on someone else's products?

In your article you even point out that, having no connection to the FireFox team, you've had to guess at some of the detail.

Wouldn't it make more sense to talk about an in-house vulnerability, where you (presumably) _could_ get access to the developers and make the article much more informative?

Again, I was (wrongly?) looking for a strategic, company wide approach. Dispassionately dissecting a Microsoft flaw would have given the article (and Microsoft's security push) more credibility. Instead, it just looks like one more FUD campaign...

re: Threat Modeling Again, STRIDE Mitigations

LarryOsterman — Tue, 02 Oct 2007 01:11:58 GMT

Thomas: The DRM team has their own set of threat models that are about DRM breaches. But a DRM breach won't generate an MSRC advisory (it might generate a WU download, but MSRC doesn't care about those). The threat modeling process I described is about analyzing the system to mitigate the security threats to a system.

In all honesty, I intentionally chose an example that only peripherally involved Microsoft to point out that this process is universal, and has benefits outside of Microsoft.

Microsoft has already done many articles disecting Microsoft flaws (Michael Howard has done several on the .ANI vulnerability, for example). But security is an industry problem.

re: Threat Modeling Again, STRIDE Mitigations

Thomas — Wed, 03 Oct 2007 02:17:26 GMT

To me, DRM is the ultimate security challenge: defending the system against the user. The attacker not only has full access to the system, they have the complete cooperation of the legitimate user (as they are the same person).

Excluding it from consideration feels like cheating.

Also, I assume that DRM places constraints on your design.

DRM might require you to accept/produce/keep a token to get permission to play something. This adds more entities, more boundaries, more data, more paths....

DRM may also also introduce time constraints, a whole new can of worms.

At the very least you have to evaluate your design in light of those constrains to make sure you don't break DRM.

I agree that security is an industry problem, though something about glass houses comes to mind...

Do you have links to the blogs/articles you mentioned?

re: Threat Modeling Again, STRIDE Mitigations

LarryOsterman — Wed, 03 Oct 2007 03:25:32 GMT

Thomas: Actually, for the Vista audio stack, DRM doesn't really affect the design at all. There are a couple of APIs added that allow the player to interrogate the state of the audio stack and that's about it.

The player itself is complicated by DRM, but not the rest of the multimedia playback infrastructure.