Of course, that marketing employee wouldn't have the proper credentials to actually access the financial database, but it's still risky to give users the potential to access things they shouldn't be allowed to see. This is where the rule of least privilege comes in. With it, you give a person only enough access so that he can do his job -- nothing more, and nothing less.

What lies behind the rule of least privilege is a concept called dynamic groups. When placed within a dynamic group, a user's role in the company dictates which areas of the network he can and can't access. For example, when a systems administrator authenticates to the VPN, his profile should allow him to access critical servers. Someone from my information security team should be allowed to access certain security-related applications.

For dynamic groups to work, the VPN concentrator has to be able to dynamically create profiles that ideally would be based on attributes within our Active Directory setup. An employee whose Active Directory attribute set identifies him as part of the Unix group should be granted access appropriate to someone working on Unix servers. And someone from shipping and receiving should be granted very limited access to a few applications. The concept is all well and good, but before we can leverage dynamic groups, the network has to be prepared.

The ideal and the real

And that brings us to separation of duties. To use job functions as a means for controlling access to our network, the network has to be segmented properly. Unfortunately, this was never done before I came on board as the security manager, and making a change to the environment to segment the network according to criticality is no trivial task. Virtual LANs and networks have to be resized and configured. Routing changes need to be put in place. Firewall rules, servers and applications have to be modified. And the list goes on.