Disruptive Telephony

FYI, for those of you attending the Internet Telephony Conference & Expo in Los Angeles on September 10-12, I'll be participating in a panel session that is part of Ingate's SIP Trunking Seminar Series.  I expect it will surprise no one to learn that I'll be on the panel about "Enterprise Security and VoIP" wearing my VOIP Security Alliance hat.  My particular session is Tuesday, September 11, 2007, from 9:30-11:00 am.  (And yes, I guess it is appropriate in a way to be talking about security on 9/11!)   More details and the schedule are available online.

The sessions are free and open to anyone to attend.  Simply fill out the pre-registration form.

Just out yesterday, TMC.Net published an interview with me titled, "Security and Disaster Recovery for IP Telephony Systems", by Mae Kowalke, where I talk about general VoIP security issues and then get into specifics about Mitel solutions.  Given that the author nicely gave me the chance to review the text and offer feedback before she published it, I have to say I'm pleased with how it came out. :-)

(And yes, I normally blog about VoIP security over on the Voice of VOIPSA weblog, but I just field weird about posting something like this over on that site.)

FYI, on the week of July 29th - August 2nd, I'll be down in Hollywood, Florida, at the annual conference of the Association for Communications Technology Professionals in Higher Education (ACUTA).  I will be speaking on... surprise!... VoIP security!  There look to be a great number of interesting talks on the schedule, and so I'm looking forward to wearing my CTO Office hat (versus my pure "VoIP security" hat) and listening to and learning from what many of the folks involved with deploying leading-edge IP communications technologies in the education space are doing.   There will, of course, also be some security talks of interest.

If any of you reading this weblog will be down there at the ACUTA conference, please do feel free to drop me a note, as I definitely do enjoy meeting with others who connect through the social media space.

P.S. And yes, Florida in late July/early August is definitely not my idea of a fun place to be... good news is that we'll be indoors!

Since I've been writing about botnets (here and here), I just had to mention that the FBI announced yesterday some arrests of botherders as part of "Operation Bot Roast" (what a great name, eh?).  More coverage is available on ZDNet's Government blog and also the Washington Post's Security Fix blog.  It's interesting (but not surprising) to note that one of the three arrests is of Robert Soloway, the "spam king" currently in jail awaiting trial related to sending spam.  The botnet saga continues...

 Since Skype has an open client-side API, why not use it as a transport to tunnel VPN traffic and blow through firewalls to connect you to a remote system?  That's the idea raised by Peeter P. Mõtsküla in his Skype Developer Blog entry: "Idea: skypetunnel".    For instance, have a Skype client running on your home machine logged in as one account.  Have Skype on your laptop on another account.  Initiate a connection between the two of them and wind up with secure, encrypted access through the firewall from wherever you are.  Being peer-to-peer, there  would be no central servers or infrastructure required (outside the usual Skype p2p cloud.) This would require, of course, a yet-to-be-created "extra" that connected into the Skype client API and was installed on both systems... but that was the point of the article - to suggest that something like this could be done (and perhaps inspire someone to write one).

It's an interesting idea, although as one commenter noted, it has already been done in a p2p fashion by Hamachi.  I don't know how large Hamachi's p2p cloud (i.e. userbase) is compared to Skype and whether or not that even makes a difference, but the point is that if you are already a Skype user, this would be a way to make use of your existing tools without using another tool.

This whole concept, though, is part of the side of Skype that is admittedly a bit scary for those of us in security, and specifically corporate security.  The client-side API can be accessed by whatever extras a user installs.  All Skype traffic is encrypted, naturally, so a corporate IT security person has no way to know what is going across that connection. Whatever the user installs and allows to access the API gets to use that encrypted Skype connection. If a user installs this fictional VPN Skype extra, the user could then access their corporate desktop from wherever they are - without going through the "approved" VPN gateways... and at the mercy of the security of that fictional VPN "extra".  How well is that "extra" secured?  Could someone else using the extra connect to your corporate desktop PC and initiate a VPN?  What kind of authentication is part of it?

Yes, with Skype's business version, you can use Windows' registry settings to control access to the API, but this means that: a) the company would need to essentially "endorse" Skype usage by promoting the Skype for Business edition; and b) the company would need to somehow block all installations of the "regular" version of Skype.  I guess I don't see that happening - yet - in many corporations.  I expect they will probably continue to take the very black and white approach of attempting to block Skype entirely from their corporate LAN... or just ignoring the issue and letting Skype be installed if users do so.  This latter case is where the Skype client API gets a bit scary.

We'll see.  I agree with the article author that it's a rather logical extension of the Skype p2p cloud.... it will be interesting to see if someone does come up with a VPN "extra" for Skype.

With my post earlier this month about the possibility of SIP botnets, I've had a number of people asking about more information and wondering about the possible impacts.  And while I will write more on botnets in general, as far as the potential impact of "botnets" in general, one need only look over at the current situation in Estonia:

• Washington Post: "Cyber Assaults on Estonia Typify a New Battle Tactic"
• CNN: "Estonia suspects Kremlin in Web attacks"
• BBC: "Estonia hit by 'Moscow cyber war'"

Now, perhaps Russia is behind the attack... perhaps not. There are obviously much larger political issues going on between the two states.  In the end it doesn't really matter on one level who exactly is behind it... the net of it is that Estonian entities are being attacked in a massive Distributed DoS (DDoS) brought about in part by botnets. For anyone doubting the potential threat, you need only to read through those news articles to understand what can happen.

In fact, I found it interesting that the UK's Centre for the Protection of National Infrastructure (CPNI) issued an advisory today about the DDoS attacks against Estonia, mostly to reassure people in the UK that no attacks were currently being seen against UK businesses.  It also included two links to previous papers written by NISCC (one of the predecessors to the CPNI) about:

• Distributed DoS Attacks
• Botnets - the threat to Critical National Infrastructure

Both make for interesting reading and give some suggestions for how to prepare.

So what does this have to do with telephony?  Well, for starters I'll admit to knowing nothing of Tallinn, Estonia, before Skype entered the picture.  Skype is, of course, headquarted in Tallinn and through things like their Life at Skype blog have provided a view of Skype as a company, but also of Tallinn and Estonia.   Since then I have also learned of other companies coming out of Estonia... certainly seems like an interesting hi-tech place these days.  Now I don't know what, if any, disruption Skype has been seeing from these attacks.  The distributed p2p nature of Skype would argue for there not being much of an impact (except, obviously, to those right in Estonia), but I don't know.

On a larger level, though, it's just a powerful reminder that the botnet threat is very real out there.  And the question is... could your IP telephony infrastructure withstand a botnet attack?  Is your larger IT infrastructure up to withstanding some degree of an attack?  Do you have multiple VoIP gateways?  Could you route around points on your infrastructure that were being attacked?  Do you (gasp) have TDM trunks that could work as backups? 

I don't know if anyone in Estonia has had their IP telephony disrupted by botnets, but odds are if the attacks are as bad as being reported, some companies probably did.  What will you do to ensure your company's IP communication isn't disrupted should botnets come calling?

P.S. For another view on the larger conflict between Estonia and Russia, here's an article (and comments) I found interesting in John Robb's "Global Guerillas" blog: "Russia vs. Estonia: 21st Century State vs State Conflict".

In a few short hours, I will be catching a plane heading out to Fort Huachuca, Arizona, to swim in an alphabet soup of very different acronyms and jargon than my normal work - the "OSD-Sponsored, JITC-Hosted DOD Telecommunications Services Information Conference".  As noted on the page:

The purpose of the conference is to provide an open forum where DOD and vendor representatives can discuss issues related to interoperability of systems providing DOD Telecommunications Switched Services.

The conference will present the current program and discuss ongoing developments to the interoperability certification and information assurance procedures and test documentation. Other topics for discussion include emerging technologies, standards and their integration into the systems providing DOD Telecommunications Services.

I attended last year as well and it's definitely an interesting experience.  The US DoD is really doing some intriguing things with how they make use of VoIP / IP Telephony.  Obviously security is rather important.  They are also driving IPv6 adoption into their infrastructure and so, with the June 2008 mandate only a year away, it will be quite interesting to hear where they are with regard to IPv6 adoption.  Obviously, their huge size and buying power is of strong interest, so the number of vendors will no doubt be high.  Also, and I would think "obviously", I won't exactly be writing about things that I hear or learn there.

If any of you reading this happen to be out there at the conference, do drop me a note as I'm always interested in meeting readers or listeners.

Over on the Voice of VOIPSA weblog, I just posted "Ready or not... here come the IRC-controlled SIP/VoIP attack bots!" Given the sheer number of VoIP security tools out there, I think I and most others involved with VOIPSA figured it was only a matter of time before someone automated the attacks.  Did I hope that the creation of "bots" could have held off for a bit longer?  Definitely... but we have to play with the cards we are dealt.

I tried in the article not to hype the threat... that we are aware of, there are not massive botnets out there waiting to attack VoIP systems.  But there is now a proof-of-concept "bot" out there and those of us dealing with VoIP security have to look at how that could impact us.

And it's definitely a sign that we as an industry really have to get security locked down on SIP systems!

I posted Blue Box Podcast #56 tonight and with it Jonathan and I are beginning a series of mini-tutorials on subjects related to VoIP security.  In this show, we talked about voice encryption. In the next show (already recorded) we will talk about signaling encryption.  The idea is to cover some basic ground so that people not familiar with the area can have a basic understanding.

Just glad to get that one up - tomorrow I'm going to work on #57 to see if I can get it online for Wednesday.  We're trying hard to get back on a weekly schedule.  (#56 was intended to go up last week.)

I just realized that I never wrote here that an article I wrote recently came out online.  Published in Mitel's "Presence" magazine, it's titled "Using IP Communications as a Tool for Disaster Recovery and Business Continuity".  Okay, so the title's not overly catchy, but here's the first paragraph:

If a hurricane devastated your main office, how rapidly could you restore telephone connectivity? If a branch office had a fire or other disaster, how soon could you connect back into the main office? Or if Avian flu or some other pandemic created a situation where you needed to stay out of the office, could you access remote phone capabilities equal to that at the office? How long would it take your business to recover? How much (and how many customers) could you afford to lose in the process?

I go on to talk about why IP communications/IP telephony/VoIP fundamentally changes the traditional way you might address these issues and offers tremendous benefits.  In fact, to me, the ability to put an IP phone pretty much anywhere you can get an IP address remains one of the major - if not the single biggest - disruptive aspect of IP telephony/communications.  Remove geography as an issue and suddenly things like disaster recover and business continuity take on a whole different view.

While it's in a Mitel publication, there's nothing in the article that is really Mitel-specific.  Listeners to Blue Box or readers of Voice of VOIPSA probably won't find it terribly new since I've been talking about this before in those sites... but for those of you not familiar with DR and BCP and how VoIP can change that, I think you'll find it a useful read.