Export (0) Print
Expand All
Expand Minimize

Microsoft Small Business Server and Security: It's All About Risk Management!

Published: December 13, 2005

Security Management

By Jesper M. Johansson
Senior Security Strategist
Security Technology Unit
Microsoft Corporation

See other Security Management columns.

Recently I became embroiled in yet another quasi-religious debate about security. (I do seem to attract those for some reason.) This one was about Microsoft Small Business Server (SBS). The basic argument was whether SBS is an inherent security compromise. Well, what system isn't? Security is not a binary decision. It is about a little thing called “risk management.” It is about the tradeoffs between security, usability, and cost. In this article, I will try to explain the concept of risk management in the context of SBS and show that, while yes, SBS sacrifices some security, there is good reason for that tradeoff and there is plenty of security left to go around. Hopefully, in the process, I will be able to lay out some reasons why risk management is the most important concept to consider when protecting your networks.

Small Business Server and Its Market

SBS is essentially a compilation of various Microsoft server products. It comes with a host of really interesting things built in. For instance, it has the operating system, IIS, Exchange for e-mail, fax services, remote access, a host of "wizards" to help you configure things, and even a basic firewall. Spend a little more and you get a copy of SQL Server and ISA Server as well. If you want information on how to secure the whole network there is relatively simple guidance at http://www.microsoft.com/technet/security/secnews/articles/sec_sbs2003_network.mspx. It is everything you need, in a single box. That last part, the single box, is the source of the controversy and the claim that SBS is a security compromise. Before we address that issue, though, let‘s look at the small business server market.

I freely admit I am not an expert on the small business market. Frankly, I have never worked in that market. There are a few things I have learned, though. First, small businesses are just as stingy as everyone else, much like my original environment—the university. Actually, it is not really stinginess as much as it is that there just is not a lot of money to go around and certainly little of that to spend on servers. The idea of buying more than one server is quite appalling to them. In fact, the idea of buying a server at all is a bit alien since you could just give everyone a printer and be done with it. Second, the IT specialist skills in that market are usually basic at best. There is rarely a full-time IT manager in a small business. Third, small businesses need server services. They do need e-mail. They can save considerable money with network printing. Sharing documents over the network is a good thing now that floppy disks are a thing of the past, and everyone "knows" that USB drives are a major source of security compromise (see Myth #8). Many need a Web site to advertise their product. Some could even use dial-in or VPN access.

The problem, of course, is how to deliver all that functionality in a way that a small business, with a negligible IT staff and associated budget, can take advantage of it. In a larger environment there is a set of people who are trained to provide IT services. There is also a budget for multiple systems, the specialized skill to set it all up, and sometimes even a conscious effort to secure it. In small businesses there are not. Prizing $1,500 away from the tight-fisted accountant (or secretary) who does the books for a single server is hard enough as it is, so that single server better come with the software necessary to run it. That is exactly the niche that SBS is designed to fill. (It can also fill the niche for the enthusiastic but cheap IT security guy who wants a home server to play with, but I am not really a target market for anyone.)

To deliver all these features, Microsoft put some very sharp people on a team to integrate several products into a single packaged installation. One of the imperative demands was that all of it fit on a single server, since small businesses would be unwilling to splurge on a multiserver solution and, even if they did spend the money, they would not have personnel resources to manage it. The team also built a large number of wizards to set it all up. For example, if you want to change the IP address on a multirole server, there are many steps to get right. You need to change the address, go into DNS to update it, change the exclusion on the DHCP server, update any Web sites that are mapped to that IP address, and probably reconfigure the firewall. Or, you run the SBS "change server IP" wizard, and it does all that for you. Honestly, this tool would be useful in the core OS itself.

Understanding that few organizations in the small business market have the IT skills to configure and integrate all the things a small business needs made it essential to the success of SBS that as much of this work as possible be automated. The result is a nearly automated installation process which will awe you, and shock you too, if you are a security geek and want to turn all the knobs and tune it yourself. To protect it all, the SBS team ensured that there is a basic firewall—a Routing and Remote Access Services (RRAS) basic firewall, in fact—turned on by default. It is a stateful packet filtering firewall with no content inspection. It does about as good a job at filtering traffic as any other stateful packet filtering firewall, like the ones you buy in a single box to hook up to a DSL router or cable modem, for anything from $99 to $1,500, depending on the color of the box and the number of connections you need. Just like those, which are almost universally based on the Linux Kernel, and therefore need many Linux Patches, this one needs to be updated with security updates for the OS it runs on—Windows Server 2003.

In summary, SBS accomplishes something that would not be possible without that product: it extends the realm of real server computing into a market that would otherwise be largely unable to benefit from server-based computing. Without a server to protect the clients and their data, it is likely that each client would actually be less secure, and hence, make the business itself less secure, than what it can be with a server in the organization.

The Threats

The next issue to be considered is the threats to which a small business is subject. There are many, but let’s ignore some that are not attacks on technology. Those include e-mail worms, which attack people; surfing to malicious Web sites, which attack human mistakes or misguided intentions; phishing, which also attack people; and outright social engineering attacks. All are attacks against humans, and they affect all types of organizations, small and large. There is very little technologically that can be done to stop these attacks, save ex-post facto detection of the threat and removal thereof by some anti-malware solution or other.

There is one additional threat that we will ignore, one which affects everyone. That threat comes from malicious administrators. You can protect against malicious users in various ways, and they are important to address, but you cannot by technical means protect against savvy, malicious users with administrative access. They will eventually do whatever they want. The proper way to deal with that threat is to turn the relevant people into ex-employees.

Which threats remain then? Well, there is industrial espionage. However, it is less likely that this will be targeted at small businesses than at a large organization. We also have government espionage (excluding the tax authority, naturally), but again, that is not a real likely threat against small businesses (again, excluding the tax authority). Then there are organized professional criminals who will attack organizations for reasons ranging from extortion to the sheer joy of destruction and terrorism. Those are plausible threats, but are less likely against a small organization simply because the potential upside is lower than with a large organization.

Finally, we have the most common threats of all, drive-by wormings, a Mack truck barreling down the highway flattening everything in its way in the form of the latest worm. These are extremely likely threats against small businesses, and they are very likely to succeed given the lack of a professional IT staff to protect the systems. In fact, in many small businesses, each system is essentially hanging out there fending for itself, with no protection against these attacks at all. How do these attacks arise? The typical source is a "Security Researcher" (read: "really smart guy with elastic morals, questionable integrity, and dubious intentions") with "a unique approach to enterprise security" (read: "manufactures the very threats he sells products and services to protect against"), who, in the interest of public safety (read: "to show how smart I am and to hawk my products/services") produces a "proof-of-concept exploit" (read: "a fill-in-the-blanks worm-kit that allows any script kiddie in the world to manufacture a devastating worm in minutes") for some recently discovered security vulnerability. The next thing you know we have a worm taking down hundreds of thousands of systems, causing billions of dollars in damages, and dooming the author, should he ever be found, to a court sentence of several hours of community service and about 4,000 job offers.

These worms are indiscriminate. They are not after you. They are after everyone. The objective is simply to cause as much damage as possible. If a particular network is not open to the attack, or not vulnerable, the worm has no hard feelings and moves on. It is one of the more important threats against small businesses today, probably matched only by malicious users.

The Defense

To explain this situation by analogy may be fruitful. If you have been in the infantry service, you may have been subjected to antitank battles. It is a wonderful concept where the individual infantryman gets to play small business, standing in front of a tank, the worm, which barrels down at him at a high rate of speed. To defend against the tank, he has a .223-caliber fully automatic rifle—the infantry equivalent of a pea shooter if you are facing a tank—and, if he is lucky, a shovel. The small business has a virus scanner that is nine months out of date, and, if it is lucky, SBS. The soldier throws the rifle aside and digs a small hole deep enough to hold himself, and maybe a few buddies. The small business sets up SBS and runs the Configure E-mail and Internet Connection Wizard (CEICW), which turns on the firewall. The tank barrels right over the hole, leaving the infantryman unharmed. The worm barrels down the Internet, attacking someone else instead.

Of course, I would much rather be in a fortified citadel along the road, out of the direct path of the tank, with walls a few meters thick between me and the tanks. I would like to replace the .223-caliber rifle with a couple of .50-caliber Gatling guns, some antitank mortars, maybe some antiaircraft batteries, and, for good measure, in case the bad guys have infantry too, some boiling oil to pour down on them. However, manning such a post would require a fair bit more resources and personnel than what I have available to me, and in any case, converting my shovel and rifle to that setup is quite cumbersome.

The same holds true in network security. The main claim is that SBS represents a fundamental compromise because it is based on a single server. Using a single server to host more than one function means that you have to make configure the server to the lowest common security denominator for all the functions it hosts. In other words, you may expose items in one function even if they are not needed for that function because they are needed for some other function. Furthermore, if there is a vulnerability in any one component on the server it exposes the entire server. For instance, if you are running IIS on a domain controller (as you would be doing with SBS) and there is a vulnerability in IIS, you would expose the domain controller component automatically. By contrast, if you separate the two components onto two different servers you expose only one of them each time. The downside is that you have to buy more servers, spend more money managing them, and increase the management complexity. Complexity is in many respects a bane of security. Of course, putting multiple components on a single system is also complex. Thus, the most important thing is not whether you have a complex system, but whether your processes for managing it are up to the task.

The argument often forwarded by opponents of putting everything on a single system, such as SBS, is that it is possible to build a network that is considerably more secure than what you would get with a single SBS server. I could probably build one of those, although the design would be rather complicated and beyond the scope of this article (in a sense, that is the subject of the book I wrote with Steve Riley). So can many others. If I have to, I could probably even do it on a single server, although that would be very hard to do. What I could not do is provide the functionality that you get in SBS, nor could I do so at a cost that comes within an order of magnitude of what SBS costs. Therein lies the fundamental tradeoff. SBS is designed around a set of processes for managing the complexity of putting multiple components on a single system. Those are processes the system architect would have to duplicate, or at least replace, if building a custom solution instead. Doing so is certainly not impossible, but it is definitely out of the scope of the vast majority of small businesses. The idea there is to manage security appropriately to their situation.

Good Enough Security

If you are so inclined you can have security, where "security" is defined as "the state of not being exposed to danger." It is really easy. First, ensure that you cannot be attacked from the network. Turn on the firewall and turn off all services. There are no longer any network attacks possible. Now ensure that no malicious users can attack you. The simplest way is to remove all the users and their ability to log on to the system. Next we need to secure the box. Go down to the local hardware store, buy a tube of epoxy, and use it to fill all the orifices you find on the back, front, top, sides, and underneath the computer. Every single one of them, from the USB ports to the power jack, can be used to steal data from or compromise your computer. Finally, take whatever epoxy you have left and glue a chain on your new boat anchor. At least that way it is good for something, because it is now fully worthless as a computer.

When I was a professor, the concept of "good enough security" used to be taught in universities. Now they mostly seem to teach how to hack systems or how to irresponsibly disclose vulnerabilities instead, since that seems to be more attractive—but far less useful. It is unfortunate that this distinction has been lost because the fundamental fact is that security is about risk management, nothing else. You do not need perfect security; you need good enough security. This is further complicated by the basic fact that security management is largely about spending good money to make sure nothing happens. The security guy is the one who goes to the finance folks and asks for huge sums of money under the promise that if they give it to him, they won't notice where it was spent. The measure of success in security is not to get attacked (which is different from not noticing that you got attacked). It is virtually impossible to trace the lack of attack to success in security, as opposed to sheer luck or maybe faulty detection mechanisms. Couple these assertions with the issue that nobody that runs systems gets calls when the printers are working, when e-mail shows up, and when the files are actually there, and you have a dire need for "good enough security."

Good enough security means that you have mitigated the threats you decide you cannot live with and can live with the mitigations instead. In some cases, you decide to live with a threat (industrial espionage, for example) instead of living with the mitigation (epoxy in all the orifices), and therefore accept the risk. The key here is the risk management philosophy that you as an organization decide to adopt, and the threats you deem valid for your organization. All computer products are designed to a threat model. Sometimes that threat model is woefully inadequate; sometimes it is very specific. SBS is no exception, and in this case, it is designed to a very specific threat model—one specifically geared toward small businesses that consider themselves not to be subject to threats like industrial espionage, potentially malicious administrators, and others that are more likely to afflict larger organizations with more resources to fight them. If this threat model does not fit yours, if this does not provide good enough security for you, you need to buy another product.

Conclusion

The point is not whether you can build something more secure than SBS. There are many that can, and a few that can build something that is as useful, or at least almost as useful, as SBS, and still at least as secure. The point is how much time, effort, and money it would cost you and how much functionality you would give up in the process. The truth is that most people would fail to build something that has the functionality or the security of SBS—particularly if they tried to build it on a single system. To that extent, SBS actually significantly improves the security posture of the organizations it is designed to serve. It does something for them that they would be unable to do: it gives them the security and functionality benefits of a server-based computing model without exposing them to unnecessary risk subject to their threat model matching the one to which SBS was designed.

The fact that we are even having this debate points to a disturbing trend in information security though. If you go to a hardware store to buy a lock for your house, you will never see one that says on the packaging: "this lock prevents burglaries." If you did, you would not buy it, because you would immediately realize that the manufacturer is making a claim it cannot possibly meet. This would make you very suspicious. Yet, in information security, we see software and hardware all the time that claim to be "unbreakable," to make your network "impenetrable," or to "ensure the security … of your information." Obviously, none of those claims are true either; yet people buy these products. The same sense of innate understanding of security as a risk management discipline that guides us through our lives seems to become lost once we start dealing with computers. We need to get back to the basics. Get back to realizing that although we cannot be secure, we can be protected. And to be protected, we need good enough security.

Postscript

If this article reads like a marketing pamphlet about SBS, that was not the intention. The intention was to highlight that security is not a binary field. It is not that we are either secure or not. The point is that we can be as secure as we wish to be, but if the level of security does not match your risk management philosophy, it will either be inadequate or disrupt functionality. Neither is acceptable. You need to judge for yourself whether your risk management philosophy matches that of a software product you are considering. If it does, evaluate other criteria. If it does not, evaluate whether you can make the product match your philosophy at a cost that is lower than that of competing products. If so, evaluate it on other criteria. If the product cannot be made to match your philosophy, consider other products and be prepared to pay for one that matches your philosophy.

As always, this column is for you. If there is something you would like to see, please send me a message by clicking “Contact Us” at the very bottom of the page. You may also contact me through my blog. You will find a thread there where we can carry on discussions about this article.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft