Web & System Integration

3 Tips to Secure Your Voice Site Transactions

At Angel.com we take great care in ensuring that your voice applications run in a secure environment. It all starts with implementing human security, such as restricted personnel access and physical surveillance. We follow a long list of data center best practices.

When it comes to software and data security, we ensure that information is only exposed to essential programs, and that no data is saved on a permanent basis beyond what is strictly necessary for the system to operate.

But, hey, don't take my word for it. A large banking customer recently sent their security staff to perform an audit of our facilities, and here's what he had to say:

Angel.com obviously has taken deliberate steps to ensure the protection and integrity of their data and that of the companies they service. With that type of dedication, the list of Impressive Features is too long to include in its entirety.

This is the foundation on which you can build a secure phone application.

Should you secure your Voice Site?

Because transactional Voice Sites rely on the exchange of information over the public internet between a remote server (your server) and the Angel system, there are several potential risks:

That somebody could sniff the packets and extract the information that Angel submits to your system or that your system submits to Angel
That a rogue client would impersonate the Angel system and illegally request information from your system.

Most applications in the Angel network run very low risks of being affected by these factors. If the information you are exchanging is trivial or non personal, you may benefit from not incurring the added overhead of SSL.

On the other side, if the information transmitted is sensitive, it makes sense to invest in securing these transactions.

How to secure your Voice Site

Use session authentication
Design your transactions so that a session has to be established the first time. Have a username/password combination as parameters, then authenticate the client. This will make it harder for a malicious client to impersonate Angel.

Because Angel behaves like a web client, every call will identify itself as a unique transient web session on your web server. This will allow you to present an authentication challenge that only an Angel Voice Site will know.
Restrict the acceptable range of IP addresses
Our external access can come through 3 different networks, due to the masquerade on all our external connections.

208.238.98.0/24
208.244.116.0/24
208.226.118.0/24
208.206.234.0/24

This means that a request from Angel will only come from an IP address from 208.238.98.0, 208.238.98.1, …. , 208.238.98.255 and so on for each of the three ranges. Or in other words, all the possible addresses within a 24 bit mask.

You would need to open up the other three networks, though most of the time the connections will come through on the first network (208.238.98.0/24).
Filtering on the range of IP addresses will ensure that only Angel can make requests to the resources on your server.
Use HTTPS
You can use SSL to submit all requests to your server. For this to work you must obtain a SSL certificate from a reputed provider (Root Authority certificates work best).

The Angel system will then act as a HTTP client, and will establish a SSL session before transmitting HTTP requests or receiving HTTP responses.

Just like a web browser would read and examine the HTTP certificate that your web server would send in the HTTP response, Angel will read the certificate and authenticate it against the certificate chain.

Unlike a web browser, if there's a problem, Angel cannot interactively show the user a dialog box to "temporarily accept" the certificate, so some extra caution is helpful when ordering the certificate. Some common examples of certificate problems:

Name mismatch. You may have DNS entries that resolve to the same IP, and you may have acquired a certificate for one entry when you are invoking a different name from the Transaction Page. (E.g: Your cert is issued for "www.yourcompany.com" but you are calling "server22.yourcompany.com")
Certificate expired. Your certificate may have expired in the past, so though it is currently valid, it is not current.
Certificate not yet valid. You may have bought a certificate with a "production live date" in the future. Trying it today would cause the certificate authentication to fail.
Response contains both Secure and Insecure Data. If you use in your ANGELXML response, make sure that the externalAudio URL is also using HTTPS and comes from the same server.

Using HTTPS will encrypt all the information exchanged. This will ensure it remains private and make it much harder for hackers to sniff the traffic.

Conclusion

A few small precautions can go a long way towards extending the platform security of Angel.com into your application and server infrastructure. Hope these tips were useful!

As always, if you're working on an IVR project we'd love to talk to you! Give us a call at 888-692-6435 and say "Developer Hotline".

Sam Aparicio