If any of you are at Fall VON this week in Boston, both Martyn Davies and I (Dan York) will be there. Martyn is moderating a panel Wednesday in the Innovator’s Track and I will be speaking on Thursday about (surprise!) security on a “Strategies for Solving Security” panel. If any of you reading this will be there, feel free to drop a note and we can perhaps connect to say hello.
I’ve long been a staunch opponent of the “isolate your VoIP network from your data network” strategy. I personally believe that by putting up such restrictive barriers as would be required to provide any sense of actual security, the owners and administrators of a VoIP deployment are severely limiting the potential value they are able to receive from using Internet telephony. One of the Great Promises of VoIP is the ability to integrate communications with other productivity technologies such as work-group software and CRM applications. A lot of VoIP security practitioners tout the isolation strategy as a solution for the insecurity of the VoIP core devices and endpoints when in reality it is little more than a stop-gap, and not a very good one at that. By providing a false sense of security by way of network isolation, many VoIP deployment administrators may become complacent and pay less attention to the security posture of the actual VoIP devices and endpoints themselves. If you plan to integrate your communications system into the data-flow of your business in even the most minimal way, you’ll find quickly that most types of isolation that are available either provide a barrier to the desired functionality or open up so many holes in the barrier that it may as well not be there.
In a few hours I’ll be boarding a plane back to New York where I’ll be attending Interop New York this afternoon and tomorrow. If any of you reading this will be there, please do drop an email. Tomorrow, I’ll be on a panel at 2:45pm with Jonathan Rosenberg about “Voice-oriented Attacks”. (Side note to Interop: Please make it so that we can link to individual sessions instead of having to link to the entire list of “security”-related sessions!) If you aren’t aware of who Jonathan Rosenberg is, he works for Cisco and is a huge contributor to IETF efforts related to SIP and in fact was one of the co-authors of RFC 3261 which is the primary RFC defining SIP. He’s also the author of “The Hitchhiker’s Guide to SIP” which aims to help guide people through the maze of the many, many documents that now are part of “SIP”. More relevant to tomorrow’s session, he’s also the author of a series of NAT traversal protocols for SIP, namely STUN, TURN and now ICE. Eric Krapf, the moderator of the session, is aiming to make it a more interactive and discussion-focused session (i.e. no slideware-to-death)… we’ll see if we can make it fun as well. I’ve also asked Interop for permission to record it and run it as a Blue Box podcast – we’ll see if they give me permission.
Note that if you are a CISSP, the ISC2 is holding a member reception today (Wednesday October 24, 2007) starting at 5:30 PM in Jacob Javits Center Room 1EO2 – LEVEL 1. Assuming that everything works with my flights today, I’ll be there.
I’ll even have some new business cards to give out… 😉
P.S. I’ve now been public about who my new employer is.
Blue Box Podcast #69 is now available for download. In this 46-minute episode, Jonathan and I discuss the Linksys SPA-941 vulnerability mentioned in the VOIPSEC list, a potential SIP DDoS, a new release of SIPVicious, a suggested Asterisk security roadmap, other VoIP security news, listener comments and more.
As I mentioned previously, I was down at the AstriCon conference a few weeks back where I spoke about VoIP security in general and how it applies to Asterisk in particular. At the end of my presentation, I did put forward some suggestions for where the Asterisk community could potentially focus to improve the product’s security. While I intend to put the slides and hopefully the recording online at some point soon, I thought I’d share with you all what I laid out as my suggestions:
- TLS-encrypted SIP – Of course, this needs SIP over TCP first…
- Secure RTP (SRTP) – There’s a patch that’s been around for quite some time, but it needs to be integrated into the main release. However, it’s not much good without the next item…
- SRTP Key Exchange – First an implementation of ‘sdescriptions” (although again that needs TLS-encrypted SIP) and then later DTLS or potentially ZRTP.
- Figure out the phone configuration mess – So that the web servers on the phones can be disabled. Auto-configuration is a start, but how secure are the config files?
- Identity – If we are to not be drowning in SPIT, one mechanism that seems pretty sure to factor in would be a way to assert the real identity of the sender. Leading candidate today appears to be RFC 4474 (SIP Identity).
- Watch out for the APIs and the apps – Always fun when a rolodex app can crash your phone system!
- Toll fraud – What specific tools are in Asterisk to prevent toll fraud? Can they be enhanced?
- Testing with tools – There are a ton of VoIP security tools out there. Can Asterisk be tested with those tools?
That was my list that I spoke about at AstriCon. Do you agree? Disagree? What would your list include?