The system rates each vulnerability as Critical, Important, Moderate, or Low. [Editor’s note: See Table 1 for a definition of each rating.] We believe that customers who use an affected product should almost always apply patches that address vulnerabilities rated Critical or Important. Customers should apply Critical patches in an especially timely manner. Customers should also read the security bulletin associated with any vulnerability rated Moderate or Low to determine whether the vulnerability is likely to affect their particular configuration. For more information about the rating system, customers can see http://www.microsoft.com/technet/security/policy/rating.asp.

Security patches are cumulative patches, so the customer just needs to apply the latest patch. They also need to apply the latest service pack. Service packs are broader than security patches: They include bug fixes and, sometimes, administrative settings and other security-related functionality, such as the Watson reporting functionality in SP3. It’s important for customers to be on both the latest service pack and the latest bulletin.

SP3 contains numerous security fixes for SQL Server 2000. Can you detail just how SP3 addresses security?

SP3 is a cumulative service pack that includes everything we’ve done in SP1 and SP2 as well as all security releases and public QFEs that we’ve announced. SP3 was the result of a 3-month code review that also resulted in several security fixes, a new chapter on security best practices in SQL Server Books Online (under "Administering SQL Server, Managing Security"), a valuable Security Checklist (available at http://www.microsoft.com/sql/securingsqlserver), and a security white paper, which we’ll post in May.

We did an exhaustive code review, developed security threats, and devised plans to test a number of other functions such as cross-database ownership chaining. Customers will see more evidence of this work in Yukon.

So SP3 addresses different potential security vulnerabilities for which Microsoft might not have released a prior hotfix or QFE? If customers’ primary concern is security patches and they were up-to-date with all the most recent security hotfixes, they’d still need to install SP3 because it addresses other vulnerabilities?

Correct. Customers first need to get MS02-061 applied on their systems as quickly as possible to protect themselves from possible Slammer variants. Then, I would highly recommend customers develop test and deployment plans for SP3, although we realize that’s a more complex process and customers have to do internal testing before they deploy the service pack.

Many companies still use SQL Server 7.0 as their primary platform. If SP3 is the culmination of the security fixes for SQL Server 2000, what is your intended release time frame and delivery mechanism for a comparable service pack for SQL Server 7.0?

When we find a major vulnerability in SQL Server 2000, we go back and evaluate whether SQL Server 7.0 is also vulnerable. If so, we issue a security bulletin for both products. MS02-061, for example, addresses both versions. We’ll continue to monitor the QFE trends and customer feedback for SQL Server 7.0 and determine whether an additional service pack is required.

At a recent SQL Server conference, you said, "Success can't be measured by whether or not a patch had been released and was available to our customers. Success needs to be measured by whether or not our customers were affected." How, specifically, can Microsoft help protect its customers, and how will you measure whether you’re successful in doing that?

We’re working on patch-management improvements in the following areas: thoroughly testing patches with customers and ISVs, packaging patches for convenient installation, making patches automatically and manually deployable, reducing reboots required when patching, letting users uninstall patches, providing patches in local languages, continuing to ensure that patches are cumulative, continuing to include all patches in the next service pack, and investing in detection tools.

The feedback we received is that we have to measure ourselves not by when we make security patches available but by when customers deploy them. To that end, we developed a set of tools—SQL Scan and SQL Check—that customers can run to identify systems vulnerable to Slammer. We also developed SQL Critical Update as an easy-to-use tool to deploy the corresponding security fix for whichever service pack customers have on their system.

Going forward, we intend to provide this functionality through tools such as Microsoft Baseline Security Analyzer (MBSA) and automatic update services. For example, we’re investigating taking technologies such as Windows Update (WU) and broadening the scope beyond the Windows OS. Patch-management tools are a focus not only of the SQL Server team, but also of Microsoft as a whole because we’ve received clear customer feedback: Don’t create solutions that are product specific. Customers need tools that help them manage their entire environment and all their applications. We’re investigating how to support deployment of security patches by using the Software Update Services (SUS) and WU infrastructures, and we’re confident that this integration will make it a lot easier for customers to deploy our patches. Right now, we’re making sure we have all the architectures and pieces in place and talking to customers about their exact requirements for a broader tool set. But it’s too early to speculate about exactly when those tools will be available.

Prev. page     1 [2] 3 4 5     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Here's another reason why SQL Server support staffs don't immediately apply service packs. Just because a service pack is available doesn't mean that it is completely tested and error free for your systems. We have a server that we just applied SP3 on last week. Immediately after the upgrade, we found applications that used to run in 2 minutes running over 55 minutes. After running and re-running sp_updatestats, we had no improvement. fter running Update Statistics TABLE with fullscan (a supposed solution if the SP_updatestats doesn't help), we again had no improvement. After studying all other possible causes, including memory settings, we could find no solution. I finally uninstalled SQL Server 2000 with SP3 (sure would be nice to have an uninstall) and then re-installed with SP2--the problem immediately went away, and we had our 2 minute response time. Now, you might say we could tune our applications and add indexes to solve this. Probably true. However, when I upgrade the server to the new and improved service pack, I shouldn't have to retune the performance of software that we have installed at 100+ customer sites. Therefore, you can see why a DBA might be reluctant to start running new service packs when they are announced as available. Beta testing service packs is not a cost-efficient endeavor.

Thanks..Ted Henderson

Ted Henderson- April 28, 2003

The ongoing emphasis by Microsoft on not using mixed mode authentication is particularly frustrating. Microsoft needs to do a better job of motivating 3rd party software vendors to support Windows authentication. NOt only don't they support it now, but when you ask when they will your question is met with silence. They have no plans to move to it. It is these vendors that make the decision for us. We have no discretion in choosing our authentication mode! Kay

Kay Conheady- May 01, 2003

To the question of why DBAs didn’t apply the patch Mr. Mangione responds, “The key will be to make these patches easier for customers to understand and deploy..." But problem is that Microsoft is becoming a victim of its our own “ease of use” success. So I was very disappointed to hear this response.

Lets be honest, “ease of use” is a double edged sword. On one side we have a product that should take care of mundane tasks BUT on the other it can dumb down a shop, lower everyone’s salaries, and ends up causing a downward spiral (dumb people doing dumb things requiring even more “ease of use”) eventually leading customers to dump SQL Server for more robust products (products that require skilled keepers). I have experience seeing this happen. Its to the point where many IT managers consider SQL Server DBAs to be mere babysitters preferring Oracle DBAs for the “real” work. And I was even been told by a MS SQL Server evangelist that for enterprise class shops they would recommend hiring Oracle DBAs.

IT shops are not hiring qualified people for MS products because MS pitches the idea that its products are self-maintaining and requires only semi-skilled labor (read as lower wages/cost). I would really like to see an honest discussion about if this minimally qualified work force is where we want to take things or not. I think if this trend continues the creative people in this field will leave perhaps for other careers or other platforms. And if we don’t want to be replaced by monkeys or robots, having all our salaries lowered to minimum wage, and work in dreadfully boring spaces with dreadfully boring people then how can we improve SQL DBA training/certification? Currently, the training and cert programs are not well respected nor do they adequately prepare one for being a DBA/database developer. BUT I don’t see anyone talking about this issue! At least not in this magazine.

Mike- May 01, 2003

 
 

ADS BY GOOGLE