Microsoft Application Threat Modeling Blog

TAM 3.0

talhahm — Tue, 30 Jun 2009 21:40:00 GMT

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

talhahm — Fri, 26 Jun 2009 04:27:00 GMT

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...

talhahm — Tue, 17 Mar 2009 22:23:00 GMT

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!!

talhahm — Tue, 03 Mar 2009 20:53:00 GMT

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

talhahm — Mon, 15 Dec 2008 20:03:00 GMT

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!

talhahm — Thu, 20 Nov 2008 09:55:00 GMT

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!

talhahm — Fri, 19 Sep 2008 19:46:00 GMT

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?

talhahm — Thu, 19 Jun 2008 02:34:00 GMT

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

RockyH — Thu, 29 May 2008 06:56:05 GMT

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

RockyH — Thu, 22 May 2008 04:49:58 GMT

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

talhahm — Mon, 05 May 2008 04:49:00 GMT

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

rvanil — Mon, 17 Mar 2008 20:45:00 GMT

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

[VIDEO] Threat Modeling and Discovering Security Issues

talhahm — Mon, 18 Feb 2008 08:05:00 GMT

Raffaele Rialdi, a Microsoft Developer Security MVP, sits down with Lori Grosland at TechEd ATE in Barcelona 2007 and talks about security and the Threat Analysis & Modeling tool (with demo).

http://www.virtualteched.com/pages/videossearch.aspx?KW=raffaele

Also check out his blog at http://blogs.ugidotnet.org/raffaele.

-Talhah

Threat Modeling: Diving into the Deep End

talhahm — Wed, 09 Jan 2008 03:42:00 GMT

IEEE paper on the TAM tool.

"Ford Motor Company is currently introducing threat modeling on strategically important IT applications and business processes. The objective is to support close collaboration between IT Security & Controls (the ITS group at Ford) and its business customers in analyzing threats and better understanding risk. To accomplish this, a core group of security personnel have piloted Microsoft’s Threat Analysis and Modeling process and tool on a dozen projects. Here, we discuss this TAM process, its benefits and challenges, and some deployment solutions."

http://buildsecurityin.uscert.gov/daisy/bsi/resources/published/articles/932.html

-Talhah

A discussion on threat modeling

talhahm — Tue, 30 Oct 2007 05:22:00 GMT

There is a discussion I had recently with a few folks over email around threat modeling that I thought would be nice to share on this blog. I’ll reduce the discussion down to 3 questions/responses.

Question: Where does the line between Threat Modeling and documenting operational best practices begin and end?

Response: A good threat model document’s OUTPUTs should be used as the INPUTs to tech specs and operational best practices. E.g., I just threat modeled our new Data Backup process and discovered a flaw that I can mitigate with a technique X that is not documented in our guidance, operational documents, policies, standards, etc. So maybe I should update them. And WOW, wouldn’t it be great if then I can share this knowledge with folks doing TMs against same similar kinds of processes so they don’t have to research X? This is the example of the interplay between Threat Models and CTL in TAMe.”

Question: How does an operational ‘attack’ like stealing backup tapes fit into CIA or STRIDE?

Response: CIA is a THREAT categorization and STRIDE is more of a SOFTWARE ATTACK categorization. Threats are like “what if” scenarios: what if my credit card numbers are stolen… what if my backup tapes are stolen. Attacks are active actions that give rise to the realization of a threat: I can SQL inject on this entry point to get credit cards… I can steal the backup tapes from the courier’s truck while it’s in transit. Jumping to think about attacks without knowing the threat is ineffective as you don’t have any prioritization (do I need to worry about data integrity here with this attack? Do I need to worry about DoS attack here for availability compromise?).

Question: How is TAMe (Threat Analysis & Modeling Enterprise) intended to model non-application scenarios (operational, infrastructure, etc.)”

Response: TAM/TAMe has been application focused (through the nomenclature and interface) on purpose so even though it may not seem like it can model operational/infrastructure/etc. scenarios, it EASILY CAN*. For operational scenario, for example, you would identify different component (one of those would be the courier’s car). You would also define Roles (one of those would be the driver/courier). You would also define data pieces (one of those would be the backup tapes). Then you would bind these pieces together under a use cases through a sequence of calls. One of these calls would be the driver (Role) initiating a transfer (Action) of backup tapes (Data) into the truck (Component). At this point, the tool/process would force you to consider three distinct threats in isolation for this call:

Confidentiality: What if someone takes the backup tapes, makes a copy, and then returns the tape as if nothing happened.
Integrity: What is someone takes the tapes, overrates the content, and then returns the tapes as if nothing happened.
Availability: What is someone takes the tapes. Period.

Then when you start looking at these 3 threats, and propose different countermeasures (we’ll skip attacks):

Confidentiality: I need to make sure data is encrypted.
Integrity: I need to make sure data is digitally signed so it can’t be tampered.
Availability: (operational) I need to make sure the backup tapes are always in site and secured in the truck (e.g., through physical locks).

Threat modeling is not a magic process/tool where you just throw stuff in and out comes goodness. Threat modeling is a structured way of thinking about and addressing the risks to what you are about to build rather than going about it randomly.

As always, continue to provide your feedback/questions through submitted comments or sending an email through the ‘Email’ link on the top.
*Imagine in the future being able to go into TAM and Select File - > New -> Operational Threat Model or Application Threat Model or Infrastructure Threat Model… oops, I’ve said too much... :-)

Thanks.

-Talhah