Restricted Zones Redux

I’m sorry if I’m inconveniencing you and the teachers, but I will not allow a networked computer system to be placed on the ship while I’m in command,” said Commander Adama as I watched the first episode of 2004’s re-imagined Battlestar Galactica series.

That is how one of my vintage posts at the Gartner Blog Network started, and I was reminded of that post on the discovery of the article “KGB Returns to Typewriters to Avoid Computer Leaks.”

According to an Izvestiya source: “After scandals with the distribution of secret documents by WikiLeaks, the exposes by Edward Snowden, reports about Dmitry Medvedev being listened in on during his visit to the G20 summit in London, it has been decided to expand the practice of creating paper documents.

The point of “restricted zones” is that separation is one of the strongest remaining defenses we have the world of information security and – notwithstanding all the hoopla about open networks – separation of systems at different management and security levels deserves its place in any systematic, comprehensive approach to security.

Source: Kevin Bailey on Flickr 

In the original restricted zones post I went on to say note that most breaches “followed a familiar pattern: intelligence gathering over social  networks; spear phishing email; exploitation of Flash vulnerability to compromise a company system; more intelligence gathering from within; compromise of additional systems; access to systems with critical data. It’s the last link of the chain at least that I’d like to see our clients try to cut off by putting any systems with critical data …into a Restricted Zone. In such a zone, these systems aren’t accessible from the Internet, or even by administrators on the ‘trusted’ internal network.

And I gave credit to my colleague Jay Heiser, for this quote: “As long as people with access to [critical data] are sitting on Internet-routed networks, and are reading email and surfing on the same systems that they use for privileged access, then simple attacks using sophisticated code are going to be commonplace.

Organizations with effective network security architectures typically apply a technique called “zoning” to separate their networks into multiple logical segments with different access and communication rules. Most every organization has at least the concept of an untrusted zone (the Internet), a de-militarized zone (DMZ) with its communication and content servers directly on the Internet and a “trusted zone”, or internal network. The DMZ and trusted zones are typically both protected by firewalls, but have different firewall rules. Whereas systems in the DMZ can normally initiate and accept communications with few restrictions, systems in the trusted zone can only initiate communications (such as web browsing sessions through a proxy.)

Many organizations stop with that minimal three zone model (untrusted, DMZ, and trusted). Their internal trusted network is, from the security perspective, a flat network where any system can access any other. Because business and IT groups have so many needs to interact with the external world, however, users and developers punch “holes” in the firewall to allow more protocols into the trusted zone or they build “tunnels” through the firewall by burying application functionality deep into the flows of the few protocols that are allowed to pass, such as LOGMEIN or JOIN.ME or IM within HTTP. This has made a mockery of the typical “trusted” zone and led security pros to variously complain that “our network’s got hard edge and a soft chewy center” or “our firewall has turned into swiss cheese.”

More than just complaining, many enterprises take practical action, separating their internal network into multiple subzones, such as end user networks (which are relatively open) and data center networks (which are more controlled.) Separate data center networks with their own firewall rules are the beginning of restricted zones as access to them even from internal end user networks (where the desktops and laptops reside) is strictly monitored and restricted. Within the data center networks, some enterprises also establish even more restricted zones around critical assets, for example, the credit card database systems might have their own firewall protections even within the data center network and only be accessible to a few trusted services.

The notion of restricted zones prompts many objections, such as

  • “We can’t completely cut off access to critical data, we have to use it.”
  • “Administrators need to get in and fix the system during an emergency.” 
  • “Even inside the firewall, administrators need to get out to review support materials when troubleshooting.” 

However, these issues can be dealt with using standard techniques such as proxies, or more innovative ones such as disposable virtual machines enabling external administrator access to support data. And while the additional architectural planning and special tools that may be needed do raise the cost of operating an IT environment, the cost of having critical data breaches could be much higher.

Subscribe to Blog Notifications...  HERE