CTO Chronicles

Gimmiv an A

As many of our customers scrambled to apply the patch for MS08-67, questions abounded on whether our default content would catch and contain the W32/gimmiv.a trojan that was quickly modified to exploit the vulnerability.  We did (and do), of course.  Also interesting to me is the use case this raises from a patch management standpoint.  Regardless of whatever generic policy is chosen and implemented with respect to patch management and NAC, MS08-67 reminds us that we may, at any given time, need to push machines over to the side to apply a critical patch that comes outisde the lines of the normal cycle.  Of course, having good post-admission protection in place gives flexibility that reduces the degree of the immediate fire drill, which is always nice.

Competitive Truth-O-Meter

Since we're nearing the end of the silly season that is the presidential election cycle, and since I've spent the past few weeks in the field, I thought it might be fun to run through the truth meter some of the competitive FUD that has come my way.  Competitive FUD is a natural part of the landscape, so this is not at all intended to cry foul; simply to set the record straight.  Thanks and apologies in advance to the good people at politifact.org for my shameless pilfering of their graphic.

They say:  Mirage technology is based on behavioral threat detection, which while a useful security feature is not NAC.

It depends on what your definition of is is.  It's true that behavioral threat detection is at our roots; it's also true that revoking network access as a result of behavioral badness is controlling network access.  I suppose one could say that controlling network access is not Network Access Control.  I'm glad I'm not the one saying that.

They say:  No persistent or dissolvable agent, which provides a less comprehensive endpoint assessment.

We do offer an on-demand Java control for full endpoint assessment, including patch levels, SMS currency; AV/AS currency and firewall status.  This assessment is done in addition to an OS and Service Port map done from the network side (see below).

They say:  Host-based firewalls must be disabled for compliance scan to take place.

Wrong on at least two levels.  First we have a Java control that can perform a deeper compliance scan, independently of any firewall status.  Second, our network-side scan that maps endpoint OS and open Service Ports is a combination of Active (meaning, packets that we send to the device) and Passive (meaning frames we receive from the mirror) scanning.  So a host that, for example, sent us a RST on port 25 but send another host an ACK on port 25 gets marked as an SMTP server.  Indeed, Mirage is the only company of which I'm aware that uses a combination of active scanning and traffic monitoring to present a complete picture of how an endpoint is behaving on the network.

They say:  Savvy users can circumvent quarantine by setting static ARP cache entries.

What Mirage FUD is complete without some ARP related FUD?  I've written about all of this before here.

They say:  Provides no integration with third party devices (IDS/IPS, VA, etc.)

We've a third-generation API available and documented, as well as any number of vendor-vendor partnerships, including IPS, SEIM, VA, DHCP and more.

They say:  Sensor appliances need to see all endpoint traffic using port mirror or "SPAN" port function on a switch.

More like "is capable of receiving all endpoint traffic."  Every Mirage sensor can take a mirror feed, but no mirage sensor must take a mirror feed.  Further, the communication of endpoint status and behavior through our common security fabric allows a "mixed" deployment, where traffic mirroring is performed at ingress/egress points rather than at every appliance.  This allows us to make behavioral decisions based on traffic from the endpoint headed to, say, the public Internet or the corporate WAN, while avoiding the economies of scale hit that would come from a requirement of mirroring at every deployed sensor.  Somewhere north of 90% of our deployments fit this mixed model.

SC Magazine article on new perimeter

SC Magazine has a cover story up here on "The New Perimeter" that features New York City Transit's NAC deployment.  In addition to being a good plug for Mirage (which I'm never above promoting!), it also has good information on the dissolving network perimeter (a primary NAC driver), NAC market sizing and the importance of defense in depth.  Definitely worth a read.

Clickjacking, CSRF, Social Networking, Oh My

DarkReading has a good article on the overarching challenges facing security administrators today (bonus alert:  it has an I Love Lucy reference!), including mentions of recently "revealed" vectors around both clickjacking and Cross-site Request Forgery attacks.  I quote revealed since, even though the Princeton researcher's work on CSRF is well documented, we'll have to wait until the Hack in a Box conference to get the full scoop.  The downside of this is that it sure sounds and smells a lot like the Kaminsky thing, and I'm not sure even he would do it that way again.  The upside is that it's a chance/excuse to go to Kuala Lampur, which is a beautiful city with amazing food (the latter being an obvious requirement for the former).  But I digress.

It's easy to come away from the series of darkreading articles with a, well, dark impression of the state of endpoint secuirty these days.  With continually morphing combinations of browser vulnerabilities, infected emails, user gullibility and malware-laden websites, it's difficult to see how any security manager can keep his endpoints malware-free for any window of time.  And all of this is made even worse by the fact that many of the new vulnerabilities aren't bugs per se, but rather dependencies on the very things that help make today's web cool.  So, never mind, one might argue.  We've failed and the cause of malware-free computing is lost.

But perhaps what we need is to change our thinking about what failure is (which is different than re-thinking what is is).  Perhaps we've spent too much time so far putting our collective eggs in the basket of avoiding endpoint infection, when, really, at least some that attention is better spent on the idea of containing infections that are, in the end, inevitable.  Put another way, it's not an engineering failure to have a router (or WAN card, or FRAD, or whatever) failure  in the Bogota office.  It is an engineering failure for that equipment failure to result in a services outage for the people in the Bogota office or anywhere else (I'm not intending to pick on Bogota, by the way.  They have fine food too).  We accepted long ago that what equipment does is fail.  That acceptance didn't stop global data networking, obviously; it simply drove best practices around the notion of engineering for that failure.

My thinking of late, then, is that we've so far put too much attention on the single point of failure that is infection avoidance.  That means (yes) having mechanisms in place to (a) detect the infection and (b) affect the network access of the endpoint in a timely way.  But it also means things beyond just NAC, like the ability to clean/restore the system without having to put a help desk person on a plane.  Not easy, perhaps, but it seems an answer that is at once more in keeping with the traditions of IT, and, well, more hopeful.