Threat Modeling of an Assembly

Question

In my scenario, I have a server-side assembly that is used by externally-facing services. This assembly basically interacts with a SQL Server database, relying on the calling service to do authentication and authorization. In working through the SDL Threat Modeling Tool, it seems reasonable to me that most/all of the threats I can certify as either being handled by someone else (callers) or that it is within a trust boundary.

 

I want to make sure I am not falling into a trap or succumbing to laziness by pushing off these concerns.

 

Is it common to threat model individual DLLs (that exist behind web services) and are these sorts of certifications common in this scenario?

Answer 1

Depending on the complexity of the individual DLL's and what functionality they provide, you may or may not model them seperately. In this case, it seems that you are assuming that the authentication and authorization concerns are handled by the calling service and that's where most of interesting threats are. When you think about the assembly itself, is performing any operation that can be split into more than one function? For example, part of the assembly does read, write on records, part of it does logging and auditing related tasks, if yes, you should consider representing this assembly as 2 processes and going deeper, else, you can consider one data flow between this assembly and data store.

---

Ashish Popli