Ms sdl threat modeling tool

Paul brings out a print-out of a diagram that he's already made from the threat model tool's "Diagrams only" report, shown in Figure 3. It looks pretty simple, but can you walk me through what the different shapes mean? He's sending commands to our Web server—the circle is any running code, and the arrow gives us the direction of communication. The Web server is consulting a database, which, just as with anywhere we store data, is two parallel lines. The system is called a data flow diagram DFD.

There's a good Wikipedia article on DFDs. The only bit that's not covered there is these trust boundary dotted lines between where different people are in control. For example, you know the IT pros require that we use their Active Directory system for logon information, and so the Active Directory is shown as outside our control.

When the tool starts, the diagram screen is displayed. Even though this was his first time, he was comfortable because the validator on the left gave him feedback, based on his experience using threat modeling as part of the SDL.

As he found himself drawing more complexity, he added additional details by right-clicking on the context folder in the upper- right and was able to create a complex, layered diagram. Paul was a little hesitant when he opened the Analyze screen see Figure 5. There was a long list of threats there—where did they all come from? Some security experts like to chase after the hacker first because the chase itself can be fun. I think it makes sense to start securing your house by making sure each door and window has some sort of lock on it, and only then wondering about an alarm system.

He read at the top of the screen that "database" is a data store, therefore subject to tampering, information disclosure, and denial of service threats. As he read down, the questions helped him think about how people might tamper with the data, and he realized that no one had specified who was able to connect to the database.

A whiteboard diagram and some simple rules revealed the first threat! Score one for threat modeling. A few minutes of discussion led to a realization that they needed to think about access control and roles. Paul filled in some quick notes in two threats. The first note said "No access control plan. The second note said "Access control plan requires a role list.

Ricardo: Hi Cristina, I worked on the threat model diagram and wanted to make sure we got the details right. Can you help me look it over? Cristina: Absolutely. Ricardo opens the tool and shares his screen with Cristina.

Cristina: Ok, looks straightforward, but can you walk me through it? Ricardo: Sure! Here is the breakdown:. The Threat Modeling Tool allows users to specify trust boundaries, indicated by the red dotted lines, to show where different entities are in control.

For example, IT administrators require an Active Directory system for authentication purposes, so the Active Directory is outside of their control. The idea is that software comes under a predictable set of threats, which can be found using these 6 categories. This approach is like securing your house by ensuring each door and window has a locking mechanism in place before adding an alarm system or chasing after the thief. The generated threat helps him understand potential design flaws. The description made him realize the importance of adding an authentication mechanism to prevent users from being spoofed, revealing the first threat to be worked on.

A few minutes into the discussion with Cristina, they understood the importance of implementing access control and roles. Ricardo filled in some quick notes to make sure these were implemented.

As Ricardo went into the threats under Information Disclosure, he realized the access control plan required some read-only accounts for audit and report generation.

He wondered whether this should be a new threat, but the mitigations were the same, so he noted the threat accordingly. He also thought about information disclosure a bit more and realized that the backup tapes were going to need encryption, a job for the operations team.

Mitigating threats. Validating that threats have been mitigated. Threat modeling should be part of your routine development lifecycle, enabling you to progressively refine your threat model and further reduce risk.

Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful? Please rate your experience Yes No. Any additional feedback?