|
|
|
|
|
|
|
|
|
|
|
|
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.
Hasler Hayes from Nortel's Security Governance & Compliance team joins us with a post which approaches Voice Security from a different perspective: In this blog post we will discuss Voice Security from the viewpoint of its role in life line healthcare. This post was inspired by my 83 year old mother's adventures with VoIP. Retired people are often very concerned in reducing the cost of their daily expenses, especially since they typically have a very limited pension income to live on. They seek every opportunity to reduce the cost of their basic necessities so they are able to support themselves better. This led my mother to replace her traditional voice service with a newer, cheaper, voice service (VoIP but she never knew that). As her son, one unexpected benefit that I saw was the self image boost she got by being in tune with the technology world, besides saving money.
In a previous post (In Situ Security Testing for VoIP) Lawrence made reference to the Security Content Automation Protocol (SCAP). What follows is some additional information about SCAP. SCAP is a method for using specific standards to enable automated vulnerability management, measurement, and policy compliance evaluation. It was developed and is maintained under the Information Security Automation Program (ISAP) lead by the National Institute of Standards and Technology (NIST), the Office of Secretary of Defense (OSD), the Department of Homeland Security (DHS), the National Security Agency (NSA), and the Defense Information Systems Agency (DISA). The goal of ISAP is to enable automation and standardization of technical security operations.
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.
Another post from Jeff Lewis with some thoughts on Voice Security In December, I had the opportunity to speak at a Secure Trunks seminar hosted locally here in Ottawa. During the Q&A, some interesting questions about voice security in general were raised. Today, I will address them here in the interest of sharing the answers with everyone who may be curious about them, and perhaps to initiate a discussion on them. Q: How real are voice security threats? A: I think this is a fascinating question to answer. One of the reasons it is so interesting, is because the industry is on the cusp of moving over from traditional TDM technology to IP based voice systems. It is a fairly significant and fundamental change to the way we will communicate. It is useful to draw a parallel to the personal computer security industry, during the early days of their adoption. They too were a fundamentally different way of communicating. Computer viruses were something we had ‘heard' about, but how real a problem were they? Without widespread deployment of malware detection and mitigation tools, the scope of the problem was largely unknown. We knew it existed, but couldn't set an accurate boundary to the size of it. Fast forward to where we are today. According to Symantec, there were 500,000 new threats introduced in the second half of 2007 alone. Now that so many PCs connected to the internet have some form of malware detection capabilities, we have a much better picture of the scope of the problem.
I found the article One Hacker's Audacious Plan to Rule the Black Market in Stolen Credit Cards in Wired to be an interesting read. I think this article provides some insight into the capability and motivation that a hacker should be considered to have when analyzing potential threat agents. It provides an example of the level of technical ability involved, motivating factors such as money and reputation, and how hacking may be linked to organized crime. The individual described in the article apparently did consulting work as a white-hat penetration tester. He was also successful in breaking into a variety of US federal sites in the 1990s and successfully hijacked competitor's underground forums. You can judge for yourself the level of sophistication that was required but it is certainly higher than that of a script kiddie relying on automated tools made by others.
After a brief hiatus the Voice Security Blog has returned. We once again welcome Eric Winsborrow, the Chief Marketing Officer of Sipera Systems. This post is based on an article he originally wrote for SC Magazine in June 2008, and is the second of two parts detailing how a real VoIP exploit can lead to the loss of confidential data....Lawrence Exploiting VoIP Vulnerabilities - Part 1/2In we covered some basic background on VoIP exploits, as well as detailed the first 2 steps in a fuzzing based buffer overflow attack using the SIP protocol. Today, we’ll continue looking at this attack including some mitigation techniques. Let’s start where we left off – at executing remote shell code.
One again we welcome Eric Winsborrow, the Chief Marketing Officer of Sipera Systems. This post is based on an article he originally wrote for SC Magazine in June 2008, and is the first of two parts detailing how a real VoIP exploit can lead to the loss of confidential data....Lawrence. Can you place a call to someone using VoIP and steal their personal data without even talking to them? Most people would have said “No” until they saw the demonstration at Black Hat 2007, which showed how to remotely exploit a soft phone installed on a Windows laptop and view or steal the personal data stored on that laptop. This means IT security administrators, responsible for keeping tabs on confidential data for privacy and compliance, must pay attention to the risks inherent in VoIP.
Brian Wilson from my team is back with part 2 of his series on risk management...Lawrence Risk Management in Voice Solutions: Baseline VoIP Security - Part 2:
Methodology for Selecting Security Controls
 The objective of this series of blog posts is to take the reader through the process of designing a baseline security architecture for voice solutions based on a generic implementation. Part 1 of this series focused on how and where security requirements fit in to the Risk Management process. Part 2 focuses on mapping controls to security requirements and ensuring the controls selected are aligned with security standards and industry best practices.
Brian Wilson, a Senior Security Architect with my team, specializes in the area of Risk Management and Compliance. With this post he begins a series of articles related to identifying and documenting a baseline security architecture for voice systems using a risk management approach. Lawrence Part 1 – Establishing Security Requirements
The objective of this series of blog posts is to take the reader through the process of designing a baseline security architecture for voice solutions base on a generic Implementation. Part 1 of this series will focus on how and where security requirements fit in to the Risk Management process. The process of risk management (RM) is continuous and is based on defining and establishing an acceptable level of risk. Once initiated, the process adapts to the following methodology:
- Plan: Establish voice security requirements based on compliance to laws and regulations, threat and risk assessments and specific voice implementation issues.
- Do: Select and implement security controls related to the voice implementation that meet these security requirements.
- Check: continuously re-assess the threats and risks to the security architecture ensuring the implemented security controls maintain an acceptable level of risk.
- Act: Take corrective and preventive actions, based on the results of changes, assessments and audits.
Jeff Lewis is back with an update on some VoIP Security Tools....Lawrence
Security professionals will be interested to know that their arsenal of Voice Security testing tools just got a little better. SecureLogix announced on Friday that they have expanded the tool set that was released with their Hacking Exposed: VoIP book. The original tool set has been available on their Hacking Exposed: VoIP website.
Jeff Lewis from my team joins us with an interesting post on the Woahphone. Lawrence The idea of open source software running on a phone certainly is not new. Windows Mobile Smart Phones have had this capability since inception. Anyone can write software to run on them, the software development kit is free, and there is plenty of source code around to draw upon. But the operating system (OS) code itself remains closed source. So what would happen if you opened it up and let everyone see under the hood? Well, if Google Android, OpenMoko, Qtopia and other such Linux based projects are successful, we are going to find out. These projects, and others like them, promise varying degrees of openness in the operating system for mobile phones, which is in stark contrast to other systems like the iPhone, BlackBerry, and Windows Mobile based devices. The million dollar question I am wondering is - As far as Voice Security is concerned, is an open source operating system on a handset a good idea?
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
|
|
|
|
|
|
|
|
|