Security in Operation (Part 1 of 4): Windows, Linux and Security Notifications

Article
05/20/2008

Security Management

By Jeffrey R. Jones
Director, Microsoft Security Business Unit

As part of my work in the Security Business and Technology Unit for Microsoft, I have spent a lot of time analyzing OS security, customer feedback, metrics for progress, and where those three things intersect. One thing I’ve discovered is that there is quite a large gap between the theoretical idea of security and the practical security concerns of customers. This article is the first of a four-part series where I’ll be examining those customer concerns and raising questions to think about with respect to using either a Microsoft Windows–based or a Linux-based operating system.

For Windows, I will largely look at Windows Server 2003 as the first operating system to undergo Microsoft’s Security Development Lifecycle [Lipner04] and as one that customers have been using for two years. For Linux, I will look at the Red Hat and Novell Suse Enterprise Linux server offerings.

At the top level, all three vendors provide Security Notifications to customers, but let’s look at how the differences might affect the operational customer environment.

Customers and Security Notifications

Microsoft calls them Security Bulletins, Red Hat calls them Security Advisories, and Novell calls them either Security Advisories or Security Announcements. Whatever they’re called, they all have the common purpose of notifying customers that a security issue affects their product and that action might be required to manage security risks.

Having discussed Microsoft Security Bulletins with Microsoft customers and customer advisory councils to understand customer needs, I believe I can lay out the set of top-level requirements for security notifications that customers have shared with Microsoft. Paraphrased from the customer viewpoint:

Notify us. Don’t assume that we all use your updating tool that automatically informs us about security patches.
Tell us about all issues. Security by obscurity doesn’t work. Tell us, so we have the option of taking action to protect ourselves. Even if you think an issue is minor, we might not agree.
Tells us what product is affected. Give us enough information to know if we’re affected. Be specific and tell us by version, and use product names we’ll recognize, not obscure subcomponents.
Give us an idea of severity. Define your severity, but understand that our assessment might be different than yours, so you need to give us all the information we need to make our own assessment.
Give us mitigation guidance. Understand that we have policies about updating our configurations. We may have a six-week test process before we can deploy your patch and we need to protect ourselves in the meantime.
Don’t assume we use your updating tool. So make sure your patches can be deployed with our distribution tools and not just yours.
Tell us what components are affected. We have to test our apps with your changes, so don’t assume we have the time to decompose your patch or look at source code to see what changed.
Be predictable. Understand that we have processes to follow and it takes time and resources, so give us some time to act.

Next, we’ll take a look at how each vendor handles security notifications with respect to these customer needs, starting with Red Hat and finishing with Microsoft.

Red Hat Security Advisories

Red Hat provides security advisories for each security issue that it addresses, and it uses a common format for all issues. Some advisories do address several security vulnerabilities when they are related by issue or by the effect on a common area of the product. Red Hat has a Web site for advisories by product, an RSS feed, and an e-mail distribution list, providing a lot of flexibility for customers.

In each advisory, Red Hat provides a unique advisory identifier, identifies the specific products affected by name and version, identifies the components affected, and identifies the vulnerabilities addressed by CVE Name [about CVE], with a link to the vulnerability description page maintained by Mitre. An example of a recent advisory is RHSA:2005-043.

Red Hat just starting providing severity guidance in its advisories last month, but still do not provide mitigation guidance. Red Hat provides a list of exactly which packages are updated. For its Enterprise products, Red Hat requires that customers use its up2date tool to retrieve patches.

Red Hat has not yet adopted a predictable patch release schedule, but appears to have a policy of releasing each patch as soon as possible.

Overall, Red Hat is open and transparent in its notifications, but it doesn’t provide much more than the basic information and it assumes customers can and will use its distribution tool.

Novell Suse Security Announcements and Summary Reports

Novell is not quite as consistent in its security notifications. It currently has two types of advisories. The first type is similar in many ways to those issued by Red Hat and is called a Security Announcement. A recent example of this type is SUSE-SA:2005:005. Novell calls the second type of advisory a Security Summary Report, and a recent summary report is SUSE-SR:2005:003. Novell first introduced summary reports in November 2004. Prior to that, similar information was included in a subsection of other security advisories.

Novell has a Web site for advisories and summaries, and there is an e-mail distribution list to which customers can subscribe. Unlike Red Hat, Novell does not provide advisory listings by product, so customers need to examine each new notification to determine if it applies to their product.

Security Announcements provide a unique advisory identifier, identify the specific products affected by name and version, identify the components affected, and usually, but not always, identify the vulnerabilities addressed using the CVE Name. For example, in SUSE-SA:2005:003, Novell describes seven kernel vulnerabilities being addressed, but only provides the CVE Name for two of the issues, making it very challenging to find further details concerning the other five issues.

Novell does provide severity guidance on a scale of 1-10 in the header of Announcements, but there does not appear to be a definition of the different severity ratings that I could find anywhere on its Web site. Novell does provide some additional information, such as whether the affected packages are part of the ‘default’ configurations and what type of attack a vulnerability might allow.

Summary reports are dramatically different in content, providing only a brief description of the security issues that have been addressed. A Novell introduction typically explains that all of the issues are considered “minor,” so less information is provided than in a full advisory. Customers are advised to proactively check the ftp site or to use the YaST update tool to check for updates to their specific products. The summary reports do list CVE Names for some of the issues, but again, not for all issues.

And though Novell considers issues addressed in Security Summary Reports to be minor, one can very quickly find other sources of security information that cast doubt on that assessment. For example, in SUSE-SR:2005:003, two of the ‘minor’ security vulnerabilities addressed—CAN-2004-1125 and CAN-2004-1267—are for the CUPS (printing) component. The National Institute of Standards ICAT list for these vulnerabilities identify both of these issues as remotely exploitable and assign a severity rating of ‘high.’

While the differences between Red Hat and Novell may not seem that great, the differences are night and day for customers. Although Red Hat does it for its customers, it is a real challenge for Novell to compile a full and detailed list of issues and patches for a given Novell product. And for any given individual issue, with the exception of Security Announcements, the amount of detail provided to enable an informed security decision is sparse.

Microsoft Security Bulletins

Since the customer requirements I’ve outlined were driven by extensive customer feedback to the Microsoft Security Response Center, it should be no surprise that the Microsoft Security Bulletins and advisory process are in good alignment with those requirements.

Microsoft provides security advisories to customers for all software security issues. Customers can subscribe to receive e-mail with either a detailed version or a simpler version without a lot of the technical details. Bulletins are also available on the Web, where bulletins can be sorted by product, by severity, or by various periods of time. An RSS feed is also available. These notifications are in addition to the notifications through the Windows Update service.

In addition, Microsoft provides advance notification of upcoming bulletins with only information about severity and affected products, so that customers can plan resources appropriately.

Bulletin content includes a unique identifier, a list of affected products on which the patches were tested, a list of unaffected products, and a maximum severity rating. The bulletin includes an Executive Summary, Frequently Asked Questions, Technical Details and details about modules affected, command line options, and other support information requested by customers. Both the summary and the details sections provide information by CVE identifier and include severities by product affected.

The details section always has subsections on mitigating factors and potential workaround alternatives and their implications.

The former three-level severity rating system was updated in 2002 to distinguish high severity issues that could be utilized by a worm (critical) from those that could not be (important). The full definitions are described on the Web site.

Each patch is available through the appropriate Microsoft update tools and also on a download center.

Finally, Microsoft Security Bulletins are always on the second Tuesday of the month, preceded by the advance notification and followed by an interactive technical webcast during which customers can ask detailed questions.

Conclusions

When comparing vendors or products, all too often the values and benefits are oversimplified into a set of comparison check boxes. It would be easy to put a check mark beside “security advisory” for all of the vendors discussed in this article, but that level of comparison ignores the practical considerations of real administrators managing software in production environments.

The Microsoft Security Response Center function has been in operation since 1998 and interacts regularly with security customer councils that provide focused feedback on their expectations as customers. In comparing Microsoft Security Bulletins to the security notifications of Linux vendors, some of the differences may be attributed to maturity and experience. I predict that, as Linux vendors have followed Microsoft’s lead in other areas, such as longer support life cycles, customers will drive similar changes in the area of security notification.

However, there were some stark differences between the two leading Linux vendors, with the Suse notifications having wide variations in the level of information provided to customers. For any issue only addressed in a Summary notification, they do not provide a level of information to enable customers to easily assess whether their operational systems are at risk and what to do about it.

As with any comparative security discussion like this, I advise you to check up on this topic yourself and draw your own conclusions. I’ve provided several references for you to follow and listed some questions you might want to discuss with your vendor, though I am sure you will add to the list.

Join me next month for the next article in this series about practical security issues to consider for operational environments. I will explore some of the practical security considerations related to security fixes that affect multiple products or distributions.

Best Regards,
Jeffrey R. Jones
Senior Director, Microsoft Security Business Unit