How vulnerable are software applications?

In a June 2007 report, the U.S Government Accountability Office (GAO) described cybercrime as “having significant economic impacts and a threat to U.S. national security interests” and referenced a 2005 FBI survey estimating that U.S. businesses lost $67.2 billion because of cyber crime and the estimated losses associated with identity theft in 2006 were $49.3 billion.

As much as everybody understands that cybercrime is serious, it isn’t clear to me that there is a broad understanding of where we are the most vulnerable.

According to the June 2007 Microsoft Security Intelligence Report, less than 10% of vulnerabilities disclosed through June 2007 were targeted at Operating Systems. With more than 90% of vulnerabilities targeted at the application layer, all software development organizations need to really think about security as it relates to applications.

It is important to note that large vendors are not the only ones whose applications are being targeted. The 2007 IBM Internet Security Systems X-Force report found that only 13.6% of the 6,437 new vulnerabilities disclosed in 2007 belong to the top five software vendors (Microsoft, Oracle, IBM, Apple, and Cisco).

A good question to ask in this context is “What is Microsoft doing to help developers build more secure applications?”

As software becomes the target for cyber criminals, it is more critical now than ever to make security an integral part of the software development process. Ever since Bill Gates’ 2002 Trustworthy Computing memo Microsoft has been infusing security into its software development lifecycle with the goal of protecting customers by reducing the number and severity of vulnerabilities in code.

In hindsight, I am very glad to note that Developer Division was one of the SDL (Security Development Lifecycle) pioneers at Microsoft. The original “security push” in 2001 was on the .NET Common Language Runtime. The “security push” format was later applied to other Microsoft products and evolved to encompass the entire development lifecycle. In 2004 the SDL became a mandatory policy for all products at Microsoft (and DevDiv of course). Silverlight is one recent and excellent example of how we leverage the SDL to enhance the security of our products. As an innovative and widely used web platform, Silverlight was developed with much attention to security and data privacy. Threat modeling, a method for analyzing security and privacy risks in the design phase, was used extensively to identify and mitigate potential attack vectors within the Silverlight framework. After the design stage, the threat models were used to focus the security efforts in the coding and testing phases of the development process. By emphasizing security and privacy early and throughout all stages of development, the Silverlight product team was able to not only enhance security, but also to surpass a higher bar of quality. In my mind, this is what the SDL is all about.

The Microsoft SDL is the industry-leading software security assurance process. SDL has played a critical role in embedding security and privacy in Microsoft software and culture. Combining a holistic and practical approach, SDL introduces security and privacy early and throughout the development process. As the images below clearly show, the SDL has led Microsoft to measurable and widely-recognized security improvements in flagship products such as Windows Vista and SQL Server:

With attacks moving to the application layer, Microsoft is committed to supporting a more secure and trustworthy computing ecosystem by making SDL process guidance, tools and training available for every developer. I encourage you to learn more about the Microsoft SDL and how you can leverage SDL resources and best practices to “bake security in” to your software applications.

Microsoft Security Intelligence… It appears, in my opinion, those words do not even belong in the same sentence. Microsoft is yet to prevent a virus written by some bored 13 year old kid with C compiler from infecting a windows operating system, yet you try to convince us otherwise.

That sounds real similar to the way you spin that pathetic excuse for a development tool kit codenamed Visual Studio as being better then Visual FoxPro and Visual Basic. I suppose if a programmer enjoys writing 100’s if not 1000’s of lines of additional code (depending on the project) to get their work done then VS and .BLOAT are way better options then VFP or VB. Currently 80% of my applications are unforunately now developed in C# and .BLOAT and I’m yet to come across a single case where the VS application turned out to contain less code, provided the same level of performance and cheaper for my clients then a VB/SQL or VFP solution. What you are tell customers about VS is all smoke and mirrors. It is unforunate that so many developers are buying into your spin simply because they have NO experience with a "REAL" programming language and development studio which they can compare Visual Studio to.

I know you at MS warns about "security by obscurity", but I would like to address an aspect of this that often causes security problems when (web) applications are being installed and does not work.

Often the error messages are on a generic form like "access denied", "missing privilege" or similar. And what is done by the installation guy? – oh yes, a lot: Access to everyone. Run application as administrator. Allow all kind of scripts, etc, and finally: IT WORKS! And delivery is overdue so the removing of privileges is left to "another day". So even if both OS, IIS and the application is secure by themselves, the result is not secure.

I would like error messages like "Read access denied to <folder> for <user>". You need privilege <privilege> to do operation <operation>.

Bad error messages are in my opinion a sort of "security by obscurity".

Firstly may I quickly thank you and your team for such an amazing product. VS2008 with dot net and WPF is truly amazing!

We understand that MS wants ISV’s to develop apps that work in Partial Trust in order to improve the overall security of users. However, there are many features of WPF and dot net that make it extremely difficult to do so. Things like limited isolated storage space (0.5MB is really very small), XAML Serialization, drag and drop, even bitmaps effect do not work in Partial Trust. Our applications started out strictly only using Isolated Storage, not using the registry etc. in order that it would run in Partial Trust. Very early on in the development cycle it clearly did not make business sense for us to restrict ourselves in order that our desktop apps will run in Partial Trust.

As ISV’s using MS development tools, we look to MS for providing us with a framework that will make it easy for us to develop in Partial Trust. Looking forward …

I make a living day to day using MSFT technology, and do really appreciate the efforts the company is making in security and other areas, but I do take one issue with your post:

Showing _disclosure_ trends of _operating systems_ on the left and _fixed_ trends of _database servers_ on the right is misleading at best.

It is great that the operating systems have had progressively less disclosures, but says nothing about how vulnerable they are because you didn’t show their fixed trends or outstanding counts.

It is also great that SQL Server 2005 has had zero fixes, but again that says nothing about how vulnerable it is because you didn’t show its disclosure trends or outstanding counts. It only says you’ve fixed nothing.

The goal of the Microsoft SDL is to reduce the number and severity of vulnerabilities in software that is released to customers. Therefore, the relevant metric for measuring the success of the SDL are disclosed vulnerabilities. For more on security metrics see the following blog post on the SDL blog: http://blogs.msdn.com/sdl/archive/2008/04/18/oh-no-security-metrics.aspx.

For SQL Server, the title of the graph is a bit misleading. The information in the graph actually represents the number of vulnerabilities that were “disclosed and fixed” for SQL server. The complete analysis, along with a comparison to database software from other vendors, was performed by David Litchfield of NGS Software and can be found here: http://www.databasesecurity.com/dbsec/comparison.pdf.

I agree with your comments on error messages. The product teams look constantly at how we can have our error messages be more relevant and meaningful and as much as we have made progress, I know we can do more here.

Eli, you make a good point about the current limitations in WPF when running in partial trust. We’ll definitely look at how we can take enable more scenarios in future versions based on your suggestions.