Web Informant #295, 24 July 2002:

Federated identities create new security risks

 

http://strom.com/awards/295.html

 

The latest threat to corporate networks isn't some gang of script kiddies based in a far-off land, sharpening up their coding skills and exploiting your unsuspecting Windows server security loopholes. The trouble lies within, and this new threat has to do with the loosely coupled web identities called federation that is being bandied about.

 

The notion is simple to explain, but complex to implement, and even harder to implement securely. Federated identities are portable across normally impervious enterprise boundaries, such as your own directory server, firewalls, and other perimeter security devices. Why bother? Well, if you are developing any web services applications, you eventually are going to want to have federated identities. You have data that you want to share with others, and you want some of their data to incorporate into your own purposes. A good example is the notion of several different companies cooperating on a single transaction (such as booking a trip that involves airlines, rental cars and hotel rooms: the federated identity could mean a single sign-on and linking all these transactions on different sites). A friend of mine working for a health care provider spoke to me about the 150,000 users on his network and most of them are working for other companies. Right now he has a mess on his hands managing all the network login identities. With federation, he has a prayer of making some sense of this.

 

So at its heart, federation means trusting these foreigners to come across your borders and opening up your services to their bidding. In other words, as security expert Dan Geer said in a recent speech, you treat HTTP as another transport layer, and share your data freely. It used to be that your corporate network perimeter contained all your internal transactions: with federated identity, that isn't the case. And as you might imagine, this creates some security issues.

 

I guess we wouldn't be in this pickle if everyone hadn't jumped on the web and used port 80 as a drive-in window on our corporate network resources. But this has opened things up so badly that it is more akin to a drive-by shooting than a self-serve menu, with everyone now using the web transports and ports as a way inside our networks. This is where federation begins to bring some order to this chaos.

 

But there is a downside as well. Once federated transactions begin to take off, your existing corporate security controls are all but useless. That content inspection firewall? Forget it: this firewall depends on a stateful model, meaning that you can figure out what state a given user is in at any time. And all that peer-to-peer stuff your R&D boys are cooking up in the labs? Forget it: there isn't any well-defined path that your data can take coming in and going out of your organization, and your transactions take a second seat to the actual connections and processing on the remote peers.

 

Federation frustrates accountability. It is harder to keep track of what happened, and who penetrated your defenses, when the attack can come from anywhere in the world, use any protocol, and anyone can be the attacker, just as long as your system trusted them long enough to establish their credentials. No single person in your corporate network universe will be able to understand the entire picture of your applications infrastructure, and trying to debug some design error could be a troubleshooting nightmare, particularly if your developers have written very modular code that pulls in data from all over the place and uses all sorts of trusted nodes or users. This is exactly the kind of design ethic that those federation guys are pushing for. All of a sudden, complexity becomes corporate enemy number one.

 

Geer's talk, at the Burton Group Catalyst conference, was a sobering one for me. He said that "hope is not a strategy" and the brave new world of federation was going to bring about increases in the need for better network forensics.

 

So what is the answer? I think companies that are interested in getting involved in federated identities and web services are going to have to move gingerly forward. First off, you can't really separate your production environment from your testing servers, not easily in any event. That will mean making copies of pieces of your production environment and figuring out some clean room to host it. But ultimately developers are going to have to throw the switch and let loose, as my friend Marshall Rose was fond of saying, the dogs of war.

 

Second, you will have to get your corporation's lawyers involved, and set up some legal limits of liability in case someone breaks the bond of trust, penetrates one of your federated partners or attacks your own network. While I am not a big fan of lawyering around a problem, now is the time to start this process going.

 

Third, you are going to need better instrumentation of applications to know what the norms are and be able to figure out when anomalies occur. Network analyzer vendors have been lobbying for this for decades, but it is even more important to do this with respect to the actual applications performance and operations. This is especially critical since pieces of the applications lie outside your control, so any "normal" operations instrumentation would be useful if you are under siege.

 

Finally, start paying attention to the various industry committees working on federated identities, such as the working groups on UDDI, SAML and WS-Security. If all of these are just acronym soup to you, then you need to get involved in at least one of these efforts.

To subscribe, send a blank email to
informant-subscribe@pez.oreillynet.com

To be removed from this list, send a blank email to
informant-unsubscribe@pez.oreillynet.com

David Strom
dstrom@cmp.com
+1 (516) 562-7151
back issues
entire contents copyright 2002 by David Strom, Inc.
Web Informant is ® registered trademark with the U.S. Patent and Trademark Office.
ISSN #1524-6353 registered with U.S. Library of Congress.