Microsoft Application Threat Modeling Blog

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

1. 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
2. It must be expandable to adapt to proposed standards for classification of threats, attack patterns, and mitigations 
3. 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.
4. There must be a clear and concise way to explain the threat, the associated attacks, and the mitigation
5. 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
6. 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.

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?

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

Check it out: www.hellosecureworld.com

 -Talhah

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.

1. Go to “Tools” Menu and select “Options” and go to “Metadata Editor” tab. 
   
2. From the “List Name:” drop down select “Technology”.
   
3. Enter the new technology and click “Add” to add it to the list.
   
4. 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:

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

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

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

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:

1. Confidentiality: What if someone takes the backup tapes, makes a copy, and then returns the tape as if nothing happened.
2. Integrity: What is someone takes the tapes, overrates the content, and then returns the tapes as if nothing happened.
3. 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):

1. Confidentiality: I need to make sure data is encrypted.
2. Integrity: I need to make sure data is digitally signed so it can’t be tampered.
3. 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

Mark Curphey (newest member of ACE) recently did a post on a set of tools we have in our portfolio that we're starting to take out to our customers (including TAMe). Read more here.

-Talhah

I've talked about threat modeling being one part of the overall information security puzzle... there are other controls and tools you need to make the process run smoothly. Our team recently released another of these tools called XSSDetect which helps detect Cross-Site Scripting (XSS) problems in .NET code; one of the most common problems in code. XSSDetect is actually a smaller piece of another tool... More information including link to download available here.

-Talhah

A common challenge for folks looking at threat modeling as a control to potentially help them secure their software is setting the correct expectations. So what exactly can threat modeling do for you? In order to answer this question, I think it’s important to first set the context.

Within our team, ACE, everything pretty much revolves around an application risk management process we’ve established known as Security Development Lifecycle for IT or SDL-IT for short. SDL-IT basically looks like the following:

The best way to think of SDL-IT is as a process that defines control points into a typical software development lifecycle (BTW: the picture maybe a little misleading as SDL-IT does work on more agile or iterative development processes as well but that’s a different discussion). So any typical lifecycle will have an envisioning, design, development, etc. phase. What SDL-IT does is mandate certain tasks (through risk management controls) alongside these development controls in order to inject risk management into the process.

Now you can also view SDL-IT as a control management framework. At the very first stage, envision, we’re trying to catalog all of our application that make up our enterprise portfolio and then to classify each application in that portfolio against a risk classification. This is important: Microsoft has one application internally that manages our non-disclosed financial information and we have another application that displays the menu items for cafeterias across the campus. Both of these applications may be built using IIS6, .NET 2.0 and SQL Server 2.5 so they have the same technical composition and yet their business risk is completely different. It’s the business risk that we use to classify the application which in turn defines the level of ‘security scrutiny’ the application is given throughout the rest of the process.

After this stage, we move onto threat modeling in which we articulate the risk in the application contextualized against the business requirements, define the acceptable assurance level of the application and align that with the kinds of security controls (e.g., Encryption, Encoding, Input Validation, Password Policies, etc.) that we would need to implement in order to achieve that assurance level. Moving on, during development, we implement the identified control, during test we verify the implementation of those controls and finally in production/release, we monitor the controls for compliance throughout the lifetime of the application.

This is the quick 30,000 foot overview of SDL-IT on a foggy day… J

So what threat modeling does is provide a framework on top of which to consistently articulate and understand the business risk and align that to an acceptable assurance level which we realize in the form of a security strategy implemented in the software we are about to build. In other words, it’s a structure way of helping application development teams to think about security in the course of designing and developing their system. And unless you can start thinking about security _early_ in the development lifecycle, you’re not going to be very successful in maintaining a secure posture of your system in a cost effective manner (as by now this fact has become general knowledge: addressing security early in the lifecycle is more effective than later).

In short: threat modeling, on its own, is a great way to start thinking about security in the systems you develop. To take it a step further, make threat modeling a fundamental part of the development lifecycle and your benefits will only increase.

As always, let us know if you have any questions or comments (click 'Email').

Thanks.

-Talhah Mir

Threat profile is a very interesting concept that identifies the complete set of threats in a given application context. The Threat Analysis and Modeling (TAM) tool generates a threat profile using an inclusive methodology; in other words, it uses the set of allowable actions to identify possible threats.

The TAM tool uses the Subject-Object Matrix (SOM) to identify the allowable actions between subjects (Roles) and objects (Components) based on the calls defined in the use cases. Threats are generated by systematic corruption of actions out of the Subject-Object Matrix (SOM).

TAM creates three threats for each call: a confidentiality threat, an integrity threat, and an availability threat. This can result in an awful lot of threats.  Most enterprise applications contain a large set of use cases, which usually results in a large SOM. With three threats for each call in the SOM, the application would have an overwhelming threat profile.  We developed the composite threat concept to bring the number of threats down to a manageable level and help focus people on the risk and risk responses.  The composite threat combines all the potential threats to actions involving the same caller and the same component.

TAM essentially generates threats based on the business perspective (i.e., from the use case/call perspective) without looking at the individual composition of the calls. For example, let’s look at the following use cases and its corresponding threats.

Use Case #1: Browse Product Catalog, where users look at product information in the catalog.

Use Case #2: User Login, where users login into the website to buy products.

Both use cases serve different business purposes: one to promote products, and the other to increase revenue by sales. If we only consider confidentiality threats, TAM would generate 6 threats for 6 calls—3 for each use case. Although these threats would appear similar due to their technical composition, each call is still part of specific business use case that contains different data: one is product information (Medium Impact Data), and the other is customer credential information (High Impact data).

Since the application passes High Impact data, you would have to secure the communication, even when it contained Medium Impact data. For example, if you were to implement SSL between website and web service, it will protect the channel at all times—regardless of the information sensitivity.  Thus, at the end, you would use the technical composition to evaluate the countermeasures that you implement. If you had just one threat to represent both calls, it would be easier to evaluate and identify the appropriate risk response.  In this case you would “Reduce” the risk.

It is important to note here that each threat generated by the TAM tool is valid according its specific business case, but the countermeasures that will reduce the risk can be the same. Countermeasures are defined using the technical attributes (Relevancies) of the components in the call; once these countermeasures are implemented in those components, all threats associated with those components would be reduced.

Combining the threats in our example reduces the threat profile from 6 to 3 threats, a 50% reduction. This allows us to view the threat profile from a technical perspective but still maintain the business perspective for the business owner to evaluate and prioritize the risks.  It simplifies the threat profile and makes it easier to decide on countermeasures. 

The enterprise version of the TAM tool has an option to generate composite threats automatically.

Anil Revuru
Security Technologist
ACE Team

In the past we have been relying on the web browser to provide/restrict the user interface for interacting with applications on the Internet. As security teams slowly work to fix the usual SQL Injection, XSS, Input validation attacks there is a whole new can of worms(or opportunities) waiting just around the corner. This is related to the recent trend starting with Ajax and more complex technologies like Microsoft's Acropolis -  which allow you to provide a rich user experience when interacting with applications on the Internet. This trend removes the restriction that the user interface for web applications be restricted to a web browser and instead allow for thicker/richer stand alone clients with "rich client-side code".

Now, this trend opens up new security opportunites as developers are no longer restricted to programming internet applications assuming a very thin client; they are able to/and are pushing a lot more UI and other functionality into client side code. However, most developers are assuming that the client side code is also trusted and hence are failing to take into consideration the potential security issues that open up with this assumption. Very basic assumptions such as when client side code that connects to a webservice - will make the WSDL of the webservice public; such issues are not being considered by the application developers.

So what does this mean to web application security in the long run? This potentially means that hackers will soon be targetting these "rich client-side code" applications and will reverse engineer them to expand the attack surface on the server-side code of these applications. You will begin to see a new set of security issues with these thick client web applications.

Now, the one thing to remember here is that some intranet based applications (mostly Line of Business applications) have been using this approach of having "rich client-side code". And most security teams like ACE have been ensuring that these "rich client-side code" LoB applications have the right security assumptions. This experience will prove valuable in securing the next wave of Internet applications that have a "rich client-side code" or thick clients.

What should your action plan look like to accomodate for these new threats? If you are a company that is building new Internet applications - educate your developers that client side code cannot be trusted and trusting it will expand the exposed attack surface on the Webservice. Furthermore, look at building a proper security development process for building these new rich internet applications. Utilize the IT Infosec departments expertise in securing rich Line of business applications and get their guidance on securing these new web applications.

Here are some articles that talk more about Rich Internet applications.
http://www.dailytechrag.com/story/the-convergence-of-rich-internet-apps-and-the-desktop/2007-02-09
http://blogs.zdnet.com/Stewart/?p=256

These predictions are solely my thoughts and do not represent any opinions of either Microsoft or the ACE team.

Deepak Manohar

I recently did a TechNet webcast to talk about how Microsoft IT Manages Security Knowledge for Better Application Risk Management and in it had a chance to demo a near release build of TAM Enterprise.

Check it out: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032337409&Culture=en-US

Thanks.

-Talhah MIr