LOCK IT UP

... Keys to Better Security

September 2006

In my previous Blog, I went over the importance of doing Threat Modeling prior to putting together your Architecture in order to understand the threats and risks that you need to deal with. But this is primarily a manual process. One of the tools that I’ve run across is Microsoft’s Threat Modeling tool, which can assist in the development of your Threat Model. Plus it has the added benefit of being free. That said, remember that you get what you pay for.

For those of you that would like to check out the Microsoft Threat Analysis and Modeling tool v2.0, you can obtain it at http://www.microsoft.com/downloads/details.aspx?familyid=570dccd9-596a-44bc-bed7-1f6f0ad79e3d&displaylang=en .

Typically, the way the Tool works is that there are 4 areas that you interact with in the tool as well as the Attack Library. Those 4 areas are:

• Business Objectives
• Application Decomposition
• Application Use Cases
• Threats

The way that the Tutorial recommends you use the tool is that you start off by filling in the Business Objectives of the Application, then detail the individual components that will go into the Application (the Application Decomposition), develop the Application Use Cases by combining the different components based on the Business Objectives, and then generate the Threats to the Use Cases. The results of the Threat generation provide the information that you need in order to create an architecture that takes into consideration your Risks.

The generation of the Threats then requires you to indicate how you are going to handle the threat, whether it’s from avoiding the risk or accepting the risk, you are required to state how you would handle the risk. You are also able to provide a quantitative measurement of the risk based on a combination of the Impact (low, medium, high) and Probability (low, medium, high). Then you decide what type of Counter Measures you want to put into place for the Risk based on the countermeasures listed in the Attack Library. Also coming out of the Threat Modeling is a visual representation of the Attack using Visio diagrams.

The Tool is also able to then generate reports based on the type of user that needs to have the report. A report can be generated for the Risk Owner, for the Architect, for the Developer, for Test, and for the Operations team. You can also generate a Comprehensive Report that includes all views.

There is an ability to customize the tool in terms of the Reports that are generated and in terms of the Attack Library that you want to have associated with the tool. The creation of your own Attack Library makes sense in that you may have specific types of Attacks that you need to focus on plus you may have different countermeasures that you would want for specific attacks. Because the tool is based on XML, it’s just a matter of creating your own Attack Library and importing it into the tool.

So that’s a brief description of the tool. Now for my opinion of it.

I want to state right off the bat that I like the potential that the tool has for standardizing something that has typically been an Ad Hoc activity in an organization. You're able to raise your security posture standard simply by having a standardized tool in your processes. Plus, I haven’t seen any other tools out there that you could use. So, overall, I would recommend using it.

That said, there are a lot of things to keep in mind with this tool:

• Once you have generated the Business Cases, move to the Use Cases to drive the Decomposition. I found that using the process recommended in the Tutorial isn’t as smooth as if you were to use the Use Cases to generate the Decomposition.
• There isn’t a capability right now to use Cut & Paste with the tool. As a result, wouldn’t be able to take from one Threat Model and load into a second which would assist in cutting down the time for the creation of each successive Threat Model.
• If you are using the Use Case Wizard, you can’t re-enter it once you leave it. As a result, you have to leave the tool running until you’ve completed the Use Cases otherwise you have to start all over again.
• a Security Professional, I would like to be able to map to the Corporate Security Standards of my company. I’m not able to do that with this tool aside from creating something in the Relevancies section of the Attack Library.
• It would be very useful to be able to import existing Visio diagrams of the logical model of the Application in order for the Tool to generate the decomposition for you rather than you having to create the Decomposition.
• The Reports are very difficult to understand. Plus, the format that the Reports need to be in is difficult to find in the Threat Modeling web site on MSDN.
• The tool presently doesn’t integrate into any Governance tool, so you can’t link the outputs of the Tool with anything else for tracking of the Risk mitigations through the Software Engineering process.
• Tutorial is limited in it’s effectiveness.

If you do the Threat Modeling properly, expect to spend between 16 – 40 hours generating the Threat Model, depending on how detailed you get. The more you use the tool, the quicker you understand the intricacies and the quicker you can get the Threat Model done.

This is a free tool and you get what you pay for. Overall, I would recommend it for your Software Engineering process – depending on what your original Business Requirements are (remember that Blog?) which drives the entire SDL. Every little bit helps and this helps a lot.

Regards,

Neil R.

Posted at 11:39 AM  Permalink |

Before you start to develop your Architecture, you need to take a close look at the Threats that will put your Application at Risk. To do that, you need to start the process of Threat Modeling.

Threat Modeling is the process of evaluating the Threats to an Application, determining the Risk associated with the Threat (Risk being the combination of the likelihood of a Vulnerability being exploited and the Result if the Vulnerability was to used successfully). To Security people, this is often called Threat Risk Assessments (TRAs).

Threat Modeling contains four basic steps:

• Define the Requirements
  
• Model the Threats
  
• Measure the Impacts
  
• Document the Results
  

When you look at defining the Requirements, you develop the Use Cases for the Application to determine where the potential vulnerabilities may be for the Application about to be designed. That way you know what to design for.

After defining the Requirements, you then model the Threats. Typically, this involves using a collection of known threats that you have collected that you have to deal with. If you haven’t collected a list of known threats, I would suggest that you go to the OWASP web site and take a look at the list of Vulnerabilities to get an idea of what you have to deal with. The OWASP Vulnerability listing is located at http://www.owasp.org/index.php/Category:Vulnerability.

Once you’ve Modeled the Threats, you need to Measure the Impacts. This means determining what the Risk is associated with the Threats, determining what the resulting impact would be, and then determining how to deal with that Risk. To use an extreme case, say one of the Threats is that someone will blow up the Server Room housing the Application. The likelihood of this occurring is very low but, if it was to occur, the result may quite devastating for a mission critical application. Hence the reason why you look into Disaster Recovery/Failover locations. Then, to deal with the Risk, you determine whether you want to Avoid (completely mitigate the risk), Reduce (partially mitigate the Risk, Transfer (move the risk to some other party such as insurance), or Accept the Risk (do nothing – this is always an option).

Documenting is basically a necessary step in the creation of any Architecture in order to ensure that the resulting Architecture has taken into consideration the modeling that you have just done. Remember that the Threat Model is used through the rest of the development process so that all parties understand what Risks have to be dealt with.

For those that would like to use a tool, the one I’ve been looking at lately is the Microsoft Threat Modeling tool. It’s free to anyone that wants to download it from MSDN and it assists dramatically in structuring the Threat Modeling process. You can get it from the following URL http://www.microsoft.com/downloads/details.aspx?familyid=570dccd9-596a-44bc-bed7-1f6f0ad79e3d&displaylang=en. I’ll review the tool in the next blog.

So, the next time you decide to architect an application, make sure you include Threat Modeling in your initial modeling processes. It ensures that your Architecture is designed with Threats in mind. And remember that all of this is driven by your Business Requirements that we talked about in the last blog. If the Requirements don’t require this level of security (eg. The application being written is a simple, behind the scenes, unimportant application) you may not be required to perform Threat Modeling).

Regards,

Neil R.

Posted at 03:58 AM  Permalink |

Typically, when you start putting together an Architecture, you start off by gathering the business requirements that are driving the project. In the case of Application Security, this isn’t any different.

But in the case of Application Security and a Secure Development Lifecycle, what you are talking about is the level of security that needs to be integrated into the Software Engineering process AS WELL AS the security features of the project. Let me differentiate the two areas.

Security features are those things that you want to have built into the product. Say you want to have the ability to integrate with a LDAP repository as well as audit logging and Enterprise Security Event Monitoring. These are security features of the project or application. But Application Security in association with the SDL goes into the level of security activities that are involved in the Engineering process. And it’s this second type of Application Security business requirements that I want to talk about here.

When you do your Business Requirements gathering in association with SDL, you are looking at the criticality of the application itself. You want to be asking questions like “Is this application going to be Internet facing? Is it a Mission Critical application? How many users will be using this application?” You then want to assess the application both from a Security perspective as well as a Privacy perspective. The results of those questions will determine the extent you will critique the different phases within the SDL.

So take the example of the Mission Critical application. If this application fails, you have major issues such as financial impacts, reputation impacts, and possibly core business impacts. As a result, you can’t afford for the application to be breached. Based on this, the level of effort you want to put into your Architecture Review is much higher. The level of code review goes up and the Application Testing requirements may move from automated testing to a full manual review.

The same goes with a simple DLL. It may be a simple code change in a small file that is only accessed by systems and doesn’t interact with any sensitive information at all. If this is the case, do you really want to go into a full blown architecture review? Will automated testing work for you?

All this is driven by your Business Requirements back at the start of the Engineering process. What you find there drives the rest of the SDL and the level of security you put into designing the application.

I would recommend that you do the following. Create a standardized Security Impact Assessment process/checklist that is used for all your Application development and have either your Business Owner or Architect fill it out (it should take <1 hour to fill out if done properly). Have the Assessment output be in a format where the Application has 3 or 4 levels possible levels of criticality (eg. Low, medium, high). As part of your SDL, you drive the next steps in the SDL based on the measured criticality. By standardizing the process, you can link the SDL activities to Enterprise Policies and ensure that personal opinions are kept out of the process.

Remember, Business Requirements may not be the sexy part of the Application design or Application Security but it all has to flow from this area. Without it, you’re just guessing as to what you need to do in the rest of your SDL.

Neil R.

Posted at 08:16 AM  Permalink |

I was going to expand on my last blog about the SDL but I've had all sorts of questions this week from numerous different sources that asked the same question: How do you protect your Application Intellectual Property? My answer: DRM

Digital Rights Management (DRM) is a technology that allows you to tie the permissions of a user directly to the File (regardless of where the File is) rather than use Access Management to limit access to the File itself. The problem with Access Management is that, once a user has the right to copy a file, they can move that file to some location that non-authorized users could gain access.

There are two focuses for DRM. The first is attaching the permissions of the user to documents such as Word or Excel documents. In other words, Document protection so that information deemed as "Sensitive" are controlled. The second focus is around Copyright protection of files. In this case, you would attach the permissions to a file such as a jpg, exe, or some other file. It's this second focus that is useful for Application Security.

The standard that you want to look into around DRM is XrML (eXtensible Rights Markup Language). The original work on this standard came from work in Xerox around a language called DPRL (digital Property Rights Language). Xerox spun off the technology around DPRL into a company called ContentGuard and DRML was modified and renamed XrML.

Basically, the Reference Architecture around DRM involves a Content Server where the protected content resides, a License Server where the rights and identities that are associated with a protected file reside, and a Client which is required on the desktop/server where the content package will be accessed and used. The ability to access the client is limited based on a set of encryption keys that are provided to approved users and the description of the user's rights that are contained in the Rights Server. There's too much detail to be put into a Blog, so I won't go further here.

There are a few vendors in this space that you would want to take a look at. I'm not recommending any one vendor, just giving you some direction to look. The vendors I've looked at are:

• Aegis http://www.aegisdrm.com/
• Alladin http://www.aladdin.com/
• Authentica http://www.authentica.com/

You'll hear of Adobe and Microsoft also being involved in DRM but their activities are from the document protection point of view.

Anyway, look into Digital Rights Management if you are interested in protecting your Application Intellectual Property. It'll help with your problems about controlling your files.

Neil R.

Posted at 01:07 AM  Permalink |