Field NotesBuilding Sound Walls
As IT professionals, we need to build an ordered realm. We want the citizens within our network realm to work and live safely and securely, and we want to protect the assets of this realm. We know there are barbarians out there who might want to acquire our assets and use them for their own nefarious ends, so we build a wall around our corporate computing assets. We construct firewalls and security policies to keep the bad guys out and let the denizens of our corporate domains conduct their commerce. We think we have a handle on securing our realm. Then some pesky applications come along.
To get full use of our corporate assets, we sometimes need to share them outside the borders of the realm. We need to let vandals, er, I mean vendors, interface with our data systems. We need to connect offices through public Internet links and move data securely through the all-too-public cloud. We also need to supply information to our customers without allowing them to see too much. And we need to protect the Personally Identifiable Information of our employees, customers, and business associates. So how do we let people in while at the same time keeping them out?
Here is a common scenario. I am working with a team that is developing a Web application. Like most applications, it comes with an administrative app which needs to be secured for use to a limited number of users. What’s the best way to secure it? The app folk don’t like to talk to the IT folk, so they just want to use a user name and password (in plain text, no less) to look things up in a database. By doing this, they control the security. The business does not want users to have to remember yet another user name and password. After all, isn’t the point of Active Directory® that you are identified on the network? So the app team goes to IT and asks for an Active Directory group to administer the app. IT says they can do it—no problem.
But, of course, there’s a problem. The group needs to be constructed and members added. But wait—the potential members have different needs, based on whether they’re doing development, QA, or production work. So now it becomes three groups. The app dev people can’t control who’s in what group. When security fails, people get frustrated because no one knows whether the failure is due to bad code, use of the wrong security group, or users being placed in the wrong groups. To keep things moving, the app development team makes everyone an admin in the development environment (or worse, they comment out their security altogether). They never really tested the security they wrote and they just threw the app over the wall to QA. Now things are running behind schedule (go figure). Since making everyone an admin in development works, suddenly everyone is an admin in QA (just so they can test).
And now it’s time to move to production. But the only way the app works is if everyone who accesses the app is an admin. The fuse is short. The app dev team says the only way they can work on this problem in production is if they are made Enterprise Admins so they can see everything that is going on in the production environment (there are too many variables to troubleshoot any other way). Suddenly, IT is under pressure to dismantle a large section of the wall so they can move a small amount of data through. Is any of this sounding familiar?
As the keepers of the wall, IT needs to maintain a delicate balance in the structural elements. There are undoubtedly good reasons to build doors and windows in these walls. But we must build them ourselves so we can make certain they are located exactly where we want them and we can help maintain and guard them. We can make certain no one builds an open arch on a main thoroughfare. At the same time, we should make everyone aware of the cost of each door and each window. For each Active Directory group, each open port, each VPN connection, there is risk and the associated expense. But there is also a cost for keeping the wall too solid. We aren’t trying to build prisons—if the wall is too rigid and restrictive, people will find ways over it, around it, or through it. And the barbarians will eventually find those little breaches, and once they do, they can make off with the assets of the realm.
The walls also fail when the necessary guards are not where they need to be. But when properly maintained and guarded, our walls protect the realm and allow us to trade with the neighbors safely and securely. It’s up to the IT pros to build structurally sound walls.
Mark Scott is a Senior Consultant with Microsoft Consulting Services. He works closely with clients to help design and build large scale, data-centric applications.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.