Microsoft Application Threat Modeling Blog

Security Guidance and Threat Modeling

2009-07-30T22:27:11Z

I just posted a blog entry on the main drivers behind CTL in TAM v3.0. You can check it out at IST blog site.

http://blogs.msdn.com/securitytools/archive/2009/07/30/security-guidance-and-threat-modeling.aspx

Thanks
RV

TAM 3.0 Beta is Now Live!

2009-07-24T04:04:35Z

I am excited to say that Threat Analysis and Modeling (TAM) 3.0 Beta is now live on download center. You can download it from here.

As this is a beta build we have set up a Connect site that enable you to submit bugs and feature requests. You will need to register at connect.microsoft.com with your Windows LiveID and then submit bugs here and feature requests here.

Thanks
RV

Threat Analysis And Modeling (TAM) v3.0 – Learn about the New Features!

2009-07-20T19:15:00Z

Last time we briefly talked about releasing TAM v3.0 this year. With each week we’re inching closer to that goal. TAM v3.0 release is focused on 3 main areas of the tool including:

threat modeling methodology
gathering application architecture
security guidance

Apart from these import and export of items to and from threat model, threat generation were also significantly changed.

The following are the prominent new features in version 3.0.

Cloud CTL – Common Task List (CTL) is a list of countermeasures. This rich structure allows the threat modeling tool to provide comprehensive and context sensitive security guidance. CTL is externally hosted on Azure as a WCF Service providing an easy way for external users to access the security guidance. In the near future, the WCF Service code will also be released so external organizations can take advantage and host their own service internally.
Visio Drawing Surface – In v2.1, the use case generation can be a very tedious process. Although automatic use case generation feature existed, it did not provide logical break down of use cases. Manually adding calls one by one in large use cases involved remembering the previous callers and mapping appropriately. In v3.0, we replaced the graph in the use case edit screen with the Visio drawing surface where users can drag and drop roles and components to build a use case.

This Visio drawing surface reduces the number of clicks it takes to add a use case from 10 clicks to now just 6! The drag and drop drawing surface also helps you visualize while you are simultaneously adding calls.
Simplified ATG – Automatic Threat Generation (ATG) from v1.0 has been the best feature in the tool providing the user an easy way to generate threats. In v3.0 we’ve added a new feature called composite threats, read more about it here. It’s suffice to say that composite threats dramatically reduces the time it takes to evaluate threats. It combines calls with same the caller and component into one threat. Essentially you have multiple threats per call which reduces the number of threats and also allows the user to focus on the countermeasures of the affected components.
Auto Updated Client – With this version users will be notified of the new release(s) and redirected to Microsoft.com download center to download the latest version. This ensures that users will always have the most up-to-date client installed.
Backward Compatibility – V3.0 is completely backward compatible with v2.1 threat models. A new plug-in has been added in the import section for users to import v2.1 threat models. All of the data is imported including the countermeasures which are mapped automatically to the new CTL countermeasures.
Intelligent TFS Sync – TFS Export in v2.1 did not provide a way to consolidate countermeasures across multiple components. This new version includes complete TFS field mapper which provides a new UI to map TFS fields to CTL Fields allowing proper export across different TFS process templates. The exported work item references are stored in the threat model which helps users avoid exporting the same countermeasure twice.
Leaner Threat modeling methodology – Items including identities, data effects, primary threat factors were removed. Service identities that are being used for specifying Component Run As and Call Impersonation Identity are now replaced with the Roles themselves. In v2.1 visibility to identities was not apparent which caused users not to create identities resulting in no mapping to the Run As property. Application Use Case data effect was used to identify the primary data effect of a single use case, but very often many calls in use case have multiple data effects. For example when creating a user, writing to a file log which has two data effects C –> User and C –> App Log. Now the use case data effects are completely removed, call data effects are consolidated to generate Data Access Control Matrix analytic. The primary threat factors were additional steps in understanding threats, however it was adding an extra step in evaluating threats.

Please continue to check out this blog site for release announcements and more updates on specific features.

Thanks
Anil

TAM 3.0

2009-07-01T00:40:00Z

Been a little quiet lately on TAM related news but head over to Channel9 to hear RV talk about what's upcoming for TAM 3.0.

-Talhah

Beautiful Security

2009-06-26T07:27:00Z

My colleague Mark Curphey made available a chapter he wrote for a recently released security book. I had a chance to read his chapter and it’s an absolutely fantastic read with some great thoughts! It’s a must read even if you have even a passing interest in the information security landscape.

Check out more here.

-Talhah

Tax Season... So Threat Model This...

2009-03-18T01:23:00Z

Tax Season! I came across a scenario that I wanted to share…

Scenario: You have some tax application that, let’s say, we’ll call OnlineTaxApp. You also have your online banking site where you manage your finances/investments/etc. called OnlineBankingSite. Then there is you looking to fill out your tax return. As part of the data you input into OnlineTaxApp, the application gives you an option to input your credentials from OnlineBankingSite with which the application can automatically import your interest/investment data, for example from the banking site. The same credentials that are used to manage your entire investment portfolio and banking data now being asked to provide to a third party who only wants access to a subset of information for read-only purposes! What do you do? Do you provide your credentials? What’s the risk here?

Well the risk is pretty straight forward. You just don’t know how the OnlineTaxApp is going to handle your credentials. What if OnlineTaxApp stores those credentials? What if the developer of this particular feature is harvesting the banking credentials in the backend from OnlineTaxApp? What if OnlineTaxApp is just inadvertently logging the credentials somewhere which are just waiting to get lost in the wrong hands in the future? What if…

Clearly lots of what if scenarios that we should be able to threat model and mitigate. The question really is who is accountable for the mitigation and how should this be mitigated?

The user? If I had to use this OnlineTaxApp, I would have two windows open. One window would be the OnlineTaxApp and the other window would be the OnlineBankingSite. Right after I imported the data into OnlineTaxApp, I would go to the other window and immediately change my credentials to OnlineBankingSite (no reason why the tax software would need my credentials ever again after it has imported the data!)

OnlineTaxApp? Clearly, as part of the threat model for this application, we would model the use case of the import feature where the banking credentials are used. In this use case, the spotlight would be on the question of retention for this piece of data. And the sensible thing here would be to ensure proper handling of this data as it’s being used but then followed by proper disposal (out of memory, out of storage, etc.).

OnlineBankingSite? This is where things get interesting. As you threat model this system you would see in your access control matrix that the role associated with the user credentials has access to not only read data but also update, create and delete other records. And yet for these APIs that this site must have exposed through which it can expose certain data to third party consuming applications, it is asking for the same credentials although it is only servicing read-only data: clearly a violation of principles of least privilege. So how could this have been designed a bit better… a bit more secure? Simple, you need a separate role with separate credentials that only allow read-only access to the data. You can setup a feature where you give the user of the site an option to create temporary export accounts, for example. It is this account’s credentials that you would then supply to a tax software where it can be ensured that the privilege of this account is aligned to the minimal set of functionality (i.e., read-only) that is exposed through the APIs.

None of this is really rocket science but in today’s world of complex, interconnected systems that we develop, it often gets difficult to assess, in a systematic fashion, the security consequences of features we develop. One more reason for threat modeling! Not only that, you see in this example, why it’s critical for line-of-business type applications such as banking and tax applications, to maintain an asset-centric view… just follow the data and the bad stuff will pop up. J

-Talhah

Updated SDL TM Tool Now Available!!

2009-03-03T23:53:00Z

Very excited to announce that the SDL folks have released v3.1.4 of the SDL Threat Modeling Tool, as the latest and greatest release to apply the DFDs and STRIDE per Element approach to threat modeling. It's a free download, so why not check it out?

-Talhah

Announcing CAT.NET CTP & Anti-XSS v3 BETA

2008-12-15T23:03:00Z

Continuing our work to share the tools and techniques we use internally to maintain a secure application portfolio, we today announced the release of CAT.NET CTP and the next version of Anti-XSS.

Irfan (Director of ACE) posted a nice entry on the ACE Team blog going over some of the history of these tools and how they came about...

Happy Holidays!!

-Talhah

SDL Threat Modeling Tool Now Available!

2008-11-20T12:55:00Z

We're really excited that our colleagues over in the SDL team have released a beta of their threat modeling tool, as one of several SDL-related announcements.

As threat modeling matures as a discipline, there's no single 'right' way to do it. Both the TAM tool and the SDL tool address specific needs that our user communities have. The SDL tool is intended to be software centric, while TAM is asset centric. It's great to be in a situation where we can really distinguish between these and make tools which are focused on the needs of the different customer groups.

-Talhah

New SDL Threat Modeling Tool Coming Soon!

2008-09-19T22:46:00Z

Even though this blog’s focus has always been the ACE Threat Modeling tool and methodology which is aligned to our SDL-IT process we use for line-of-business application in Microsoft, there is another security team in Microsoft dedicated to SDL. And as part of that process, they are getting ready to release the latest incarnation of their threat modeling tool.

The man behind that tool is Adam Shostack who we’ve been working with now for some time see how we can coordinate our efforts and provide better language and messaging around the two tools we have. Progress is being made on that end as we continue to work on our respective areas for threat modeling.

At a high-level, here’s one way to think of the different focus of the two tools.

The focus of SDL Threat Modeling is the products we develop such as Windows and SQL Server. In that space, the final deployment pattern is not known so you don’t know if that software is going to be instantiated to manage business-critical applications with customer credit cards or your nearby cafeteria menu. As such, the focus of the methodology and tool is on the software to try to ensure security of the underlying code.

In the LOB-space, we deal with applications with business objectives clearly defined, deployment pattern well understood and, most importantly, a good understanding of the data assets being managed by the application. Examples could be the application we use to manage our expenses, manage our HR data, or yes, the application we use to look up the menu of our nearby cafeteria. So in this context, we take a deliberate, asset-focused approach in trying to understand the business risk in the application and help identify controls needed to manage that risk.

The tool should be out by November.

-Talhah

Is Threat Modeling Right For You?

2008-06-19T05:34:00Z

Great post by my friend and colleague around threat modeling in a series he's doing on application security lifecycle.

http://blogs.msdn.com/akshay_aggarwal/archive/2008/06/11/application-security-development-lifecycle-5a-is-threat-modeling-right-for-you.aspx

-Talhah

Threat Management the bigger picture

2008-05-29T09:56:05Z

Threat Modeling is one those ‘sciences’ that is just now starting to gel into something that can be implemented in a semi-automated fashion. With TAM/e, we have a good approach to threat modeling that is both easy on the development team, and fairly comprehensive (perhaps too much so). However there are still two very different camps on the subject within Microsoft, and a few more outside.

There have been a lot of advances in groups such as PTA (Practical Threat Analysis http://www.ptatechnologies.com/ ) as well as a push to formalize Attack Patterns (yours truly http://en.wikipedia.org/wiki/Attack_patterns and http://www.attackpatterns.org/ , Mitre / Homeland Security http://capec.mitre.org/ , and some commissioned work by Cigital https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/attack.html ) into something that can be used to assist not only Threat Modeling, but attack activity classification as well.

In any case, a thorough, and comprehensive threat modeling methodology must begin to consider these things. There aren’t any established standards yet, but I feel there will be in the near future. For my money, there are a few key things that a TM methodology must have:

It must consider and be adaptable to the known usage pattern (TAMe/SDL-IT {Microsoft ACE Team})and unknown usage pattern (Snyder/Swiderski, SDL {Howard/Lipner}) approaches
It must be expandable to adapt to proposed standards for classification of threats, attack patterns, and mitigations
It must be able to model any system from software to physical devices. The standard way to break down the blocks into Threat, Attack, Mitigation will fit almost anything.
There must be a clear and concise way to explain the threat, the associated attacks, and the mitigation
There must be a way to loop the TM process back into the development lifecycle, as well as provide visibility up the chain to management
Tooling support is critical to the success of a process like this. There are way way too many manual processes and methodologies involved in writing software. We need to remove the process burden from the team, and build it into workflow of the toolset.
1. The tool must be intuitive to use and not require a degree to figure it out
2. It must provide the information most important to the particular viewer in context, and in a clear uncluttered manner
3. It must provide a comprehensive view of the security profile of the application portfolio across the organization.
4. It must provide information relevant to auditing and regulatory compliance
5. It must provide trend analysis across the application portfolio to identify areas where training, and process improvements need to be made.
6. It must integrate closely with common development platforms (Visual Studio, Rational Rose/Clearcase) to reduce the need for re-entering data of the modeled system
7. It must provide usable output to the development, test, deployment, and operations teams in the form of actionable tasks.

When considering existing tools and processes, I tend to go with TAM/e as it is the one our team developed and the most applicable to typical in-house software development. But when I talk about it the thing I get asked the most about TAM/e is; can it integrate with modeling tools like Rational Rose/ClearCase and to a lesser extent the modeling tools in Visual Studio. The biggest hurdle we have to overcome is the duplication of effort around re-entering data. Teams really get turned off when they find out that not only do they have to model their solution in Simply Objects/Rational but then they have to do it all over again for TAM/e.

I wouldn’t’ say that tooling has to necessarily be ‘built into Visual Studio’ but it certainly has to integrate with it through inputs/outputs. I suppose we should also pay homage to the fact that TAM/e in this case originated from application threat modeling.

Since that is our baseline, that is where we tend to start. With the capabilities of the current TAM/e system, it is quite possible to model anything through an independent client, but the ability to interoperate with existing application, and system modeling tools is critical in my opinion.

Our base ACE Threat Modeling methodology, where threats are essentially broken down into three parts, the Threat, the Attacks, and the associated mitigations, can be used in a physical world. I did just such a thing with TAM. I modeled physical attacks on an ATM for a bank as a demonstration exercise.

Here’s the reader’s digest version:

Vandalism

Threat – Denial of Service due to damage of the machine
    Attack – Damage through blunt weapon attacks
     Vulnerability - Machines made of mostly plastic parts
        Mitigation - Use Cast Iron parts
     Vulnerability - Exposed telephone style button
        Mitigation – Use recessed buttons
    Attack - Damage through vehicle intrusions
      Vulnerability - ATM exposed in outdoor settings
        Mitigation –
             Recess ATM behind wall with only interop panel exposed
             Install Secura-Posts in front of ATMs

Skimming

Threat – exposure of ATM card/account data due to the presence of skimming devices on machines
Attack-Skimming device placed over card reader slot
Vulnerability – User cannot tell when a skimming device is present
Mitigation – place an LCD screen along edge of card slot. When user inserts card, ask user to enter code displayed on LCD. If the user cannot see the LCD, skimming device present, notify bank personnel

etc

Obviously you wouldn’t feed this into Team Foundation Server. But you may need to feed it into the bank’s risk management system. So having the ability to define exports/imports to other systems is critical. As any good ‘customer’ I’ll leave the implementation to our development team, but if I had to speculate, I would envision this to be something like BizTalk’s schema transform mapping system. You have the TM schema on the left, the target schema on the right, you drag fields from on to the other and the tool creates the XSLT to make the magic happen during output. (hint hint)

With this simple process in place, you can model any threat/vulnerability/mitigation from a software system, to defending a radio comms truck on a battlefield. There is a tendency, especially in academia, to over complicate things for the sake of appearing to be doing new research. KISS is the key.

Comparing Risk Analysis to Threat Modeling

During some discussions on this topic one of the guys on our team said:

"All security people know about Risk Assessment. If the end goal is to measure (loose definition) Risk, then why still call in Threat Modelling? Modelling the threats is a part of the goal (if you think about what ACE does its find the threats and vulns) but it’s not the end goal and it’s the end goal that customers care about, managing risk."

I’m not sure I’d generalize that much. Security people also care about Risk Management, not just assessment. If you can identify and assess a risk, you are only ½ way there. Doing something about it needs to be part of the process. So if Threat Modeling is the first ½, would Threat Management be a more appropriate term for the full process?

Hmm...the more I think about it the more I like that term. It’s akin to the paring of Risk assessment and Risk Management. Risk Assessment is what those rent-an-auditors do. But Risk Management completes the circle. Threat Modeling, provides the context and identifies the areas to be covered, but Threat Management completes the process. Threat Management should be a part of any good Risk Management strategy.

Another person on the team said:

As I understand it, threat modeling is the combination of risk analysis and risk management.

TAM for example provides the functionality to assign a risk to each threat, decide risk management strategy for each threat (reduce/accept/transfer/avoid) and choose appropriate countermeasures.

Risk analysis has these steps:-

1. Asset and data valuation

2. Identification of threats and vulnerabilities to the assets

3. Calculation of risk for each threat

Risk management has the following steps:-

1. Choose what to do with the risk based on the risk appetite (reduce/accept/transfer/avoid the risk)

2. If you choose to reduce the risk, choose a countermeasure commensurate with the level of risk.

Threat modeling does all the above 5 steps and hence covers both risk assessment and management.

I believe that Threat Modeling is a subset of an RA process. There is more to RA/RM than threat modeling. There are many areas of RM that do not include any sort of ‘attack’ portion. There are many instances where RA/RM is performed on things that are not systems in any stretch of the term. While TM is a Risk Management process, it is not completely transferable as Risk Management.

Think of it this way, Risk Management is a base class, while Threat Management inherits from Risk Management.

Risk Management ideas/principals can be used on almost anything, but Threat Management is generally restricted to implementations of things.

You can have internal risks, and their mitigations, but there may not be any ‘attacks’ associated with it. TM comes into play where you may have nefarious entities actively or accidentally damaging your stuff.

For Example, investment firms and financial organizations do a lot of RA against stock and share prices. Yet there is nothing they can do to prevent them from actually crashing, and there is no attack or attacker involved. This is not something you can threat model based on commonly understood or applied principals of TM. You can’t identify a vulnerability that you can provide an actionable mitigation for. So the best you can do is plan for failure based on probability and likelihood and shore up your decisions on those plans.

Threat Management is differentiated by the fact that there is an identifiable vulnerability that could be attacked intentionally or accidentally where an actionable mitigation can be executed to remove or reduce the identified vulnerability. (look, a new definition just appeared. )

So while I agree that TM is PART of an RM strategy, I believe they are distinct and different things with one being a subset of the other. Ask yourself, isn’t it important to be able to clearly identify the holes you can, and be able to do something about the hole itself? In standardized RM strategies, you can't do anything about the stock crashing, you can only decide if you are willing to take the chance that the value will hold or not. You will either buy the stock, or you won't.

So, Threat Management is a part of any good Risk Management strategy. It includes identifying the threats, and providing actionable items that can address a vulnerability in the system/thing being modeled. This process is essential in the larger picture of Risk Management which not only takes into account system/thing based risks, but postures, and approaches to risk in general at a higher level.

Using Threat Models Beyond the Design Stage

2008-05-22T07:49:58Z

Threat Modeling is no longer the obscure magic is used to be. With the creation of tools like the Threat Analysis and Modeling tool from the ACE Team, Threat Modeling is now easier to implement, faster and more comprehensive. Threat Modeling is the cornerstone of any good Secure Development Lifecycle. One of the reasons it became such an important part of the process is because it provides visibility of the potential threats to an application, and how to defend against them before you start writing code. Many teams that implement Threat Modeling, create their threat models, get their list of countermeasures that they have to put into the code and then go make a system. People don’t realize just how valuable a threat model can be to the team, beyond the development stage. Another huge benefit of Threat Modeling is how it can help other teams during later phases of the development life cycle. Testing, Deployment and Incident Response are some of the areas that gain huge benefits from threat models.

Testing teams are often focused on feature tests, performance tests and acceptance testing. More and more they are checking for basic security vulnerabilities as part of the normal course of testing. A Threat Model is a very suitable guide to assist the security testing process. Not only does it increase the security awareness of the test team, but it will help the testers create tests to ensure that the countermeasures identified in the threat model were put in place correctly. After all, if you don’t test the countermeasure, how can you be sure you got it right?

The TAM tool can also be used to create work items in TFS for the testers to do exactly that. For each countermeasure work item that the tool generates for the developers to implement, TAM generates a corresponding test for the testers to execute to verify the countermeasure. This makes creating a test plan for the application much more comprehensive and valuable.

Beyond testing is the deployment phase. During deployment a threat model can greatly improve the deployment teams awareness of the security profile of the application, it’s attack surface, and the potential security hot spots of the application such as trust boundaries and critical data storage areas. All of this information helps the deployment team increase their ability to deploy the application correctly, and give it the proper attention it deserves. This will increase the efficiency of deployment, and any potential incident response activities.

As much as we would like to believe that applications survive well on their own after they are deployed, there is always something that comes up. We would all like to think that our applications are hack-proof and that they will never suffer a security incident. But we don’t know what we don’t know, and can’t be sure that some new attack won’t be created. In these situations, we need to be able to respond quickly and effectively to these sorts of incidents. With a good application threat model responding to security incidents is much more efficient.

With a good threat modeling practice in place, when a new attack type appears the security team examines the attack, scrutinizes it, formulates appropriate defenses, and generates awareness of the attack. They can update the Attack Library in the TAM tool, and instruct teams to re-generate their threats to see if their application is subject to the new threat or not. This will very quickly tell you if you have to start getting your emergency patching process rolling, or if you are safe from this new type of attack. This may not seem like much but consider what this provides in the bigger picture.

With the click of a button, in the case of the TAM tool, you will instantly know if you have to patch your application immediately, or if you aren’t affected by the attack. With the Enterprise version of TAM, you can even see if applications you are dependent on are subject to the new attack or not. If you are, the threat modeling process will notify you, provide you the countermeasure you need to implement and provide the test you need to ensure the countermeasure is implemented correctly It will also create updated reports so that the entire team is aware of the issues, their responsibilities and compliance requirements very quickly. What this all means is that your patching cycles are much shorter, the application is maintained in a secure manner, which all results in increased customer satisfaction and loyalty.

Ultimately, you can say that good Threat Modeling practices = more customer satisfaction and loyalty. After all, isn’t that what we’re really after?

Hello Secure World

2008-05-05T07:49:00Z

An awesome site to check out which also includes virtual labs you can leverage for secure coding!

Check it out: www.hellosecureworld.com

-Talhah

Customizing TAM Dropdown lists

2008-03-17T23:45:00Z

One of the most frequent questions we get is that someone is using a technology that is not listed in the “Technology” drop downs and how can they customize it. Most of the dropdowns are part of the metadata system in the tool and are stored in an XML file in the user’s profile. Fortunately, the v2.1.2 release of the tool contains UI to edit this. The following steps will allow you to customize the list.

Go to “Tools” Menu and select “Options” and go to “Metadata Editor” tab.
From the “List Name:” drop down select “Technology”.
Enter the new technology and click “Add” to add it to the list.
Click “Save” to save the list to the XML file. Note that after saving the list, if you are already on a Component, you might have switch to a different item and back to the Component to reflect the changes.

The above steps can be used to add items to any of the following drop down lists in the tool:

Item Type	Property Name
Role	Authentication Mechanism
Role	Approximate number of Identities (Weight)
Data	Data Classification
Component	Technology
Component	Service Type

Any new item in the dropdown if selected in any Role/Data/Component will be saved with the threat model. If you get a threat model with new items in it, the new items will automatically be synchronized with your list. You can also manually synchronize the lists from the opened threat model by going to the “Tools” menu and selecting “Synchronize Lists”. Select the appropriate list properties and click “Save”.

If you want to edit the XML file manually, you can find it at %USERPROFILE%\AppData\Roaming\Microsoft\TAM\Temp\AppLists.xml.

Thanks
Anil Revuru