Should We Treat Our Private Network as Public? (GMIS Member Article Contribution)

 

Recently, I received an article from GCN about changing the trust method on a network to trusting no one, including PCs on the private network. It reminded me of an idea I have been toying with for years: firewalling our datacenter off from everyone, including our users. In a similar fashion to the article, it makes perfect sense when you break it into simplest form. Treat everyone as if they are the enemy and your defenses will be better.

For us public sector folks, we routinely support many different "businesses" that may have completely different requirements. Thus, the setup and maintenance can be a nightmare. We treat our private network as a private network in order to allow a moderate amount of needed flexibility to accommodate the applications used. I have found through experience there are two types of applications that are purchased: the fair to very well written programs, and the really terrible, horrible, no good, very bad written ones – RTHNGVB for short. Unfortunately, the latter seem to frequently pop up when a solution is needed for some municipal-specific business need.

What causes the issues with the RTHNGVB is that the program is designed as if the programmers looked at the OSI model, laughed and said "That’ll never catch on." Non-standard ports are used for communication, administrator rights are required simply to double-click the icon, registry work is conducted to look like the outcome of Cousin Eddie’s dog after rooting through the trash, the application only runs in Internet Explorer 9 with Java version 6, and security isn’t even an afterthought – it’s a no-thought. Besides those amazing features, it tracks some finance, public eorks, police, etc., data really well and puts our logo in the upper-right corner.  

So let’s say we have firewalled off our datacenter, tuned the Intrusion Protection System, and we are ready to be a hacker’s worst nightmare. This application needs a place to centrally store the file system/database so multiple clients can reach it. Information Technology calls the RTHNGVB Enterprise software support line simply to ask what ports are needed to communicate (after checking ReadMe’s and other potential help docs). After asking the seemingly innocuous question, the silence is deafening. IT offers to help find the solution, and together, IT and RTHNGVB spend hours reaching into the depths of the documentation of the various components of the program to determine what is being used (this assumes that there is documentation on anything for the program ... been in that situation too). During this process, you also find out that not only is the data sent to the server not secure, but you also must open about 15 ports. Oh, and all 50 PCs and tablets across the division need access, you need to account for that. Also, the communication on those ports is so noisy that the IPS starts blocking traffic until you adjust the rule. Of course, it took a few iterations of systematically pulling your hair out thinking it is a port restriction problem or an application problem because the firewall just keeps dropping the packets until you finally figure out the cause is a chatty, non-standard use of a protocol.

The point is, until public sector software development matures to the point of having standards in place before a product is released, and public sector IT has standardized requirements for software (and, most importantly, sticks to them), walling off our datacenter will continue to be out of reach. We will continue to fight RTHNGVB applications and need the flexibility (and accompanying risk) of a private network. We will continue to be subject to the threat of insider attacks.