1

In MS SDL Threat Modeling, there is an External Interactor and Process. While the meaning clearly shows a difference between them, when threat modeling, one can't really threat model an external interactor as it impossible to enforce anything on it.

So why do we need an external interactor? In case we can analyze its threat and make assumptions and plan solutions for it, why/what is the difference from Process?

user20259
  • 155
  • 5

1 Answers1

1

We differentiate so that it's easy to know what's in scope of the threat model and what's out of scope.

An external interactor is something that the component(s) we are modeling interact with, but which we do not want to cover in this threat model. A process in a threat model represents a component (or collection of components) that we do want to cover. When someone looks at your diagram, they'll very quickly know what's in scope and what's out of scope if you use these two denotations.

For example, if we are modeling a web browser and that browser does DNS lookups, we may not be interested in modeling the DNS server. As such, we can denote the DNS server as an external interactor. However, we are interested in the behavior of the web browser, so we denote the browser as a process.

We need external interactors because they provide input to the component that we are modeling. In the case of the web browser, we are not interested in modeling the web server, but we do need to ensure that the web browser properly handles data received from the DNS server - for example, DNS names with 64 characters in a (sub)domain (between two dots) have historically caused browsers to crash. If we leave the DNS server out of the diagram, then we are also leaving the inputs from the DNS server into the web browser off the diagram. In the case where we are modeling a complex server application, and the client application is out of scope, if we leave the client application off the model then we miss the opportunity to discuss authentication and authorization controls around the client-server interaction.

We also need external interactors because they receive output from the component we are modeling. If we leave the output off the model, then we lose the opportunity to discuss the content of these outputs, and that they are correct.

atk
  • 2,426
  • 16
  • 16
  • many thanks for the answer, still this means that we can only have assumptions or configuration recommendation. Many times as well we will just need to trust it. Am I correct? – user20259 Jul 18 '13 at 08:28
  • 1
    When naming something an external interactor, you're placing it's internal workings out of scope. This does not mean that your application should automatically trust the external interactor. Instead, it means that the internal details of the interactor are out of scope. For example, your process stills need to authenticate the interactor and you still need to authenticate to the interactor. – atk Jul 18 '13 at 12:21
  • You can also still find flaws in the interaction with the interactor that can only be fixed with the help of the interactor's manufacturer. Example: the communication protocol is cleartext. You can fix your application to wrap it in SSL, but you need the help of the interactor's manufacturer to support SSL as well. You then can work with the vendor to fix their software, consider other vendors' software, consider custom applications, consider dropping the feature. – atk Jul 18 '13 at 12:23
  • 1
    What you're really saying when you mark something an external interactor is "I will investigate this part of the data flow no deeper than the data flows with this element. If there are additional data flows that this element makes on which it depends, those will not be discussed during this threat model. However, security considerations of the direct interactions between the processes in the application and the external interactor will be covered" – atk Jul 18 '13 at 12:25