|
Take Charge of Your Own Security (Continued)
But achieving these benefits means that development teams must use Team System, Visual Studio 2005, and the application lifecycle processes defined by Microsoft. It will probably be some time before even established Microsoft shops fully adopt Team System features that can improve security. If you want to go beyond the support offered in Team System, you must investigate solutions from ISVs.
Also, many developers have yet to make the transition to managed code. Whether for reasons of legacy code, language skills, or tradition, it will be many years before C and C++ code becomes fully marginalized. That puts additional burdens on those developers, including those who work at Microsoft, to write code that minimizes the potential of successful attacks.
PreFix, available in Visual Studio 2005, will help find vulnerabilities in C and C++ code, and FxCop includes rules that cover security issues in .NET code. (FxCop has been a free download since 2003.) These are small steps, however, in providing a comprehensive security solution for application developers.
At this time, Microsoft is largely leaving security development and testing practices to ISVs. Microsoft will no doubt start incorporating its own features into Visual Studio, but it's also late to the game in doing so. There's a measure of truth to the adage that secure applications won't help unless the OS is also secure, but there's no reason your attack perimeter should be any larger than necessary. It's critical for developers to learn and apply security tools to application development to minimize the surface area for potential attacks. Every day Visual Studio goes without such built-in tools represents that much more time for hackers to exploit known application vulnerabilities.
The issues described so far are significant. But perhaps Microsoft's most insurmountable obstacle is that security and usability are often at opposite ends of a continuum. The most secure systems tend to be the least user-friendly, while user-friendly systems tend to have significant weaknesses that the bad guys can exploit.
Microsoft has long opted for user-friendliness over security at most decision points—a strategy that has served it well in building market share and becoming the ubiquitous desktop OS. For example, for many years Windows systems were easy to set up, with system defaults that made them open and widely accessible. This spread the use of the platform because it didn't require specialized expertise to do productive things. But the long-term downside of that strategy is that deployed systems can be exploited more easily.
But things are changing. For individual desktops, Windows XP SP2 turns on the firewall by default. Microsoft has also fine-tuned user privileges so that users need access to fewer system and network resources to do useful work.
Finding that ideal balance between security and usefulness is elusive, and neither the platform nor the development tools are there yet. And it's not as though Microsoft starts over with each new version of Windows. Some of the code base is more than a decade old, with all of the warts you expect to find in legacy code. The full code base might never get fully scrubbed.
The definition of a vulnerability changes over time, too. Talented and dedicated hackers can expose a code construct, data structure, or algorithm that looked perfectly secure at the time it was conceived and implemented. An attack can happen years after the code enters widespread use. Even software that looks perfect might eventually fall victim to the use of new technologies.
Take Security Into Your Own Hands
On many parts of the platform, such as the operating system, Microsoft isn't yet where it should be in terms of security. In other areas, such as individual applications, you are at the mercy of the application provider or the internal development team.
But you do have decent control of your own platform security. At least one major end-user enterprise I've spoken to requires all third-party applications to undergo an internal security review before the application is ever purchased. A failing grade means that the application isn't purchased or that the supplier must modify it suitably before it's reconsidered.
While few enterprises have that kind of power over software suppliers, one answer is to do your homework and "just say no" to applications that require open ports or fail tests for vulnerabilities.
As for the OS and your own software, it is long past time for all users to take charge of their own security. Taking security into your own hands is the surest path to protecting yourself over the long-term. Begin by determining your desired level of security and how much confidence you want in meeting that level. If asked, many IT professionals would claim to want security guarantees, something that isn't possible at this time (nor is ever likely to be).
Next, develop and apply a security checklist for all packaged applications, and don't make exceptions. Set the same standards for applications that you buy as well as for those that you build. Also, move to managed code, if you haven't already. Managed code is the future of application development, and it produces higher-quality code. High-quality code tends to be more secure code. You should also be sure to schedule time to research and apply patches to the OS and to any application that issues them. This is neither a waste of your time nor a failure of Microsoft or the application vendor who provided you the software initially.
You should also set aside a small test bed to learn the behavior of viruses, worms, and individual attacks. You'll learn how to recognize attacks by seeing how they affect systems and software.
In the end, the most important grade Microsoft's security efforts can receive is for providing the tools needed for development and IT professionals to identify security holes, patch or otherwise address those holes, and detect intrusions.
There are certainly gaps in the OS, in packaged applications, and especially in the development tools. But Microsoft is providing more tools for you to assess and manage your own security. Using them effectively will do more for your security than Microsoft could ever hope to implement across the entire platform.
About the Author
Peter Varhol is a senior member of the technical staff at Progress Software, and a frequent speaker on software development and architecture at industry conferences.
Back to top
|