Threat Modeling

Microsoft ""BSPs"" require compliance with the Microsoft Security Development Lifecycle1 (SDL). What this means is that the entire BSP must undergo a Threat Model (TMD) and Code Review cycle. In summary, what SDL requires is:

1. Produce and reviewed a threat model for all BSP components. This effort is designed to identify Threats and highlight remediation for those threats.
2. Perform security code reviews to make sure threats and mitigations identified in the threat model (step #1) are implemented in code.
3. Reviewed applicable source files for adherence to PQD and Microsoft standards.

To assist with this effort, the following information is provided as an example implementation:
* Threat Modeling example. The attached Basic Stream Driver Threat Model will help you establish the right mindset and also give you an idea as to what the TMD should look like.

* The purpose of threat modeling is to assess and document the security risks that exist in the code, and take action to mitigate those risks. These threats range from very broad (a user with a USB device should not be able to gain control over the OS) to very specific (an application that passes a null buffer to a driver can fault/hang the system). The threats in a piece of code are entirely dependent on what that functionality that code provides.

* The steps that make up Microsoft’s threat modeling process provide a systematic approach to identifying and eliminating security risks.

* Install the SWI Threat Modeling tool. This is what will be used to create your TMD. It is a very useful tool and the help for this tool has a concise Threat Modeling primer as a bonus. The threat modeling tool is here

* Write the threat model. By reading through your source files, take note of any security threats that become apparent. Once you have identified the threat areas, complete the fundamental threat model:

*Data Flow Diagram (DFD). In short, the DFD is a picture that puts the component in context with the outside world. Always do the DFD first. Does the component receive data from another application or cross a process boundary? Does the component rely on data from the registry? Does the component access hardware? After constructing a DFD, you may find that a component has no external interaction, and should possibly be grouped with another component, or omitted from threat modeling.

* Entry point list. Does the component expose ""IOCTLs""? What external entry points are defined by the DLL? Do any of those entry points operate on embedded (in a struct) or external (from another process) pointers? List all entry points in the threat modeling tool as a guide.

* Threat list. The DFD will help in identifying the broader threats that exist in the component. The entry point list helps catch common errors such as null-pointer dereferencing and improperly protected ""IOCTLs"", which are common and can easily be mitigated with access checking and _try/_except. The threat list should identify all threats that the developer has considered, so that during review the others involved can add threats that may have been missed.

* Have a TM review session. Once you have completed the TMD, have a threat model review session scheduled. Typically invite list includes at least one other expert in the technology being modeled. Simple modules such as backlight may only require review over e-mail. Incorporate feedback from the threat model review: threats that were missed, entities missed on the data flow diagram, etc.

* Hold a security code review. Once the TM is finalized, it’s time to review the code with the TM in hand. The modeler should drive this review, but have at least one other expert present. Make sure that the mitigations listed for each threat is properly implemented, and look for anything that may have been missed.

* For example, for a driver that writes data to hardware, the data buffer should be traced from the entry point to where it is actually accessed. Along the way the reviewers should verify that access checks were performed, and if necessary, access was protected in _try/_except blocks.

* Open security bugs on missing mitigations.

* When all threats have been covered, ensure that bugs have been opened for anything found in the code review.

* Perform a PQD/Cleanup code review. The PQD/Cleanup review is listed last on this list, but can actually happen in parallel with threat model reviews. However, the feature should already be fully implemented and passing all LTK/CETK tests first.

* For device drivers, the PQD checklist should be filled out by the reviewer. This makes sure each driver exposes power handling interfaces, can handle suspend/resume, is properly architected between BSP/CSP, has configurable threat properties, etc; all of which add to the quality-level perceived by customers. If the code gets re-factored due to something missed in the PQD checklist, and this occurs after threat modeling was completed, be sure no new threats were introduced. Return to the threat model if necessary.

* For all code, perform final cleanup. This means making sure comments are not distracting, spaces were used instead of tabs with correct indentation, and no names, //TODOs or //FIXMEs appear in the sources file. This step is mainly for ‘fit and finish’.


* You are finished after an independent developer has code reviewed your cleanup and PQD changes.

At a minimum, all participants should understand the basics of the OS and how processes are laid out in memory, the difference between kernel/user mode, and how to use secure API’s like ""SetProcPermissions"", ""StrSafe"" functions, and ""MapCallerPtr"".

Attached documents that help explain the Security and Threat Modeling process are:
1. Threat Modeling Process for 3rd Party Drivers. A document from the internal Microsoft security team instructions for 3rd party ""OEMs"". Can be downloaded from here
2. OEM Threat Modeling Supplement. This is an abridged version of #1 which can be downloaded from here
3. Stream Interface Driver Threat Model. This is an example threat model that demonstrates a typical threat model. This sample can be downloaded from here

""1 See http://msdn.microsoft.com/security/sdl for details. ""

---

Go up to BSP Features
Go up to Big Book of BSP

Thank you for contributing to this BSP Wiki. To ensure your comments and concerns receive proper exposure, include bspwiki""@""microsoft"".""com when providing feedback or topical suggestions.

---