1
2
3
4
This presentation isn t intended to be comprehensive, but hopefully we ll expose you to some new options or new ways of thinking about Threat Modeling. 5
Security people don t all agree on the definitions for Risk, Threat, Vulnerability or what Risk Management, Threat Management and Threat Modeling are. These are my definitions. Another way of describing Risk Management is Information Security Program. 6
7
Threat Models are done primarily for the benefit of the development team. They are used to address possible issues in the design to prevent vulnerabilities from being introduced. There is a lot of information out there on Threat Modeling and a lot of different views and approaches. I encourage you to search the web and read as many of the different views on Threat Modeling as you can. I m going to share with you the names of some products that can help in this area, I will show you one particular product I really like, and will end with a demonstration of how to add threat modeling activities into standard UML model-driven design with common tools. 8
Regardless of the specific methodology employed or tools used, these are basic activities that should be part of a complete Threat Modeling process. 9
Web systems like Archer & Rsam Graphical systems like MS Threat Modeling Tool, MyAppSecurity Threat Modeler, Prevari Technology Risk Manager 10
You can produce attack trees with many common diagramming tools like Visio, or Mind Mapping tools like FreeMind. The root of the tree is one specific type of compromise and the branches and nodes of the tree list all the possible ways you can think of to perform the compromise. 11
Whatever approach you use to create a Threat Model, you probably want to have some method of ranking the severity of a given threat. This way you can determine how to prioritize resolution. 12
STRIDE describes the type of vulnerability, DREAD describes the level of risk 13
14
Minimal, Low, Moderate, High, Critical or 1-25 Probability: Best Guess. One of the problems with this approach. 15
There are other systems out there like this one. The elements are different but the concept is the same. For each threat, each element gets a score and they are added up, not always taking the average. 16
17
18
Mature as in its been around for many years and there have been many releases. Not so mature, in my opinion, in terms of functionality. 19
The tool requires the completion of 3 tasks before a completed threat model can be turned into a report. The tasks are shown at the bottom left. The first task consists of drawing a basic diagram of the system to be evaluated. MS has gone for the ultra-simplified approach to system modeling, as you can see here. The only elements that can be depicted in the diagram are the ones shown in the stencil. This type of diagram is called a Data Flow Diagram (DFD). 20
The 2 nd task, which MS calls analysis requires certifying that either no issues exist for each STRIDE element or documenting the ones that do. In this app, analysis is really done by the user. They supply a library of common threats, but not common impacts, controls, etc.???? 21
The 3 rd task is to document things that are not directly part of the application but that affect it. 22
The final task performs the actual analysis by creating reports listing all of the issues and any mitigating controls that have been documented. 23
24
This modeling application takes a more friendly and visually pleasing approach. Each function has its own icon as opposed to TMT where every function has the same icon. The app comes with a library of pre-defined icons/functions and allows the user to create their own. There are pre-made templates and icon/function sets for different types of apps such as Banking, ecommerce, Social, etc. Due to time constraints I cannot show a complete model or flow through the application, but I do want to show a few elements of the app and a model to give you an idea of how this works. 25
As previously mentioned, one key ingredient for a good threat modeling application is that it must have a library of (at least) common threats, mitigating controls, & data elements. The controls and classifications of data elements should be drawn from organization security policies, which are represented in this application as Rules. This application, like others in the space also works off of a database of common questions that the user answers to determine which threats exist based on implemented functionality and presence or not of required mitigating controls. This application comes with an extensive library, and can be completely customized. 26
When you start to create a Threat Model in this app, one of the first things you do is indicate which data elements the system uses. The available data elements are predefined in the library, along with their data classification, per organizational security policy. 27
Continue building the model by answering questions about the controls to be implemented in the system. Questions come from the library and serve to enforce policy. The answers are used as inputs to the threat model. 28
A further step involves indicating which data elements are used by each specific component. In this screenshot User Name and Password are assigned to the Login component. 29
Once a component is defined with its data elements and technical controls, a list of applicable rules/policies gets added to the properties of the component. This screenshot shows rules/policies to apply to the Login component. 30
Once the model is complete, you can use different views to look at the risks from different perspectives. This screenshot shows only components susceptible to SQL Injection. 31
This view shows all threats for one specific component (Login) along with their current risk level. The Status and Comments field are used by developers as they respond to the findings. 32
This is a view that shows a list of all threats to all components and the mitigating factors. The application has much more functionality, including being able to produce reports like TMT. For the sake of time however, we must move on. 33
This is my preferred approach and one that I share with my clients. Most approaches to threat modeling, including the ones just seen in the two modeling apps, as well as all of the applications that work on the Q&A forms approach are, in my opinion, all missing something very pertinent. They all focus on finding technical threats to particular system components, which is good, but there is something else they should be looking at. Can you guess what it is? 34
How the app or components of the app will be used! So, like we always should do when doing any UML model-driven design, we start with Use Cases! 35
then we figure out how the use cases can be subverted and we add Mis-use or Abuse Cases from the Attacker s point of view. Note that I am focusing on threats related to fraud here but it could easily be any type of info-security threat. For the sake of simplicity, this model has only one type of attacker, but in reality we typically have to account for multiple types of attackers. I usually go with External Fraudster, Internal Fraudster and Customer Fraudster. 36
These mis-use cases must now be seen as extended use cases that the design must solve for. 37
My preferred CASE tool, but there are others. (Computer Aided Software Engineering) 38
We started with Use Cases, next, let s take a look at some other design models. We are now looking at a simple, but authentic Communication Model for a login process. Note that the validatecredentials() function uses ID and PW as parameters. Note now on the right, in the Project Browser window in this design tool, what should look like a pretty standard list of models to anyone who does model-driven design with UML. With one possible exception: the Security Model. Let s look at it. Notice that there are 3 packages or sub-sections to the Security Model Controls, Data Elements, and Threats. 39
Let s look at the Controls. In this model we have a bunch of packages of security controls shown as components. In the Communication Model we saw that there was an authentication function that used ID and Password 40
by viewing the properties of the ID/Password control component, we can see that there are Security requirements regarding how ID/Password components must be implemented 41
and there are details about how the component is actually implemented. How did these get there? Model driven architecture is usually done by working off of standard templates, or project files, and then modifying them for the system being designed. The Security Model I m showing you would be part of the base model or project file used by every project. The Requirements for each security control will be present in the model, and are based on organizational policy (or best practice). When applicable, the Parameters for a particular security component will also be available but their values will have to be filled in. Through process, it is the Architect s responsibility to fill in these values and make any changes to any of the details of any used control if there will be deviation from policy. The Architect can also note why there is deviation on one of the other tabs of this window. Controls listed which are not used in any way by the project are simply deleted from the model. 42
Moving on, here we see a simple Component diagram and a list of data elements associated with a specific component 43
Here we see how data classifications are a property of the data element. Remember, these are created in a base model and inherited by every project. 44
Here in the Threats section of the Security model we see an unfinished Threat Tree. 45
Now this may be all nice for Architects, designers, those versed in UML and those who have access to a tool like this. But what about others in an organization that are part of the Security process? In my experience, most of my clients personnel who perform the actual risk assessment like to, or are required to work with Word documents. In most cases, the final report or Risk Assessment for a particular system or project is presented and stored as a Word document. EA allows you to export all or parts of your model to Word (and a variety of other formats). This is a simple export of the Security Model only, with no customization. With a bit of customization the report would look a lot snazzier. In any case, a security consultant or risk analyst looking at this would be able to easily understand the security aspects of this system or project. Remember, none of the text in this document is typed and formatted by hand, it is all exported from the models in the EA project. 46
47
The point of this presentation was to make you aware of some of the approaches out there that you may want to try. 48
49