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.

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.

Hotel Hacks

There's an interesting, if unsurprising, article up on darkreading about the security of hotel networks.  I think we've all been to a hotel or two before that had, say, SNMP community strings that were easily guessable.  In general, it seems that "Broadband" Inernet access at hotels has morphed from being an ammenity to simply being a given.  However, it does not appear that most hotels take any real steps to manage that resource, or the people using it.

So, first, it seems from the study that hotels should look to technologies like Network Access Control to protect themsevles.  Second, we should all be mindful of just how open these networks are when our users come back from them.

SCADA Exploit Released

SC Magazine has an article up that a security researcher has "released" an exploit for the CitectSCADA vulnerability announced earlier this summer.  I've written about the challenges around SCADA systems before, and we continue to monitor this space, so the article caught my attention.

I have little doubt that the original vulnerability was serious, and all indications are that it was taken seriously, if not by the press then at least by Citect and their customer base.  This newly released "exploit" seems a bit over the top to me, as do a couple of quotes in the article.  Here's an example:

"As a result of the need for real-time business information, it is becoming increasingly popular for the plant network to connect with enterprise networks and the open internet."

I don't know Brian Ahern, and far be it from me to say that companies, industrial or otherwise, shouldn't secure their networks.  But is Mr. Ahern truly making the allegation that power companies are giving their industrial control systems unfettered access to the public Internet?  Seems a bit of a stretch.  The stretch gets even broader when a look at the code shows a high ephemeral port related to ODBC connectivity.  Is there really any company that allows incoming connections on ephemeral ports to internal systems?  Much less industrial control systems running SCADA applications?  None of the utility guys that I've had the opportunity to meet does.

Given today's landscape, what seems a more likely vector is a bot or otherwise malware-infected host already inside the company's perimeter.  Put another way, given that we're in an election year, "It's the Inside, stupid."

By all means, take this vulnerability seriously.  By all means, leverage perimeter security devices (if you don't already) to protect critical infrastructure devices from the public Internet.  But you should also secure your network from the inside out, not just from the outside in.

The Anti-Social Network

DarkReading has an interesting article up on a proof-of-concept attack leveraging social networking sites (FaceBook in this case).  I've written about this recently; and we've seen an uptick recently in the field of infections that were ultimately traced back to social networking sites.  I continue to believe that attacks centered around social networking will continue to grow.  Be careful out there; practice safe browsing whenever possible; and remember that it's all about the layers.

Knock Knock

What's there?

We recently commissioned a survey of IT staff on network security concerns generally and NAC adoption plans specifically.  What we found, interestingly enough, was that 86% of the respondents had controlling network access as a priority, but 45% of them were not sure what was connecting to their networks at any given time.  I feel a bit like a political spin machine on this, since the basic visibility components of NAC implementation has often been a topic for me, but it seems to just keep coming up in its own right.  802.1x can help authenticate the endpoints in your network (and that seems to be on peoples' list, at least according to Gartner), and may help judge the posture of devices as we move forward.  However, failing back to MAC based authentication for MAC addresses you know little to nothing about seems too circular to be useful.  Any meaningful policy springs from at least basic knowledge of what you have connecting today.

I think this is a particular challenge for NAC vendors, since (a) it's basic blocking-and-tackling of NAC implementation so it needs to work; and (b) it's not really a huge business bang for your NAC buck.  However, there has to be opportunity here as well, since it appears none of the current tools in the IT toolbox is stepping up to do a satisfactory job at this.

You can read the full study here.

Another Patent Born

Actually, birthing.  We've received a notice of allowance from the USPTO for our patent application around address resolution based restriction of devices post-admission to the network.  Ironically or no, this was pretty much the first patent the company filed; yet it remains extremely relevant.  I've written recently on the importance of post-admission controls, as well as the reasons and (some of the) methods of our ARP based approach to quarantine.  Our initial patent protects ARP based quarantine for the purposes of enforcing authentication of devices onto the network.  Once issued, this one will protect ARP based quarantine of devices as a result of threat detection at any time during the device's network lifecycle.

We're excited about this.  Two down, 8 more to go.

SCADA and NAC

I thought I would take somewhat of a break from beating the standards and post-admission drums, and share some thoughts on how companies might bring embedded OS devices (generically) and SCADA   devices (specifically) under a NAC umbrella.  The move away from serial communications and towards Ethernet and TCP/IP is not a new phenomenon for SCADA devices, nor are the security vulnerabilities and concerns that come as part of the move.

In May of this year, the GAO conducted an audit on the Tennessee Valley Authority, with less than stellar results.  The North American Electric Reliability Council now has a set of ratified "Critical Infrastructure Protection" (CIP) standards designed to address these and other concerns.  The CIP standards end up setting up roughly as one would expect:  Identify critical assets, segment and protect them, control physical access, patch machines, manage security events, etc.

NAC should be able to help with at least some of those.  Given the specialized function of these devices, though, as well as the specialized nature of their OS, care must be taken.  To wit:

First Do No Harm

What's generally true about network security engineering is doubly true here.  Any "security" apparatus that causes lights to go out, or a cooling plant to shut down, is quite obviously bad.  In essence, this is a two-fold model change for NAC.  First, it is a view that is geared more towards protecting the critical devices, as opposed to protecting the environment from them.  Second (and somewhat related), access to the network is presumed as a normal case and restricted only in an extraordinary case.

Passive Device Fingerprinting

Some identification mechanism is necessary to fingerprint these devices and classify them correctly (see below).  Given specialized OS platforms, though, performing that fingerprint via agent software seems unworkable.

On-Segment Protection

The segment containing these devices must be protected from all threats, foreign and domestic:  malware-infected hosts, mal-intentioned users, mis-informed users, unauthorized hosts, etc.  Of course, this includes ongoing protection of the segment, not just protection from device entry.

MAC-Based Authentication for 802.1x

At some point, organizations likely want to meld this under an overarching 802.1x umbrella.  Given the likely lack of 802.1x supplicants for these devices, MAC based authentication is required.  This is also where the fingerprinting piece comes in to plug the holes inherent in MAC based network admittance.

Generically, of course, this governance problem is applicable to any number of other devices (medical, HVAC, badge readers, etc.) that now have Ethernet connections and IP addresses.  The set of Critical Infrastructure Protection standards for the utility industry just provides an additional driver for the IT and Security teams in that industry to do something (or a set of somethings).  It is both a challenge and opportunity for NAC vendors to find a way to help, but help in a way that takes into account the specialized nature of these devices.

Malware Survey

Blackhat's underway, and while Kaminsky's DNS vulnerability continues to garner the lionshare of attention, there are other interesting malware-related developments that I thought would be worth surveying here.  This is not an exhaustive list, of course.  Just ones that caught my eye for one reason or another.

For all the Facebook/MySpace lovers out there, blackhat researchers are due to demonstrate a file that the web server treats as a Gif, but the endpoint processes as a jar archive.  Kaspersky as also identified a worm that is spreading through MySpace and Facebook.

Storm continues to chug along and find ways to add people to its botnet.  The latest is attempt is via an "FBI vs Facebook" spam.  Given Storm's history of looking to capitalize on events around the world, I'd look for more as the Summer Olympics gear up.

In a development that surprises none of us, but is a bummer for all of us, Information Week has an article on a recent Websense survey that 75% of sites serving malicious code are legitimate sites that have been compromised.  According to the article this is a 50% jump over the previous 6 months.

Finally, Twitter has apparently reached a level where it is now also worthy for use as an attack vector, prompting users to download malware disguised as an updated codec for Adobe Flash player.

What's any of this to do with NAC?  It highlights two points that I've drummed on before:  (1) the critical importance of a post-admission security and detection strategy, and (2) the importance of isolation and cleanup of infected hosts.