Nortel Voice Security

Tom DeSot from Digital Defense joins us again….Lawrence

The Argument Begins

In my last post I talked primarily about how many organizations are looking to utilize vulnerability assessments to learn what issues are being introduced into their enterprise by newer IP based voice systems. Before I went any further in the discussion, I wanted to cover off on a topic many organizations neglect to consider before assessing their networks, whether voice or data. The topic is risk evaluation and system prioritization.

While I do not think any reader would dispute the need to conduct vulnerability assessments and subsequently patch any systems where issues are discovered, many would debate what systems take priority in the grand scheme of things. I have seen plenty of discussions regarding system priority turn into outright melees as each person jumps into the fray with their rationale for why a particular system or group of systems falls higher on the importance scale than something else. This is especially true when you mix voice and data folk. Who is right? Who is to say?

Do voice systems matter? You bet. But when you roll in domain controllers, mainframes, web application servers and ERP/ERM systems, your vision of a vulnerability assessment program can quickly go from clear to rather fuzzy and murky. With that being said, a well done risk assessment acts like a spotlight in the darkness and lights the way to the truth: which systems matter most.

Getting There from Here

In reviewing system priority, the biggest question tends to be how to decide where things fall. Couple this challenge with the fact that everyone wants their “baby” to be at the head of the line, and you have got a sizable problem that can, at first glance, appear to be rather insurmountable. Obviously dealing with the issue is not trivial. This is especially true if you are trying to make headway without really understanding the impact vulnerabilities are going to have if left sitting for hours, days, or even weeks.

If any reader feels they are facing this issue alone, I can assure you this is not the case. Typically when I give talks, this conversation invariably comes up. Usually the first question I get is “OK, fine, I will admit I am at an impasse, so what risk assessment methodology should I use to move forward?” Typically, but not always, I will tell them, “It does not matter.”

Before any methodology loyalists start screaming, let me assure you I do not leave it with that comment. To ensure the other party understands what I mean, I go on to explain that for all intents and purposes the popular risk assessment methodologies (OCTAVE, NIST, NSA-IAM, STAR) are all basically the same, just with some unique twists and quirks that make them look different. Regardless of the methodology, when they are all boiled down to their basic parts, each evaluates systems and/or data, and then based upon the CIA (Confidentiality, Integrity and Availability) values (no, not the agency) and/or other variables, come up with a relative risk score for the system or data in question. Based upon that relative risk score, the person conducting the risk assessment can make an educated call as to how to prioritize their systems, assess their networks, and where to start patching when the results come in.

The Common Topics

So back on topic, you still want to conduct vulnerability assessments and secure your voice networks, right? But where do they sit amidst all of the other systems screaming for the same attention? Let’s consider how evaluating confidentiality, integrity, and availability can provide insight.

Confidentiality

Discussing what happened over the weekend? While terribly interesting, the associated information is not all that confidential, unless it concerns Vegas of course. However, roll in some healthcare related information or financial transaction data and you have got a whole different story. As soon as you start discussing protected information, you have to take confidentiality into account; if not, you are leaving yourself open to an eventual violation.
And while some previous posts to the blog have outlined the challenges of intercepting the traffic, it is still something that needs to be considered so the evaluation, and subsequent risk rating, is on par with reality.

Sample Questions to Consider When Evaluating Confidentiality:

• If calls were somehow intercepted, recorded, and reviewed, would the organization be placed at risk?
• If the voicemail system was compromised, would confidential data be placed at risk? What would the impact of the breach be?
• If users utilize soft phones while working at home or on the road, are voice systems placed at risk?

Integrity

Would it matter to you of the data contained in the voice stream had been altered in some fashion during a conversation? What about calls stored on the voicemail server? In some organizations it would have little impact, however when dealing with sensitive or protected information, a loss of integrity could be a real concern.

Sample Questions to Consider When Evaluating Integrity:

• Do any of your business activities require that call integrity be maintained throughout the life of each call?
• What if the integrity of any call logs on the call management system came into question? Does that place the organization at risk in any fashion?
• What if the voicemail database became corrupted? How would this impact your operation?

Availability

When considering voice platforms, this is usually the topic that bumps them up to the front of the line. Even with so many users utilizing the Internet and e-mail to communicate with businesses, most still have the expectation of being able to pick up a phone and call a company. Lose that capability for a good period of time, and most people will begin to quickly wonder if the company is still a viable concern.

Sample Questions to Consider When Evaluating Availability:

• How would an extended period of downtime impact your business operation? How many customers would you stand to lose?
• How quickly would you be able to get parts for a down switch? What if they were not available?
• How often can the switch be taken down to patch for vulnerabilities? What if an un-patched issue left a system “wide open” to attack?

By evaluating these questions, and the many, many others that need to be considered regarding the voice platform and other networked systems, most individuals will be able to tell, with reasonable certainty, where each system falls in the vulnerability assessment hierarchy. Is it a long road to get to the answer? Yes, regrettably sometimes it is. However, it is a path that everyone needs to walk at some point to ensure systems, voice and otherwise, are prioritized appropriately.

In upcoming posts, I’ll talk more about how to take the findings from your assessment and start rolling that into a well defined vulnerability management process. See you soon.

Tom DeSot
Chief Compliance Officer
Digital Defense Inc