CHAPTER 34

SECURING VOIP

Christopher Dantos and John Mason

34.1 INTRODUCTION

34.2 REGULATORY COMPLIANCE AND RISK ANALYSIS

34.2.1 Key Federal Laws and Regulations

34.2.2 Other U.S. Federal Regulations and Laws

34.2.3 State Laws and Regulations

34.2.4 International Laws and Considerations

34.2.5 Liability

34.2.6 Risk Analysis

34.3 TECHNICAL ASPECTS OF VOIP SECURITY

34.3.1 Protocol Basics

34.3.2 VoIP Threats

34.4 PROTECTING THE INFRASTRUCTURE

34.4.1 Real-Time Antivirus Scanning

34.4.2 Application Layer Gateways and Firewalls

34.4.3 Logical Separation of Voice and Data

34.4.4 Quality of Service

34.4.5 Network Monitoring Tools

34.4.6 Device Authentication

34.4.7 User Authentication

34.4.8 Network Address Translation and NAT-Traversal

34.5 ENCRYPTION

34.5.1 Secure SIP

34.5.2 Secure Real-Time Protocol

34.5.3 Session Border Control

34.6 CONCLUDING REMARKS

34.7 FURTHER READING

34.8 NOTES

34.1 INTRODUCTION.

Whether it is referred to as Voice over Internet Protocol (VoIP) or Internet Protocol Telephony (IPT), the digitization of voice messaging has had and will continue to have an impact on society. Voice messaging is part of a shift that some are calling the Unified Messaging System (UMS).¹ The future does not include separate applications for instant messaging, text messaging, voice communications, video conferencing, e-mail, and network presence. These are expected to become one application that will be shared by both the home user and large corporations. New technologies promise to empower users as never before by freeing our communications from geographically stationary limits. For example, users can decide to work from home and have their office telephones ring into their laptops. Aside from convenience and capability, there are also great financial justifications for VoIP/UMS systems. They replace formerly expensive equipment with common microcomputers, resulting in substantial savings.

Just as there are security issues with our current operating systems and applications, the popularity of VoIP will draw the attention of criminals. Most disturbing of all is that many current exploits can be used with deadly effect against VoIP.

34.2 REGULATORY COMPLIANCE AND RISK ANALYSIS.

This section addresses the myriad of regulatory compliance and risk analysis issues that are inherent in VoIP implementations and usage. These issues are categorized into these major areas:

• Federal laws and regulations
• State laws and regulations
• International considerations
• Liability
• Risk analysis: the impact of Sarbanes-Oxley, Health Insurance Portability and Accountability Act, and privacy laws

Each of these areas provides an overview of the key relevant issues and strategies.

34.2.1 Key Federal Laws and Regulations.

The principal federal laws that apply to VoIP include:

• Sarbanes-Oxley Act of 2002 (SOX)²
• Health Insurance Portability and Accountability Act of 1996 (HIPAA)³
• Gramm-Leach-Bliley Act (GLBA)⁴

Among these laws, and the associated regulations from the Securities and Exchange Commission (SEC), Department of Health and Human Services (HHS), and the Federal Trade Commission (FTC), the principal common denominator is the standard for establishing and maintaining privacy for consumers, for businesses, and for corporate entities. The SEC established the Public Company Accounting Oversight Board (PCAOB) to provide rulemaking concerning SOX.

While HIPAA establishes and defines standards for the protection of patient and consumer information, SOX goes further, as it requires extensive periodic management testing to support management's attestation that the internal controls—including those surrounding privacy—are adequate and functioning effectively. Currently SOX is applicable to most publicly traded and for-profit entities. Although it does not apply to privately or publicly held nonprofits as of this time, many nonprofits have implemented it in advance of upcoming regulations. For example, the National Association of Insurance Commissioners (NAIC) in 2006 extended the application of SOX 404 over the insurance industry; this is to become effective in 2009.⁵ In anticipation of this, some health and property casualty insurance companies began implementing the regulation as early as 2004 since the multifaceted SOX review process can be time consuming to implement. Indeed, many organizations have found that SOX is not a one-time compliance effort; multiple calendar years can be required to fine-tune the internal control, monitoring, and assessment processes.

In terms of how this affects VoIP, the implementation process generally includes most, if not all, of these issues:

• Reviewing and enhancing the VoIP and IT-related policies and procedures
• Mapping and verifying major and significant process flows that impact VoIP, or where VoIP can affect significantly the financial condition of the organization
• Creating risk control matrices
• Creating and implementing test plans and matrices
• Testing VoIP controls, both logical and physical
• Reporting the test results, and determining the risk exposure level for exceptions noted
• Effecting the appropriate remediation, as needed
• Follow-up testing to ensure that the remediation was effective, and the proper controls are now in place
• Coordinating and liaising with the external audit firm that files a separate report on management's assessment
• Publicly reporting on management's assessment of the VoIP and other internal controls

Since VoIP affects key areas of an organization, such as systems, applications, privacy, networks, transmissions, and end users, appropriate controls here are part of a well-considered defense in depth strategy. Generally, a SOX review will cover most, if not all, of applicable items for a HIPAA or GLBA audit. It also covers many aspects of an ISO/IEC 27002:2005 audit;⁶ however, it should not be considered all-inclusive.

For more information on GLB and SOX, see Chapter 64 in this Handbook. For more information about HIPAA, see Chapter 71.

34.2.2 Other U.S. Federal Regulations and Laws

34.2.2.1 Enhanced 911.

Enhanced 911 (E911) mandates a location technology advanced by the Federal Communications Commission (FCC) that enables mobile or cellular phones to process 911 emergency calls and enable emergency services to locate the geographic position of the caller. According to the FCC's Web site:

The wireless E911 program is divided into two parts: Phase I and Phase II. Phase I requires carriers, upon valid request by a local Public Safety Answering Point (PSAP), to report the telephone number of a wireless 911 caller and the location of the antenna that received the call. Phase II requires wireless carriers to provide far more precise location information, within 50 to 300 meters in most cases.

The deployment of E911 requires the development of new technologies and upgrades to local 911 PSAPs as well as coordination among public safety agencies, wireless carriers, technology vendors, equipment manufacturers, and local wireline carriers.⁸

In a simple solution, a VoIP provider takes the stored location information, passes that through its own call center, and routes it to the local 911. In a more sophisticated solution, some gateways can map MAC addresses to locations, and the 911 calls then can be passed to a PSAP.

Currently, E911 is not required for companies that are using VoIP for internal purposes only. This law is empowered by the FCC, but the Department of Homeland Security (DHS) and the Federal Bureau of Investigation (FBI) appear to want it for surveillance and location tracking.

34.2.2.2 Communications Assistance for Law Enforcement Act.

Electronic surveillance consists of either the interception of call content (commonly referred to as wiretaps) or the interception of call-identifying information (commonly referred to as dialed-number extraction) through the use of pen registers and trap and trace devices.⁹

Although various earlier laws, such as the Omnibus Crime Control and Safe Streets Act (1968),¹⁰ Foreign Intelligence Surveillance Act (FISA; 1978),¹¹ and Electronic Communications Privacy Act (1986),¹² have provided for the judicial authorization process and the rules surrounding the interception and surveillance of wire, oral, and electronic communications, the purpose of the Communications Assistance for Law Enforcement Act (CALEA) is to preserve law enforcement's ability to conduct electronic surveillance in the face of rapid advances in telecommunications technology. To this end, CALEA

The standards for surveillance of VoIP networks have been a joint effort of industry and law enforcement for some time.

The Packet Technologies and Systems Committee (PTSC) has published the Law-fully Authorized Electronic Surveillance (LAES) for Voice over Packet Technologies in Wireline Telecommunications Networks, Version 2 (Revision of T1.678-2004), which is a surveillance standard for basic VoIP.¹⁴ The standard covers basic VoIP and supplementary services and was published in May 2006. The full document is available for a fee from the Alliance for Telecommunications Industry Solutions (ATIS), a U.S. standards organization.¹⁵

The PTSC published T1.IPNA (IP Network Access) in May 2006. This standard defines the requirements for broadband access.

The Telecommunications Industry Association (TIA) has published J-STD-025-B, which provides a surveillance standard for CDMA2000 broadband access. The Wireless Technology and Systems Committee (WTSC) has created T1.724, which provides a surveillance standard for GPRS/UMTS broadband access.¹⁶

The FCC's role in implementing CALEA by May 14, 2007, can be summarized in this way:

• Section 102. States that the FCC has the authority to establish findings that identify telecommunications services that are subject to the requirements of CALEA, which are not specifically detailed in the law.
• Section 103. Requires a telecommunications carrier to ensure that its equipment, facilities, or services that provide a customer or subscriber with the ability to originate, terminate, or direct communications are capable of meeting the assistance capability requirements.
• Section 105. Requires the FCC to establish systems security and integrity regulations for carriers to follow.
• Section 107. Requires the FCC to establish by rule the technical requirements for CALEA if a party petitions the commission believing that the industry standard is deficient.
• Section 109. Requires the FCC, upon petition from a telecommunications carrier, to make determinations of reasonable achievability regarding the assistance capability requirements of Section 103 with respect to any equipment, facility, or service installed or deployed after January 1, 1995. Under CALEA, the surveillance content's call identifying information typically includes the “dialing or signaling information that identifies the origin, direction, destination, or termination of each communication generated or received by a subscriber by means of any equipment, facility, or service of a telecommunications carrier.”¹⁷

A key part of the CALEA enforcement and debate is determining who is really responsible for compliance. According to the law, “all entities engaged in the transmission or switching of wire or electronic communications as a common carrier for hire.”¹⁸ However, a question arises when an organization builds its own VoIP solution; that is, does the organization then become a common carrier? It would seem so, according to CALEA:

However, the law specifically excludes “persons or entities insofar as they are engaged in providing information services.” Given this possible exclusion, an organization should seek advice from appropriate legal counsel prior to creating its own VoIP network.

34.2.3 State Laws and Regulations.

All states have laws concerning surveillance; 31 states specifically address computers and 14 refer to cell phones. Because a detailed discussion of this diverse environment is beyond the scope of this text, an organization should seek appropriate legal counsel not only concerning the state it is domiciled in, but also the states of any branches, divisions, subsidiaries, or affiliates. The National Conference of State Legislators provides links to the applicable laws of each state and a summary of the coverage (e.g., cell phones, computers, video, photos, etc.).²⁰

34.2.4 International Laws and Considerations.

Similar to the diversity in the United States, many countries have laws concerning surveillance and intercepts. As such, appropriate legal guidance and advice should be sought before installing or using VoIP networks in international locations. In particular, standards such as ISO/IEC 27002:2005 and privacy laws may be applicable, and may affect VoIP implementation and usage.

34.2.5 Liability.

Because both laws and standards apply to VoIP, violations may result in criminal penalties as well as civil penalties in the United States; this may vary by state and by the nature of the violation, since federal violations may take precedence over the state jurisdiction and prosecution. At the federal level, violations concerning surveillance often involve the Communications Act and 18 U.S.C. 2511 and 2520.²¹ These penalties can include:

• Injunctive relief and fines of more than $500 for each violation²²
• Statutory damages of whichever is the greater of $100 a day for each day of violation or $10,000²³
• Fines of $500 per day of violation²⁴
• Civil liability

Additional penalties can be incurred if the violations involve SOX, GLBA, or HIPAA. These can include:

• Fines of up to $250,000 (HIPAA, under certain circumstances)²⁵
• Imprisonment
• Adverse review or audit findings that possibly can affect an organization's SOX annual control assessment
• Stock delisting (SOX)
• Additional regulatory reviews (SOX)
• Additional SOX-related attestations (SOX)

34.2.6 Risk Analysis

34.2.6.1 SOX.

In estimating the impact of SOX, the primary measure is whether a weakness or deficiency in management's controls relative to VoIP could result in a material impact to the organization's financial statements. This need not result from a single failure of a single control, but can result from a single failure of multiple controls that may have a compounding effect on each other, or multiple failures of a single control. The control can be manual, automated, or a combination of both.

The materiality will vary by organization; if management is unsure of the materiality threshold (e.g., 5 percent of net income), then the external auditors who attest to management's assessment of its (management's) internal control over financial reporting usually can provide this information. Using this threshold, the “in-scope” systems and applications are identified, given their potential effect on the financial statements. If there is a disagreement between management and the external auditors as to whether a system or application is deemed in scope, then this difference of opinion should be resolved as quickly as possible, so that sufficient time and sample size are available for testing. If there is insufficient time or sample size available, then generally the testing will fail and could result in at least a significant deficiency, even though the tests performed were acceptable and encountered no errors.

Among the key tools that commonly are used in identifying and assessing the risk are a management-created risk control matrix and a segregation of duties (SoD) matrix. The former identifies and describes the key or primary controls that management relies on. The SoD matrix identifies which employee activities, roles, and functions are or are not acceptable; for example, a software developer may not be permitted to edit code on the production system at all, or, if permitted to do so, will require subsequent verification. Depending on the extent of implementation and the number of staff involved, the SoD matrix can impact any VoIP risk significantly, particularly in a small organization or area, since there may be challenges in restricting or segmenting access in the various job activities or roles. For example, an organization might have a single person who creates, reviews, and effects the changes in the VoIP-related systems and applications; the SoD matrix likely would prohibit this. Management's challenge then is to determine how much risk is acceptable in this type of situation and how to mitigate it to an acceptable level; methods might include detailed auditing, logging, and reviews.

Monitoring of the VoIP-related controls and deficiency status are effected within the overall SOX framework. For example, spreadsheets and simple databases can be used to record and monitor these key controls:

• Level of financial risk associated with the control or area
• Control objectives
• Control or business application owner(s)
• Related tests
• Testing status
• Test results
• Deficiency and remediation status and follow-up
• Compensating controls
• Executive-level “dashboard” for status
• Other related information

Often organizations will use third-party tools to assist them in this process. Doing so can help streamline and facilitate intraorganizational communications and ultimately help reduce the VoIP risk by helping ensure that all appropriate areas are addressed. However, it is beyond the scope of this text to provide a general SOX discussion or specific recommendations regarding these tools.

In determining the risk for VoIP-related systems and applications, there is a key difference among internal audits, external audits, and SOX reviews; in both internal and external audits, when errors are encountered, the test may still receive a “pass” because the errors are not material or significant enough to impede the normal operations or the reliability of the financial statements. In SOX testing, the results are interpreted in more of a black-or-white or yes-or-no manner. If there are any errors in VoIP testing, then the test fails, unless the testing allows for a very minimal number of errors, and provided that an expanded test sample does not identify any additional errors. Multiple minor control deficiencies may have a compounding or magnifying effect on each other, or on the reliability of minor controls used to detect if a major control is not working properly.

34.2.6.2 HIPAA.

The applicability of and risks related to HIPAA generally go much farther than might be presumed initially. It might appear that HIPAA applies solely to healthcare-related organizations, but any organization that offers and retains information on employee benefits must comply with the law. Generally, if an organization is considered SOX-applicable, then the appropriate privacy controls should be in place, or under review; this includes both the documentation and the periodic security testing that is to be performed. However, neither the IT control objectives nor SOX itself specifically mandate compliance with HIPAA.

Still, there is overlap between SOX and HIPAA regarding the VoIP security testing and documentation (e.g., periodic vulnerability assessments, information and document protection, and policies and procedures) that can help reduce some of the duplicated review areas. Some of this can be affected by measures utilized to reduce risk exposure concerning privacy laws (see the next section), particularly as they concern encryption and data protection. Therefore, in evaluating and measuring the risks addressed by HIPAA, a more integrated, holistic risk evaluation approach should be used.

34.2.6.3 Privacy Laws.

GLBA is among the best-known federal laws and California's Senate Bill 1386 (SB1386) is among the best-known state laws concerning privacy and protection of information. GLBA's reach specifically extends to financial institutions and to financially related information. It was enacted in early 2002 and became effective in July 2003. It is one of the best-known state-initiated privacy laws; many other states have subsequently followed California's lead with similar legislation. The common emphasis of these laws is on the unauthorized access to or disclosure of consumer-protected information; the type of information protected may vary slightly from state to state. Also, rather than apply only to events that occur within its borders, often these laws apply to and protect the state's residents, irrespective of the state in which the breach or unauthorized access occurred. For example, if a California resident's personal identifying information, as defined by the law, is breached because of business transacted in another state (perhaps while vacationing), the law applies.

Given this type of situation, appropriate VoIP security should be provided at all times, varying by state as required. Some states, such as California, provide a “safe harbor” if the protected information is encrypted within the system; however, no level of encryption strength is mandated, nor is transmission encryption required. Because other states with similar laws may vary in security requirements, the VoIP security that management is considering may need to reflect the laws and consumer information protection requirements of other states. Appropriate legal counsel may, therefore, be needed to provide advice and to help management assess the level of risk.

34.3 TECHNICAL ASPECTS OF VOIP SECURITY.

The next section is de-signed to provide a technical overview of VoIP and related security issues. It starts with an introduction to the protocols used and then progresses to associated threats. Following that is a discussion of best practices and then encryption.

34.3.1 Protocol Basics

34.3.1.1 Audio Stream Protocols: RTP and UDP.

Real-time Transport Protocol (RTP) is the packet-based communication protocol that provides the base for virtually all VoIP architectures. Part of RTP is timing and packet sequence information that can be used to reconstruct audio streams. Like TCP, User Datagram Protocol (UDP) is a layer 4 network communication protocol. Both of these protocols provide the basic packet addressing needed to get from one network address to another. When dealing with VoIP, packet delivery time is of the essence. Both TCP and UDP add overhead to the organization's network communication. This overhead results in greater time delays to the communication. UDP adds less overhead as it provides comparatively little packet error checking. The compromise is that UDP will help deliver packets quicker but will also result in more lost packets. It has been observed that a packet loss of 10 percent spread over a VoIP call may be virtually undetectable to most users. However, all of the features that can make VoIP secure also add latency. Added latency means more lost or discarded packets, which then results in an unpleasant or unacceptable user experience. In the end, a slow packet is a lost packet.

34.3.1.2 Signaling Protocols: SIP and H.323.

Session Initiation Protocol (SIP) is a protocol that is used to establish interactive multimedia sessions between users. In addition to VoIP, it is also used for video conferencing and online gaming. SIP appears to be the most commonly accepted form of establishing VoIP calls. Secure SIP (SSIP) is discussed in Section 34.5.1. Like SIP, H.323 can be used for video conferencing or VoIP call setup. While SIP appears to be the standard for new installations. One may find H.323 in use at enterprise scale installations that have large investments in older, analog communication equipment.

Briefly, the basics of a VoIP call include these details. A VoIP client application, whether on a personal computer or a dedicated handset, uses SIP or H.323 to set up the call. This call setup is an exchange of control parameters that may include encryption and compression algorithms to be used. This is called “signaling.” Once the call is set up, the VoIP client uses RTP to start packetizing the voice data. The RTP packets are incorporated into a UDP packet that adds addressing and sequencing information. The UDP packets are collected and sorted by sequence number at the receiving station. Some systems use a “jitter buffer” to assemble and store the packets. The endpoint VoIP client then reads the jitter buffer and turns the RTP packets back into voice.

34.3.2 VoIP Threats.

Although not an exhaustive list, these hacks represent some of the vulnerabilities likely to be encountered when using VoIP:

• SPIT
• Eavesdropping
• Theft of service
• Man-in-the-middle attacks

34.3.2.1 SPIT.

Most users have become accustomed to finding 10 or 20 (or 100 or 200) spam e-mail messages in an inbox on daily basis. The thought of receiving an equal number of voicemails on a daily basis leads to the unappetizing acronym SPam over Internet Telephony (SPIT). Even the most ambitious devotees of fear, uncertainty, and doubt (FUD) will admit that SPIT has yet to become a major issue. This is because there appears to be no current method of sending one voicemail to a number of telephones (i.e., SPIT messages must be sent one at a time, which is not an efficient use of resources). However, would-be SPIT spammers may have been both encouraged and then disheartened when, in 2004, Qovia,

The author explains that Qovia realized that broadcasting VoIP messages could be useful for agencies such as Homeland Security but could also be abused by spammers. Therefore, Qovia pledged to “incorporate its SPIT-blocking technology in future releases of its security products, while enforcement of its patent on broadcasting, if granted, could be used to shut down VoIP spammers.”

EXHIBIT 34.1 Packet Capture Showing RTP Packets

34.3.2.2.Eavesdropping.

In an unsecured VoIP environment, eavesdropping is reduced to a task that is quite straightforward. Earlier, it was mentioned that RTP is the de facto protocol for VoIP communication. RTP adds unique sequencing information to its packets. Because of this, one could collect a number of RTP packets and then assemble them in a consecutive order, as a receiving station would collect these packets in a jitter buffer.

Knowing this, the first step in eavesdropping is be to obtain a packet-sniffing tool such as Ethereal from www.ethereal.com. One may then use Ethereal to perform a packet capture, or one may obtain sample capture files from the Ethereal Web site. If the user chooses to perform packet capture, care must be exercised not to violate any privacy laws applicable to the user's network. Once obtained, Ethereal is used to sort out any RTP packets. Exhibit 34.1 depicts a packet capture filtered to show RTP packets. Notice that the first column at the left contains a list of sequential numbers. These numbers indicate the packet placement within the capture. However, farther to the right is the actual conversation sequence number. Once the RTP packets are assembled by sequence number, they can be saved as an “.au” file, which can be played on most computers. As shown with this example, eavesdropping on unencrypted VoIP traffic is not a complicated or expensive process.

34.3.2.3 Theft of Service.

One of the classic theft-of-service attacks that has occurred was reported in June 2006. In this case, a brute-force attack yielded special access codes allowing attackers entry into the provider network. Once in, the attackers obtained router passwords and login credentials; they then programmed the network transport devices to implicitly accept and route VoIP messages from the attackers' server. The attackers then sold VoIP access to public providers, who then sold it to the public. In the end, 15 exploited companies were left to pay the bill for the calls that were routed out of their network.²⁷

An organization's own employees could exploit its VoIP infrastructure as these attackers did.

34.3.2.4 Man-in-the-Middle Attacks.

As with any technology that digitizes communications, VoIP that sends data without encryption is inherently open to manipulation if an attacker can intercept traffic, alter its content, and send it on its way to the recipient in a classic man-in-the-middle (MITM) attack.²⁸ Once an attacker has control of VoIP traffic, the attacker can not only eavesdrop but can also:

• Initiate calls to a third party and impersonate a caller by sending data that appear to come from a legitimate phone belonging to someone else
• Deflect calls to the wrong destination
• Intercept traffic in real time and generate simulated voice content to create mis-leading impressions or cause operational errors

This last point warrants expansion. An eavesdropper could collect the digital patterns corresponding to words or phonemes generated by a particular user during normal conversation. Using simple programs, it would be possible to generate data streams corresponding to any spoken sequence including those words or phonemes in real time, allowing the MITM to feed the recipient (or even both sides of a conversation) with distorted or invented information and responses. The potential for mayhem is enormous, especially if the conversation involved, say, emergency response.

34.4 PROTECTING THE INFRASTRUCTURE.

This section focuses entirely on VoIP networks. For general information on infrastructure protection, see Chapters 22 and 23 in this Handbook.

34.4.1 Real-Time Antivirus Scanning.

Protecting the VoIP infrastructure would appear to be a routine decision. Remember that as with VoIP, a slow packet is a lost packet. Many of the routine measures used to protect a typical server will introduce latency into the voice system, leading to jitter and sporadic communication. One of the first routine measures to be sacrificed is real-time antivirus protection of the VoIP server. Some vendors will suggest that real-time scanning of the organization's entire VoIP server is next to impossible, and unsupportable. This is an unacceptable myth. The VoIP server must be scanned in a fashion that is at least consistent with other production servers. Requests from system administrators asking to disable real-time scanning is a common first step in creating issues with the VoIP system.

34.4.2 Application Layer Gateways and Firewalls.

An organization's VoIP infrastructure is much more than a series of systems that are digitizing voice and forwarding packets. Its servers will have real-time contact with e-mail servers and central authentication systems using Remote Authentication Dial-in User Service (RADIUS) or perhaps Active Directory. It may also have database systems devoted to logging call information or even recording the calls themselves. An attacker who gains access to part of the organization's VoIP infrastructure may be able to access the most sensitive parts of its network. Consider the use of application layer gateways (ALGs) or SIP/VoIP-aware firewalls to segregate the VoIP systems.

34.4.3 Logical Separation of Voice and Data.

It would be ideal to have a separate network for the organization's VoIP system. Bandwidth issues would be minimized and troubleshooting simplified. In most instances, it may not be possible to make a business case justifying the installation of a separate set of cables and network gear. The VoIP handset on the user's desk or the VoIP softphone in the user's PC will share the same wire as the workstation. The logical separation of voice and data begins with assigning the organization's VoIP devices to a network subnet separate from the data devices. This is initiated by a Dynamic Host Configuration Protocol (DHCP) request from the user's handset. Part of this request allows the DHCP servers to distribute addresses based on hardware identification parameters. For example, connecting a laptop to the organization's network will result in the assignment of an address that is on a subnet different from the Cisco handset that is plugged into the same connection. This logical separation of voice and data allows the organization's firewalls to protect its VoIP infrastructure by screening out protocols and requests that are not voice related.

34.4.4 Quality of Service.

The term “quality of service” (QOS) refers to a set of configurable parameters that can be used to control and/or prioritize communication through the network. Again, with respect to VoIP, a slow packet is a lost packet. QOS can be used to prioritize the VoIP packets so they can be delivered in a timely fashion. Most vendors will provide a choice of default QOS configurations to be used according to the organization's needs. Some even provide VoIP firewalls that are capable of buffering VoIP messages and retransmitting packets. Regarding QOS, it is not just one parameter that can be turned on to make the VoIP installation work properly; it is a series of parameters that may need to be tuned to fit the organization's exact needs. For more technical detail, see IEEE standards 802.1p and 802.1q.

34.4.5 Network Monitoring Tools.

Best practices require a dedicated security operation center (SOC) watching the organization's networks for attacks. Whether it is a 7 × 24 SOC or just one network administrator who does everything, it is absolutely critical to provide the tools and training necessary to detect attacks and to troubleshoot performance issues. With VoIP, the staff will be facing attacks using a new set of attack vectors and protocols. If the network administration is outsourced, review of existing service-level agreements to guarantee that the provider is capable of supporting VoIP is strongly recommended.

34.4.6 Device Authentication.

Device authentication can be accomplished in a variety of ways. The simplest is to store a list of device MAC addresses on the organization's VoIP server and to authenticate all SIP requests through that list of addresses. The standard is to deploy devices to desktops without configuration. Upon connection, a technician enters a setup utility that connects to the VoIP server and then downloads a preconfigured image.

34.4.7 User Authentication.

The organization's finance people likely will demand some type of call tracking and usage so departments can be charged or reviewed appropriately. Users can also be placed into different groups that the organization can configure. This group-level access can be used to limit services, such as long distance or international calling. It is common for a VoIP infrastructure to have ties to a central authentication server, such as Lightweight Directory Access Protocol (LDAP) or Active Directory. This central authentication will ease functions such as forwarding voicemail to a personal computer or cell phone. There are two common problems to watch for:

1. The authentication interval will be set by user. The organization can configure a demand for authentication to be hours, days, or months; 24 hours is suggested. Some users complain, and demand that their central credentials be stored in the handset for months so they only need to log in infrequently; this practice is generally undesirable.
2. Most handsets will come with default accounts and passwords. These accounts must be disabled or, at the least, strong password discipline must be maintained over them.

34.4.8 Network Address Translation and NAT-Traversal.

Network address translation (NAT) is a technique commonly used by firewalls and routers to allow multiple devices on an internal network to share one IP address on the Internet. A user's internal address should be known only to systems on that user's own network. When connecting to an external network, the organization's router or firewall forwards the user's communication to an external address but replaces the user's private address with its public address. When the communication is returned, the firewall routes the message back to the correct private address. Similarly, consider the broadband router in a home. The user may connect a series of systems to this device, each with a unique internal address distributed by the router, but the ISP sees it as only one address. These internal or private addresses are stored in what is commonly called a “translation table.” At a higher level, the process of getting a packet through a NAT device is called NAT-Traversal (NAT-T). Understanding how NAT-T issues affect VoIP is vital to understanding the danger of sending a voice call to the Internet.

Section 34.3.1.2 outlined how SIP is commonly used to set up a call. Once the call is set up, the actual audio stream typically is relayed via RTP/UDP. This is where the issues start. The firewall does not have a problem with passing SIP traffic back and forth to the Internet, as the internal address of the VoIP device is stored in the translation table. However, the SIP signaling has passed on the private address of the user's VoIP device. This means that a device outside of the local network is trying to send the RTP/UDP audio stream to a fictional IP address. Essentially, NAT prevents VoIP from functioning.

Several work-arounds are commonly used. Sometimes the NAT device can be configured to provide VoIP support. Sometimes VoIP devices can be configured to work over otherwise open ports, overloading a common protocol such as HTTP, unfortunately, often with unintended side effects. Or VoIP proxy servers can be used on either side of the NAT in order to facilitate the traversal. Each of these solutions opens up its own security concerns, which should be carefully addressed; these concerns include the consequences of external proxy servers or creating anomalous traffic over other protocols, as in the overloading example.

34.5 ENCRYPTION.

Encryption plays a critical role in communications security. For a general introduction to encryption, see Chapter 7 in this Handbook; for more details of public key encryption, see Chapter 37.

34.5.1 Secure SIP.

Transport Layer Security (TLS) was sponsored by the Internet Engineering Task Force (IETF) to secure and encrypt data communications crossing public networks. It is intended to replace Secure Sockets Layer (SSL) as a widely accepted form of securing data communication. This protocol consists of a “handshake” and a “record.” TLS was designed to be application independent so developers could choose their own way of initiating a TLS session.

Secure SIP is a mechanism designed to send SIP signaling messages over an encrypted TLS channel. A SSIP session is initiated by a SIP client contacting a SIP proxy and requesting a TLS session. The proxy returns a certificate that the SIP client then authenticates. The client and proxy then exchange encryption keys for the session. If the call is destined for another network segment, the SIP proxy will contact that segment and negotiate a sequential TLS session, so the SIP message is protected by TLS the entire time.

34.5.2 Secure Real-Time Protocol.

Secure Real-Time Protocol (SRTP) is an enhancement of RTP that provides encryption, authentication, and integrity to the VoIP audio stream. The Advanced Encryption Standard (AES) originally was a block cipher;

SRTP incorporates AES into the data stream with an implementation that utilizes it as a stream cipher.

Encryption is good but it does not protect the user or organization against replay attacks. SRTP uses a Hashed Message Authentication Code (HMAC-SHA1) algorithm to provide authentication and integrity checks. The MAC is calculated using a cryptographic hashing function in conjunction with a private key. SRTP uses one of the five Secure Hash Algorithms (SHA) designed by the National Security Agency. All five of these algorithms are compliant with requirements set in the Federal Information Processing Standards (FIPS).

34.5.3 Session Border Control.

To this point, a number of issues affecting a VoIP deployment have been identified. Session border control (SBC) is a set of services that address VoIP issues related to security, QOS, NAT traversal, and network interoperability. SBC collects real-time bandwidth statistics that can be used to allocate the network resources necessary to maintain the QOS desired. SBC will also support a number of NAT-T algorithms that will allow calls to be routed to public networks while maintaining the anonymity of internal resources. At the same time, SBC can accommodate both SIP and H.323. This allows the signaling protocol translation necessary to connect both types of networks.

34.6 CONCLUDING REMARKS.

VoIP provides expanded functionality and lower costs for corporate users, but managers must integrate security considerations into the architecture and implementation of all such systems to prevent interception, deception, and denial-of-service attacks. In addition, technologists must monitor developments in this rapidly changing field to keep abreast of new attack methodologies and countermeasures.

34.7 FURTHER READING

Boyter, B. “Voice-over-IP Sniffing Attack,” 2003, www.giac.org/certified_professionals/practicals/gcih/0442.php.

Davidson, J., J. Peters, and B. Gracely. Voice over IP Fundamentals. Indianapolis, IN: Cisco Press, 2000.

Endler, D., and M. Collier. Hacking Exposed—VoIP: Voice Over IP Security Secrets & Solutions. New York: McGraw-Hill Osborne Media, 2007. See also the associated Web site, www.hackingVoIP.com.

Kuhn, D. R., T. J. Walsh, and S. Fries. “Security Considerations for VoIP Systems.” NIST Special Publication 800-58, 2005, http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf.

Long, T. “Eavesdropping an IP Telephony Call.” GIAC Security Essentials Certification Practical Assignment, 2002, www.sans.org/reading_room/whitepapers/telephone/318.php.

Molitor, A. “Deploying a Dynamic Voice over IP Firewall with IP Telephony Applications,” 2000, http://cnscenter.future.co.kr/resource/rsc-center/vendor-wp/aravox/aravox_deploying_dynamic.pdf.

Molitor, A. “Securing VoIP Networks with Specific Techniques, Comprehensive Policies and VoIP-Capable Firewalls,” 2000, http://cnscenter.future.co.kr/resource/rsc-center/vendor-wp/aravox/aravox_specifictechniques.pdf.

Porter, T., B. Baskin, L. Chaffin, M. Cross, J. Kanclirz, A. Rosela, C. Shim, and A. Zmolek.Practical VoIP Security. Rockland, MA: Syngress, 2006.

Thalhammer, J. “Security in VoIP Telephony Systems.” Master's thesis, Institute for Applied Information Processing and Communications at the Graz University of Technology, Graz, Austria, 2002; www.iaik.tugraz.at/teaching/11_diplomarbeiten/archive/thalhammer.pdf.

Thermos, P., and A. Takanen. Securing VoIP Networks: Threats, Vulnerabilities, and Countermeasures. Boston, MA: Addison-Wesley, 2007.

VOIP Security Alliance White Papers:www.voipsa.org/Resources/whitepapers.php.

34.8 NOTES