Illuminations

Attacking Anti Virus Software

Wow, it's been a while since I posted. How time flies....

Sowhat from Nevis Labs gave a very well attended presentation at Black Hat Europe last week on "Attacking Anti-Virus Software". He has been running a research project for several months now focussed on  how attackers might be targeting the very software that more than 80% of Enterprises rely on to keep them safe. In just those few months he has discovered numerous vulnerabilities in widely used AV products. Nate McFeters at ZDNet gave a pretty concise summary of Sowhat's presentation that I encourage you to read, so I won't recount all the detail myself.

By demonstrating how vulnerable one of the key security tools in the Enterprise toolbag is, Sowhat has shown just how far we in the security industry have to go to put our own house in order.  A few years back Microsoft used to come in for daily bashings as yet more vulnerabilities and exploits were unearthed in the Windows OS.  At first it looked as if big company arrogance might prevail, and the press lambasted the folks in Redmond for not taking responsibility for creating security holes that you could drive a bus through.  But give credit where credit is due.  Microsoft stepped up and put a focus on security and cleaning up vulnerabilities that few other software companies have (Apple, for instance, have flown under the radar thus far, but it looks like their day in the limelight is coming).  Today, Microsoft have processes and procedures in place that make updates predictable and manageable, they have developed relationships within the security community that improve their visibility into future threats and most importantly they have invested some of their billions in making security an integral part of what they do and cleaning up their own act.  Pretty impressive for a company whose primary revenues do not come from security. Can we expect the same response from the titans of the security industry like Symantec and McAfee?  After all security is their business.  The irony is not lost on me that both these companies ship "NAC" solutions that are client based and are supposed to ensure that your AV is patched and running.  Good to know that the fox is out there guarding the chicken coop.

//Dom

 

More NAC confusion and FUD in the press....

Tim Greene's recent article "NAC may find its niche as a supplement" announces that in-line devices will not be the main choice for enterprises moving forward because of:

1) the number of boxes that you need to proliferate throughout the network for an in-line solution

2) the adoption of 802.1X in network switches since NAC first came along

3) the introduction of Microsoft NAP

Let me address these points with some degree of fact, rather than opinion and speculation.

1) We are an inline vendor of Identity Driven LAN Security solutions that include NAC as an element of the feature set. We have successfully deployed our solution in large global deployments that include fortune 500 companies and span >40,000 active users.  We have done this very cost effectively with fewer appliances than specified by OOB vendors in the same competitive bids.  Contrary to popular belief you can in fact put a Nevis in-line appliance in above disti or in the core, or better still use your existing switch refresh $$ to buy Nevis secure switches in the wiring closet which means you've done away with the additional cost of OOB software, hardware, licenses, etc. 

So the first point to make here is that OOB does not mean you can add one box to the network for all users.  In most cases network topologies will dictate that you need many OOB appliances and then the limitations on user count per appliance further impacts the equation.  The reality is that OOB is often more expensive and cumbersome to deploy.

The other point to consider is that enterprises are very often looking for more than just the pre-connect Network Admission Control that most OOB solutions provide, particualrly when they want to scale the solution to include employees as well as business partners, contractors and guests.  To get this functionality from an OOB solution I have to have a bunch of other supported elements (switches, IDS/IPS, Firewalls, etc) that I then have to hang together with complex interoperability, deployment, maintenance and policy issues.  I've said it before and I'll say it again.  The hidden, dirty little secret of the OOB approach is that reliance on VLANs and port based ACLs in switches for post connect access control enforcement means that what used to be a simple network topology change now has a new NAC policy dimension to complicate things.  Things are probably ok if you stick to the Guest/Employee VLAN model, but start to get more granular than that, and start wanting to add a little more granularity on the ACLs that are enforced, and all of a sudden you've got a full grown oak tree to prune where you thought you had a bonzai tree.  Group based L2-L7 policies, enforced independently of the network switched and routed infrastructure remove this dependency and complexity. 

2) For the rebuttal on the tired old 802.1X assertion please start by reading the great article that our own Gary Kinghorn just had published in Enterprise Networks and Servers.  Gary did a lot of research within the analyst community and with customers when writing this article and found that while the technology is there in the switches as Tim points out, implementing it has so many costs and pitfalls associated with it that very few people are implementing it in the short to medium term.  If it is a requirement for a NAC solution then I would argue that the vast majority of Enterprises, particularly in the mid tier, won't be rolling out that NAC solution any time soon.  I'd also refer you to a Nevis white paper for further discussion on how 802.1X compares, contrasts with, and can also be a part of, a Nevis Identity Driven LAN Security solution.  802.1X will have it's day, but the fact that the OpenSEA Alliance was founded should give you some indication of the problems that still have to be overcome.

3) We have advocated interoperability with Microsoft's NAP from the very early days and have shown our strong commitment by actually putting in the effort to do development work while others just talk to it.  Our feeling has always been that NAP will become the dominant Network Admission Control technology, which is why we provide a solution today that can interoperate with it.  We can also add tremendous value to the NAP framework rather than providing the significant overlap that OOB solutions give.  What do you do about non-windows or legacy endpoints for instance?  How will you ease the transition to a full corporate roll out of NAP while getting the protection you need in the short term?  How will you secure against network born threats?  How will you cloak network resources from sophisticated attackers in the network?  How will you ensure that your network is intelligent enough to recognise, authorize, prioritize and control the applications that use it?

Anyway, I have pontificated enough.  The simple message here is that there is another side to the story that Tim Greene published and it's not "the Dark Side" that's been portrayed.  Besides everyone knows that marketing is the Dark Side and that Darth Vader was the VP Marketing for the Empire. Don't they??

//Dom

A Rose By Any Other Name Still Can’t Grow Market Share

With apologies to the Bard of Avon…The news is finally going mainstream regarding Vernier Networks getting out of the NAC market and changing its name to Autonomic Networks. Industry observers are digging deep to read the tea leaves as to what this means to the industry as a whole, with specific speculation about Vernier’s one-time inline NAC rivals, Nevis and ConSentry. Matt Hines at InfoWorld quotes Paul Roberts at the 451 Group as saying, “ConSentry and Nevis Networks -- both direct rivals of Vernier -- could be among the other NAC providers looking to be sold, or under consideration for a buyout from the bigger fish”.

Before we offer some insights on the Vernier situation, it’s important to point out that this move by Vernier really has no bearing on us or what the industry perceives to be similar companies. The fact is that Vernier is a very different situation, with a substantially different product. For example, what Vernier was never able to figure out, or couldn't make work, was the importance of delivering inline access control as a secure switch, as well as an appliance. This critical detail is lost on many of the pundits covering the NAC market in general (because the concept of a secure switch is lost on the out of band appliance vendors), although ConSentry to its credit, as well as Nevis, is educating the market. Vernier was also at a different growth stage, and with a different set of investors, having raised over $100 million dollars with less to show for it than many of the other NAC vendors, not to mention its more direct inline competition. The telling point is that it appears that Vernier needed to ramp down its headcount into the 50 or so range, according to the Matt Hines article, and, well, that just requires a new plan and a new image to survive.

Nevis, which has had a different growth model, and quite frankly a different primary focus, is not in the same situation. We continue to ramp sales, and gather momentum and support from both the market and our investors. Now is not the time to be looking for the exits (it’s only Act II after all), although I don’t think any company would be completely closed-minded to a reasonable consolidation offer, NAC vendor or not. Having said that, it’s hard to deny that some consolidation in the NAC space isn’t warranted. The NAC market is still immature, and hasn’t grown according to early prognostications. But, here again, that may not have a great bearing on Nevis. We don’t consider ourselves a “NAC vendor”, in the way that the industry likes to clump vendors into simple sound-byte buckets. We have always taken a much broader view of the real problem customers are facing, and offer a solution of which NAC is only one of several primary components. We believe companies are better defined by the markets and problems they address than the features of their product anyway.

Back to Autonomic Networks (nee Vernier), it’s interesting that the industry view is that they are getting out of the NAC market and have remade themselves into a “role-based access control” solution based on existing intellectual property, while their “inline NAC technology may… be up for sale”. It has always been our contention that role-based access control, along with NAC (as well as intrusion detection and application use controls) are an integral part of a complete solution customers are looking for. It’s no secret that the inline vendors have always had a major advantage in this area, and that ultimately that’s what the market will demand. As Forrester stated early last year “NAC as we know it will fail”, and pure NAC vendors are seeing some effect of that. We are trying to change the “as we know it” part. We know the market needs more, and we believe customers (and finally the analysts and press) get it as well. It just doesn’t make sense to us that Vernier would throw the baby out with the bathwater, although we wish them luck in whatever they end up sorting out. It seems like I've seen this play before though...

In-line versus Out-of-Band Revisited

Tim Greene over at Network World had another post today in his NAC Alert column on the "NAC placement debate", whether it's better to be in-line or out of band. He took the opportunity to highlight a new Infonetics report that showed the market was about evenly divided and that the debate was roughly a draw. Revenue apparently is about equally split as well, with in-line devices getting only a couple percent more of the revenue pie.

In all fairness, we haven't drilled into the Infonetics report yet, but most of the conclusions Tim points out we would agree with: deployments are increasing in size, 2/3 of the market is still North America, etc. What gets me going is the simplified view of the merits of each. Tim summarizes as follows: "In general, in-line NAC appliances are better for smaller deployments because as the size of the installation grows, so does the number of devices. Out-of-band scales better."

Call me biased, but, folks, this just ain't true. Rather than get all huffy and technical here, I'd just like to point out our recent whitepaper on this very topic for a more in-depth analysis. In reality, when deploying out-of-band, just to provide the authentication functionality, an appliance is required in every switch domain, so the number of appliances required tends to be comparable. The bottom line is there are a lot of myths out there, so be careful. [One out-of-band vendor states that the two terms refer not to analyzing packets in or out of the flow of network traffic, but to whether or not the communication to enforcement points (a downstream switch, e.g.) was in or out of the flow of traffic. (Note that if you are in-line you can BE the enforcement point).]

I just hate to see these misconceptions and myths get propagated any further than they need to. I hope that clears things up.

Top 10 Vulnerability Trends for 2008

Our own Nevis Labs organization has published their prognosis for the top vulnerability trends for 2008. Get the document here. This is pretty typical for security research teams that track threats on a daily basis by both looking for new vulnerabilities and analyzing emerging threats around the clock, as our Nevis Labs team does. Some of the areas they expect to see increasing vulnerabilities include in Anti-Virus software, instant messaging applications, VoIP, and VM software.

Cisco TrustSec: What does it mean for the industry?

The Blogosphere has been surprisingly quiet about Cisco's TrustSec announcement, so I thought I'd weigh in and try and get some debate going. Mitchell Ashley did put out a couple of insightful posts on the subject and there have been a few articles reporting the news.

First thing I should say is that this announcement finally validates what we've known for sometime. The task of managing internal access to an Enterprise LAN is a problem that is too complex to use the traditional Cisco topology-based access control approach. You absolutely need to take an identity-based (or role based) approach otherwise the task of defining and managing policy becomes complex and unworkable. So the first piece of good news from this announcement is that we will be able to stop wasting energy on the religious wars over topology vs. identity because the big guy on the block finally admits that we were right all along.

As an aside, I do have to have a chuckle at Jayshree's quote on CNN where she claims "a new paradigm for security in role-based user access to applications and resources without compromising business velocity". Puhleeease, Nevis Networks, Consentry, Vernier (or should I say Autonomic Networks as they are to be known henceforth, more on that later) have been shipping solutions for years, and the paradigm was around long before that (can you say DEN). So history will be recast and re-written again, but that's ok, I'm quite flattered actually since Cisco has viewed our website over 2500 times in the past 6 months, I'm going to assume that their marketing team learned a lot from us.

So what about the Cisco TrustSec technology itself? What will this mean for customers and the market?

Cisco vs. Microsoft - Round 1,658  ding, ding

TrustSec is a Cisco response to Microsoft's Server Domain Isolation.  We saw an attempt by the two giants of the Enterprise to make nice over NAC/NAP with the promise of interoperability, but it strikes me that they are increasingly trying to solve the same problems at different network layers, so how long will that peace last and who ends up as the collateral damage in the ensuing battle?  You guessed it, Enterprise customers.  While Microsoft stuck to the desktop and Cisco stuck to switching and routing everything was fine, but Cisco has pushed further up the stack, and even set up shop in MS's backyard with an endpoint initiative in NAC.  Microsoft on the other hand just keep trying to abstract the network and diminish it's role to nothing more than a dumb transport.  All of this gets further complicated by the fact that they sell to different teams in IT organizations and that can lead to overlapping efforts or turf wars.

The Cost of Upgrades

For those Cisco customers interested, what will this mean in terms of cost?  Well, 802.11AE describes a new Ethernet frame format so that will mean software upgrades, and possibly hardware too, not just in the wiring closet but throughout the network and in the router infrastructure as well.  The big issue, as always, is that Cisco wiring closet switches have a very limited set of ACLs available and you need both ingress and egress ACLs.  So if you get too granular on your identity based policy you are definitely looking at hardware upgrades, possibly throughout the network.

It also relies on 802.1AF for key management, which is an extension of 802.1X.  So you're going to have to deploy that as well.  Bottom line here is that for Fortune 500's with big IT teams and money to spend, this might be possible, but for everyone else the cost of deployment and maintenance will probably be prohibitive. 

Secure Malware Channels

The thing that really struck me about TrustSec is the fact that it provides the ability to create point to point encrypted channels based on policy.  This is near and dear to my heart because Nevis introduced this ability using IPSec 2 years back.  The piece that Cisco seem to have overlooked is that if you don't implement IPS on each and every access switch port at wire speed like we do, you've just created secure channels to spread malware throughout the network.  Now, I'm sure they'll tell you that this is where NAC comes into play and that if you deploy NAC alongside TrustSec you have nothing to worry about.  Hmmm, except, as we all know, pre-connect NAC alone (particularly Cisco's flavor of it) is really bad at mitigating blended malware threats, particularly zero day threats. 

Heterogeneity

Another big stumbling block with TrustSec is that it depends on you having a 100% Cisco network.  Cisco has really been pushing hard against the best of breed approach lately and redoubling their efforts to lock customers into a single vendor approach.  Call me crazy, but I see this as a sign that there is a chink in their armor.  They've been losing switch market share slowly but surely to HP, and now you have other upstarts in the Secure Switch arena like Nevis Networks and Consentry starting to make in-roads in the wiring closet.  It's interesting to see Cisco starting to adopt "defend your turf" strategies that the other 7 dwarves in switching have had to live with for so long to defend against Cisco.  I think there is good opportunity for some of those other switching vendors to go on the offensive right now using security and wiring closet commodotization as the weapon of choice.

Standards (or are they?)

According to the Cisco releases and whitepaper, TrustSec is "based" on 802.1AE.  Interesting word "based".  Are we to conclude that Cisco have "interpreted" this new IEEE standard, which is just another way of saying "made it proprietary"?  Or have they developed proprietary extensions to lock in some additional Cisco goodness?  Or have they just built an architecture on top of the IEEE standard so that it would be interoperable with multi-vendor equipment?  I think the latter is highly unlikely.  I tend to agree with Mitchell Ashley's assessment, that this will be a closed Cisco architecture

If anyone else has any insight or opinion, I'm all ears

//Dom

Apple exploits instead of Apple pie on Thanksgiving

I was asked recently by some prospective customers how our 24/7 global support coverage works?  The inference being that they expect that we log calls and then wait 5 or 6 hours to start Engineering working on it.

Since a zero-day Apple QuickTime vulnerability was published on Thanksgiving day with associated exploit code, I thought that would make a good example of the benefits a truly global engineering team can have.

Apple QuickTime RTSP Response Header Remote Stack Based Buffer Overflow Vulnerability

Apple QuickTime RTSP Response Header Content-Length Remote Buffer Overflow Vulnerability

Apple has not released any patches/updates so far. However, the exploit code is publicly available, which puts users at risk.

This vulnerability, if successfully exploited by the attacker, would allow full control of the victim's computer. The attack can be as easy as convincing the user to browse a website.  Nevis Labs has tested the exploit and it works pretty consistently, and, as per the reports, it also works for Windows Vista.  I'm happy to report that our customers are well protected because our Nevis Labs offices are global and work 24/7, so we developed a threat protection signature to cover this threat while everyone else in the US was enjoying their Apple pie.

//Dom

It's Patch Tuesday again....

So I thought I'd share an example of the timely updates that our customers receive on a daily basis from our Nevis Labs service.  Subscribers obviously get a lot more information, and access to the Threat Encyclopedia that we maintain, but I've received a few requests to give a taste of the service, so thought today was a good day to do exactly that.

Vulnerabilities

MS07-061

Windows URI Handling Remote Code Execution Vulnerability

Description

Windows URI Handling Remote Code Execution Vulnerability refers to a vulnerability which exists in the way the Windows shell handles specially crafted URIs that are passed to it. An attacker could exploit this by including a specially crafted URI in an application or attachment, which could potentially allow remote code execution

This vulnerability can be exploited through a variety of applications, including Adobe PDF Reader, mIRC, Firefox, Outlook, Netscape Navigator, and others.

Impact

Windows XP Service Pack 2

Windows XP Professional x64 Edition and Service Pack 2

Windows Server 2003 Service Pack 1 and Service Pack 2

Windows Server 2003 Service Pack 1 and Service Pack 2

Windows Server 2003 x64 Edition and Service Pack 2

Windows Server 2003 with SP1 for Itanium-based Systems and SP2

Severity

Critical

Solution

On LANenforcer, update the CEI profile to the latest version

To check for CEI profile version, type “show version” on the CLI prompt of the LANenforcer.

MS07-062

DNS Spoofing Attack Vulnerability

Description

DNS Spoofing Attack Vulnerability refers to a vulnerability which exists in Windows DNS Servers. It could allow non-administrative users to send malicious responses to DNS requests, thereby spoofing or redirecting Net traffic from legitimate locations.

Impact

Microsoft Windows 2000 Server Service Pack 4

Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2

Windows Server 2003 x64 Edition and Windows Server 2003 x64 Edition Service Pack 2

Windows Server 2003 with SP1 for Itanium-based Systems and Windows Server 2003 with SP2 for Itanium-based Systems

Severity

High

Solution

On LANenforcer, update the CEI profile to the latest version.

To check for CEI profile version, type “show version” on the CLI prompt of the LANenforcer.

Can we detect sleeper cell bots?

Think of a botnet as a terrorist sleeper cell. A terrorist sleeper cell consists of a group of terrorists that blend themselves into the society without attracting the attention of organizations such as the FBI. When they get commands to strike, they go blow up planes, disrupt power plants, detonate dirty bombs, etc. Similarly, a botnet sleeper cell sneaks silently into computers; stays inactivated and undetected, until the botnet owner issues orders to attack. These orders can be anything including sending spam, performing a DDoS attack, or recruiting more bots.

Terrorist sleeper cells can lead directly to the loss of life as well as great physical and physiological damage, while botnet sleeper cells could cripple network infrastructure and inflict economic losses, or worse. Early this summer, Estonia was pounded by a DDoS. This displayed a tremendous amount of coordination and the destructive power of sleeper cell bots. Today, Storm worm is becoming more powerful by the day, and can easily overpower the world’s top supercomputers. Terrorism prevails when both types of sleeper cells work together. With the rumors of Al Qaeda announcing Cyber Warfare starting this Sunday, and with availability of electronic Jihad 2.0, we have yet to see the impact, but might soon.

Detection of both types of sleeper cells can be done using behavior profiling. In both cases the steps are to understand normal behavior, look for suspicious triggers, narrow down the watch-list, and continue to observe the suspect more closely until the suspect is proven to be guilty or innocent. On the other hand, there are important differences that make detecting terrorist sleeper cells a harder problem than detecting sleeper cell bots.

Total surveillance is the first key component of sleeper cell detection. It is possible to have all the hosts under total surveillance in an enterprise (Nevis does it), however, it is hard to watch every person in a nation 24/7 (even though it is attempted). The FBI has a watch-list and as of today there are about half a million people in there. Watching half a million computers is much easier than watching half a million people. (Perhaps the half a million people are best watched by primarily watching their computers.)

Characterization of behavior is the second key component of sleeper cell detection. The more characteristics you look for, the better the detection mechanism gets. Instead of going after every Muslim-like name (such as mine, but that is another and ongoing story), adding more information such as background, religion, bank and phone records, degree, age, sex, etc. would make the profile stronger and hence less false alarms. But the list of possible characteristics to include is nearly endless. On the other hand, while a few of us use computers in a diverse way, the huge majority do so in ways that are far easier to characterize than a person, even a mundane blog-writing cubical worker.

Correlation across suspected bots is more fruitful than correlation across suspected terrorists. The detection of a single bot in the botnet sleeper cell can often result in the capture of the entire botnet. However, the capture of a single terrorist may not necessarily lead to the capture of the entire terrorist network (even with waterboarding).

The impact of false alarms varies in both cases. False positives in terrorist sleeper cell detection can have a wide range of damage from a cop showing up at your doorstep to a person ending up in Guantanamo. False positives in sleeper cell bot detection can range from a guest user being cut-off from a network for a few minutes to extra work for a sys-admin, or even taking down a large chunk of the network and damaging the enterprise financially. Arguably, false negatives in the case of terrorists are worse than they are in the case of bots; even a single terrorist can lead to substantial loss of life.

While the fundamental theory behind detecting sleeper cells remains the same, the FBI’s job is much more difficult than mine. So, I’ll keep my job as well as cube life which the FBI secretly classifies as: D8DBQFHM6/RERAJ9O7woT0QB7xmpMACbBxfq4pLMkwyUxbOMFglno1gA4ÇGÊPœ/td^ÖÐÚÒÅ%iõÜ/'NO7*‰o{¶ˆ0öp%‑ÎUPuŠ4'ÅÞ©(8¹

//Khushboo Shah, Ph.D.

NAC deployments under scrutiny...

Lisa Vaas over at eWeek is reporting on a new NAC survey coming out of the Aberdeen Group. In Carol Baroudi's "Who's Got the NAC? Best Practices in Protecting Network Access" report (it's free if you discount the sponsor sending bugging you for the next few weeks), she surveys close to 400 NAC adopters and attempts to benchmark who is doing a good job of controlling access to their networks (while also reviewing some the processes and technologies they are using). It's interesting reading and reviewing the deployments rather than the technologies and vendors is a refreshing take on a NAC survey.

Here's the take away for me. Those who are considered Best in Class in the report have a strong focus on a holistic approach to NAC and prioritise the post-connect functionality and the need to persistently monitor and control endpoints and users in a meaningful way after they get on the network (and we're not just talking about doing an endpoint posture check every 10 minutes). They also believe that operational considerations and the end user experience are of paramount importance to success.

Here is what those Best in Class organization say are the most important things to expect out of a NAC solution:

- Prevents unauthorized users from accessing the network
- Causes minimal operational impact on users, help desk and network performance
- Supports/enforces policies specific to different user groups
- Logs all network access events for auditing
- Prevents unauthorized devices from accessing the network
- Centrally records all events
- Can be installed without directly impacting network performance
- Is transparent to the user
- Supports enforcement for remote users
- Can quarantine unhealthy machines without cross-infection
- Assesses endpoint security status

This certainly gels with what our customers are telling us as well. I think point number 2 is where most NAC solutions fall flat on their faces. Most vendors have given very little consideration to getting the solution into the network seamlessly and ensuring there is a transparent user experience. I'm proud to say that our customers have no such worries. If you'd like to read an impartial, blow by blow, daily account of the evaluation and operational deployment of a NAC product into a sizeable production network, head over to Justin Gerharter's blog at www.bumpinthewire.com

//Dom