MSDE patches and service packs aren’t easy to deal with. Installs are often different from SQL Server and might even be different based on how the MSDE bits were deployed to the server initially. Microsoft describes MSDE and SQL Server as sharing essentially the same code base, so why can’t Microsoft release one service pack that can be applied to any instance of SQL Server, whether it’s Enterprise Edition or MSDE? Do you have any plans to simplify the process of working with MSDE patches and service packs?
We realize that keeping MSDE up-to-date with patches and service packs is difficult. Although MSDE and SQL Server use the same code base, the way they are used and deployed can be fundamentally different. We’re working hard to devise a specific solution for patching MSDE and hope to have a solution that will let MSDE be patched automatically.
Customers told us that their SQL Server deployments and how they patch them were more straightforward than their MSDE implementations. They needed better tools for identifying MSDE in their environment, and they needed graphical tools that end users could use to deploy patches. With Version 3 of the security tools, rolled into the Critical Update Kit, we incorporate an easy-to-use GUI for these tools so that end users can patch their MSDE systems in a straightforward way. Customers can just run this one tool, and it will upgrade their MSDE instance, independent of how it was installed on their machine. In fact, we’re going to the level, based on customer feedback, of disabling network access by default in MSDE because the vast majority of MSDE applications don’t require network access. This will reduce the surface area of attack going forward. Microsoft products that redistribute MSDE also will disable network access by default and will use only integrated security, significantly reducing their exposure to network-based attack.
Buffer overflows of different types seem to account for many of the SQL Server security vulnerabilities discovered recently. Many people say that buffer-overflow errors should be easier to detect than logic-related programming errors and should be easier to prevent in the first place. How is Microsoft addressing this area of vulnerability in SQL Server?
Our line-by-line security review of SQL Server looked at buffer-overflow issues carefully. We also invested in training so that, going forward, developers and testers would have the relevant information and knowledge to ensure that we don’t repeat these mistakes. In addition, we’ve worked closely with the Microsoft research team to build tools that will help identify these issues in an automated fashion during the development process. The tools generally analyze our code, integrate with our compiler technology, create ways for us to better target tests at the code, and help us to be introspective about what’s going on inside the software.
Buffer overruns are one of many types of ways that attackers can take over a system. But security is much bigger than buffer overflows. It’s about what you’re doing to protect yourself against elevation of privileges and what you’re doing to find other vulnerabilities in the code. Since introducing the Trustworthy Computing initiative, we’ve elevated security to our No. 1 concern. Every Microsoft developer, tester, program manager, and vice president in the company—including myself—has gone through security training. It’s important that we instill this philosophy throughout the organization—it’s really about changing the way we do software development.
What is Microsoft is doing to security-harden SQL Server now?
We’ve re-released MSDE with SP3 included, and we’ve re-released SQL Server 2000—all editions—with the new Super Socket Network Library that eliminates the buffer-overflow vulnerability and copackaged it with SP3. If customers have already patched their systems to protect against Slammer, they don’t need to reinstall these versions of SQL Server. We decided to re-release with SP3 included and to re-release SQL Server 2000 with the vulnerabilities for Slammer addressed out of the box so that customers could confidently deploy new installations of SQL Server and know that they already had these patches installed. In addition, we’ve visited customers to understand requirements better, invested in patch-management solutions and vulnerability-detection tools, and created the security best-practices document that I mentioned earlier.
Prev. page
1
2
3
[4]
5
next page 
