What is RTO and RPO and why should I care? Part One

Okay, so lions, tigers and bears probably sound a bit scarier to the average Joe, but in the wake of huge data breaches this past year, the news of encryption vulnerabilities caused earth shaking tremors in the IT security community. I don’t intend to discuss the actual details of POODLE, FREAK or BEAST (or Heartbleed, Logjam, BREACH, Lucky 13, or any others that I have forgot to list) in this article. Suffice it to say, these are at least representative of the encryption vulnerabilities disclosed in recent times.

If you are “fortunate” enough to work in a small company, or at least a company with a small attack surface, addressing these vulnerabilities from exploitation outside your firewall has not been overly difficult. You may not even have any encrypted traffic (typically HTTPS) traversing your firewall. You may even be lucky enough to not somehow know that the people who connect to your network, inside your firewall, are a threat.

However, if you are a large enterprise, or even a mid-size organization, chances are your attack surface is large. You have many entry points coming through your firewall where encrypted traffic is coming from an external source to a device in side your network. Typical examples of this include web servers, browser access to corporate email, VPNs, remote support appliances, etc. I know of one local healthcare organization that has well over 80 separate devices accepting encrypted traffic through the firewall today – including web servers, Outlook Anywhere, multiple VPN solutions, and Citrix Web Interface. This is not likely not as large as what you might find at some very large corporations. However, patching these 80 separate systems addressing this list of vulnerabilities has become an unbudgeted, full time job in some organizations. Not only do you have to find out what patches need to be applied and then deploy them, you often have to be willing to dig, scratch and claw at the vendors to get them to 1) admit that their product contains a vulnerability, 2) give you an estimate on when a remediation will be released, and 3) getting the remediation solution delivered to you so you can somehow fit in into your schedule, without (somehow) completely disrupting service to your own users (and more importantly, your customers).

We all know that these vulnerabilities can be exploited from both outside and inside your firewall. Obviously, our first reaction is (and should be) to address remediating the issue to prevent exploitation by external entities. (Security analysts, please sit back down now. I am not suggesting we leave these vulnerabilities unaddressed internally, as I am well aware that many security breaches occur from within our walls. I am only suggesting we first secure the external threat.)

I have been working with NetScaler appliances since Citrix acquired them back in 2005. In that time, the NetScaler product line has gone through major enhancements and additions. Not once during that timespan has there been as much public visibility regarding the vulnerabilities in encrypting traffic, as there is today. By no means has the NetScaler been exempt from requiring patches to address many of these same vulnerabilities in it’s own code (as have many firewalls, intrusion detection devices, switches, routers, etc.).

In the past few years, I have been very successful in mitigating this first level of exposure (external threats) by using a device like the NetScaler as the “proxy” between internal systems and the firewall. The firewall, in its simplest role, allows traffic on a port (such as 443) to travel through to an internal device (such as a web server). By inserting the NetScaler between the firewall and the internal device, all of the encryption handshake, etc., is handled by the NetScaler instead of the internal device. The NetScaler establishes connections to the internal devices, effectively acting as a “TCP multiplexer” for the traffic, and passes only the appropriate traffic through to the internal device.

The beauty of this configuration is that it reduces the external attack surface to be only the NetScaler. I only need to patch the NetScaler against the latest disclosed vulnerability to prevent external threats from reaching internal devices. Within the past year, I have used this to do things like requiring a TLS 1.2 connection from an external user, even while the internal server wouldn’t accept it – as an example, one was a Domino 8.x environment, using a SHA1 certificate, which only accepted SSLv3 connections.

Going a step further (to address the internal threat), it would not be terribly difficult (and is no longer uncommon in large security conscious organizations today), to separate your datacenter devices from your end users, with a firewall. Doing this, and configuring a NetScaler to handle all of the traffic coming from the users’ LAN based devices, just as we did for external devices, we have effectively closed the door for a large number of threats.

Of course, this is not a permanent solution. Nothing ever is. There will always be new vulnerabilities disclosed, and more remediation and solutions required. This separation I depict here, using NetScaler appliances, is certainly a step in the right direction.

Brian E. Holzer, CCE-V, CCP-N, CCP-M, CCA-N (former CCI)
Sr. Architect
Innovative Integration, Inc.

About Brian Holzer

Brian is a seasoned IT consultant (pre-sales, delivery and marketing) with experience across many industries (healthcare, financial services, communications, manufacturing, education, government, utilities, professional services, etc.). He is a former IT Director, Assistant Professor with Purdue University, and an application developer.

Leave a Reply

Innovative Integration can help you optimize your IT infrastructure. Request a Consultation