If you are developing applications for Avaya's Communications Manager (CM) platform, security measures are already in place, but you need to heed a few best practices to make sure your applications are as secure as your customers expect them to be.

Let's start with exploring some of the expectations your customers have, then examine some development guidelines you can follow to make your VoIP software as secure as possible.

Customer Expectations and CM Security
Customers often don't know how their applications are secure; they just want the guarantee that the correct security measures were taken during development and deployment. Their expectations are not much different with converged voice and data applications than they are with any other application. However, the technologies and protocols that provide secure development and deployment of VoIP applications are very different. And you need to know how to take advantage of them.

First and foremost, customers expect support for media and signaling communications encryption, if your applications handle them. If possible, all communications between network elements should be encrypted. Customers expect IP voice encryption to mitigate the threat of eavesdropping.

For classic H.323-based signaling, Avaya has implemented encrypted signaling based on the H.235.5 standard, which adds confidentiality to the authentication that has always been supported within H.323. Both H.323 and SIP have some standardized security mechanisms, but some of them are not enabled by default. For instance, the H.235.5 standard supports efficient encryption of sensitive signaling elements, and provides efficient signaling encryption without the need for provisioning certificates as part of a Public Key Infrastructure (PKI). Avaya's CM can encrypt signaling between Avaya devices, and it can also offer secure signaling between H.323 solutions from different vendors if those devices support H.235.5. The voice channel can be encrypted with the AES encryption algorithm today and support for IETF standardized Secure Real-Time Protocol (SRTP) will be released with Communications Manager 4.0.

In the SIP world, Avaya supports Transport Layer Security (TLS) for SIP signaling today and will support SRTP with SIP Enablement Services 4.0 and CM 4.0. In each place where integration with H.323, SIP signaling, or RTP media takes place in your application, support for the secure versions of each protocol will become increasingly important to your customers.

Next, customers expect secure protocols to be deployed for application and server administration, and they expect administrative access to critical server and network components to use encrypted protocols. Traditional server access methods like telnet, Hypertext Transfer Protocol (HTTP), and File Transfer Protocol (FTP) work for some environments, but they send password information in the clear. For truly secure administration across converged voice and data network applications, you need to provide Secure Shell Access (SSH), Secure Copy Protocol/Secure FTP (SCP/SFTP), and secure Web access via Secure Sockets Layer (SSL) with HTTPS in place of their insecure counterparts. If your company is using CM Media Servers, these secure protocols are supported.

Using SSH and SCP/SFTP, you encrypt an entire administrative session. SSH and SCP/SFTP provide terminal access and file copy mechanisms that protect the entire session, including the login sequence and all data transfer. The same holds true for Web access with SSL/HTTPS.

For other protocols your application might use, customers also expect support for Transport Layer Security (TLS) to protect the session. TLS uses the same protection mechanism used by HTTPS (Secure Sockets Layer or SSL) and has been used with protocols such as Session Initiation Protocol (SIP) to protect signaling traveling between SIP devices. However, keep in mind that it works on a hop-by-hop basis and does not ensure end-to-end encryption. TLS runs only over TCP and requires a digital certificate to exist between communicating devices and that it be authenticated. This means you will need to allow your customers to provision unique certificates into your product and manage a trust repository of root certificates that lets your customers control what devices and servers they want your server to trust.

Links such as media gateway control links, registration, admission, and status (RAS) links, call signaling links, media (voice or data) links, and administration access links, must be protected—from information loss to people who should not have access to it, from interference and disruption, or from theft of services. You can protect communications from these threats by encrypting the entire link, by encrypting critical data, and/or by secure challenge/response mechanisms. Encryption via the Advanced Encryption Standard (AES) algorithm and Secure Real-Time Protocol (SRTP) can protect voice streams. AES protects server and gateway signaling links by default. Administration links use SSH or TLS/HTTPS.

Best Practices
Even though Avaya's CM provides safeguards, it's up to you to make sure they are implemented properly. Here are some best practices, as defined by Avaya, that will help you write secure VoIP code.

First, remove all unnecessary services and operating system packages to mitigate exposure to vulnerabilities. All non-essential network services on the server should be disabled or removed. While this may seem like common sense, you might be surprised by how many services some operating systems enable by default. The CM Media Server, based on a customized distribution of Red Hat Linux, helps in this effort by turning off many unnecessary Linux services by default.

Secondly, use the vulnerability- and attack-testing resources available through the open source community or commercial software vendors as additional validation steps aimed at reducing the chances of known vulnerabilities being reintroduced. During development, Avaya systems are exposed to a variety of attack scanning tools, such as Nmap and Nessus, and the results can help you correct security problems prior to the product release.

Make sure network services (like telnet and ftp) that pass login and password information in the clear are disabled by default. If you sell an appliance that ships with an OS platform, be sure to prune the operating system installation to just those packages that your application needs. On CM, only 15 percent of the Red Hat Linux distribution is loaded; the operating system is configured specifically for Avaya's servers. Further, components that are used only in specific configurations are disabled when they are not in use. Make sure SSH, HTTPS, and other secure services are available and enabled by default.

Make sure your applications force the user to create a unique password (and account name) for any privileged logins installed by default—no default passwords should exist after installation. Even more importantly, make sure there is no direct login at root level if your system runs on Linux.

Secure APIs are important and highly advised. As we mentioned earlier, products that implement VoIP to other Avaya products should use secure signaling. Avaya's CM and SES servers make this best practice easy for you as a developer.

Avaya's Communication Manager makes developing secure applications for converged voice and data networks easier, but you, as a developer, are still responsible for making sure the safeguards are in place after your product is installed. CM's implementation of Linux makes security easier for you, but you still need to make sure you follow the best practices listed above.

Customers don't need to know every detail about what you do to make their applications secure, but they routinely learn the protocols, best practices, and buzzwords that tell them if your applications are secure enough for them. Rest assured that the average VoIP customer will soon look for SIP-TLS, SRTP, Secure Shell and Secure Copy Protocol/Secure FTP support in all the solutions they purchase. You also need to be sure you're educated in the capabilities of CM to deliver what your customers expect from their VoIP applications.