Endpoint Security

In this month's SearchSMB column, I provide a primer on endpoint security and why it's important. I also include 5 tips to ensure the security of your endpoint. Attacking the endpoints is the vector de jour and for obvious reasons. The one's with the controls (basically you and your users) have that little issue of human nature that forces them to click on stuff, even when they know they shouldn't. So here are some ideas on how to take that vector out of play. Of course, nothing is foolproof, but it's a start.

http://searchsmb.techtarget.com/tip/0,289483,sid44_gci1213598,00.html

 

PS: Also keep in mind this is for SearchSMB, which means mid-sized businesses. Some of the stuff I discuss in this specific column are better suited to this segment (100-1000 users). So you enterprise folks can put your guns back in the holster.

 

Note from Mike: I'd like to introduce the Security Incite community to Mark Bouchard, a former META colleague, good friend and tremendous analyst. He runs his own analyst shop now, called Missing Link Security Services and is one of my go-to guys when I need to bounce some ideas around. Mark kindly offered some perspectives on the recent NAC "discussion" among myself, Shimel, Hoff, and Stiennon and even more graciously is allowing me to publish them to the community. Of course, these perspectives are Mark's and not my own - as you'll soon come to see.

Scratch AND Sniff (aka, SNAC and SNF)
by Mark Bouchard, Missing Link Security Services

This is by no means a point-by-point analysis of the Stiennon/Hoff/Shimel/Rothman NAC debate. Truth be told, I didn't even review all the threads before compiling this. But for what it's worth, here's my two cents on the topic.

The practice of infosec has always entailed using both belt and suspenders. The principle of defense in depth guides us in this matter, driving the use of multiple, overlapping countermeasures. Appropriately, both approaches discussed (i.e., SNF and SNAC) have value, and both approaches will ultimately be used, at least in some manner.

Perhaps a better question though is which has greater value. In this regard, I’ll have to weigh in on the side of Mr. Stiennon. That said, my version of SNF is actually pervasively deployed IPS (which eventually will come in network switch form factor) that is enhanced with passively and actively gathered contextual information about (a) the environment it is trying to defend, and (b) the entities (i.e., devices, users) that it is trying to protect the environment against (albeit to a lesser extent, I suspect). This contextual information is the key to making IPS much more accurate in terms of false positive and negatives, and in turn enables a greater degree of automated response (e.g., blocking access, quarantining).

This seems like a much better investment than NAC, at least as I understand it. Some of the advantages that I see are these:

1. There is no need to maintain 10’s, 100’s or even 1000’s of granular access rules to achieve a robust level of defense. Tellingly, this is an anathema to any organization that has already made significant investments in Identity Management. What I routinely hear from many large organizations is: “why do I want to re-create this wheel at the entry point of my network when I’ve already spent hundreds of thousands of dollars trying to do it with provisioning systems at the servers and apps themselves”.
   
   
2. There is less likelihood of adversely impacting the business by quarantining legitimate (low risk) users/traffic for potentially useless reasons (e.g., DAT file is > 1 day old).
   
   
3. There is far less reliance on components that are outside of the organization’s control. External clients and their software will always eventually be broken/hacked. That is one of the long-standing criticisms of most DRM techniques. Consequently, everything originating from (or about) an external client is not really trustworthy. Presuming otherwise is a dangerous trap. This is in contrast to the network traffic that shows up at our network entry points. It is what it is, and is always presumed guilty until proven innocent. To be perfectly clear, I’m not saying that the network defense system shouldn’t account for information pertaining to the client. I’m just saying that how it is obtained and the weight that is put on it deserves more attention – and that NAC doesn’t seem like a good way to get this information.
   
   
4. And the clincher in my mind: security posture checks done via NAC would need to be significantly more comprehensive before we would have reasonable assurance that the clients are in fact not compromised, and therefore not a threat to the organization’s environment. Just checking for AV, FW, and a few patches is laughable. Let’s also not forget the challenge of building/maintaining agents and/or scanning techniques for every type of client out there – undisputedly an impossible task. However, barring such breadth and depth of checking, it will still be necessary to erect network-based defenses to help prevent attacks. So … if you’re going to have to do that anyway, then why not make SNF (or whatever you want to call it) the focal point of your defenses, especially since its under your control. Let’s face it, NAC is really just a refinement of the traditional firewall-based approach to security – and we all know how well that worked!

And this list is not even close to being exhaustive.

Will the SNF-like approach be easy; of course not. But then nothing in security ever is. But it does seem to me that the SNF-like approach will be far more effective. Consequently I'm beginning to think that NAC is on a slippery slope to becoming one of the greatest disappointments of the decade – at least the pre-admission stuff (i.e., posture checking), and potentially at least part of the so-called post-admission capability (i.e., granular access control). It will probably survive to some extent, but much more likely as a feature as opposed to THE foundation of a network security strategy.

Finally, I could probably come up with a colorful analogy here (e.g., about how it makes more sense to better protect one’s own borders before trying to extend the battle to other, external geographies), but that would just give you something else to pick apart as opposed to focusing on the main issue :-)

Richard Stiennon has responded to the SNAC and Cocktail post, and by proxy to Shimel and Hoff. Many of you don't check my comments and Richard pretty much wrote a book, so I'll post it to the main blog and then provide some of my thoughts. I'm flattered that Richard would state his position here at Security Incite, as opposed to dealing directly with either Senators Shimel or Hoff, but I can see his logic. Fact is, I find both of those guys some of the most un-vendor vendors, but I understand what their jobs are and how they get paid.

Here is Richard's comment (here):

You want to step outside?

Better yet, we'll do it right here. This sort of debate is better served by a couple of independent analysts. I would rather risk your skillful barbs then get into a pissing match with the Chief Strategy Officers of two vendors, one that sells NAC solutions, and one that thinks honk’n monster UTM’s is the answer to everything,

First of all Allen is right that I am still singing the same tune after two years. As far as I know I am the ONLY analyst that thinks the whole idea of end point data being used to grant access is worthless.

Let's take a simple scenario. A large enterprise (5,000+ users) running Symantec AV, Microsoft AntiSpyware, and a spanking new Cisco NAC infrastructure (I know, that does not exist yet but someday...)

It's the day after the Labor Day Holiday in the US. The CEO, CFO, and half a thousand other workers show up for work. They have been on vacation and their DAT files, and Microsoft updates and critical patches have not been installed. They plug in to the network and are barred from connecting. About 250 people follow the instructions from the damn quarantine server. The rest call the help desk which is not answering the phone because EVERYBODY is scrambling to get the CEO online before his conference call with the Board.

Network IT people are not stupid. Their first mandate is "do no harm". The only reason they are looking at NAC solutions is they think it can help them *reduce* help desk calls from infections brought in by bad laptops. NAC requires your laptops, your AV vendor, your network vendor, your NAC vendor and Microsoft to play nice. There are too many opportunities for things to go wrong.

I consider myself a network security guy. Doing security in the network invariably is better than doing it on the desktop. Desktop AV is the biggest pain in the ass to administer. *Any* agent is a pain to administer.

So, yes, I have dreams. My dream is that an infected laptop brought on to the network will do no harm, yet will still be able to talk to the exchange server and be a productive device. Unlike Cisco I cannot turn my fantasies into billboards on highway 101 before demonstrating a single element of their CNAC fantasy. But I can continue to talk to people who have dumped their host NAC solutions for inline blocking and tackling. I can watch and report on network security vendors that are combining with switch vendors or introducing access switches of their own.

Keep in mind that even in the fantasy world of a complete NAC infrastructure there is still no defense against the malicious insider with credentials and perfectly updated laptop. Why would you spend millions to deploy a security solution that did nothing to defend you from malicious users? Huh?

I view NetFlow tools as an underutilized and powerful technology for understanding the corporate network and helping to harden it. You date yourself Mike when you equate NetFlow with DDoS defense. But it is important to point out that NetFlow on a carrier is used for tracking down and blocking DDoS as well as spammers. Why wouldn’t an ISP enforce NAC on its customers? Why wouldn’t they quarantine all zombies until they were remediated? Answer that and you will understand why just as NAC does not work in the cloud it does not work in the Enterprise.

NetFlow is just one of the elements that can make the network secure. You mention a bunch of others. IPS, access controls, VLANs, firewalls, ACLs. I say work with those proven technologies; don’t fall into Cisco’s dream of owning the desktop as well as the network!

So what says me about this rant? First of all, per usual Richard has some some underlying deep thought in his position. Fact is, I still don't buy it. Endpoint security is another tool in the bag. Why wouldn't we use that data to ensure the network is safer? His example of everyone logging into the network at the same time is tired and irrelevant. Anyone that would have a policy in place that would quarantine hundreds of employees after a holiday weekend is an idiot. There is a middle ground, there always is. You want to make sure you are quarantining only the devices that can harm the network, not the one's that just have a DAT file a week old.

So I believe there is value to ADMISSION CONTROL, though there is more value in ACCESS CONTROL over time. Richard and I will just disagree on the admission control stuff. Which is OK, that's what makes the world go around.

I definitely take issue with the idea that you can do EVERYTHING security in the network. I'm a network security guy too, and I understand the limitations that mobility and the "insider threat" provide relative to doing everything in the network. The answer is not one or the other, it's both. And that's just for infrastructure security. When you think about having to secure data and information, unless you have adopted a dumb terminal model - YOU MUST SECURE THE ENDPOINT. If sensitive data is there (and it's there), it must be secured. Is it a pain in the ass? You bet. But certainly less of a pain in the ass than having to disclose a data breach due to stupidity, ignorance or apathy.

I do agree that inline blocking and tackling (LAN security or Secure Switches - whatever you want to call them) will prevail over time. My point in suggesting the cocktail is that I envison a correlation engine factoring in all sorts of information will drive what policies get enforced in the fabric. I know a lot of folks don't like the idea of security in the fabric, but I don't care. That trend is inevitable. The train has left the station and though it'll take a generational upgrade to get there (5-7 years), WE WILL GET THERE.

Finally relative to Netflow, if Richard is saying that it's one of many data sources - then I'm cool with that and it's what I've been saying for a long time. NBAD is still predominately a DDoS mitigation technique, regardless of what crap the vendors are feeding - because the ISPs buy most of the equipment and the ISPs have taken on neither spammers nor zombies. NBAD technology is applicable to both of these problems, but only if customers use it.

So at the end of the day, Richard and I still have some fundamental disagreements as to how this all shakes out. I appreciate him weighing in and suffice it to say we'll both be looking for opportunities to prove we are right. If there is one thing I know, it's that be both hate to be wrong.

 

Looks like Chris Hoff is back in form, and I'm grateful. There are few people that make me think EVERY TIME they write something, and Chris is one of them. This time he weighs in on the Shimel/Stiennon discussion that I mentioned in today's TDI (here).

Read Chris' post right now. The rest of this post will make no sense until you do. Don't worry, I'll wait...

[Romantic interlude]

See what I mean? Chris is funny and he makes you think. BUT, despite the fact that his points are all well taken, he doesn't take the discussion far enough. This was no draw. It was a KO. After thinking a bit more about it, Stiennon came into the battle with a foundation of quicksand. So it wasn't that tough for Shimel to dunk him under. Not that Alan is entirely right, Chris points that out as well. But on the continuum of correctness, Alan's got him hands down. And I am always right, just ask me. :-)

Basically, there are two key points that make Richard's analysis totally flawed - both of which Chris points out. First, the decoupling of host-based and network security. I said it this AM and I'll say it again. That is just stupid. The point of gathering data is to use it and correlate it in interesting ways. Sure some of the data is unrelated, but not all of it. I'll dig into that in a bit more detail in a minute.

Second, the idea of basing decisions entirely on Netflow is ridiculous. I'm not saying that there isn't value in L2/L3 information, there is. BUT it's no panacea. As Chris says, if you are looking at stopping a DDoS (the main value of anomaly detection solutions today), Netflow is what you need. But most attacks are not DDoS anymore but happen at the upper layers of the stack. Basically you're looking at the culprit only from the waist down. I'm not saying that a lot of motivation doesn't happen below the waist, but I wouldn't say it's based on higher order thinking.

So what's the answer? As opposed to Chris' proffered new SNAC acronym (kind of gives me the munchies, I say) - I'd rather we think about a COCKTAIL. And no, that's not just because I'm an alcoholic.

Since I started this gig back in January, I've been talking about losing the religion (Day of Incite post here, Incite Redux post here), but let me take it one step further and leverage something I know a little bit about - anti-spam.

Basically, there are about 30-40 different techniques you can use to determine if a message is spam. None work all the time, in fact most are downright abysmal across the universe of undesireable messages you get. But each can detect a certain type of spam with pretty good effectiveness. The Spam Assassin folks were really the first (regardless of whatever spin the vendors want to use) to take a bunch of those techniques and correlate them into an anti-spam cocktail that was much stronger than any specific technique on its own. Of course, the vendors have greatly improved the cocktail mixture(s), and given the core concept staying power. No one relies on only a single technique anymore.

So what? We need to see the same approach applied to the network security business. Whether it's data from Netflow, an anomaly detection engine, an IDS/IPS and/or an IP address' "reputation" - we should be gathering all this information, correlating it and using that perspective to figure out if something is amiss. And no, SIM is not the answer because they don't DO ANYTHING with the information beside pump out some reports, which don't help you stop an attack.

Now before I get a bunch of comments saying I'm an idiot and you can't do that, just think about it for a second. I know there are processing limitations of doing this in real time on big pipes that anti-spam boxes don't have to deal with. I know correlating this information is fraught with peril and if you get it wrong, half of your friggin' network will be quarantined. I also know that without some kind of standard for this data interchange, this will only work in a homogenous environment and that's a problem given the best of breed mentality of most large enterprise security folk. But Big is the new small, after all.

So, I'm not saying this is easy, but I also don't think the way we are doing things is working either. I'd love to get a dialog going on why this idea is wrong. It very well could be. But I'd rather some smart folks poke holes in the idea, so all of you brainiacs out there - sharpen your battle-axes and have at it. Why am I wrong? And more importantly, what is the RIGHT ANSWER?

 

It was an interesting afternoon for Secure Computing. I'm sure great highs and terrible lows. First off, they missed their Q2 by a country mile. This was the second consecutive quarter they missed since they closed the CyberGuard deal. The Street is taking their pound of flesh and then some. The stock is off 40% after hours and on the investor call there was obvious angst.

On the other hand, Secure announced the acquisition of CipherTrust for between $240 and 270 million, depending on whether Secure's stock recovers at all before the deal closes. It's a mixture of cash ($185 million) and stock (10 million shares), which makes CipherTrust CEO Jay Chaudhry as Secure's largest individual shareholder.

Interestingly enough, CipherTrust decided to go through with the deal even with the huge miss and resultant impact to the deal size. That means either they are true believers in the strategy and upside potential or there weren't any others at the dance.

In terms of disclosures, I am a CipherTrust shareholder and expect to liquidate my holdings upon closing. Yes I'll end up making a little money on the deal, so I'm happy. And a number of my good friends that are still over there seem to be excited about the deal, so good for them. But given my "insider" knowledge, I'll restrict my comments to the strategic rationale of the deal and the impact to customers. That's only fair.

The new Secure Computing is positioning as the "enterprise gateway security" company. With UTM, messaging security and web security under one roof, the story actually works. Secure wants to own the DMZ and they've got most of the pieces to do that. They specifically will not play on the desktop or the data center for the time being, and I think that focus is good.

Of course, they need to integrate all of those pieces or else there is no leverage. That is Job #1 and they don't have a lot of time. Secure also will be well suited to start looking at integrated hardware. Maybe blades, maybe virtualized stuff, but something to differentiate from McAfee or Cisco, that don't really have a combined appliance.

They also will not be able to buy anything else for quite some time, so they'll need to run with the horses that are already in the barn. Optimally, you'd like to see them add some more sophisticated outbound content filtering (beyond Webwasher), but besides that they've got the pieces. And over time, the gateway only play is inherently limiting. There is some stuff that will need to be done on the devices and some in the data center. But one step at a time, they've got a lot of integration work prior to this being an issue.

In terms of the strategic rationale, Secure outlined 4 reasons why the deal makes sense, but I was only able to capture 3. Oh well. Let me pick them apart.

1. Differentiated product set - Not so much. That's why the management integration and eventually the hardware integration is going to be critical to making differentiation a reality. Secure definitely has more pieces than a BlueCoat, SurfControl, F5 or Websense now, but that makes them the tallest 3rd grader on the playground. They aren't going to match up well against the 5th graders (Check Point and ISS) with a lot more revenue, or the Big Security 9th graders (McAfee, Symantec, Juniper, Cisco) that have much bigger resources and huge cash cows to milk.
   
   
2. Reputation-based technologies - This is actually the key to unlocking the value of the deal. When IronPort announced their web gateway a while back, it's positioning was based specifically around integrating "reputation" into the web filtering space. Secure can now do that, but it's not going to happen on day 1, let's be clear about that. CipherTrust is an email security company and gathers email security data. Once the deal closes, they'll presumably have access to a much wider mix of data, but then the fun work of gathering, correlating, and integrating it into the products start. Don't expect impact here until late-2007 - best case.
   
   
3. Distribution - Secure acquired a great enterprise customer base and a strong sales force (I should know, I used to work with them). If they can retain the talent, that will help especially with big, competitive enterprise class deals against Big Security. But I'm not so sure Secure's 1600 resellers will know what to do with a complicated, enterprise class email security gateway. That will be one of the biggest initial challenges because CipherTrust always stayed very focused on a select set of resellers. But Secure does have a lot more resources for training, etc. and a much better and broader international platform, which has been problematic for all the email security players.

CipherTrust is also committing some people resources to the deal as well. Specifically mentioned were Jay as Secure's new Chief Strategy guy. Paul Judge as the CTO, and Atri Chaterjee as the lead marketing guy. The ultimate success of this deal depends on at least some of the CipherTrust DNA sticking around. In order to thrive longer term, Secure's culture will need a bit of the CipherTrust aggressiveness. And candidly, CipherTrust's culture needs a bit of big company structure and process. If those guys (and many of the sales folks) are still there in mid-2007 that would bode well.

So, overall I can see the strategic rationale behind the deal. Customers that don't want Big Security in their DMZ now have an alternative, and if the technical integration is pulled off it's potentially a compelling alternative. CipherTrust customers will now have more stuff to think about as they re-architect their DMZ and Secure customers get a leading email security gateway option.

There will inevitably be some integration hiccups, so folks like IronPort and Proofpoint have a small window to throw some FUD (fear, uncertainty, doubt) around to try to get new deals. But neither is a stand-alone opportunity over time, so they should buddy up to Check Point and ISS, as the 4th graders are going to need additional stuff to compete on the playground.

This morning I stumbled upon Roger Grimes' column in InfoWorld and his recent post "Effective Security isn't easy, but it's possible." Link here. In this piece, he makes a number of contentions that make a lot of sense and highlights the point that security your environment is achievable, but there is a cost - and I'm not talking about money.

The thing I didn't see in Roger's column that I think is pretty important is every company's threshold for security is going to be different. Some are willing to accept a bit more risk in order to either improve the user experience or perform an important business function. But the key here is for the end user to MAKE that decision, as opposed to having it thrust upon them.

Some of Roger's ideas will work for your environment, some not so much. But this is the kind of simple stuff (in concept anyway) that can really make a big difference in your security posture.

So let's go through Roger's list of "effective security solutions" (in his order of effectiveness):

1. Do not allow end-users to run or install unauthorized software - Bingo. This is why application control software is so effective at stopping malware. If users can't do stupid things, everyone is better off.
   
   
2. Don't put unnecessary software on the authorized list - This is where the rubber of #1 meets the road of the customers. He specifically mentions Flash, Real Player and iTunes. I'd posit that for many employees, RealPlayer is the only one that is "optional." With iTunes being a prevalent distribution mechanisms for podcasts (where folks can get info directly related to their jobs), I'm not sure iTunes is the villain it once seemed. And anyone that surfs the web needs Flash. Do these add risk, yes! But I'm not sure a strategy preventing these applications is defendable.
   
   
3. Implement default deny - Amen to this. Otherwise called the positive security model, unless you say it's good, it's not - so you block it. This can be implemented on routers and firewalls and will dramatically increase your perimeter security posture.
   
   
4. Don't allow end-users to be logged in as Administrator - This is easier said than done, and Roger admits that. But getting new applications isn't a very good answer for most folks. Vista will do a lot to help this problem for Windows users.
   
   
5. Automate comprehensive patching - This is great advice. A lot of companies have rigorous change control that takes weeks to authorize a patch. That is weeks of exposure. I say patch first, clean up the small percentage of messes later.
   
   
6. Convert all inbound email to plain text - Hmm. I'm torn about this one. If you have application control implemented, I'm not sure this does anything but piss people off that their email looks like crap.
   
   
7. Enforce long passwords - I don't buy this one. So it takes a password cracker 3 hours instead of 3 minutes. And the reality is that hackers get passwords via social engineering anyway. If you are worried about it, two factor (like BioPassword) could be a good alternative.
   
   
8. Encrypt all confidential data by default - I'm not sure what this means and how you do it. This only solves half the problem. What happens when that data is loaded to a laptop or sent in an email?
   
   
9. Spend less money on new security software and more money on reviewing the basics - This is the best one of the bunch. A misconfigured firewall is about as good as not having one, so yes - in all of our desire to get that shiny new thing, we tend to forget about the simple stuff that can kill us.
   
   
10. Hack and audit your own network regularly - Again, this is great advice. Public companies need to do this and private companies should as well. You never know how effective your defense are until you try to break them.

So in general, Roger's list is real good. I agree that all of these are possible, given a CIO/CISO with an iron fist that can ram a no iTunes policy down the throats of the users. I know they exist, but I don't know too many.

In this week's NetworkWorld column, I address the zombie issue. What are zombies, what do they do, and what's the impact to users and carrier networks? Suffice it to say, the ISPs need to step up and both accept responsibility for the problem and start looking at technological solutions to deal with the problem. I also introduce a company called Simplicita, which portrays to address the situation for ISPs. Check it out and let me know what you think.

http://www.networkworld.com/columnists/2006/060506rothman.html 

Seems the folks over at Yankee Group are making some waves today by hypothesizing that the emergence of Vista will "dramatically" affect the Windows security product market. CNET's coverage is here. I will admit to being the master of the obvious at times, but I want to remind everyone that regardless of whether this projection is right or wrong - YOU DON'T CARE.

We all know that nothing happens overnight in this business. Vista will be out at some point (you don't care about that either) and it will have some embedded security capabilities that will overlap with some commercial products. So what? Are you going to shut off all the ZoneAlarm, Webroot, and Safeboot stuff you've been buying? Of course not, you are at risk TODAY and Vista is not going to be there for another 300-450 tomorrows (depending on your threshold for pain). So you better keep on keeping on. That's the only choice you have.

Let's look at the situation from a historical perspective because we've seen this moving before. Windows XP SP2 was supposed to kill the personal firewall market. I actually thought the timing was interesting that Check Point had acquired Zone Labs about 2 weeks before Microsoft announced they were bundling the XP firewall for free. Did that kill the personal FW market? A resounding NO.

Actually some of the personal firewall markets got a bit enterprising (like Sygate) and started morphing their "endpoint" security capabilities into a piece of a larger Network Access Control environment. Senforce is moving towards this vision as well, integrating StillSecure's NAC technology in. Microsoft did that too, right? Isn't that what NAP is about? Well, if you get in your time machine and step out in 2008 when Longhorn is there too, then the answer would be yes. But not today.

We'll see similar evolution in spyware and full disk encryption. Microsoft will offer a lowest common denominator and existing vendors better have a very clean, very crisp value proposition on top of that. If they don't, then these 3rd party vendors deserve to get steamrolled by the Vista juggernaut.

I also take issue with some of Yankee's comments about when to deploy Vista. They seem to think that because the user experience is different and the additional security may cause some users to get grumpy, it's OK to wait until 2008 to upgrade. My opinion is that it's OK to wait until 2008, but do it because you aren't refreshing your PC's until then or you've got other priorities, NOT because you don't want to impact the user experience. That's a stupid reason to do nothing.

Windows XP SP2 is not secure enough. We are reminded of this every day. If you are committed to Windows (like 80% of the world), then you'll want to upgrade to Vista when practical. As a security administrator, you have a choice - spend some time training your users about Vista's user account protection or continue cleaning up the mess of Windows XP.

So I applaud the Yankee Group's PR savvy, since I saw a lot of pick-up for this story today, but feel compelled to remind folks that Vista is still practically a year away and you've got a lot of work to do between now and then.

There is clearly a move to take back control of corporate networks. Which, to be clear, is a good thing. Ultimately corporate networks (and the devices that run on them) are the property of the corporation and should be treated as such. I'm as big an MP3 user as most, but that doesn't mean I should have 20GB of music on my work laptop. I have a jukebox that I carry with me, and that suits me just fine.

But what about Skype? Obviously a lot of small businesses are using Skype for business calls. So, controlling Skype is not high on the agenda given the cost savings it provides, especially for those global organizations. Yet, it still begs the question about enterprises, should you allow Skype? If so, can you control it? If not, how can you stop it?It seems that my friends over at the Burton Group have a strong opinion about the topic, as evidenced by this quote in an article called "Skype Dangers May Be Acceptable to Business" on March 7:

"If the risk is too high - ban Skype. If the reward outweighs the risk - consider Skype as part of your overall communications strategy," says Irwin Lazar, senior analyst for Burton.

Now that is taking a hard position. First let's weigh the actual risks of Skype. It uses a very innovative mechanism to evade both detection and ensure connections go unfettered regardless of the security products put in place. They also use their own encryption techniques to make sure the sessions (and files or conversations) cannot be snooped. NetworkWorld contracted with Ed Mier a while back to see what the real impact of Skype was on a network and whether it was a security risk. The article is [http://www.networkworld.com/reviews/2005/121205-skype-test.html]. The answer was rather impressive in that Mier couldn't really find anything wrong with running Skype, from a security perspective.

Of course, that assumes that none of your devices is a Skype Supernode, their term for a call switching node. Kind of like a Class 4 switch for Skype calls. Have any of you seen a Class 4 switch? They are big, have lots of horsepower, and a ton of network connectivity. Your desktop is not that, so if you mysteriously have significant network congestion and your computer is inexplicably smoking, you should probably turn it off. SuperNodes are bad for corporate network hygiene.Now from a policy perspective it could present a big problem.

Let's say you are in a regulated business and you need to have every call with a customer logged and in some cases recorded. You can't do that with Skype. You won't even know the call happened. Most of your diligent employees wouldn't be doing something below board like this, but you wouldn't know it even if they did. That's a problem. Same goes for environments with real sensitive intellectual property. Skype can transfer files too.

I'm pretty sure that the "extrusion prevention" tools like Vontu and Reconnex don't know what to do with Skype either. So it's not something that you can control if you let it in. Yes, free is a good price, so the cost savings can be compelling. But for those having to answer to Sen. Sarbanes or Rep. Oxley, you may want to think twice. It's hard to have strong controls on something that you can't control.

How do you stop it? As with most things, you can attack it at the network or at the endpoint. Skype was designed by the folks that did Kazaa, so they know a little bit about how to go into a network undetected. I saw an announcement from SurfControl (http://biz.yahoo.com/prnews/060321/sftu084.html?.v=52) that says they can stop Skype on the gateway, and maybe they can. For now. How long will it be before Skype changes the packet dynamics and connection mechanisms? I guess since they are owned by eBay now, they are less likely to act like hackers, but still. Part of their value is that it just works, so I suspect they'll spend some time making sure it still works, regardless of the "defenses" that security vendors put in place. That may not be a battle that SurfControl (or any other network solution) can win.

So that leaves the endpoint, which is where I think it should be controlled. You can deploy application control technology as a subset of endpoint security to basically define a list of acceptable applications that can run on the desktop. Skype wouldn't be on it. Thus, the executable will not run on the desktop and Skype is not a problem anymore.

Does that seem too simple? Maybe it is, but there is no prize for finding the hardest, most technically elegant solution to anything. Do what works, and application control will work to control this (and any other) unwanted application.

As part of my daily analyst ritual, I am always scanning the wires, looking for interesting stuff and trying to get a feel for the impact to the user of what I find. Yesteday I came across a press release from a company called RedCannon Security, and their KeyPoint access control system. 

Basically, if you believe the marketing stuff (since I haven't tried it - I'll put that disclaimer on) KeyPoint gives you the ability to plug a USB thumb drive into any device and get your local desktop (through Citrix) with access to whatever corporate files you'd need to get to. You could then enforce whatever usage policies are in use on your internal networks. All of the cookies and cache is actually written to the USB drive, so there is no record or information left on the device.

Seems pretty cool, no?

The thing I struggle with is why do I need this? Sure, if I have a bunch of managers roaming around a shop floor and they need to quickly plug into a kiosk and get information, this could be useful. But if I'm a mobile professional, is this going to allow me to stop carrying around that friggin' laptop. My chiropractor wouldn't be happy with that, but I probably would.

I don't think this gets me there. I can do a bulk of my email when I'm travelling on my blackberry. Attachments are challenging and it's a pain to write anything more than a paragraph or two, but it's possible. But how long do I want to sit in a business center or Internet cafe on someone else's machine to catch up on stuff? I'm pretty sure those Internet access devices that plug into a hotel TV don't have a USB port or a Windows OS, so that won't work. I also need to work on a plane, so this doesn't really help me there either. 

So in concept, I like this idea. If folks in your company always have access to some type of desktop, this could be an interesting solution to make sure your corporate policies are enforced regardless of where your users connect from. But I'm having a hard time understanding the use cases where this is anything but a niche. Yet another example of technology looking for a problem to solve.

To be fair, I have not spoken to RedCannon, so maybe they can explain more legitimate use cases to me. So why am I going to hit submit anyway? Because the rest of you out there don't have either the time or desire to call up a company and figure out what they do. They need to be able to tell you quickly and succinctly. I hate it when I'm talking to a vendor and it takes them 45 mintues to tell me what they do. If it takes more than 5 minutes for me to understand your value proposition and how you do things (not necessarily the specifics, but the high level), then your messaging and positioning suck and you need to go back to the drawing board.

From time to time, I'll pick apart the public face of some company BEFORE I TALK TO THEM because that's what users do. The vendor may not like it, but too bad. Got to love the First Amendment. If they can't make their value proposition and use cases very clear from their external presence and collateral they aren't going to be around for too long anyway. I'm going to call these pieces "Drive-By."

I do promise to be fair, so if the vendor does want to clarify things for me, I'm happy to publish a follow-up telling everyone what I've learned. But be cautioned that this cuts both ways. If the story once I hear it is no better (or even worse), then I'm going to publish that as well.