Monday, April 2, 2012

Securing the Network – Part 1: Run Separate Networks

A few years ago, I worked as an independent Microsoft Solution Provider.  Microsoft put our company URL on their web site in the Solution Providers listings area, correctly touting us as experts in MS technology.  Unfortunately, the only “customers” who found and used the URL were bright hackers out of China.   I’ve always been impressed with that thinking:  to target the top echelon of technical expertise to see if you can get past their door.  In other words, to hack into a hacker’s system should be the ultimate challenge.

One Chinese fellow would leave polite notes on my desktop or sometimes hidden in a directory to let me know he had found a way in and left a little surprise or two for me somewhere.  We spent several months playing this “cat and mouse” game until I either secured the network well enough to keep him out; or, he went in search of different prey.

This was about the time I started travelling broadly for Microsoft helping to build and secure large public networks and I’d like to share some of the simple best practices that almost any small to medium business can deploy – especially hospitals and health organizations.

I’ll start in this post with one of the most powerful and really very simple ways to secure the network:
Deploy two, three, or more discreet networks that are virtually and physically separated from each other.

For example, you might have an application network on 192.168.x.x that your general network users will use to interact with line-of-business applications.

On the 172.16.x.x network, you can host your management network.  This is where your SNMP traffic will travel, logging traffic is transmitted or consumed, the system administrators will do their thing, and generally provide access to non-application or non-management related data.

Finally, on the 10.x.x.x network, you may support your data network.  Your data network is generally only available to machine and service accounts and transmits:  database traffic, domain login traffic, and service to remote-service communication for things such as HL7 messages.  In other words, this network should almost never be available to human eyes.

Of course the DMZ would have it’s own network too…

The key advantages of these separate networks are:
  • Smaller attack surface.   Application users with lower rights, can only see items on the application network and are unable to even connect to the data or management networks.  Management users with elevated rights can see the whole network, but they are still isolated from the data and/or the applications.  The data network is generally only available to service accounts and machine accounts and is very isolated.  
  • Traffic can be prioritized according to need.  Application users listening to Pandora will not impact the data network; and the transfer of the 500GB log file across the management network won’t disturb the web to database traffic.
  • Configuration errors on one network, will typically not impact the other networks.
  • Firewalls, SSL, and other deterrents geared for the application network often retard the data networks.  Isolate the data network and remove all the stuff needed by the application network and management, performance, and security will be improved.
One closing tip, in the datacenter it can prove to be very difficult to determine which network is which. One way to solve the problem is to use color-coded network cables for Cat 5/6; or tag the fiber cables with color tags to differentiate one network from the other.

Separate networks would probably solve a high percentage of security breaches both inside and outside the perimeter.