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

Thanks
RV

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

1. 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.
   
   
2. 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.
   
3. 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.
   
4. 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.
   
5. 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.
   
6. 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.
    
   
7. 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

-Talhah

Check out more here.

-Talhah 

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

-Talhah

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

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

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