Spot the Bug! : Microsoft Developer Security

Microsoft Threat Analysis & Modeling v2.0

rsamona — Tue, 14 Mar 2006 07:16:00 GMT

BETA2 of Microsoft Threat Analysis & Modeling v2.0 (formerly codenamed “ACE Torpedo”) is now available for download here.

Check out this blog for more info: http://blogs.msdn.com/threatmodeling/

For those of you that haven't downloaded it yet, you should. It's a great tool that helps automate the creation of a threat model. Very slick and very useful!

Security Development Lifecycle (SDL) document is now live!!!

rsamona — Sat, 19 Mar 2005 05:08:00 GMT

This document outlines the security-related process improvements we have put in place at Microsoft.

http://msdn.microsoft.com/security/sdl

if (Technology=1 && Outdoors=1) {is_person_cool_in_my_books=1;}

rsamona — Sat, 05 Mar 2005 05:05:00 GMT

I spoke with Don Kiely today, who will be my partner in crime at TechEd in discussing Whidbey Security Enhancements. One of the first things that I found out is that we went to college a couple of hours away. Shortly after insulting each other and saying who's school is better (mine, of course! :) ), we got into talking about serious stuff -- hiking. It turns out Don is a fellow outsdoorsman as well. So, we've got two major things in common.

Oh yeah, we finally got around to chatting about what the call was actually schedule for -- what the preso at TechEd should look like. It should turn out great, so make sure to come visit us at TechEd! And btw, yes, I know that I only have a single "=" above in my conditional if then statement. But I bet you didn't know that PREfast, which will ship with VSTS, will actually find this error ;).

cout << "end of post" << endl;

eWeek - Getting a Head Start on App Security

rsamona — Fri, 07 Jan 2005 06:49:00 GMT

Getting a Head Start on App Security

December 7, 2004

3 comments posted
Add your opinion

With security on the minds of IT managers more than ever, some companies are addressing the issue even before applications are developed. Microsoft Corp. is delivering technology, advice and best practices to enable developers to write more secure code. In an interview with eWEEK Senior Editor Darryl K. Taft, Rick Samona, product manager of .Net Framework and Developer Tools at the Redmond, Wash., company, discussed some of the things the software giant is doing to assist developers in creating more secure applications.

What does the Microsoft tool set provide developers in terms of security?

Developers require an innovative security architecture and features at both the application platform and programming tool levels. The .Net Framework and Visual Studio.Net provide developers with the necessary tools and information to write secure applications. Managed code and the .Net Framework make writing secure applications easier than ever before and help developers avoid one of the largest types of security breaches—buffer overruns. Furthermore, the .Net Framework contains added features like integrated garbage collection, the ability to do sandboxing, and several libraries such as Strsafe.h for safer string handling in C and Server.HTMLEncode to help prevent cross-site scripting.

Another thing that the Common Language Architecture [CLR, part of the .Net Framework] provides is evidence-based security, including strong names for assemblies. In .Net, all of the core libraries shipped by Microsoft are signed and strongly named.

One area where we are ahead is in the ease of use in implementing WS-Security. WS-Security is a fairly involved family of specifications, and it is not trivial for a developer to properly apply it to a Web services app. With WSE [Web Services Enhancements] 2.0 and Visual Studio 2003, a developer can set up a secure Web service with a few clicks and menu selections through the easy-to-use wizard. In other tool kits this is a complex, error-prone process, involving many lines of hand-authored code.

Finally, Microsoft realizes that writing secure code is more than just about the tools—it is also about people and processes. Therefore, in addition to providing the security features in the tool set as described above, Microsoft is committed to providing organizations with information necessary to ensure relevant processes are in place. More information can be found on http://www.microsoft.com/resources/practices/default.mspx. Free advice on helping developers to write secure code and be found on http://msdn.microsoft.com/security/.

How much attention is typically paid to security at design time and initial stages of development? Does Microsoft plan to offer developers a mechanism to pay more attention to security earlier on in the development process?

Application security must occur throughout the entire design process. Unfortunately, many developers take security into consideration as an afterthought. Microsoft has started releasing information on our own internal best practices and plans to release more in the near future. We here at Microsoft have been in the software industry for quite some time now. Therefore, we believe in helping other organizations learn from both our security successes and challenges.

In many instances additional security means some sort of performance hit. Would this necessarily be the case for apps where security has been part of the design process? How about for apps where extra precautions have been taken to error-proof the code? Does it take longer to build these kinds of apps?

Conventional wisdom says that increased security means decreased performance. In past cases this has been true. For instance, an important security feature, called code access security, has been optional in the Java VM because it caused a performance hit at runtime. However, with the advent of the .Net Framework, we introduced ways to make things like code access security a default feature without causing a significant performance hit. The .Net Framework can do most subscript checking during compilation using optimization algorithms, ensuring the application runs at a high performance level. There is also a preconceived assumption that added security means added lines of code. But we built the .Net Framework to actually reward increased security with fewer lines of code. The .Net Framework also provides several built-in security tools and libraries, such as System.Security.Cryptography, which contains innovative and vigorously tested cryptographic algorithms. Overall, we built the .Net Framework with security in mind; writing secure applications is easier than ever before and uses fewer resources than was previously possible.

A recent study by Gartner ["Security at the Application Level: Are You Ready?" September 2004] points out that the National Institute of Standards and Technology demonstrated in its 2002 study that removing security defects during code and unit tests can reduce the cost impact by an additional factor of between three and 20. Therefore, prioritizing security as a focus during the development phase can reduce stress on both yourself and your bottom line in the long run.

Rather than addressing the design and coding phase, what other things or areas are there to delve into during the development process that could impact application security?

Every organization, small or large, must have a Security Design Lifecycle [SDL] in place to ensure security occurs at all relevant phases, not just at code review. In addition to having an SDL, organizations must provide their developers with the adequate training to write secure applications. A recent Microsoft study showed that 64 percent of developers are not confident in their ability to write secure applications. Developers should be required to attend relevant security training and become certified. Microsoft provides free training on http://msdn.microsoft.com/security/ and has two developer security certification courses [70-330 and 70-340] as part of the MCAD and MCSD certifications. We will be further adding to our security training and certification within the next 12 months.

What's the status of PreFix and PreFast? Are they currently implemented in Microsoft tool sets?

Microsoft scans applications with PreFix and PreFast prior to shipping. We are pleased to say that PreFast will be included in Visual Studio 2005 to scan applications build in C++. Furthermore, the /GS switch used to recompile Windows XP SP2 will be defaulted to "on" to make the process of writing secure code more seamless. In addition to PreFast, FXCop will also be shipped with Visual Studio 2005 to scan managed code. Microsoft is committed to providing the developer community with the tool sets needed to write secure applications.

Who tends to care about this stuff? Any particular markets/industries more than others?

Security should be of utmost priority in all markets and industries. Some industries take added measures to ensure their applications are secure. This includes governments all over the world and ISVs that create mission-critical applications. Microsoft Visual Studio 2003 and the .Net Framework provide the ease and functionality for every developer, from hobbyists and students in academia to Global 100 companies, to write secure applications. If you are not focused on security, chances are one of your competitors is.

Writing Secure Applications using Least Privileges

rsamona — Fri, 07 Jan 2005 06:43:00 GMT

Microsoft Recommended Best Practice

Microsoft encourages that as a best practice developers write their applications to execute with the least privileges to get the job done. The reason for doing this is quite simple – if an attacker creates a security vulnerability and it penetrates your system, whether it be a Trojan horse or virus, this code will run at the same privileges as the compromised process. In Writing Secure Code, Second Edition, Michael Howard states that "I haven’t been [using an admin account] for over three years, and everything works fine. I write code, I debug code, I send e-mail, I sync with my Pocket PC…" Microsoft has been working on several things to make writing least privilege applications as easy and streamlined as possible.

We recommend that before a developer creates an application, he/she should write down the resources it must access, special tasks it must perform, and the necessary permission settings. Many times the developer will notice that there is not need to create the application to need admin privileges.

There are three main reasons for developers writing applications which require elevated privileges:

1. An Access Control List (ACL) issue

2. A privilege issue

3. Using LSA Secrets

Many times these can be avoided. More information can be found in "The Challenge of Least Privilege."

Windows XP

With Windows XP, Microsoft allows users to do something special when running an application that requires admin privileges. A user can use the runas command or click on the shortcut for the application and check the Run as Different User option.

Visual Studio 2005

Visual Studio 2005 has evolved to make writing secure applications easier than before, including least privilege applications. VS 2005 allows developers to develop and debug applications as a least privilege account. So, for example, if a developer is writing an application that targets least privilege users, the developer can now developer and debug this application as a least privilege user himself. This makes developing the application much easier, because if the developer inadvertently writes the application in a way that requires higher privileges (i.e. write to the registry), then the application will not run since the current login is not an administrator. This was not the case before. This will be true for both unmanaged and managed code.

Furthermore, VS 2005 will enable developers logged in as an administrator writing managed code to run the code in a sandbox using custom privileges. This is called Code Access Security and is provided by the .NET CLR. Let me give an example:

Assume that a developer is logged in as an administrator and he/she is developing an ASP.NET application that launches calculator on the computer. This is obviously not something a developer should want an ASP.NET application to do. If the developer tests this, it will obviously run since it is running on the developer’s privileges. Currently, the only way to know if the application will run under least privilege is to post it on the website and run it. With CAS, the developer can select what privilege the application should run at and test it. So, for this ASP.NET application, the developer can select "Internet privileges," and when he/she tests the application, it won’t run. It will also highlight the chunk of code that has the issue in order to aid the developer to fix the problem.

This will make the process of writing least privilege applications much more simplistic and streamlined.

Longhorn

Longhorn will introduce even more functionality for least privilege – the idea of Application and Deployment Manifests. Application Manifests will allow application developers the state what permissions their application requires to run properly. Deployment Manifests allows System Admins to indicate how much trust they have in an application. This is a high-level explanation of a powerful functionality which will work for both managed and unmanaged code.

To simplify security both for admins and end-users, Longhorn will have only two levels of system access: least privilege and administrative. Developers will need to make a choice of how they want their applications to run and write the code accordingly. For example, developers will have to store the application state in the user profile, not in the Program files directory.

Addition Resources

The Challenge of Least Privilege

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure06112002.asp

Security in Longhorn: Focus on Least Privilege

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/leastprivlh.asp

Chapter 1: The "Longhorn" Application Model

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnintlong/html/longhornch01.asp

Michael Howard and David LeBlanc

Writing Secure Code, Second Edition, pages 60-62

posted on Wednesday, December 15, 2004 4:57 PM