Nortel Voice Security

In the last post we looked at 3 of the most common techniques for disclosure of security vulnerabilities. Today, we will examine which is best suited for the Voice Security industry, as well what some other firms are doing. We will also touch on some additional important considerations regarding disclosure:

• Is there need to have independent 2nd party verification?
• What does claiming that a vulnerability exists without details accomplish?
• What is disclosure for gain?

Again, the terminology you will find within this post is meant to be consistent with terms used by the Organization for Internet Safety.

To answer the question of which disclosure method is best for Voice Security, we must look first at the sensitivities of such a system. What is the impact of a compromised voice system asset? Some may argue that VoIP is nothing but a data application, and it should be treated with the same security posture. Some of the differences lie in the assets, and a proper risk assessment will highlight this.

Immediate disclosure of vulnerabilities without any sort of mitigation from the vendor or otherwise (sometimes with functional sample exploit code) can result in serious consequences, ranging from theft of service, disclosure of personal information, economic harm, or even loss of life. Consider a denial of service attack on a voice system that coincides with a subscriber’s attempt to dial 9-1-1. We aren’t just talking about losing access to your e-mail for a few hours anymore. Disclosing the vulnerability with the sample exploit code prior to vendor mitigation simply invites the exploit, and could put lives at risk.

Non-disclosure may be equally harmful if those vulnerabilities are discovered by an attacker and exploited even though they were not published. Exactly the same dire consequences may result if the vendor and administrators don’t mitigate the risks because they did not see a need, based on the fact that the vulnerability was kept under wraps. The best way to make sure all affected systems have the appropriate controls in place is timely communication.

Some organizations have melded reasonable disclosure with a modified full disclosure approach. These hybrid processes are re-igniting the flames of debate over disclosure processes. In this approach the part of working with the vendor for responsible disclosure still exists, albeit loosely. It begins with formal (and sometimes informal) notification followed by the initiation of a count down timer by the Finder. When the timer expires, the vulnerability is publicly disclosed without example code or 2nd party confirmation. During the countdown time the vendor is expected to respond to the vulnerability with a suitable patch or work around.

This process is fraught with problems.

• It tells the hacker community that vulnerability exists, and where it exists, even though exact details are not made available. This focuses them, and will minimize their time to produce a working exploit.
• It is a sensationalist approach to security which is never a good mix. The vulnerability has yet to be confirmed by the vendor and may not even truly exist. It sets the industry abuzz and gets everyone spending time and money to look into it prior to having it substantiated. This alone warrants the need for 2nd party verification of the vulnerability.
• It does not take into account the threat, risk or the sensitivity of exploit. For instance, if a vulnerability exists on a box deployed in a private network behind a firewall, the threat needs to be determined, and consequently what is the risk?
• It does not verify if the vulnerabilities are all unique, or just multiple instances of a single fault.
• If the vendor cannot reproduce the vulnerability the clock continues to run. Without all the necessary details, it is slower for professionals to validate the vulnerability, and whether or not it is reproducible in the wild.

What does posting the existence of vulnerability like this accomplish? It levels the playing field between the mitigators and the attackers by slowing the efforts of those trying to correct it, and accelerating the efforts of those that would exploit it. In this industry, that is a significant advantage to the attacker.

Quite often this style of vulnerability disclosure is accompanied with a recommendation for a particular technology to mitigate the vulnerability. That sounds helpful enough and in fact is a good idea if done correctly. The mitigation techniques should always either come from, or be approved by the vendor – not the vulnerability Finder. If a researcher continuously finds vulnerabilities for the purpose of selling their own product or service, we have an undesirable situation known as disclosure for gain.

The best strategy, by far, for Voice Security is the cooperative model of reaching an amicable agreement between the Finder, the coordination center and the vendor. At Nortel, we fully support responsible disclosure and have processes and practices in place that ensure due diligence in all reported potential vulnerabilities. Nortel works with the Finder and, optionally, an appropriate coordination center to ensure that only the information required by the public to mitigate the vulnerability is released. With this as its mantra, Nortel ensures that its products and solutions are as secure as they can be while protecting its customers through a risk mitigation process. A mitigation process built on foundation of best practice:

1. Voice Systems should be deployed with a clear threat and risk assessment in place to help assess vulnerabilities. Without such an analysis, a vulnerability cannot be properly classified. The threat necessary to exploit the vulnerability cannot be determined, and no accurate picture of the resulting risk exists.
2. By following a “defense-in-depth” approach, we can ensure that best practices for deployment have been followed, and that no vulnerability compromises the system as a whole.

With these two thoughts in mind, we’ll close by saying there may be a time and place for non-disclosure, full disclosure, or some variation of them, but it’s certainly not appropriate for Voice Security. Responsible disclosure is the industry best practice, and it is one that Nortel stands behind. You can read about Nortel’s Security Advisory Task Force here.