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

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

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.

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…

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

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

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

Many people assume a certain level of confidentiality is assured when they use their phone. Concerns have been raised about the increased risk of someone eavesdropping on a VoIP call compared to a traditional PSTN call. Although the concern applies similarly to other VoIP protocols such as UNIStim, H.323, or SCCP as well, what follows is an opinion on the susceptibility of a SIP call to remote eavesdropping.

A quick web search will identify a list of tools which can be used to capture and replay a VoIP call. Examples include VOMIT, VoIPong, Oreka, Cain and Abel, and rtpbreak. Wireshark has this capability as well. However many demonstrations of eavesdropping use a known or fixed endpoint which reduces the complexity of the task. Which begs the question, how difficult would it be for an attacker to eavesdrop on an arbitrary SIP call?

The tools mentioned above all operate under the same basic principle:

1. capture the call traffic,
2. decode it, and
3. present the audio stream in a format that can be replayed.

As a result an attacker must gain sufficient access to capture the traffic at a point along the call route. Although somewhat obvious, this detail is often glossed over when you read about the risk of VoIP eavesdropping.

There are two channels to be considered when capturing VOIP calls: signaling and media. A “SIP” call is set up over a signaling channel using the Session Initiation Protocol (SIP). A media channel is then brought up where audio information including codec and sequencing is encapsulated and transmitted within the Real-time Transport Protocol (RTP). Depending on the topology of the environment there is no guarantee that both channels will be transmitted over the same route since signaling traffic usually involves call servers or media gateways and media traffic goes directly between endpoints. This is not important if you are trying to capture your own call, however to eavesdrop on a targeted conversation it is. As a result the best places to capture a call are at one of the endpoints or at a point through which both channels are likely to be transmitted.

If you set up a test environment and try some of the tools mentioned above you will find that even with access to the call traffic you may not capture conversations as expected. VOMIT only works for Cisco’s proprietary Skinny Client Control Protocol (SCCP). VoIPong identifies conversations based on the use of RTCP, as a result it may fail to capture some SIP calls. Rtpbreak only decodes the RTP traffic. To listen to a conversation you must mix together the correct streams. Since no signaling traffic is considered you lose the who is talking to who information.

In a real-world setting some additional factors would increase the complexity of eavesdropping on a VoIP conversation. These may include controls limiting access to the network traffic, security monitoring, network topology, encryption, system hardening, and physical security.

An individual with no technical skills would not find it easy to remotely eavesdrop on a VoIP call even with the proper tools. For an attacker with some technical knowledge it is not difficult to record and play back SIP calls under ideal circumstances. The traffic by its nature is easy to identify in a packet capture. Tools to decode unencrypted calls are easy to get and free to download. However, regardless of the attacker’s skill level, in order to be successful you must be able to capture packets somewhere on the signaling and media paths of the conversation you want to record.

An attacker can’t simply record a VoIP call from any remote location by downloading and installing a tool like the ones mentioned. They would first need to compromise a device which would give them access to capture a call that they were interested in. In an environment employing best practice security principles such as defense in depth this would require compromising more than one layer of defense. However due to common vulnerabilities such as missing or outdated patches, misconfiguration, and undetected software defects, it is likely that in many cases a determined sophisticated attacker would be capable of eavesdropping on unencrypted SIP calls.

An “insider” will have opportunity for access greater than that of a remote attacker. This must be considered when determining the acceptable level of risk for a VoIP deployment. Best practice controls include:

• port based network access control,
• VLANs,
• signalling encryption such as TLS for SIP, and where available,
• media encryption such as SRTP.

A proper Threat and Risk Assessment, which includes an network architecture analysis, will reveal the right controls for the job. In a future post we’ll look at some alternatives for controlling access to the media & signaling paths.

Stephan Varty
Vulnerability Analyst
Nortel

Over the past 10 years, SecureLogix has conducted many voice security assessments for enterprise customers. A proper voice security assessment will include two parts. First the TDM or VoIP trunks connecting one or more enterprise sites to the public network must be instrumented. All the voice traffic into and out of the site(s) is monitored and any security issues are identified. For customers with VoIP, a VoIP security vulnerability assessment/penetration test should be included. In this case the internal network is accessed and the IP PBX, network, and VoIP phones are tested for vulnerabilities.

Interestingly, while we always find vulnerabilities on VoIP systems, we have only seen one real world attack, and that attack involved good-old-fashioned toll fraud. However, we also find voice application security issues. These security issues are present whether the enterprise is using VoIP or not. Some of the issues we find include:

• Unauthorized modems used to access the Internet – most users know that if they access inappropriate sites on the Internet through the primary connection, that the access will be detected, logged, and possibly blocked. Some users bypass this security by connecting an analog phone line to a modem in their PC/laptop and dial their Internet Service Provider (ISP). While this isn’t a fast connection, it is fine to check personal mail, check stocks, look at sport sites, etc. We have seen as many as 100 simultaneous unauthorized modem connections at large sites. These connections are unmonitored and can allow the user to accidentally download malware or leak confidential information. Plus, the connection is also not protected by a network firewall and an attacker who finds the user’s IP address can hack in, attack the PC/laptop, and/or jump off onto other systems.
• Poorly secured authorized modems – many critical infrastructure systems, including PBXs and other equipment, use modems for remote access. These modems can be easily found by simple “war dialing” of numbers at an enterprise site. Many of these modems are poorly protected and once found, can be exploited. These attacks can be very serious, because the systems connected to the modems are often critical.
• Toll fraud – while VoIP has made some long distance calling a lot cheaper, some long distance, especially international calls, can be still be expensive. Toll fraud is still a serious issue for the enterprise. It can range from a few international calls made over fax lines to a hacked Direct Inward System Access (DISA) or VoIP interface, where the attacker sells numbers/access and can rack up $100,000s of charges in a short amount of time.
• Harassing calls – this includes a variety of irritating and even dangerous calls and call patterns, to include fax SPAM, harassing executives, bomb threats, and other attacks.
• Social engineering – includes calling into enterprises and call centers looking for inexperienced users who give out confidential information.

So while VoIP vulnerabilities get a lot of the hype, don’t forget about basic application voice security issues. They are virtually always present at enterprise sites, whether VoIP is used or not.

Mark Collier
Chief Technology Officer/Vice President Engineering
SecureLogix Corporation
13750 San Pedro
San Antonio, Texas 78232
www.securelogix.com
www.voipsecurityblog.com

]]> http://blogs.nortel.com/voicesecurity/2008/06/30/traditional-voice-security-threats/feed/ http://blogs.nortel.com/voicesecurity/2008/06/27/vulnerability-report-proper-process/ http://blogs.nortel.com/voicesecurity/2008/06/27/vulnerability-report-proper-process/#comments Fri, 27 Jun 2008 16:31:26 +0000 Lawrence Dobranski http://blogs.nortel.com/voicesecurity/?p=15 You may have seen that some Nortel products, as well as others, have recently been identified with a few voice system vulnerabilities. This is timely because one of next week’s Voice Security Blog postings will be about responsible disclosure for Voice Security….but let’s start the discussion about the proper process for vulnerability reporting now.

The reporting process followed by some commercial firms involved in this type of research is raising some concerns. Most firms involved with vulnerability reporting will agree that the accepted protocols for disclosure have been well established – and they have been worked out to the satisfaction of vulnerability researchers, manufactures, and users. However the debate over full disclosure versus non-disclosure versus responsible disclosure continues. In addition, concerns are being raised about the need to have independent 2nd party verification. Is claiming that a vulnerability exists without details actually sufficient?

To add to the debate some companies are being accused of disclosing vulnerabilities as a way to generate demand for their own products and services which are designed to identify vulnerabilities or mitigate their effects.

So what do you think?

Nortel customers that have seen the reports and are concerned are referred to the Nortel Security Advisory Task Force web site.

]]> http://blogs.nortel.com/voicesecurity/2008/06/27/vulnerability-report-proper-process/feed/