Delen via

Threat Modeling again. Drawing the diagram.

  • Artikel

In my last post, I listed off some of the elements that make up a threat model.  Now that we have a common vocabulary that can be used to describe the names and types of the elements, let's see what we can do with it.

For this series, I'm going to use an API that's near and dear to my heart: PlaySound.

The nice thing about PlaySound is that it's a relatively simple API, but it's complex enough that it can demonstrate many of the characteristics of threat modeling.

So how do we go about drawing the whiteboard diagram for PlaySound?

First off, you need to characterize the data flows associated with the API.  I often find it helps to describe the design of your component to someone - for some reason, it helps me understand the data flow if I explain it to someone (I can't explain why, but I know it does).

For PlaySound, my description was something like:

"The PlaySound API takes as input a string which represents either a WAV filename or an alias.  If the input is an alias, the PlaySound API retrieves data from the registry under HKCU to convert the alias into a filename.  Once the filename is determined, the PlaySound API opens the WAV file specified and reads the two relevant pieces from the file: the WAVEFORMATEX that defines the type of data in the file and the actual audio data.  It then hands that data to the audio rendering APIs."

Given that description, what elements are going to appear in the diagram?  Well, obviously the PlaySound API itself.  In addition, you're going to have the .WAV file, HKCU, the audio playback APIs.  You'll also need one other element that's not immediately obvious - the application that invokes PlaySound. 

 

Here's what it looks like (I drew this in Visio, obviously you could use any tool to draw it (I know one group that literally draws their diagrams on the whiteboard then takes a picture of it with a cell phone camera and then pastes the picture into a Word document)):

image

All the elements I called out in my description above are present.  As I said above, the application calling the API is modeled as an external element (because it is outside your control).  Similarly, the audio playback APIs (and there may be more than one of them - it doesn't matter to this threat model) are modeled as external elements because you don't control them either. 

The WAV file and the registry are separate data stores, and PlaySound is a process sitting in the middle of it.  Remember that when you're drawing your diagram, a "process" isn't the same thing as a WIn32 process, instead it's a piece of code that processes data.  Once you've got your elements, you just need to add the data flows and trust boundaries and you're done with the diagram.

It's not obvious from the picture, but the dataflows between "WAV file" and "PlaySound" all flow from "WAV file" to "PlaySound" - that's because we don't ever write data into the file, we only read it. Similarly, since we don't write data into HKCU, there's no data flow into HKCU.

One key thing to notice is that this diagram is significantly simpler than the actual implementation of PlaySound.  It doesn't include lots of the options that PlaySound supports (like SND_ASYNC, SND_MEMORY or SND_RESOURCE).  This is quite intentional because those options don't change the results of the threat modeling (I'll spend a bit of time talking about this later).

 

You'll note that I've chosen to inserted trust boundaries between the WAV file, the registry and the application, but I don't have a trust boundary between PlaySound and the audio playback APIs.

The reasons for this are:

  • For the Application, you have no way of knowing where the data contained in the "PlaySound Command" comes from.  It might have been read from the internet or other untrusted source, so you have to assume that that data is untrusted.
  • For WAV file, the same rules apply - you have no way of knowing where the contents of that file came from, so you need to treat the contents as untrusted.
  • The trust boundary between "HKCU Sound Aliases" and "PlaySound" exists because (a) as a matter of general purpose, you shouldn't trust data from a data store unless you have some way of assuming it's trusted (if the ACL on the data store prevents anyone but an admin from writing to the store, it's probably safe to trust it, for example), and (b) because PlaySound is such a common API, it has some use scenarios that involve it being called in an elevated context.
  • I don't have a trust boundary between PlaySound and the playback APIs because the playback APIs execute at the same trust level as PlaySound.  It's possible that the playback APIs might invoke elevated components but that's an issue for the playback APIs threat model, not the PlaySound threat model.

That last point is important.  When I'm doing a threat for a component, I usually don't bother to put a trust boundary between my component and data flowing out of my component.  That's because I trust that my code produces correct data.  On the other hand, the downstream component often can't trust the upstream component (so the Audio Playback APIs can't trust the WAV file Data that is provided by PlaySound).

Next: STRIDE.

Comments

  • Anonymous
    August 31, 2007
    The fact that audio playback APIs are left so fuzzy leaves me wondering if there's a piece missing from this diagram that's still relevant to PlaySound itself. On what basis does PlaySound decide which API to use? Since that decision is presumably driven by some kind of external factor, it sounds like that piece of data is on the other side of a trust boundary. Could PlaySound be attacked by trying to persuade it to use a different playback API - which (for the purposes of this diagram) PlaySound treats as completely trusted...

  • Anonymous
    August 31, 2007
    Stuart, that's only if Playsound can be configured to use different playback APIs.  Since it doesn't (it currently only uses the waveOutXxx APIs), I didn't include it. In the future, PlaySound might be changed to use a different set of APIs, that's why I left it ambiguous.

  • Anonymous
    August 31, 2007
    Btw, PlaySound treats the audio APIs as totally trusted is because they're running in-proc. In general, you treat code that run in the same process as you as being fully trusted - after all, there's nothing that this code could do that would compromise the machine/process.

  • Anonymous
    August 31, 2007
    Fair enough :) Am I right that if it was possible to configure which API was used, then the source of that configuration should appear on the diagram?

  • Anonymous
    August 31, 2007
    Stuart: Possibly.  It depends on the mechanism used to determine the output. For instance, consider what would happen if PlaySound was augmented to play WMA files (NOTE: 'm explicitly not saying that's going to happen, it's just an example that would involve using multiple render paths).  In that case, we'd rename "WAV file" in the diagram to "Audio file" and we'd add a new external interactor "Media Foundation Playback APIs" and have data flows going to that external interactor.

  • Anonymous
    August 31, 2007
    "[...] Here's what it looks like (I drew this in Visio, obviously you could use any tool to draw it (I know one group that literally draws their diagrams on the whiteboard then takes a picture of it with a cell phone camera and then pastes the picture into a Word document)) [...]" I use to draw on black- or white- boards or paper a lot. I don't always take pictures of those, because most of the times they are not meant to be shared. But I certainly would if I had to share those diagrams. I remember at least one time when I really did that (take a picture of) a drawing a customer made on a blackboard, to "take note" of what he explained to me, so that I could take his explanation with me and do some background-thinking about his architecture....

  • Anonymous
    August 31, 2007
    I'm not a programmer, but couldn't help noticing that one block is missing: DRM. The article talks about trust and relations and this was not mentioned (i hope it would be in the next article in the series, maybe). I think ( I'm not sure, and don't have any links at hand, and I think random googling would be pointles due to credibility of the sources ) that protected path is mandatory for HD playback on certified devices, including Vista ( or only Vista 64bit ? ) - proscribed by the consortium that invented HD-DVD or Bluray or both (again, the text between the asterisks is from memory and very innacurate, but it was all over the web for quite some time and is often quoted. So, any thoughts on this? I realize Larry might be bound by NDAs and similar, and I wouldn't mind if he doesn't respond or deletes this post, but I would be happy if anyone sheds some light on this directly from the source. :) Dan

  • Anonymous
    September 02, 2007
    The comment has been removed

  • Anonymous
    September 02, 2007
    "I know one group that literally draws their diagrams on the whiteboard then takes a picture of it with a cell phone camera and then pastes the picture into a Word document". Larry, this is actually recommended in the much acclaimed book "Applying UML and Patterns" by Craig Larman. I think it makes sense, too - if you draw well enough on the board and the picture is good, it can be added to a document.

  • Anonymous
    September 03, 2007
    Dan: DRM?  Why would DRM matter?  There's no DRM involved in playing WAV files.  Heck, the audio engine threat model diagram doesn't include DRM either, because the DRM system doesn't functionally change the data flow for the audio system. Threat modeling is about modeling data flow through a system.  It's not about describing all the features and possible features of a system.

  • Anonymous
    September 10, 2007
    As I mentioned the other day , we had three huge big realizations as we've been doing more and more threat

  • Anonymous
    September 10, 2007
    As I mentioned the other day , we had three huge big realizations as we've been doing more and more

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

  • Anonymous
    September 18, 2007
    I've been writing a LOT about threat modeling recently but one of the things I haven't talked about is

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

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