As information security professionals, we tend to throw around certain terms when we talk about how information security should be implemented. Lately, when I've gone to meetings or written an e-mail that gives me a chance to evangelize about our security needs, my terms of preference have been "rule of least privilege" and "separation of duties."
The rule of least privilege arises in regard to our client virtual private network. This IPsec VPN, which is operated using Nortel Networks Ltd.'s VPN Gateway, allows our employees to work remotely as if they were on our internal network, with access to most applications, services and internal infrastructure.
In contrast, Secure Sockets Layer VPNs allow the remote use of only those protocols and applications that are supported by the vendor of the SSL VPN. For example, most SSL VPNs won't support the remote use of our implementation of BMC Software Inc.'s Remedy, which we use as our IT service management application. But our client-based IPsec VPN seamlessly allows users to launch Remedy while on the road and connected to our wireless infrastructure.
The limitations of an SSL VPN can actually be desirable. Many of our company's contractors, vendors, suppliers and partners are given access to our portal environment through an SSL VPN, which naturally limits what they can access. But some of them require client VPN access because they need to use applications that aren't available via the SSL VPN.
At the heart of a client VPN are profiles. Currently, we are using a single profile for every user with access to the VPN, and it provides full access to the network. The idea was to provide an officelike environment for remote users, but naturally, we don't want to give full infrastructure access to nonemployees such as partners, suppliers and contractors.
In fact, often there is no good reason to give full-time employees full access to the network. For example, someone in marketing shouldn't be able to access the administrative interface of a production Oracle database containing financial information.
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.
Ideally, we would segment the network so that a single segment would contain all employee desktops, except for those of certain users, such as systems administrators and network engineers, who would be situated on an isolated network with a trust relationship to the production data center. Within the server farm, there would be separate networks and virtual LANs for Web, application and database servers. This arrangement would let us control the relationships between these servers and help prevent malicious activity.
For example, in a three-tiered application such as SAP, there is no reason for a Web server to have any relationship with a database server. The relationship should be between the Web server and the application server. These are the types of separations of duties that I am trying to achieve.
There will have to be compensating controls for certain situations that are likely to arise. For example, placing systems administrators on an isolated administrative network might prove to require too much effort. That could result from our use of the DHCP (Dynamic Host Configuration Protocol) or simply because of the way our network is architected. A compensating control in this case might be to place a bastion host -- a gateway between the critical network and the general corporate network -- on a separate network and have that bastion host be the only server that can access the production environment. The purpose of a bastion host is to defend against attacks aimed at our critical network. We would then force all administrators to authenticate to the bastion host before accessing any of our production servers.
I don't imagine I'll win many friends with my recommendations, but I will be able to sleep better knowing that our infrastructure is a bit more secure than it was before.