Security Misunderstandings in Federations
What does it mean to have a secure environment? Is it proper authentication and access controls? Freedom from viruses and worms? Availability? Acceptable disaster recovery? Freedom from human error? Data integrity? I would argue, and I would assume most would agree, that security is all of these things.
Why is it then, that federations focus so heavily on viruses and worms? Perhaps it's because those two things cause them the most work. In fact, I would argue that many of my customers have tremendous holes in the other areas of security, but because they're fighting viruses and worms more frequently, the fight against them receives all the attention and budget.
Federations can be quirky things; a group of people wanting to get along, but because they don't trust the other side's security implementation, they need fences. They want firewalls between domains in the same forest. Or they want spam/virus filters between routing groups in Exchange. They say that good fences make good neighbors, but what about families? We don't put locks of different keys on the doors of the bedrooms in our house, even though we might have that one child who isn't entirely ethical or trustworthy.
I believe that many of the problems created by federations is the failure to recognize that departments coming together under a single enterprise are no longer neighbors but families. Take the physical world analogy of the single family home. Putting firewalls between departments in a federation is like putting an external door on my child's bedroom and forcing him to use that door to enter and leave the house, while not allowing him access to any of the other rooms. My reasoning, he might contract a virus and I don't want to catch it. Oh sure, I can tell my friends that we're a single family, but anyone coming over to dinner might find our living arrangement strange. When I see this in customer sites, I sometimes feel like the awkward dinner guest.
When I inquire about the reason for all the firewalls, I typically hear how firewalls prevent viruses. I start looking at the other "security" practices and notice a common trend. Most of today's security personnel are reacting, not preventing. A DOS attack occurred over ICMP, let's disable ICMP. A ZIP file in email once contained a virus, let's block ZIP files. Someone once broke into another person's office, let's change the physical security rules so that everyone can only get into their own office with their badge. A worm spread over HTTP, let's block HTTP. Oh wait, we can't do that because our web servers need to listen on HTTP. Well, guess what, Microsoft products sometimes need to communicate over ICMP. People sometimes need to exchange large files in ZIP format. And, occasionally, people need to work with other people in different offices.
This is not security. This is complexity. This is external doors in every bedroom, but locked doors within the house. Complexity is the surest way to reduce the security of your environment, if you take the aggregate approach to security that I scratched the surface of in the first paragraph. Complexity makes troubleshooting more difficult (longer downtime - disaster recovery). Complexity actually increases the attack surface; you need to watch over 100s of configurations, but the bad guy need find only one weakness. How do you know what weakness he found? Complexity is typically the reason that things just stop working one day and no one can explain it until you discover that someone misunderstood the purpose of the NETWORK SERVICE account and disabled it in a GPO, shutting down your servers (availability). Complexity increase the number of human mistakes because no one person has enough knowledge of the system intricacies to always push the right button.
Federations (although not necessarily the people in them) love complexity. Have you ever tried troubleshooting a problem that occurs in a single technical environment managed by multiple political environments? 60 people get together in a room and try to figure out who done it, what they're going to do about it, and how they're possibly going to get it done with 60 different ideas. So, complexity feeds sluggishness, which means that changes and updates to an environment that might make it more secure can't be resolved in a timely enough fashion, keeping everyone in a less secure state. Incidentally, complexity also prevents increased service levels to the end users. End users are stuck on older technology because 60 different ideas on how to deploy a product are being hashed out in committee, sometimes for years.
If you've found yourself in charge of security for one department within a federation, I urge you to take the time to find and remove the complexities in your environment. Avoid the temptation to continue adding more complexity on top of complexity. Instead of doing B to get around the problem created by A, just get rid of A. This is a challenging call for many. My words have often been misunderstood as a failure to understand the complexity of a customer's environment. I think I understand the complexity quite well; I just don't believe its the best way to run an enterprise.