Gathering at the local .Net User Group
Yesterday, September 17th, 2014, I attended a magistral lecture by Dana Epp at the .Net BC User group entitled "Making Threat Modeling Fun and Easy". During the presentation Dana explained the STRIDE Threat Model in detail and associated every term of the acronym with real live examples and stories about how data and services have been compromised. Scary stuff!
STRIDE
Although you can read about this paradigm in one of the references that I provide in this note I would like to mention in very few words what this means:S | Spoofing Identity |
T | Tampering with Data |
R | Repudiation |
I | Information Disclosure |
D | Denial of Service |
E | Elevation of Privilege |
Data Flow Diagrams to Identify Risks
He also explained through Data Flow Diagrams how our data could be at risk every time it crosses a boundary and that mitigation of these risks must be taken into account seriously at design time and not after the fact.
Microsoft provides software engineers with a free tool to create Data Flow Diagrams diagrams to create a model of the system and once the graph is created the tool will identify each risk and mark them as "High" risk until it is reviewed. While reviewing the result of the analysis of the tool assessment engineers can mitigate these risks by addressing these vulnerabilities in their design. In the case that we are satisfied by the mitigation the risk then the item could be marked as "mitigated".
We would then design and implement, and unit test, the system making sure that the identified risks have been properly mitigated in the implementation of the system. The unit test will prove that the implementation works but also need to exploit these boundaries and validate that threats have been mitigated.
But we are not done yet! QA Engineers will then base their test case design on the threat model of the system and try to validate the mitigation and obliterate the system.
Microsoft provides software engineers with a free tool to create Data Flow Diagrams diagrams to create a model of the system and once the graph is created the tool will identify each risk and mark them as "High" risk until it is reviewed. While reviewing the result of the analysis of the tool assessment engineers can mitigate these risks by addressing these vulnerabilities in their design. In the case that we are satisfied by the mitigation the risk then the item could be marked as "mitigated".
| Microsoft Threat Modeling Tool 2014 - Analysis View |
But we are not done yet! QA Engineers will then base their test case design on the threat model of the system and try to validate the mitigation and obliterate the system.
After Dana finished his presentation we had a little break followed by creating two big working groups where attendants discussed the learned concepts using a risk analysis game card. This activity was refreshing and sometimes I wish we could do more of these sessions because we get to exchange ideas and thoughts... we learn more this way.
I rate the meeting as very top quality, delivered by one of our own, Dana, who was supported by one of his colleagues. Some times I wonder the reason we do not get higher attendance to these events when the entrance is always free, it has been like that for a number of years thanks to the user group sponsors.
This meeting was graciously sponsored by BCIT and the Burnaby office of TekSystems. The references provided bellow will get you introduced to the main concepts of the meeting and will get you going using the Threat Modeling Tool.
"If you wish to make an apple pie from scratch, you must first invent the universe"
Carl SaganReferences:
- Microsoft Threat Modeling Tool 2014: This is the same threat modeling tool used at Microsoft and it is free!
- Definition of the STRIDE Threat Model. MSDN article where the terminology is defined.
- Introducing Microsoft Threat Modeling Tool 2014. In this article the reader is introduced to the paradigm of how to use the Threat Modeling Tool during the Security Development Lifecycle (SDL).
Cool! Threat modeling captures an understanding of what’s important to the business, details of an application's underlying technology, and relevant attack vectors. In our experience, the most time-efficient approach is to gather the stakeholders for all three factors into a room to discuss, business/application/product owners (often known amongst technology workers as "the business"), architects and/or lead developers, and an application security subject matter expert. TME, therefore, is fundamentally group-based. It helps build buy-in from all three stakeholders and decreases resistance to decisions later on whether or not to include security controls within the application. We recommend scheduling a four hour meeting for this discussion. If scheduling constraints make this impractical then try to arrange the longest meeting that you can – in many cases, this may be one hour.
ReplyDeleteThanks For sharing this Superb article.I use this Article to show my assignment in college.it is useful For me Great Work. Sacramento photography
ReplyDeleteI went over this website and I believe you have a lot of wonderful information, saved to my bookmarks how to get more instagram likes reddit
ReplyDeleteThis is my first time i visit here. I found so many interesting stuff in your blog especially its discussion. From the tons of comments on your articles, I guess I am not the only one having all the enjoyment here keep up the good work microsoft office 2016 free download full version
ReplyDelete