Reduce Your Risk: 10 Security Rules To Live By
At a Glance:
- Security is not black and white
- Don’t sacrifice security for compatibility
- Technical and nontechnical users pose a threat
- Ignore excessive product claims
- There’s no magic bullet
In the 15 years I’ve spent working with Windows, I’ve watched the IT landscape progress from a world where General Protection Faults and bad drivers were the primary
concern to a world where "Patch Tuesdays" and defensive computing have become the norm. Along the way, I’ve gathered some valuable knowledge. From my experiences working at Microsoft, time spent with customers, and stories I’ve heard from colleagues, I’ve built a strong background in Windows® deployment, management, and security—especially fundamental aspects of Windows security. I understand how these concepts fit into the ideal world (which is often the context of discussions about best practices) as well as the more relevant real world where enterprises have their own needs and want Windows to adapt to their requirements.
Spyware, viruses, rootkits, and a growing amalgam of other types of malware threaten the very core of the global computing infrastructure. As the sheer amount of malware increases and administrators deal with the chronic gap that exists between the exposure of an exploit and the release of a signature file or patch to address or prevent the problem, most organizations managing a significant number of computers are left with very few options on the table. So what is any large organization supposed to do while managing its system?
First, remember that security deals with risk. When you manage security you must strive to reduce unacceptable risk while keeping the impact on workflow of the organization and total cost of ownership (TCO) of the infrastructure to a minimum. The TCO includes money, time, system resources, efficiency, lost productivity, and so on. You can look at it this way: security management, at its core, is risk management.
One of my favorite documents—for its truth and accuracy on a number of security fronts—is the TechNet article "The 10 Immutable Laws of Security
". In similar vein, here I’ve outlined what I believe to be 10 key points an administrator should keep in mind while working on a security management plan.
1. Security is not black and white.
One of the key tenets of security management is that you are in the business of risk management. There is no surefire firewall. There is no impermeable solution. Your plans must consist of a cross-technology, cross-specialty, multitiered approach. From your network to your desktops, from security software to security features built into the operating system, you need a stack of solutions (a strategy referred to as "defense in depth"). You must understand how each component protects your infrastructure and how each might be vulnerable. You need to know how best to protect your end users, and how to protect your infrastructure from those end users.
Most importantly, remember that security management is a strategy and must be dealt with persistently. There is no "complete" solution and the work is never finished. There is no gauge to tell you that your network or systems are now secure or not secure. And it doesn’t always get easier by simply adding more solutions to the stack.
You are never totally secure. There is never a point when you can say the infrastructure is secure and walk away. Why can’t you be 100% secure?
- Because people are involved.
- Because users make mistakes.
- Because administrators also make mistakes.
- Because systems don’t always get updated when they should.
- Because software itself is never completely secure.
This is a fundamental concept that needs to be understood. There are too many variables and too many dependencies. A false sense of security can truly be your worst enemy.
2: The road to least privilege is a long one.
As Windows Vista™ and its collection of security enhancements near release, more and more is being said about running with least privilege. This phrase means different things to different people. I like to describe least privilege as follows: users should be allowed only the privileges and rights on their local system and the network absolutely required for them to complete their day-to-day tasks.
All too often, though, users are still running as Administrators on their machines. The main reason is that, while it will get easier with the new User Account Control functionality that is planned for Windows Vista, many roadblocks still exist to running as a normal user today. That doesn’t mean it can’t be done.
If you intend to forcibly take end users down from the Administrators or Power Users group, first make sure that someone in your enterprise has felt the pain firsthand of running in the Users group—especially on a mobile system. Simple tasks like refreshing your IP address or repairing your wireless connection (which is critical on mobile systems) don’t work without tweaking the security policy. Adding hardware or installing software is even harder. ActiveX® controls just silently fail, generally with no notification that you don’t have the necessary privileges. Providing incomplete least privilege is counterproductive.
That said, you should focus your endgame on how you can successfully move your end users to the Users group for their day-to-day operations. There are numerous advantages to the Users group. Members can’t disable or modify most firewall, antivirus, or antispyware solutions. Nor can they install unauthorized software or hardware. But you need to understand what will be required to allow the necessary privileges.
When users move from Administrators or Power Users to the Users group, the reduction in their security footprints is massive. They move from a world where one malicious Web page can destroy an entire system to one where the same page may harm their profile but leave the rest of the system intact. Equally important is that you gain complete control over what the user can do within Windows. Learn and understand exactly what it is that is keeping you from moving your end users to the Users group, and then find out how you can conceivably work around these obstacles.
3: Sacrificing security for compatibility is a bad idea.
I’ve seen plenty of organizations create what, in my opinion, were significant security risks by easing file system and registry access control lists (ACLs) to a point where the system’s security footprint could no longer be assessed adequately. The security policy and permission lines that were drawn between the Administrators and Users groups were not drawn arbitrarily (well, not completely arbitrarily) by the Windows team.
Every step you take to open security restrictions in order to make an application work is a potential security loophole. Choose wisely and understand the risks of each decision before going down a rabbit hole. An application that is updated—or manipulated—to behave within the constraints of Windows security is preferable to an application that makes Windows more porous in order to accommodate the software’s needs.
4: Using the Windows Power Users group is never an answer to least privilege.
Relaxing your ACLs can make your users more powerful than you want—or, more dangerously, this can create an avenue for malware to take down systems. The Windows local security group, called Power Users, exemplifies this problem. Several known exploits allow Power Users to become Administrators. And Power Users can take down critical components of your defense strategy by disabling services, such as a firewall or antivirus software. Meanwhile, the increased abilities given to accounts in the Power Users group allow malware to do far more damage to Windows than could be done with Users group accounts.
Consider the following if you are planning to assign end users to the Power Users group:
Will users be inclined—or inconvenienced to the point that they will be inclined—to try to make themselves Administrators?
Are you using the Power Users group to reduce your attack surface against Windows?
Are you using the Power Users group for compatibility with legacy apps that do not behave well when the interactive logon is in the Users group?
If you answered yes to these questions, consider that a recent study showed that systems on which the primary user was a member of the Power Users group were susceptible to 19 malware threats the system was exposed to—the same number as systems where the primary user belonged to the Administrators group. Also note that technologies exist that allow you to elevate just one application’s privileges, rather than requiring the user to be overly privileged at all times.
5: Your enterprise is only as secure as your most- and least-technical users.
This point may seem obvious, but it can be easy to overlook. A key component of your infrastructure is your users. Your security strategy impacts your end users and affects their actions. If your security policy is too oppressive, more technical users are likely to seek ways to set themselves free. Sure, you can put organizational policy into play, but you need to take a step back and examine the underlying reasons your end users don’t want what your organization has prescribed. Do they have good reasons for wanting more power? Is there a happy medium you can achieve?
Local Administrators can completely defeat Group Policy. Users who have the local Administrator password can do the same, so that should be a guarded secret. And technically savvy users can often thwart security just as readily by bypassing the primary operating system using software such as Windows PE (see Law #3 in "The 10 Immutable Laws of Security"). If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore).
On the other end of the spectrum you have to worry about your less-technical users and your ability to control their risky behavior. In a world of phishing, spam, and other forms of malicious trickery, it’s not enough to simply update and lock down systems. You must also educate users. If they run in the Administrators group, this is critical. If they run in the Power Users group, it is equally important. If they run in the Users group, it isn’t as critical—at least to the security of their local system—but should still be a part of your defense strategy. Malware that replicates through e-mail or an instant messaging client can still execute under an account in the Users group. It can then propagate to other users who may be susceptible to further damage if they are running with elevated privileges.
6: "Not knowing" is often your biggest exposure point.
The first step in securing the infrastructure is actually understanding the infrastructure. How many different versions of Windows are you using? What management software are you running? How do you handle Windows and Office patch management? What antivirus, antispyware, and third-party firewall software do you use? How many versions of each product are you using? How secure are your systems—in terms of both network/Internet accessibility and physical accessibility? Are your signature files current? Do your users use IM or e-mail clients you don’t know about?
How about your end users? Are they running as Administrators, Power Users, or Users? Do they have strong passwords, and do they change passwords regularly? Do you audit your systems to identify unmanaged software? (Software you don’t manage centrally can pose both security and licensing risks.)
Is your network wireless? If so, it is probably a good idea for you to use Wi-Fi Protected Access (WPA). Wired Equivalent Privacy (WEP) should not be used on a business wireless network since it does not provide adequate security.
It’s important that you perform regular audits of your infrastructure. This will help you to know your hardware, your software, and your overall network. Commit this information to documentation in a location known to your entire team and upper management. Work to define a strategy to reduce or mitigate every attack vector you find.
7: If you trust a single piece of security technology to do everything, you’re making a big mistake.
Remember that no single vendor in the security space has "the solution to your security needs." Your strategy should be to build a defense-in-depth—a thorough arsenal of firewalls, antivirus, antimalware, antispyware, application lockdown software, and so on. You need to select the pieces that will define your security strategy, but don’t expect that one piece of the puzzle can obviate many others.
In today’s world you must layer your solutions: good systems management software, good security management software, and a reliable patch management strategy. Seek out the best solutions in each category, basing your decision on capability, not on price. The best solutions may or may not be the most expensive solutions. Likewise, they may or may not be the cheapest. They also might not be the best-known or most popular name in the space.
To sum up, stack your defense forces aggressively—because the larger your enterprise, the more forces there are being aggressively stacked against you.
8: Any vendor who claims "100% security" is probably lying to you.
I remember when a certain database vendor started using the term "unbreakable" to describe its software. Ludicrous! That’s like inviting criminals to break into your customers’ systems.
Similarly, you also should closely examine any security vendor who makes overly strong claims like "bulletproof," "unbreakable," or "impervious." This is marketing speak and nothing more. This probably isn’t news to you. But make sure those you work with maintain a discerning eye and don’t take such claims too seriously. Always remember that no solution is 100 percent secure, and if anyone tells you his solution cannot be penetrated, he is either lying or doesn’t really know what he is talking about.
9: Not deploying updates is expensive.
I hope we’re moving beyond this era to a degree, but I recall when many customers would hold off on deploying a patch until it had run through a suite of compatibility tests. This process could take a considerable amount of time, depending on the suite of applications in use.
Sure, it’s OK if you wait—as long as the system you’re waiting to update is not on a network connected in any way to the Internet. (But, as you know, very few systems are not connected these days.) Otherwise, you need to update aggressively. It may appear you can defer updating for a brief period, but as we’ve seen in the occurrence of zero-day exploits, that period is shrinking. And don’t discount this advice just because you have an isolated network. If a system that has been on the Internet (such as a laptop) can connect to your network, it can potentially infect the rest of the network.
You should aggressively analyze the threat posed by not applying any patch or update. Unless the threat is effectively benign or the systems being deferred are on a completely isolated network, apply updates as broadly and as soon as possible. Part of your risk management strategy should include being prepared to rapidly recover systems should they, or the applications running on them, prove more harmed by the patch than threatened by the vulnerability. Remember, patch early and patch often.
10: The next big thing probably won’t do it all.
The security space is evolving at a breakneck pace. The most important thing to remember is that there are hundreds of security technologies out there—and none of them is the magic bullet. Even Windows Vista, with many significant security-related changes, won’t be a perfect solution. Applications will require rewriting to behave optimally, installers will still require administrative rights, and you won’t necessarily have the ideal solution to break enterprise users from the administrative logon habit.
Any new security offering should be evaluated, tested, and compared. Do not expect to find one that solves 100 percent of your security headaches, or provides a 100 percent solution to any one problem (I made this particular point earlier, but it’s worth repeating). Just keep in mind that while future products will offer improved technologies, it will still be just as unlikely that any product will offer a complete solution in a single package. Understand the risks and benefits of any solution, and what additional components you may need to put in place. And realize that as new threats arise, new additional solutions may be required.
Threats to Windows systems are far more advanced today than they were just a few years ago. This means Windows administrators are working harder than ever to protect their systems from more attacks coming from more directions. It’s hard work and not always guaranteed to be successful. I hope these rules—and the 10 immutable laws that inspired them—can help guide your daily risk management decisions. The future promises to pose more rapid, more surprising, and more dangerous attacks against Windows systems. Be prepared. Be proactive. Be secure.
Wes Miller is the Product Technology Strategist at Winternals Software in Austin, Texas, where he focuses on all of Winternals products, including Protection Manager, the Winternals Enterprise Security product. Previously, Wes worked at Microsoft as a Program Manager and Product Manager for Windows enterprise deployment.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited