The Microsoft Security Debate, Part Two

Roberta responds to the critics of Microsoft's methods.

Last Wednesday we presented two essays from folks with security experience, who made the argument that Microsoft continues to miss the mark on security. Roberta Bragg was going to respond to both articles in this edition of Security Watch, but her comments are too lengthy to fit into one newsletter, so I've decided to divide them up: Her response to the first critique will be today, and the response to the second letter will come next Monday. And buckle up: Roberta's response is long, but well worth the read.

As I mentioned previously, we're also working on the best way to publish the other excellent essays received. We'd like an interactive format, so that the debate can continue. That will be appearing shortly.

The original essays can be read here: http://mcpmag.com/columns/article.asp?EditorialsID=675.
— Keith Ward
Editor,
Security Watch

Roberta Responds to Robert Michael Slade
It was great last week reading all the marvelous replies to Keith's request. Without exception, each respondent had good points. I found very few cases of vitriol or wild claims. Space, however, doesn't allow me to respond to each and every author.

In the essays that were published last Wednesday, the following points were made in the first essay by Robert Michael Slade. I'll respond to each.

Point 1. Security is a fad in the marketplace and within Microsoft.

The World Net dictionary defines fad as "an interest followed with exaggerated zeal", while Webster's says it's a "temporary fashion or manner of conduct." I presume that you mean interest in security will fade soon, both from the marketplace and within Microsoft. Frankly, I think we'll experience far too many worms, viruses and attacks for interest in security to fade. And I don't think Microsoft will stop trying to make their products more secure either. If they should drop the ball, they'll be eaten alive.

But I do agree that security is, in many cases, followed with exaggerated zeal. Some people fasten on one small issue or pick some rhetoric-spouting malcontent to follow. But zeal isn't necessarily a bad thing. There's nothing worse than a twit who yesterday couldn't spell security and today thinks he knows it all, but I'll take that any day over complacency.

If the security newbie keeps at it, they'll mature. They'll take the time to do the "long, hard, boring work," as you put it, of learning what security is. They might even learn how to apply it to more than one OS. They'll secure their network, PC, PDA, code and so on; perhaps they'll even participate in "changing the corporate culture central to real security". They'll be able to identify for themselves what needs to be done. If they decide to do something else, well, that's a good thing too. Maybe their talents lie elsewhere. The important thing is that, in whatever capacity, everyone strives to do the things that combined will make computing more secure.

2. You say that security isn't a "one-off" deal. Related to this, you say that Microsoft has a policy that requires input buffers to be crafted to avoid buffer overflows, yet we still have them.

I'm not sure what you're getting at here. By "one-off" I assume you mean that Microsoft can't get away with just fixing one thing one time, or in doing good work this month or this year and then slacking off. I don't think they're attempting to do that. I've seen a lot of activity on the security front over the last several years. Is it enough? It's never enough. The problem is that an attacker only has to discover one flaw. Microsoft has to discover every flaw and never, never make an error again. Sound like something you can do?

And about that zero buffer overflow policy: We have a law in the U.S. that states when the light turns red you're supposed to stop. Yet every year people die because someone doesn't stop at a red light. Sometimes it's a deliberate "I don't care" action on the part of the driver, sometimes it's a momentary lapse of attention, sometimes it's a lack of judgment as in "the light turned yellow and I thought I could make it" mistake. As most people know, policy is great, policy is a start, but it's very hard to prevent an action by creating a policy. You have to enforce it, you have to educate people, and you have to assume that sometimes even that isn't enough.

I'm not trying to excuse Microsoft, or some lowly newbie or careless coder. I'm just saying get real. Yes, Microsoft should keep working to make their products buffer overflow-free, but I don't think you're going to find any commercially available product of any size perfectly free of coding error anytime soon. Yes, let's pressure Microsoft to meet this goal, but let's not act surprised, nor damn them to hell because they're not there yet.

3. You say "simplicity is security…Complexity, obscurity, and labyrinthine structure are problems."

I agree. Unfortunately, we often require complex products to do complex tasks. Or we require complex products because the simple ones that can do the tasks we need to do are too complex to operate, or plain just take too much time. Remember when computers were so simple that it took a mathematician to operate them? Remember when the interface was blinking lights? Punched cards? Command lines? A simple cart with wheels can be dragged by a man and transport another person across town. Most of us have to choose transportation that is a little faster—we have a greater distance to go.

I also agree that complexity is also the bane of security processes. If it's difficult to apply security, then few will do it. The process of security is easier or more difficult depending on more than the OS. It also depends on the number of computers you must work with, the people who use them, what you're securing them against, and what specific security requirements you have. Securing a Windows system, or any other, isn't horribly difficult. Securing thousands of them is. Part of the complexity that is security is this problem. We have more than one server or desktop system to worry about now.

In addition to complexity, you say you find obscurity a problem. I don't find Windows products difficult to use. I don't find them difficult to understand. When I need to do normal tasks, the GUI explains itself. When I need to do something more complex there's a wealth of documentation, tons of newsgroups, thousands of experienced administrators, programmers and others to turn to.

4. You state "Secure operating systems (and secure systems) have a clearly recognizable and identifiable security structure…Windows, and other Microsoft products, have an adhoc collection of security-related gizmos and gadgets. This includes, strangely enough, the various security management tools. The simple fact that there are so many tools for managing security is rather telling."

Once again I'm mystified. I see a security structure in Windows. I see components such as Kerberos authentication, discretionary access control on objects such as files, folders, Registry keys, printers, and Active Directory objects, a reference monitor that arbitrates the authorization process. I see protected areas of the OS. Do I think it's perfect? Invulnerable? No. But I see a structure, not just a collection of gizmos and gadgets. I see in modern versions of Windows the things held up as paragons of security structure by both ancient security oracles and today's recognized security experts.

Let's also talk about those many tools for managing security. Have you spent much time with or studied Windows 2000 Server or Windows Server 2003 domains? In these domains I can take a single tool—group policy—and implement password policy and user rights. I can shut down inessential services and prevent non-authorized individuals from starting them. I can restrict membership in groups—even preventing a local administrator from making permanent changes to local computer group memberships. In some cases (Windows 2003 and Windows XP) , I can establish a Software Restriction Policy that dictates what software can and can not run on domain member computers. I can write IPSec policies to protect communication between computers, and set Public Key Policy to provide autoenrollment of certificates. I can also, should I choose, enforce standard permissions on files and Registry keys.

With this single tool, not only can I do all of these things and more, I can make different choices for different computers and users. I can implement and enforce security automatically across thousands of computers and users in the time it takes the data in the Active Directory to replicate across my enterprise. And if I don't have a Windows Active Directory based domain? Well I can do the same thing with the local Group Policy of a computer. Want me to make it easier? Well, then, I'll create security templates and apply them via a script. Oh, pardon me, that would require a separate tool. And what if I have a very large environment and want to provide role separation and least privilege? Well, now I can delegate control over various parts of my infrastructure to non-members of the powerful administrator groups, essentially creating custom groups that can only perform part of the administrative job. Then, oh yes, here's where all those tools come in. The security tool structure of Windows is modular, and I can build a tool that only has those parts that these mini-admins need.

Is all of this getting too complex? Maybe you'd prefer that all these duties be spread amongst a large number of full-fledged administrators instead of implementing least privilege and role separation, which would result in giving a large number of people absolute power in the enterprise. Perhaps that is the simple security model you desire?

5. You say that security is a people issue, but Microsoft interfaces bury important settings in a bewildering variety of locations and provide scant documentation; what's there is misleading. We're supposed to trust Microsoft to provide what is right for us.

I'd agree that security is a people issue. And I'd agree that documentation is incomplete in areas that I'd like to know about. These are separate, yet entangled issues. Documentation is getting better. We need to get people to use it. And some security practices can't be explained in two words or less. It's a big problem when attempting to secure complex systems. If you don't need the complex system, then don't use it.

I'd even go so far as to agree that some stupid mistakes were made and probably will be made in the future. Security is a people issue, Microsoft is made up of a lot of people and a lot of people use their products.

And I think that yes, there are some settings that aren't immediately obvious. After all, you have to know that you need to set them, then you have to know where they are. I'll agree that even an experienced administrator is not going to find something by using the hunt and peck method. And I'll agree that the location of every setting is not intuitive. I just don't think someone at Microsoft is intentionally making things harder. Could they make it easier? Sure. But I'll take some responsibility; I'll invest the time it takes to understand how to do things today. Not sit back and whine that it's too hard.

Slade points to two security vulnerabilities and Microsoft's response. Specifically, he mentions IFRAME and the ability of phishers to take advantage of the URL username:password structure to trick people into sharing confidential information. He contends that users should have been educated to solve the latter, and that that Microsoft should have just banned autoexecute to solve the former.

It seems Microsoft is damned no matter what they do. While I have to agree that education is an extremely useful tool and necessary if we're going to protect our computing infrastructure, education is a slow process. Meanwhile we need some real controls. No matter what controls are put in place, they won't solve all the problems, and they're bound to cause someone grief. It's very difficult to take away features when someone's program or business depends on them.

Did Microsoft do the right thing? The way I read it, they corrected a problem with their code that didn't perform appropriate checks on scripts run from within an IFRAME. On the URL issue, they removed the ability to use username:password@ in a URL and then returned the ability only if the username and password are passed as parameters in an Open() call; for example, in a Web service application. Did they do the right thing? I'm not seeing complaints anymore about phishing attacks—are you?

Could security be made easier? Of course it could be. But I don't believe it's purposefully obscured, nor am I bewildered by it. I don't find important settings buried in a bewildering variety of locations. I don't find all securing or using security in Windows to be as simple as driving a car, but I don't find it the equivalent of guiding a space ship to Mars, either.

6. Microsoft is working on making their products more secure but they don't "get" security.

Well, thank goodness. I thought I was in for a lecture on how they haven't done nothin', no how. Actually, I don't really care if Microsoft gets security (whatever the heck that means). I do care about whether they're working on making their products more secure. Do they have a commitment to continue to do so? Is there solid documentation that helps me secure any network that incorporates their product? Are they doing a better job as time goes on? Are more people more aware of how to secure Windows? Are more people doing so? Are there lots of people evangelizing security? The answer to all of these questions is yes!