Nortel Voice Security

Brian Wilson, a Senior Security Architect with my team, specializes in the area of Risk Management and Compliance. With this post he begins a series of articles related to identifying and documenting a baseline security architecture for voice systems using a risk management approach. Lawrence

Part 1 – Establishing Security Requirements
The objective of this series of blog posts is to take the reader through the process of designing a baseline security architecture for voice solutions base on a generic Implementation. Part 1 of this series will focus on how and where security requirements fit in to the Risk Management process.

The process of risk management (RM) is continuous and is based on defining and establishing an acceptable level of risk. Once initiated, the process adapts to the following methodology:

1. Plan: Establish voice security requirements based on compliance to laws and regulations, threat and risk assessments and specific voice implementation issues.
2. Do: Select and implement security controls related to the voice implementation that meet these security requirements.
3. Check: continuously re-assess the threats and risks to the security architecture ensuring the implemented security controls maintain an acceptable level of risk.
4. Act: Take corrective and preventive actions, based on the results of changes, assessments and audits.

To start the process one must establish and document security requirements which in turn will be used to define a baseline security architecture.

Establishing a set of security requirements begins with identifying the environment in which the system will operate. For example, a hospital environment would require the security practitioner take in to account regulatory and legislative requirements such as the Health Insurance Portability and Accountability Act (HIPAA) in the U.S.A, the Personal Information Protection and Electronic Documents Act (PIPEDA) in Canada, and/or the European Union Data Protection Act in the EU, among various others. These regulatory requirements will then lead to specific mandatory security requirements. Using the example of the hospital, one might have a security requirement similar to: “The hospital shall implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

Once these “mandatory” security requirements are documented, there will be a need to identify more implementation specific security requirements. In these cases, security requirements can be based on assessing the risks associated with a particular voice implementation or derived from existing organizational policies, local laws, and special needs associated with the organization’s service offerings. An example of this would be an organization that has many public areas were internal staff phones may be exposed. There may be specific needs for positioning phones so that they are observable at all times. This could be expressed through requirements such as “IP phones must be positioned such that any unauthorized use can be easily detected.”

Once the security requirements are documented, security controls must be selected (Part 2 of this series) that map back to the requirements, and then appropriately applied to the architecture. After all of the appropriate controls have been selected and applied, the resulting configuration becomes the baseline security architecture of the platform.

Once placed into a production setting, this baseline is then monitored and adjusted to account for:

• an incident resulting in a compromise of the voice solution, which results in a loss of confidentiality, integrity, or availability of the information/data processed, stored, or transmitted by the system;
• an identified evolving threat which affects the voice solution’s operation, or its assets, based on security advisory information, security research, and/or other credible sources of security information;
• significant changes made to the configuration of the voice solution’s design through the removal or addition of new hardware, software, or firmware; changes are made in the operational environment which may potentially degrade the security posture of the implementation; or
• any other time when the security posture of the system is affected.

In part 2 of this series we will look at Selecting Controls. This will cover mapping controls to security requirements and ensuring the controls selected are aligned with international standards and industry best practices.

Brian Wilson, CD, CISSP, CISA
Senior Security Architect
Nortel

Jeff Lewis is back with an update on some VoIP Security Tools….Lawrence

Security professionals will be interested to know that their arsenal of Voice Security testing tools just got a little better. SecureLogix announced on Friday that they have expanded the tool set that was released with their Hacking Exposed: VoIP book. The original tool set has been available on their Hacking Exposed: VoIP website.

The tool set, now available with a free registered account, is available here.  All the original tools are still included, along with many enhancements, and several interesting new tools. You can find all the details over at their VoIP Security Blog. Some of the tools that were added include:

·         More DOS Attack tools – byeflood, optionsflood, regflood and subflood

·         A SIP address scanner – dirsniff, and dirsortmerge to help manage its output

·         Call Monitor & sipsniffer – for your eavesdropping and voice insertion needs

These tools should prove to be quite useful to Voice Security specialists, in their efforts to design and test secure voice solutions.

Jeff Lewis, CEH

Security Architect

Nortel

Jeff Lewis from my team joins us with an interesting post on the Woahphone. Lawrence

The idea of open source software running on a phone certainly is not new. Windows Mobile Smart Phones have had this capability since inception. Anyone can write software to run on them, the software development kit is free, and there is plenty of source code around to draw upon. But the operating system (OS) code itself remains closed source. So what would happen if you opened it up and let everyone see under the hood? Well, if Google Android, OpenMoko, Qtopia and other such Linux based projects are successful, we are going to find out. These projects, and others like them, promise varying degrees of openness in the operating system for mobile phones, which is in stark contrast to other systems like the iPhone, BlackBerry, and Windows Mobile based devices. The million dollar question I am wondering is - As far as Voice Security is concerned, is an open source operating system on a handset a good idea?

If history has anything to say about it, open source operating systems seem to be more secure than closed source ones. Maybe that is because undifferentiated access to the inner workings of an operating system makes it less of an attractive target for wrong doers. Or maybe it is because the number of eyes on the code helps to improve its security posture. Maybe it has nothing to do with the open source vs. closed source debate at all, and what really makes a target out of an OS is the way a company conducts its business. As such, the question remains, “Will Google’s Android be as popular a target as the Windows family is, or will it be on par with other open source operating systems?” The jury is still out. However, looking at the open source nature of a mobile phone OS is not the entire picture. There is something else that can change the security landscape significantly.

Google is positioning Android to herald in a new age of connectivity in handsets. Wired Magazine has a interesting article surrounding what Android is trying to accomplish, and one thing that stands out is the idea that “Coders were told that their applications would have constant access to the Net”. (Page 4). So this is interesting on at least two fronts – a mobile phone with a totally open source operating system and a constant connection to the Internet. Is that even a phone anymore? Seems to me that’s more of a mobile computer with voice capabilities, or a “woahphone” - a Wireless Opensource Always on Handset. To be clear, Android is not actually a phone – it is the OS. Any device running it would then be the woahphone. Although I found no specific evidence of OpenMoko and Qtopia being positioned as woahphones, there is certainly no reason they could not be since they already satisfy the open source requirement.

The security implications of a woahphone like Android are quite interesting. If anyone can study and alter the OS, the SDK is freely available, and the internet connection is always on, are we about to see a new generation of “woahware” such as mobile viruses, botnets, trojans, worms, malware, adware, scanners, sniffers, spoofers and who knows what else? That is just on the data side. What about toll fraud, eavesdropping, vishing, SPIT and the rest of the usual voice security concerns? Are we about to witness a new wing of the security industry open for business, or are we about to see the most secure mobile platform that has ever existed? The answer will partly lie in their (Google’s) security strategies, and partly in their success. Android’s security model actually looks a lot like Bitfrost from the OLPC Foundation. Both are based on a sound “least privilege” model, and that is a very good thing.

Looking at Google’s past success in the search engine space, it is easy to imagine that they will be similarly successful with Android and thereby reach critical mass with its deployment. This same critical mass and success also stands to make Android a lucrative target for attackers. In short, the more successful a product is, the bigger a target it is. According to Gartner – the number of PCs in use right now has just surpassed 1 billion globally, and we all know what the security situation is like there. By comparison, the number of mobile phones has nearly tripled that at 2.6 billion and the number of smart phones sold in 2008 alone is approaching 200 million – one fifth the total number of PCs in use. Clearly, it will not take long at these rates for smartphones, and possibly even woahphones, to outnumber PCs. Given these statistics, and that more and more people are using their phones to bank, invest, shop and conduct other such financial transactions, where might attackers focus their efforts? Looking at the law of averages, the picture becomes pretty clear.

In preparation, Google seems to be doing the right things. They have set up a vulnerability disclosure process, which is based on a responsible disclosure philosophy. They have also published some details on their security model, and started a forum for discussion, although it appears to have gotten off to somewhat of a slow start. At the time of writing this blog post, none of the questions posted there had been responded to, including my own.

To be fair, they have not officially launched Android yet, so I would expect the discussion groups to become a little more lively as we approach release day. I am more than a little disappointed they have not published any whitepapers or architectures on how the security model works, or at least if they have, they are not on their website at the time this post was written. Security professionals need time to look into the security behind the launch of these devices so they may better prepare their infrastructure, perform threat and risk assessments, and implement changes if required. If a vulnerability is discovered in the OS, what will the mechanism of patch deployment be? Can it impact the voice infrastructure? Traditionally, if a mobile phone had a vulnerability – it stayed there. Carriers are usually quite reluctant to release updates for their client’s handsets. Will Android change this through its always connected paradigm? Will it even be up to the carrier anymore? We’ll have to wait and see.

Moving forward, I will continue to watch this fascinating endeavor as it evolves, and dig a little deeper into the Android security model and its potential implications (if any) on Voice Security. The concepts of woahphones and woahware may be new, but malware is not. Given the level of openness of these operating systems, and the “always connected“ paradigm, there will certainly be interesting times ahead. I prefer to be prepared.

Jeff Lewis, CEH
Security Architect
Nortel

Tom DeSot from Digital Defense joins us again….Lawrence

The Argument Begins

In my last post I talked primarily about how many organizations are looking to utilize vulnerability assessments to learn what issues are being introduced into their enterprise by newer IP based voice systems. Before I went any further in the discussion, I wanted to cover off on a topic many organizations neglect to consider before assessing their networks, whether voice or data. The topic is risk evaluation and system prioritization.

While I do not think any reader would dispute the need to conduct vulnerability assessments and subsequently patch any systems where issues are discovered, many would debate what systems take priority in the grand scheme of things. I have seen plenty of discussions regarding system priority turn into outright melees as each person jumps into the fray with their rationale for why a particular system or group of systems falls higher on the importance scale than something else. This is especially true when you mix voice and data folk. Who is right? Who is to say?

Do voice systems matter? You bet. But when you roll in domain controllers, mainframes, web application servers and ERP/ERM systems, your vision of a vulnerability assessment program can quickly go from clear to rather fuzzy and murky. With that being said, a well done risk assessment acts like a spotlight in the darkness and lights the way to the truth: which systems matter most.

Getting There from Here

In reviewing system priority, the biggest question tends to be how to decide where things fall. Couple this challenge with the fact that everyone wants their “baby” to be at the head of the line, and you have got a sizable problem that can, at first glance, appear to be rather insurmountable. Obviously dealing with the issue is not trivial. This is especially true if you are trying to make headway without really understanding the impact vulnerabilities are going to have if left sitting for hours, days, or even weeks.

If any reader feels they are facing this issue alone, I can assure you this is not the case. Typically when I give talks, this conversation invariably comes up. Usually the first question I get is “OK, fine, I will admit I am at an impasse, so what risk assessment methodology should I use to move forward?” Typically, but not always, I will tell them, “It does not matter.”

Before any methodology loyalists start screaming, let me assure you I do not leave it with that comment. To ensure the other party understands what I mean, I go on to explain that for all intents and purposes the popular risk assessment methodologies (OCTAVE, NIST, NSA-IAM, STAR) are all basically the same, just with some unique twists and quirks that make them look different. Regardless of the methodology, when they are all boiled down to their basic parts, each evaluates systems and/or data, and then based upon the CIA (Confidentiality, Integrity and Availability) values (no, not the agency) and/or other variables, come up with a relative risk score for the system or data in question. Based upon that relative risk score, the person conducting the risk assessment can make an educated call as to how to prioritize their systems, assess their networks, and where to start patching when the results come in.

The Common Topics

So back on topic, you still want to conduct vulnerability assessments and secure your voice networks, right? But where do they sit amidst all of the other systems screaming for the same attention? Let’s consider how evaluating confidentiality, integrity, and availability can provide insight.

Confidentiality

Discussing what happened over the weekend? While terribly interesting, the associated information is not all that confidential, unless it concerns Vegas of course. However, roll in some healthcare related information or financial transaction data and you have got a whole different story. As soon as you start discussing protected information, you have to take confidentiality into account; if not, you are leaving yourself open to an eventual violation.
And while some previous posts to the blog have outlined the challenges of intercepting the traffic, it is still something that needs to be considered so the evaluation, and subsequent risk rating, is on par with reality.

Sample Questions to Consider When Evaluating Confidentiality:

• If calls were somehow intercepted, recorded, and reviewed, would the organization be placed at risk?
• If the voicemail system was compromised, would confidential data be placed at risk? What would the impact of the breach be?
• If users utilize soft phones while working at home or on the road, are voice systems placed at risk?

Integrity

Would it matter to you of the data contained in the voice stream had been altered in some fashion during a conversation? What about calls stored on the voicemail server? In some organizations it would have little impact, however when dealing with sensitive or protected information, a loss of integrity could be a real concern.

Sample Questions to Consider When Evaluating Integrity:

• Do any of your business activities require that call integrity be maintained throughout the life of each call?
• What if the integrity of any call logs on the call management system came into question? Does that place the organization at risk in any fashion?
• What if the voicemail database became corrupted? How would this impact your operation?

Availability

When considering voice platforms, this is usually the topic that bumps them up to the front of the line. Even with so many users utilizing the Internet and e-mail to communicate with businesses, most still have the expectation of being able to pick up a phone and call a company. Lose that capability for a good period of time, and most people will begin to quickly wonder if the company is still a viable concern.

Sample Questions to Consider When Evaluating Availability:

• How would an extended period of downtime impact your business operation? How many customers would you stand to lose?
• How quickly would you be able to get parts for a down switch? What if they were not available?
• How often can the switch be taken down to patch for vulnerabilities? What if an un-patched issue left a system “wide open” to attack?

By evaluating these questions, and the many, many others that need to be considered regarding the voice platform and other networked systems, most individuals will be able to tell, with reasonable certainty, where each system falls in the vulnerability assessment hierarchy. Is it a long road to get to the answer? Yes, regrettably sometimes it is. However, it is a path that everyone needs to walk at some point to ensure systems, voice and otherwise, are prioritized appropriately.

In upcoming posts, I’ll talk more about how to take the findings from your assessment and start rolling that into a well defined vulnerability management process. See you soon.

Tom DeSot
Chief Compliance Officer
Digital Defense Inc

Like many other professions, security has its demons. One of which is how do we ensure that the products that we use are trustworthy, or have “assurance.” An emerging method of validating the assurance that is present in a solution made up of many different products is the concept of In Situ Security Testing. This testing is periodically done on the running solution without interrupting the normal state of operation. This approach is ideally suited to the high availability, real-time environment of VoIP and Multimedia solutions, specifically solutions made up of many individual products and components.

The National Institute of Standards and Technology (NIST) is overseeing the Information Security Automation Program and The Security Content Automation Protocol (SCAP). SCAP compliant tools with appropriate checklists allow for in situ security testing.

The Internet Security Alliance (ISAlliance) working with the Department of Homeland Security and NIST has been designated to lead an industry based program to develop SCAP checklists for VoIP, Real Time Converged Networks, Multimedia, Unified Communications , and VoIP based converged data and voice solutions.

At the upcoming 4th annual IT Security Automation Conference (Sept 23rd and 24th, 2008) the applicability of SCAP to these VoIP based systems and solutions will be explored. On Tuesday, September 23rd the ISAlliance will present a panel to discuss the applicability of security automation in VoIP, Multimedia, and Unified Communications environments, including VoIP based converged data and voice solutions.

In particular the value of performing in situ security testing will be covered, and how it can be applied to bring a level of security assurance to a high availability, high reliability network. This discussion should also set the stage for broader participation in the ISA sponsored workshop.

The workshop will be held on Thursday, September 25 and will focus on developing broad answers to the following four questions:

1. How can SCAP based testing be productively used to create a level of assurance in high availability/high reliability networks and what might some limitations to that approach be?
2. What SCAP protocols/approaches/components are best for voice and real time networks?
3. Is there a baseline of best practice/standards to base the development of SCAP checklists to achieve a level of assurance in voice and real time networks?
4. What are the next steps?

Details on the ISAlliance Project are here.

I will be participating in both the panel and the workshop, as well as reporting on the event here on the Nortel Voice Security Blog. In future posts we will explore the technology of In Situ Security testing and the use of SCAP in more detail.

Lawrence

Disclosure: Nortel is a founding member of the Internet Security Alliance, and a member of its Board of Directors.

Jeff Lewis is back with a post on TDM Voice Systems — Lawrence

A colleague of mine, just tipped me off on a fantastic article written by Vassilis Prevelakis and Diomidis Spinellis over at the IEEE Spectrum Online. It is an absolutely enthralling read about a real life example of voice systems espionage, and I highly recommend it.

Voice security is increasingly being associated with VoIP and Unified Communications. What is being called the “Greek Watergate” shows us quite clearly that legacy TDM systems are just as much at risk, and always have been. But it also shows us that there are individuals that are capable of attacks at level of sophistication we may find surprising, alarming and downright frightening.

Let’s review some of the facts from the incident, which occurred around the 2004 summer Olympics in Athens:

• Malicious software was implanted in 4 TDM voice core switches in a Greek Telecom’s network.
• This software activated the Lawful Intercept (LI) feature on the switch for the attacker’s benefit. This is a fully legal feature, usually required by law so that telephone conversations of any kind can be lawfully eavesdropped upon. It is activated on specific DNs only, when those DNs are of interest to law enforcement officials. It works by ‘duplicating’ the 2-way speech path between the targeted parties, and redirecting it to a law enforcement center for monitoring and recording.
• The switches had the LI feature installed, but it was not licensed and therefore was not actively executing. This is a very normal telecom practice, and allows for tiered levels of service. It also served to further obfuscate the attack.
• The cell phone calls were actually encrypted for the final mile to the handsets, but not within the voice core.
• The software was installed without detection using the software patching system on the switch, and subsequently hidden from it.
• The perpetrators frequently re-configured the numbers being monitored without detection.
• The software bypassed both the logging system and the user interface.
• What tipped them off to the intrusion was a bug caused by the rogue software, introduced after the attackers upgraded it. The new code interfered with the systems ability to forward text messages – and that generated logs.
• The perpetrator(s) are not yet apprehended. Hindering the investigation is the mis-handling of some critical log files that were erased over an upgrade – and contrary to policy – no backups were created. Additionally, the software was removed almost immediately upon detection, instead of being monitored for activity, and tracing back to the attackers.
• The telecom operator was held liable for a €76 million fine ($113 million US) for illegally wiretapping 106 cell phones and impeding the investigation, as well as an additional €19 million fine ($28 million US) for violating privacy regulations.

Was this intrusion preventable? Of course. There was a single point of entry that afforded the attackers access to the voice core switches – once they had access, they obviously had the technical prowess to do whatever they pleased. They clearly had the capability to write compatible software for the system, including interfacing with the APIs for several of its key software functions in a format that was deployable by the vendor’s own patching system. It remains speculation whether they came in through the network, or had physical access to the equipment. It is also being debated over whether or not this was an inside job or not.

How could such an intrusion be prevented in the future? What else can we learn? The answers are surprisingly simple, and we have heard them all before:

1. Physical Security. Tightly control all access to critical equipment, and ensure that only trusted individuals have access rights. Enforcement, monitoring, and logging of all individuals coming and going is key here. Policy does not make reality unless it is enforced. Even the most sophisticated attacks start with access. Cut them off there, and they have nothing.
2. Network Security. A full analysis and audit of every conceivable way into the equipment is required – and on a regular basis. Doing it once is only the beginning. Penetration testing, vulnerability assessments are just some of the tools available to help with this. If you must have access ports open to the network – they had better be monitored, traced, logged, and protected with strong AAA-like techniques.
3. Intrusion detection and response. Legacy voice core TDM switches are large, proprietary platforms, that vary immensely from vendor to vendor. Detection of an intrusion in one system may be dramatically different in another. As a result, an IDS may be a set of policies, activities, or specialized h/w and software tailored to that specific vendor, product class, and release version. At the very least, an in-situ verification system is warranted that looks for anything out of the ordinary, such as additional processes, files, system logs, logins, network activity, software CRC checks, memory profile and CPU usage. Above all, be diligent. Work with your vendor to identify what you should be doing to detect intrusions and have a planned response so that any security incident is handled in a systematic way thus limiting any damage to evidence.
4. Perform a Threat and Risk Assessment. Know what’s important, and what actions to take. That includes defining an Intrusion Handling Policy. How you deal with an attack will greatly influence the consequences. You could be fined, or face even more serious legal repercussions. Check your policies before you hit the delete key.

I think its worth noting that “end to end” encryption of the speech path would effectively stop this kind of eavesdropping, but it would also break the Lawful Intercept feature, and add some very serious complications to the way legacy TDM calls are routed. In fact, this is one of those situations where encryption cannot and should not be utilized to secure the entire voice path. Having said that, encrypting the final mile is still an excellent security control.

I’ll re-iterate again the level of sophistication behind this attack. The attackers were both highly motivated and very capable of executing this attack and it is a strong possibility that this intrusion was an inside job, although that is speculation and has not been proven. It’s a hard learned lesson about what can go wrong if you fail to define and follow your own security and operational policies. It’s also a demonstration that the right attackers with the right skills can wreak utter havoc if you fail to adequately control and monitor access to your systems. The “Greek Watergate” incident proves that voice security threats are very real, even in tried, tested and true legacy TDM systems. The important thing to remember is that these networks are still very much defensible.

Jeff Lewis
Security Architect
Nortel

Jeff Lewis on my team joins us again with an interesting comparison…Lawrence

I often read in the blogosphere about how Voice over IP is so much less secure than traditional TDM based technologies. There certainly seems to be enough compelling reasons for such thinking, but I frequently wonder how much truth there really is to it. Is it really that dangerous? Is it really that different from the old way of doing things? Keeping the scope to the telephone lines and sets themselves, I think the answer is probably yes – but it certainly doesn’t have to be.

I recently joined a tech trial at the office to help test out a new VoIP call server. Installation was easy enough – I just plugged the phone into my ethernet jack and I was making calls in seconds. The problem was, I was making calls as if I was someone else! As it turns out, I was given a phone to use for the trial that had previously been assigned to another employee. I could have made calls to just about anyone as if I were that person. Fortunately I’m an ethical guy and swatting/vishing isn’t my thing. OK, that’s fine, it’s a tech trial right? These sorts of things happen, but it got me thinking.

Physical security aside, even if this phone had been deployed with my own identity assigned to the caller ID, what’s to stop a would be thief from taking the phone off my desk, plugging it in at another quiet location and making calls to whom ever they wanted? If that same thief grabbed my TDM phone off my desk and plugged it in elsewhere, my identity would not follow it. Well that’s a pretty big difference right? Perhaps the jack they plugged the stolen TDM phone into is their own, with their own CLID, or perhaps the line card for that jack is offline altogether. In this case, there is an inherent extra level of physical and network security in TDM because the caller’s identity is tied to the line card, not the terminal. More often than not, VoIP reverses this relationship and places the identity in the terminal.

How likely is it that someone is going to steal my phone off my desk, and make impersonated telephone calls at the office? I’d say the odds are against it, so I’m not losing sleep over this. After all, anyone can make calls from my TDM set at my desk when I’m not here and I would notice if my IP set went missing.

The situation is a little more interesting if you consider how this problem scales. What about a massive enterprise roll out of thousands of VoIP lines. Companies that large always have churn and turnaround in the employee ranks. It would only be a matter of time before a phone previously used by one employee ended up in the hands of another without having been reprogrammed. What then? I just hope they are honest. It may be some time before the administrators figure out the mistake.

Now, granted, not all VoIP systems behave in this manner. Your identity does not have to be tied permanently to the phone. One would hope that your redeployment process would include a reset of the phone’s memory, and then re-configuration. But all it takes is one phone to slip through by mistake with the old data. Instead, a simple tweak to make the user log in each time they boot up the phone would solve the problem rather nicely. Most people are used to signing into their PCs everyday, but not their phones – so this might seem a little strange at first. Having had my IP phone for a few weeks now, its never rebooted. I’d say the bigger problem would be remembering the user id and password if it ever did.

Another way to level the playing field between these technologies is through 802.1x authentication. By only specifically allowing certain devices on certain ports, you very much achieve a similar level of security that TDM phones inherently had. Now if the thief grabs my phone and tries to plug it in at his desk, he might have limited network access – but he certainly won’t be making any calls. However, this strategy only works if the policy was deployed everywhere on the network. All they would need to do to circumvent the restriction is find a port that doesn’t require 802.1x authentication and they are back in business.

Yet another method to even the score between TDM and VoIP would be to VLAN all your VoIP traffic. In the past, we all expected a phone jack and a computer jack to be separate. Why change that? If the thief grabs your IP phone and plugs it into a regular data jack elsewhere, they get nothing. This of course assumes you do not leave ports on your VoIP VLAN enabled when they are not in use. If you did that – it’s all for naught.

I will agree this is all a bit of a crooked case study. If you have thieves willing to steal phones from within the office, you probably have much bigger concerns, like what they might be doing to the integrity of your entire network. But it does serve as a very good example of some key differences between the inherent security in a TDM based system, and the newer VoIP systems.

A proper defense in depth strategy that deploys all of the above controls would go a long way towards leveling the playing field between the two technologies. If you compare apples to apples within the context of this example, a default VoIP installation without any security controls in place is probably less secure than that of a TDM system. However, if you’ve performed a proper threat and risk assessment, you may be better off spending your security dollars elsewhere if you deem the risk of insider abuse is minimal. Of course this argument does not take into account remote access, multiple branch locations and the like, but that’s a topic for another day…

I am becoming very amazed at the number of people (Analysis: Hacking VoIP, As Easy As 1-2-3) that are equating the presence of vulnerabilities in voice systems to the voice system being compromised (AKA hacked). It is true that a vulnerability increases the possibility of a system being compromised but it does not equate to it. This is a very important distinction.

Let’s look at what has to happen before a vulnerability can be successfully exploited. I am reminded of the consecutive steps in the Three-mile Island Accident of 1978 that all had to happen for the accident to occur – breaking any of the steps would have mitigated the accident. Despite diligent efforts to discover and eradicate IT vulnerabilities some may still exist – as system complexity grows so does the possibility of vulnerabilities being present. Even with a very mature software development process vulnerabilities will exist. How they get into systems is the subject of a future post.

So we now have a vulnerability in our voice system. What needs to happen for it to be exploitable – so that the system can be successfully compromised? A suitable threat vector must exist. A threat vector is a path or a tool that a malicious agent uses to attack the system and exploit the vulnerability. As was discussed on this blog by a recent post by Stephan Varty of Nortel, just because a vulnerability and threat vector are present does not mean a viable method of compromising the system exists. So a vulnerability by itself does not result in a compromised system – it provides a target if a viable threat vector exists. If the threat vector succeeds we then can have a compromised system.

So how do we mitigate this vulnerability/threat vector pair? We can either eliminate the vulnerability or remove the threat vector. This is why we assign a probability to the success of the threat vector – we determine the risk. Once we know the risk we can select appropriate controls and risk mitigation strategies. This is why it is important for vulnerabilities to be appropriately reviewed, a determination made on the corresponding risk of compromise, and an appropriate measured response made.

Best practice is very important in the deployment of voice systems, whether VoIP or TDM. It is even more important as we merge data and voice in Unified Communications (UC) systems. Best practice security is not new to UC or VoIP – we all should remember the stories of companies that did not change their PBX configurations so that “phone phreakers” that where able to be authenticated to the system for voice mail could easily get an outside line and make toll calls. A vulnerability, not really; a miss configured feature yes; a threat vector yes; the solution – proper installation, configuration and best practice.

Let’s look at the example discussed in the article: Analysis: Hacking VoIP, As Easy As 1-2-3. Without having a detailed architectural diagram of the system compromise I can only comment in generalities. It is stated that they attacked the target system outside the firewall. Hmm…how was the firewall treating VoIP? Were pinholes punched through it – allowing all traffic on a specific port, with a specific protocol to transition the firewall without inspection? Or was an application level gateway for VoIP running, an application gateway understands the specific protocols allowed through and ensures that the protocol requests are appropriate, coming from specific end-points? The example further states that a laptop was used to monitor the exchange between the call server and the soft client. Why is this exchange not encrypted? SSL for signaling and SRTP for VoIP is one approach, an SSL or IPSec VPN is another. To successfully exploit the vulnerability as explained two threat vectors had to exist. Both vectors could have been mitigated by the use of standard VoIP best practice installations; coupling these with additional best practices in the VoIP deployment (ex. Session Border Controller) would have further lowered the risk; and ensuring the vulnerabilities are patched in a timely manner would have completed the mitigation. Just like in the Three Mile Island Accident example it is not one vulnerability that results in the compromise, but a vulnerability and bad risk management decisions.

In a series of upcoming posts we will discuss current best practices for voice system deployments including UC solutions – and how with an appropriate risk management approach you can put controls in place to mitigate many potential vulnerabilities and threat vectors. In the mean time remember that media buzz surrounding voice system vulnerabilities may sound worrisome, but it you have a proper risk management system in place with appropriate controls and best practices you can respond in an appropriate manner. Vulnerability identification is important, managing the risk is critical.

Lawrence

Today’s guest post is by Eric Winsborrow, the Chief Marketing Officer of Sipera Systems. Eric has more than 20 years experience in both security and unified communications. He has a broad depth of VoIP and Security experience having senior positions for companies such as McAfee as VP of Product Marketing, Symantec, Sygate, Nortel, Lucent and Cisco. Lawrence

Enterprises are increasingly deploying real-time, unified communications such as VoIP, IM, video and others to increase productivity, reduce costs and improve collaboration. Enterprises can fully experience unified communications when IP PBXs and real-time communications applications are extended beyond the enterprise to soft phones on PCs, hard phones at remote sites, and WiFi/dual-mode phones.

It is critical for enterprises to understand the security risks to VoIP and Data assets associated with extending any VoIP infrastructure. Potential vulnerabilities number in the tens of thousands and may allow remote attackers to carry out spoofing and denial-of-service attacks, unwanted reboots, uninitiated toll calls, and allow hackers to take over the device and either steal or delete data. But are these attacks actually happening or is it all theoretical? Let’s look at some numbers. The following data from the Sipera VIPER Lab shows just how tangible SIP vulnerabilities are:

Without a doubt, VoIP exploits are real but as of yet they do not happen nearly at the volume or public awareness as data exploits do. However, it would be very risky to ignore the trend that we are seeing around VoIP attacks, which will grow over the next few years. As the number of VoIP users and the adoption of open protocols like SIP grows, and as new entrants like Microsoft OCS takes hold, hackers will start taking notice.

Even today, the media is reporting real attacks on real networks with real damage (these articles are tracked in the following link). And, if the media is reporting these attacks you can be assured that many more are happening which go unreported, since enterprises would not want to share this information publicly. Some customers did not even know their system outage or performance degradation was due to an intrusion.

A webinar entitled VoIP Attacks are Real, was recently hosted on TMCnet which discussed a VoIP threat taxonomy as well as recent vulnerability research around VoIP Hopper and VoIP-to-data exploits. Specific exploit types were discussed in detail. You can view a recorded version of the webinar and learn more about these unique threats that target the enterprise UC networks.

Eric Winsborrow
CMO
Sipera Systems

Today’s post is from Jeff Lewis. Jeff is a Security Architect on my team, and has more than 10 years experience in voice communications technology, including technical support of global voice networks, product verification, software integration, and most predominantly, carrier grade voice application software development. He was involved in some of the very first ground breaking voice over IP calls performed in Nortel’s laboratories in Germany. Lawrence

The discussion over the usefulness and applicability of taking a Risk Management (RM) based approach to voice security is an interesting one to say the least. Welcome to the front line.

Let’s begin by considering why a company might decide that RM is the wrong way to go. Perhaps the process is seen as too lengthy and too slow to allow rapid reaction to new threats. There may be a perception that there is no business need to support a risk management process, or that it only exists after a vulnerability has successfully been exploited. Or maybe there’s some discomfort over what an ‘acceptable’ level of risk actually is. It is possible, that a lack of understanding of what risk management does for you, could lead to the idea that individual vulnerabilities cannot be addressed in real time, and that you would be unable to evolve your security strategy along with the threats. All of these perceptions are understandable, and should be addressed.

One of the key components of performing a risk management analysis on your voice security system is to identify your assets, and evaluate them. What are you trying to protect? What are the most critical things you stand to lose if you are attacked? This doesn’t require a committee, a trained individual with the right experience, acting in a consulting fashion with the right knowledge holders, can collect, evaluate and document what assets are critical and what impacts are associated with their compromise. Once you know where your soft spots are, you are even more prepared to act quickly when one of them is compromised. As new threats arise, you can quickly assess their impacts instead of having to investigate them from scratch since all the heavy lifting has already been done. You can better allocate your budget to protecting that which matters most, instead of blindly plugging all the holes that pop up in places that are less sensitive to your business needs. It is about taking a balanced approach and spending your money intelligently. Yes, there is some overhead in performing a risk analysis, but once it is established, it is an enabler and an accelerator, not a roadblock.

The inability to see a business need for security until after you’ve lost money as a result of an attack, is the hallmark of an absent risk management process. A sound risk management analysis and strategy will reveal where your mission critical assets are, and what you stand to lose if they are compromised. In short, it reveals business drivers that you were not previously aware of.

What is an acceptable level of risk? This question may cause some uneasiness, but the answer isn’t as difficult as you may think. Think of it more in the terms of “what can I afford to lose?”. Once you’ve done a risk analysis, you know your assets. You know what matters. It’s actually very easy to decide how much risk you can tolerate in your critical and non-critical systems. An even larger advantage is that your risk assessment is customized for you. It’s a bad business plan to implement a voice security architecture designed for a bank, if you are running a university. Each organization has a unique set of assets, with their own ‘acceptable’ level of risk. How can you adequately implement security, in a an efficient and cost effective manner, if you do not employ a risk management based approach to voice security? The fact of the matter is, you cannot. Enforcing a security architecture or set of controls on an organization that was not born from a risk based approach may in fact leave you exposed while depleting your budget.

The risk assessment approach to voice security or even unified communications isn’t a one stop bus ride. It is a continuous process that evolves with you as you evolve your network. In fact, it makes evolving your network even easier. Because you’ve done the assessment, you’ll be that much more aware of how changes to your architecture will affect the security of your key assets. What’s even better is that you’ll be aware of them before you implement them. Re-engineering an entire network to plug an architectural security flaw is a mistake you cannot afford to make.

This voice security blog is about risk management as much as it is about voice security. They are not the separate things they appear to be. It is about driving home the need to understand your assets, sensitivities, threats, and risk levels before you leap into a costly business venture. Equally, it is also about the technology, controls and architectures behind voice security. In future posts you will see these very things discussed, but with the understanding that a sound risk management philosophy is at the heart of everything we do here.

Jeff Lewis
Security Architect
Nortel