|
|
|
|
|
|
|
|
|
|
|
|
The release in March of the WarVOX war dialing tool may attract attention to an area that might not have been receiving enough focus lately. At an abstract level War dialing involves scanning a series of phone numbers to see what responds. In essence that's not really very different from running a tool like nmap to scan a network for open ports. Reasons to run such a scan are not all that different either. It might be done as part of a security assessment, or by an attacker looking for a target. If you have deployed a VPN to reduce your dependence on modems for remote access, you might feel that your organization isn't exposed to much risk from war dialing. This highlights what is in my opinion one of the benefits of the ‘buzz' generated by WarVOX. It is an opportunity to generate awareness. War dialing is a threat to much more than just unsecured modems that might give access to corporate networks. If you haven't read this presentation found on the WarVOX site, you should, since it provides insight into some of the potential uses of war dialing tools beyond simply the identification of modems and fax machines.
After reading the recent news article "Fugitive hacker indicted for running VoIP scam" I re-read the following older article which includes additional details about the methods used: "Interview With A Convicted Hacker: Robert Moore Tells How He Broke Into Routers And Stole VoIP Services". The events in question were from some time ago (2006), however I believe that the methods used by the hackers in this article are still just as likely to succeed. In this post I'll discuss the vulnerabilities that were mentioned in the article and suggest some controls that would help to mitigate them.
Matt Trainor from Nortel's Security Governance & Compliance team joins us with a post about vulnerability disclosure. Back in June and July of '08, Lawrence Dobranski posted on this blog a two-part series titled "Security Vulnerability Disclosure - What is Right for Voice Systems? Part 1 and Part 2", which discussed the topic of Responsible Disclosure. This post provides more specific details of the Nortel process for ensuring Responsible Disclosure through the Nortel Security Advisory Task Force (SATF), and why such a program is necessary.
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.
Like many other professions, security has its demons. One of which is how do we ensure that the products that we use are trustworthy, or have “assurance.” An emerging method of validating the assurance that is present in a solution made up of many different products is the concept of In Situ Security Testing. This testing is periodically done on the running solution without interrupting the normal state of operation. This approach is ideally suited to the high availability, real-time environment of VoIP and Multimedia solutions, specifically solutions made up of many individual products and components. The National Institute of Standards and Technology (NIST) is overseeing the Information Security Automation Program and The Security Content Automation Protocol (SCAP). SCAP compliant tools with appropriate checklists allow for in situ security testing.
Read More >>
Comments (1)
Tags: security-testing,
nist,
nvd,
isalliance,
voip,
uncategorized,
scap,
vulnerabilities,
voip-security,
vulnerability-assessments,
voipsecurity
Jeff Lewis is back with a post on TDM Voice Systems -- Lawrence A colleague of mine, just tipped me off on a fantastic article written by Vassilis Prevelakis and Diomidis Spinellis over at the IEEE Spectrum Online. It is an absolutely enthralling read about a real life example of voice systems espionage, and I highly recommend it. Voice security is increasingly being associated with VoIP and Unified Communications. What is being called the “ Greek Watergate” shows us quite clearly that legacy TDM systems are just as much at risk, and always have been. But it also shows us that there are individuals that are capable of attacks at level of sophistication we may find surprising, alarming and downright frightening.
I am becoming very amazed at the number of people (Analysis: Hacking VoIP, As Easy As 1-2-3) that are equating the presence of vulnerabilities in voice systems to the voice system being compromised (AKA hacked). It is true that a vulnerability increases the possibility of a system being compromised but it does not equate to it. This is a very important distinction. Let’s look at what has to happen before a vulnerability can be successfully exploited. I am reminded of the consecutive steps in the Three-mile Island Accident of 1978 that all had to happen for the accident to occur – breaking any of the steps would have mitigated the accident. Despite diligent efforts to discover and eradicate IT vulnerabilities some may still exist – as system complexity grows so does the possibility of vulnerabilities being present. Even with a very mature software development process vulnerabilities will exist. How they get into systems is the subject of a future post.
The Nortel Voice Security Blog will regularly feature posts by members of Nortel’s Voice Security Ecosystem. Today Tom DeSot, the Chief Compliance Officer for Digital Defense, Inc., will be our featured blogger. Digital Defense is a network security firm based in San Antonio, Texas, that specializes in working with organizations to meet their compliance and security goals through the use of a multitude of Software as a Service (SaaS) delivered services. Why Vulnerability Assessments Matter… While the use of ongoing and recurring vulnerability assessments to uncover issues on data networks has been in place for quite some time now, these activities are still somewhat new, to some, in respect to their use within voice networks.
The Nortel Voice Security Blog will regularly feature posts by members of Nortel’s Voice Security Ecosystem. Today Mark Collier, the CTO and VP of Engineering of SecureLogix will be our featured contributor. Mark is well known in the Voice Security Industry, having co-authored with David Endler Hacking Exposed VoIP: Voice Over IP Security Secrets & Solutions (Hacking Exposed). He also writes about VoIP security on his own VoIP Security Blog. Over the past 10 years, SecureLogix has conducted many voice security assessments for enterprise customers. A proper voice security assessment will include two parts. First the TDM or VoIP trunks connecting one or more enterprise sites to the public network must be instrumented. All the voice traffic into and out of the site(s) is monitored and any security issues are identified. For customers with VoIP, a VoIP security vulnerability assessment/penetration test should be included. In this case the internal network is accessed and the IP PBX, network, and VoIP phones are tested for vulnerabilities.
You may have seen that some Nortel products, as well as others, have recently been identified with a few voice system vulnerabilities. This is timely because one of next week’s Voice Security Blog postings will be about responsible disclosure for Voice Security….but let's start the discussion about the proper process for vulnerability reporting now. The reporting process followed by some commercial firms involved in this type of research is raising some concerns. Most firms involved with vulnerability reporting will agree that the accepted protocols for disclosure have been well established – and they have been worked out to the satisfaction of vulnerability researchers, manufactures, and users. However the debate over full disclosure versus non-disclosure versus responsible disclosure continues. In addition, concerns are being raised about the need to have independent 2nd party verification. Is claiming that a vulnerability exists without details actually sufficient?
Recently a great deal of attention is being paid to vulnerabilities being found in various vendors VoIP systems. Some of the pundits are claiming that these represent major risks and that hackers will exploit them and run a muck with the systems. Are these fears justified or is it a bit of “The sky is falling” issue? For the average CISO, CITSO or CIO struggling to keep their systems patched and up to date this represents a very important question. How do you determine if these vulnerabilities represent real threats? And do they represent a threat that the other CxOs, board members, share holders and customers will care about? How do we answer these questions? The answer lies in a good risk management framework that links the business needs of the organization to security solutions and controls that are implemented in the network. Once an understanding is reached of what is really important to the organization (its “assets”), the questions of “what threats do these vulnerabilities represent?”, “what organizational assets do they expose”, “what risk do they introduce?”, “can the risk be mitigated?”, and “is fixing it worth the expense?” can be answered. Understanding the risk that they introduce allows the selection of appropriate safeguards and controls, and the urgency that a given risk needs to be addressed. The advantage of following this process is that the response is driven by the business need – not by a perception of what is important.
|
|
|
|
|
|
|
|
|