Export (0) Print
Expand All

Getting to the Third Wave of Security Responsiveness

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
By Scott Culp

January 2001

The start of the new millennium provides a good opportunity to dust off the crystal ball and peer into the future, and we in the Microsoft Security Response Center would like to let you know about some dramatic improvements that are already underway. These improvements are part of an effort to move Microsoft into something we call the Third Wave of Security Responsiveness. In this article, I'll describe what the Third Wave is and some specific initiatives that will help us move into it.

On This Page

Three Waves
Getting Microsoft to the Third Wave
What's Next?

Three Waves

The Three Waves of Security Responsiveness is a model that categorizes the maturity of a vendor's security response processes. In our experience, much of the industry is still in the First Wave, but many vendors are moving toward the Second Wave. There are a small number of second-wave vendors, but at present there are no third-wave vendors. Our goal is to take the first steps into the Third Wave during the upcoming year.

It's worth stressing that this model only encompasses a vendor's security response processes. It doesn't include evaluation of the security of a vendor's products or the quality of its software development processes. So, while Microsoft is making significant strides in improving the quality of its security development processes and the security of its products, I won't be discussing that work in this essay.

First Wave

First-wave vendors treat security vulnerabilities as a force of nature – unforeseeable cataclysms that strike with little or no warning and that pitch the vendor and its customers into disarray. A first-wave vendor may have a variety of motivations for treating vulnerabilities this way. It may believe that its products are of such high quality that they can't possibly have any security vulnerabilities. Likewise, it may have simply never considered the possibility that its products could contain vulnerabilities. Or it may assume that better-known competitors will attract the attention of hackers, and that it will be able to "fly below the radar."

Whatever the reason, a first-wave vendor is characterized by its lack of an effective, repeatable security response process. When a security vulnerability is found in one of its products, it may simply attempt to weather the storm until the next product release. At the other extreme, it may respond with frenzied activity, but then discover that it lacks the means to quickly develop and distribute a fix or even tell its customers what the problem is. In either case, it's unlikely that a first-wave vendor will be able to provide useful remediation to its customers.

Second Wave

Second-wave vendors recognize that security vulnerabilities are an unavoidable part of software, and they develop processes for dealing with them. A second-wave vendor typically has a formal response process with a well-publicized channel through which people can report vulnerabilities. It dedicates development resources to investigate these reports and build fixes as well as developing a channel through which it alerts customers to new vulnerabilities. A second-wave vendor also typically has a feedback mechanism through which it ensures that it learns from past mistakes and improves the quality of its future products.

Second-wave vendors can become victims of their own success. The more comprehensive, thorough, and responsive a vendor is, the more likely it becomes that its customers will be swamped by fixes, bulletins, and information. Successful second-wave vendors eventually reach a point where they recognize that the measure of success is not how many security fixes they can produce, but rather how many security fixes are actually installed on the customers' systems that need them. This crucial distinction is what separates second-wave from third-wave vendors.

Third Wave

Third-wave vendors focus on security as a holistic concern. A second-wave vendor's process may make it easy to apply a specific patch to a particular machine, but a third-wave vendor recognizes that the security of a network depends on every machine in the network being protected against all of the security threats that apply to it. As a result, a third-wave vendor will provide tools and information that help customers manage the process of protecting their systems. For example, it may provide tools to let customers know what fixes have been applied to which machines on the network, to determine which machines need a newly-released fix, and to apply needed fixes on a network-wide scale.

In addition, third-wave response processes are significantly less disruptive to customers. A second-wave vendor's security response process may appear to simply generate recurring emergencies, with every fix arriving like a bolt from the blue and demanding immediate action. This can desensitize customers; ultimately, they may forego applying critical fixes. In contrast, a third-wave vendor takes steps to ensure that a fix only appears to be an emergency when it really is one. It provides an easy way for customers to assess how critical a fix is and also provides a variety of delivery mechanisms that balance immediacy versus convenience. In sum, a third-wave vendor's security response process is integrated to the greatest extent possible into customers' normal maintenance processes.

Getting Microsoft to the Third Wave

In our admittedly biased opinion, Microsoft has the best security response process in the industry. Even so, we believe that we are, at present, still in the Second Wave. However, we have a number of initiatives underway that we believe will let us take the first steps into the Third Wave. The most significant of these are discussed below. Some of these will be completed sooner than others, but we fully intend to deliver on all of them during the upcoming year.

Severity Assessment Information

We have traditionally been reluctant to rate the severity of security vulnerabilities because of the myriad different scenarios in which our products are used. A vulnerability that poses only a minor threat to one customer may pose a major threat to another. However, customers have made it clear that they need us to provide this information.

We are currently developing a set of severity assessment criteria. When these criteria are complete, we'll review them with third-party security experts, post them to http://www.microsoft.com/technet/security/default.mspx, and then begin using them in our security bulletins. It's important to note that our assessment will be made with respect to our entire customer base, and customers will still need to evaluate for themselves the risk a vulnerability poses to their specific systems. However, we believe our severity assessments will make it significantly easier for customers to evaluate the urgency of applying various patches and to determine which ones need to be applied immediately and which can be applied as a matter of routine maintenance.

Additional Delivery Mechanisms for Security Fixes

Currently, we only have two options for delivering security fixes to our customers. When we identify a security vulnerability, we can either develop a patch or we can include the fix in the product's next service pack. On the whole, we believe that service packs should be the preferred delivery vehicle. However, a significant number of vulnerabilities are too serious to wait for the next service pack, yet don't realistically warrant the disruption that a patch entails. We are developing a third option—a periodic "roll-up," which we plan to unveil for selected products.

Roll-ups will be released at fixed intervals, according to a published schedule. Each roll-up will contain fixes for vulnerabilities found in the product since the previous roll-up. In addition, we're investigating the feasibility of including all previously released fixes in each roll-up. If indeed it's feasible to produce a cumulative roll-up, it would mean that customers would only need to install the latest roll-up in order to be protected against all known vulnerabilities in the product.

Although the advent of the roll-up will be an important change, there's much that won't change. If we find a particularly serious vulnerability, even in a product for which we build roll-ups, we'll immediately release a patch that eliminates only that vulnerability, and then incorporate the patch into the next roll-up. Similarly, all of the fixes we provide through roll-ups will be incorporated into the next service pack. Finally, just as we do with patches, the roll-ups will be available from both the Microsoft Download Center and the automated Microsoft Update site.

Improved Security Bulletins

You may have already seen the proposed changes to our security bulletins and mailers. The overall goal is to make our bulletins more useful to both technical and non-technical readers, to provide additional information that customers have requested, and to ensure that customers always have the latest information. We plan the transition to the new format early in the year, but we'll continue to make changes as we receive feedback from customers.

We also plan to deliver a new service for customers using Pocket PCs. We plan to deploy a Mobile Security Page on our website to which anyone can subscribe. Whenever we release a security bulletin, we'll post a synopsis of the issue on the Mobile Security Page. This will allow subscribers, no matter where they are, to learn about new bulletins immediately.

Improved Information About Vulnerabilities and Fixes

Customers have told us that they need better ways to find and use information about security patches. We plan to address this need by deploying an XML database on the Microsoft TechNet Security website that will contain all of the salient details about patches and bulletins—information like the bulletin number and affected product, the service pack on which the patch should be installed, a list of the MD5 hash values of all files in the patch, and so forth.

Deploying the database will enable the development of tools that make it easy to manage security fixes. The recently released IIS 5.0 Hotfix Checking Tool provides the barest glimpse of what this technology can do, and it's gotten rave reviews from customers. With the deployment of the new XML database, we'll be able to develop much more sophisticated tools. We'll provide tools that allow customers to find specific security bulletins based on a wide array of search criteria and check their systems to ensure that they are up to date on patches; and we have a major project underway that will provide significantly more advanced functions. In addition, we'll publish the database schema to enable third parties to build additional tools.

Better Support for Localization

Microsoft is fortunate to have millions of customers around the world, and it's vital that we make localized versions of security patches available as quickly as possible. We are in the midst of a complete re-engineering effort that will let us release some localized patches simultaneously with the release of the English patch and dramatically shorten the release time for all localized patches. We also will take steps to make it easier to find the localized patches on our website and will include information in our security bulletins that makes it clear whether localized versions are needed or not.

What's Next?

As mentioned above, these improvements represent only the first steps into the Third Wave. We can and will make additional improvements to our processes. In the long term, we believe that Microsoft's .Net vision offers an opportunity to dramatically improve our customers' ability to keep their systems secure. The same technologies that will enable customers to continuously add new services and capabilities to their systems will also enable them to continuously ensure that their systems are protected against the latest security threats.

Scott Culp is a security program manager in the Microsoft Security Response Center.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft