Security is a serious topic and, unfortunately, it is either overlooked, exposing organizations to risks, or incorrectly addressed through cumbersome solutions. In the series of blog articles I will try to shed light on what you should pay attention to, in terms of security, when choosing a UC solution.
Notwithstanding all the advantages of a UC solution, there is one important prejudice against its adoption: security concerns.
There is a widespread belief that VoIP solutions based on SIP are not secure, and that their usage must be blocked, or at least limited to local networks (eventually extended by VPNs).
Nothing could be further from reality. Well-developed and deployed VoIP solutions that are based on SIP and XMPP are actually more secure than traditional communications.
How did the prejudice start and spread?
Historically speaking, any new protocol is deployed without taking into consideration reasonable security concerns. Early adopters are relying on the fact that only a few are using it, and that nobody is going to take advantage of non-secure passwords. This happened for several technologies (HTTP / FTP / Terminal / Remote Desktop / Mail corporate services). All of these were deployed without enforcing the basics of security: secure passwords and protection from Denial-of-Service attacks. As a result, in many cases, knowing the names and surnames of employees (besides the organization’s domain) was enough to get access to their resources. This access was achieved by writing simple software that simulated login attempts using the most common passwords (such as 1234, 0000, 12345678, mypass, etc.).
The same issue arose with the appearance of e-commerce websites.
The solution is implementing tools that prevent users from setting overly simple (and therefore non-secure) passwords, and preventing attackers from using brute force password attacks. This can be done by blocking large numbers of authentication attempts (setting a maximum number of attempts) from an IP, or by using graylists. Further checks were added to prevent an excess of requests (from Denial-of-Service attacks) by blocking the connectivity reserved for the server. Finally, adding encryption and identity certificates allowed users to have a private transaction and know they were connecting to a legitimate service.
And yet, when SIP (and before it H.323) appeared, the old story repeated itself again. The systems were installed using the phone number as the login, and the password was a simple, predictable sequence (such as 1234, 0000, etc.).
With corporate services such as mail, HTTP, and confidential information at stake, in the case of SIP, the resources at risk are the phone lines of the company. So attackers dedicate their time to guessing valid logins and passwords. They then sold this information to exotic countries. Although a threat exists, it is clearly not as relevant as, say, getting insider information by using the mail credentials of an executive. In summation, the risks must not be underestimated, as a few days of international traffic through a few lines can easily cost a company a lot of money.
Is this a technology problem? No. It is a technology usage and awareness problem.
The problem was generated by the human belief that new, easily reachable services can be kept secret.
These days, nobody believes services like mail, web, or FTP to be insecure when properly deployed. Occasional attacks can take place, sometimes by using credentials left in public places.
SIP and XMPP (SIP and XMPP standards) services are also secure when properly deployed. The proof is VoIP providers with millions of accounts, and XMPP based services like Messenger or Whatsapp with billions of users.
Unfortunately, in the case of corporate servers based on SIP, many companies saw a business opportunity in spreading false beliefs about its security problems.
The fear that was created is used to implement non-secure VoIP solutions with no Internet access (meaning the solution is basically a legacy system without any advantages for the customer), selling dedicated VPN servers to connect remote endpoints, or using SBC (Session Border Controllers) to check the sessions in transit.
A word of caution, especially about systems which use VPNs to implement secure communications: a VPN, by itself, is only secure when well-implemented, when certificates are kept secret, and when the encryption algorithm is secure.
