There is an interesting conversation in the Security Catalyst Community with the title “vmware bridge vs. NAT“. It started as a discussion about developers utilizing VMware for development on their local machines. The initial issue was whether to allow the developers to configure their systems so that the guest communicated through the host via NAT or to require that all guests be assigned an IP address on the network.
The thread has already gone through a spiral of recommendations and additional questions. I will not hash those out here. But what I found interesting is that this all comes back to a question of policy. The current policy, at this company, “stats [sic] that no workstation should route traffic.” One respondent pointed out that although the implementation of VMware might be a concern, perhaps the problem is actually the way that the policy has been written.
The way that policy is written should never get in the way of the desired goal for which the policy has been instated. What I mean by that is that the requirement that ‘no workstation should route traffic’ is a means, and not a goal. What you probably want is that no workstation should be able to connect networks in a way that they were not designed to.
Very sage advice.
All of this brings the risk of unauthorized network extension to the forefront. What I mean by network extension is any hardware or software configuration that permits other systems to utilize the network. What I mean by unauthorized is anything that has not gone through the proper approval channels to be placed on the network. We see examples of this all the time in most work places. Somebody attaches a network hub or switch so that they can have a desktop and a laptop. Another person bridges their network interfaces through their handy-dandy Microsoft XP configuration capabilities. And the one that everybody knows best, wireless, wireless, wireless. All of these scenarios can increase the risk to any environment. Not only do you have unauthorized systems on the network, but there is no telling how they have been configured, what software and hardware has been installed, or what the administrative passwords may be. Just to name a few.
So, how do we combat the extension of our network. Well, at my last job at the university, they started with (yup, you guessed it) policy. And despite a few rough encounters that occurred while confiscating equipment, I believe that they handled it quite well. First they started with an over-arching policy to start the control effort. (I have changed a few of the position and department titles to be more universal and understandable.)
All University data, video, wireless, and voice telephone network connectivity, including but not limited to active data net-attached lines, hubs, switches, telephones, wireless and extenders, must be approved by the Chief Technology Officer. Such connectivity must be coordinated and supervised by IT Department. Any installation not approved may be disconnected.
Next they developed policies with more detail that provided the users with information about the policy’s scope, applicability, terms, implementation, and consequences. They made it very clear that ownership and operation of the campus’ network would be handled by a specific department and that all approvals for connectivity would have to be processed by that department. They provided very clear wording to ensure that all users understood that this included any instances where the network was extended.
All hardware and software configured to extend or re-transmit the university network and telecommunications infrastructure, including all wireless technologies, must be approved by the Chief Technology Officer prior to acquisition and deployment. All systems, devices, and software capable of extending this infrastructure must adhere to configuration standards developed and maintained by the IT Department.
Finally, they very specifically stated what would occur if the policy was violated and the devices extending the network were located.
Any device, system, or software found in violation of this procedure may be confiscated and temporarily stored by the Chief Technology Officer or a representative of the office.
Of course these are all just snippets from several policies that combine into a proactive security stance for the University. But I believe they state very clearly the organization’s stance on network extension and may help those of you who have not considered these types of policies.
Now, where does this all get us with the original issue of permitting NATed VMware instances. I believe that it leaves it open to interpretation. It allows the IT personnel, developers, and Chief Technology Officer to negotiate an agreement by looking at the risks and implementing controls. The policies are flexible enough to permitted this type of configuration with prior approval, while also empowering the IT department should a high risk situation arise.
Go forth and do good things,
Don C. Weber
SCC, policy, management, university, security, Security Ripcord, network extension