Choose Your Poison, Part I

This Musing continues the Long Conversation About Security started in October of last year. 

So far in our Long Conversation About Security we have established that there is a tremendously painful security problem in the LAN related to infected devices connecting to the network that in turn create reliability, information leakage, and performance issues for all devices and services associated with the internal network.  IT resource is also consumed in the process of resolving issues that arise from such infections, often manually.  There is nothing that has been and can be done at the traditional WAN perimeter to resolve these problems.  The growing popularity of portable devices is a factor, since such devices can be infected outside of the firewall and then via “briefcase bypass” be connected internally.  But even without portable devices, you’d have a problem as end users can be duped into installing various forms of malware in ways that are impossible for firewalls to detect and prevent.  

We have also established that the dominant networking vendor, Cisco, identified such issues as being critical a couple of years ago and initiated a major effort – the Self Defending Network initiative – to attempt to solve them.  But we have also determined, or at least I have opined, that SDN is not the solution because it is too much, too late.  Too much in the sense that there are too many moving parts that need to be installed, managed, and maintained to be deployable. And too late because it is slowly coming out in phases and the problem is right here and right now.

The good news is that there are a lot of other vendors out there marketing solutions to these problems.  The bad news is that there are a lot of other vendors out there marketing solutions to these problems.   Over time the noise will subside. Best practices and market leaders will emerge.  But you can’t wait for that to happen.  The security and availability risks are too high and opportunity cost due to the load on IT too expensive. The problem is also not just going to go away.  So this is a case where implementing a solution early if it truly alleviates a pain makes sense, even if you decide to rip it out 2-3 years from now if you guessed wrong about which direction the industry in general would head.  This may also be a time where you need to take a risk on a start-up, since the risk of having no solution is so high. 

This next phase of the Long Conversation About Security will focus on defining, categorizing, and rating the relative pros and cons of the various solutions emerging to deal with the LAN Security issue.  In doing this, we will use specific company names where useful to help exemplify what we are talking about and to give you a web site or two to go to for further research.  By no means will this list of vendors or products be exhaustive. I’m not even attempting that.  I expect I’ll get a lot of feedback from vendors along the lines of “Why didn’t you mention us?  We’re stealth and haven’t shipped any product yet, but we’re the clear global market leader in the such-and-such space.”  Well, I know what I know, and I don’t know what I don’t know, and I can only draw on the knowledge I know.  But as other vendors make themselves known to me, I’ll try to point them out in future Musings or in other communications to be fair. 

At the highest level of taxonomy, I’d like to organize and discuss the plethora of existing and emerging solutions out there by the form of the solution.  We’ll then discuss how that form influences functionality and efficacy. 

The categories and sub-categories of form include:

• Host-based
  • Host operations monitor
  • Host configuration monitor
• Network-based host vulnerability analysis
• Network-based
  • In-line
  • Off-line
• Hybrid

We’ll drill down some on the host-based solutions in this Musing and then discuss the others in the next one.

Host-Based LAN Security Solutions

As the name implies, host-based solutions reside on the host being protected or managed to exert their security influence.  There are really two very different types of host-based solutions. 

Some host-based solutions are geared towards hardening the operating environment on the host to reduce the probability of infection, and more importantly, to render the infection toothless by preventing it from accessing and using any of the host system resources.  This is usually accomplished by creating a software “wrapper” around the host Operating System that intercepts O/S systems calls to file, network, and registry sources, as well as to dynamic run-time resources such as memory pages, shared library modules, and Component Object Model (COM) objects. Such host-based solutions execute real-time “allow” and “deny” decisions based on rules that define inappropriate or unacceptable behavior for specific applications.  Cisco’s Security Agent (CSA) and SecureWave (www.securewave.com).

Other host-based solutions are geared more towards configuration integrity – making sure that the host is running the right application releases, security software, O/S versions and patches, etc.  Usually this information is leveraged as part of the network admission control process – providing information to back-end servers (such as RADIUS servers) to allow a more informed connect/deny decision to be made.  The theory is that if the host is running all the right software, configured properly, then it is “safe” to connect to the network, meaning it won’t have a latent infection in it that could spread and impact overall system availability and security.  If a host does not have the right software, then these solutions usually facilitate remediation in some way to get the host desiring connectivity up to snuff before allowing it to attach to the network.

Examples of host-based integrity solutions are numerous.  They include the Cisco Trust Agent (CTA), Microsoft’s planned Network Access Protection (NAP) capability for Longhorn, and agents that form part of the Sybase (www.sybase.com) solution and the ENDFORCE (www.endforce.com) solution, to name a few.  In all cases, these software agents communicate internally to other software modules such as anti-virus software, personal firewalls, spyware detection, etc. that communicate their existence and status to the communication agent.  Cisco started this ball rolling via partnerships with Trend Micro and Symantec and others in relation to CTA.  Now, the Trusted Network Connect subgroup with-in the Trusted Computing Group is driving an industry initiative to define these host-based modules and interfaces geared towards interoperability, so that vendors and customers can achieve the leverage of more commonality.  One of the things emerging from this effort is the concept of a hardware-based Root of Trust that measures and reports on the integrity of the platform hardware and software components.  This device would then take the place of the communication agents identified above. 

Whatever the source of the communications agent, as its name implies, it communicates its information about host integrity to the network in some way to facilitate authentication.  In many cases, the LAN solution requires or assumes the use of 802.1x in the LAN, which means you get to not only upgrade all of your hosts but all of your edge LAN switches as well.  To their credit, some vendors such as the aforementioned ENDFORCE have come up with 802.1x-avoidance schemes that allow more intelligent RADIUS and/or DHCP authentication and thus allow you to achieve host integrity admission control without having to upgrade your existing switches. 

Issues with Host-Based Solutions

Both types of host-based solutions share a common characteristic – they have to be installed and launched on the host in order to work.  This creates some issues.  The “getting there” can be difficult if you have a large network with lots of servers and a much larger number of clients of various types – PCs, workstations, laptops, PDAs, IP phones, packet-ready cell phones, printers, toasters, instruments, toasters, etc. It used to be that the mere configuration management burden associated with loading and maintaining all of that host software would be a non-starter for host-based solutions.  But that issue has been alleviated somewhat in recent years.  Windows Update, for example, shows that it is possible to maintain a vast number of PCs and laptops spread all across the world (if you have the resources of Microsoft). On a slightly smaller scale, the anti-virus vendors have demonstrated the ability to keep large numbers of users current as well.  And vendors like Altiris (www.altiris.com) have developed tools to bring some of that desktop management power into the hands of the enterprise IT manager. 

So maybe the effort required to install and maintain host-based solutions isn’t a fatal flaw like it used to be.  But there are still other issues.  The main one is coverage.  Most vendors, to address the biggest possible market, have geared their host-based solutions towards Microsoft environments. And not necessarily all environments, but in many cases just the most recent ones like XP.  That leaves a lot of endpoints uncovered – older Microsoft clients,  Sun workstations, Linux servers and clients, Apple and Mac desktops, IP Phones, printers, cell phones, PDAs, etc.  And it seems like the coverage is going to get worse over time, not better, as a whole slew of new devices with bare bones O/Ss connect to the network. It is estimated that in a few years there will be five to ten non-traditional devices connected to the network for every PC/laptop.  How can any host-centric solution keep up with such diversity?  In this case, since the goal of the host-based solution is system security, lack of coverage is a huge issue.  Nobody ever says “I’m going to cover half my ass.”  Lack of coverage leads to points of vulnerability which in turn requires you to implement an entirely separate layer of defense. If that other layer of defense is effective and scalable, why bother with the partial coverage of the host solutions?

Host solutions of both types also suffer from another disadvantage, which is probably real, but for sure perceived, which is that they are “out there” running on people’s desktops, readily downloadable, and much discussed.  That all combines to make them vulnerable to reverse engineering and attack. 

In addition, each type of host solution introduced above (O/S wrapper and configuration agent) has its own unique issues.

I actually believe that the O/S wrapper approach may represent the light at the end of the tunnel.  If you can truly make sure that the host operating environment is locked down, that only valid applications and application requests can be executed with no false positives and few undetected attacks, then you really wouldn’t need a whole lot of other security infrastructure.  But, of course, this science is in a fairly young stage of development.  There are or can be performance issues, there can be interoperability and configuration management headaches, there are sometimes false positives, and of course, you can’t have the protection – good, bad, or indifferent – everywhere because there is not support for all modern, trailing edge, and future host environments.  I look forward to the day that this approach is tuned and honed, and then integrated into the various O/Ss themselves, so that the hardening is bottoms-up and universal.  But this process may take 5-10 years, and we have to solve some problems in the mean time.

I’m less enamored of the present status and future prospects for the configuration agent type of host solution.  All you get with it, even if you have complete coverage, is assurance that the host has the correct and latest software configuration (integrity) before connecting to the network.  That doesn’t provide enough protection relative to the effort, in my opinion.

The lack of protection is exemplified by the much talked about “Zero Day” issue.  “Zero Day” refers to the time at which a newly discovered vulnerability is attacked, and starts the clock ticking until a solution is identified to that vulnerability, tested, soaked, made available, and then uploaded to all hosts with the vulnerability.   While that clock is ticking, your system may be very vulnerable, even if you a have perfect host integrity solution in place. 

The unstated implication is that all software configurations have vulnerabilities.  The “bad guys” just haven’t decided to exploit them yet because they haven’t needed to because most people haven’t implemented protection against the exploits that have been around for a long time and are well known.  But when they need to, they will, and quickly.  So integrity management is inherently an exercise where you can’t quite walk as fast as the treadmill is rotating.  You probably have a feel for what that can lead to.

My conclusions from this are:

1. You are going to need another layer of defense to deal with vulnerabilities that evade the capability of the present “trusted” host configurations to thwart.  If that layer of defense is good, then perhaps the value of host integrity management, at least from a security point of view, is reduced.
2. If you still want host integrity configuration management, maybe for operational reasons more than security reasons, then do it in a way that reduces or eliminates some of the burden of host-based solutions.

Fortunately, there are options to achieve both (1) and (2) above.  We will discuss these in my next Musing.