Rather than presenting a "Frequently Asked Questions" (FAQ) section on modem security, we thought that we would turn the problem on its head by presenting some "Frequently Assumed Answers" (FAA).

So what exactly do we mean by a Frequently Assumed Answer? Essentially, it's the opposite of a Frequently Asked Question. It's based on the assumption that since you already know the answer, you don't need to ask the question in the first place. In this case, the question would be "Why do I need to look for Modem Access?" Many organisations believe that they don't, but this is often based on erroneous preconceptions of how their systems are organised, rather than on an objective assessment.

In this section we'll cover a dozen or so of the commonest FAAs that we come across, and explain exactly why we believe that they are founded on false assumptions.

This is actually a difficult assumption to counter, for one simple reason: modems are largely hidden from public view. If a website is defaced, everyone knows. If somebody hacks in through a modem, it's private, and with little incentive for disclosure, it's likely to remain so. Nevertheless there are some published examples. In one, a modem-initiated attack succeeded in closing a provincial US airport (http://www.justice.gov/usao/eousa/foia_reading_room/usab4903.pdf, http://edition.cnn.com/TECH/computing/9803/18/juvenile.hacker/). In another, a disaffected former employee used a support modem to deliberately destroy data on a customer order system (http://www.justice.gov/criminal/cybercrime/press-releases/2002/eitelbergArrest.htm). Despite the paucity of documented evidence, respected security professionals continue to regard modems as one of the most overlooked (and popular) routes used by malicious hackers to gain remote access (see Hacking Exposed: Network Security Secrets and Solutions. McClure, Scambray & Kurtz. 1st Ed 1999 - 7th Ed 2012). For certain classes of devices (e.g. SCADA control and data acquistion systems, often deployed by Utility companies), modems still fulfill a significant role in supporting remote access.

Many people think that Voice over IP telephony doesn't support modem data communications. The true answer is: it depends. Data calls are inherently less resilient than voice calls to the type of timing fluctuations that commonly occur during a VoIP session, but at a level which goes unnoticed during a voice call. However, VoIP lines can be configured to reliably work with fax calls, using a high quality, low compression codec such as G.711. This is really the crux of the answer, and it revolves around semantics. Analogue modems can be used reliably in a VoIP network, but for low-speed communications. Using a simple off-the-shelf analogue telephone adapter (ATA) we have successfully used analogue modems to communicate at V.32 speeds (9600 baud) across VoIP networks, with no other special configuration. This might not seem very fast, but bear in mind that remote management interfaces are often built around simple text-based menu systems, with very little data flow. In fact, during audits we still routinely detect equipment that uses 2400, or even 1200 baud modems. Compared to these devices, 9600 baud is blisteringly fast.

(It's also interesting to speculate what the future impact of VoIP communications might be on war dialling, when it can be initiated anywhere across the globe at minimal cost.)

Excellent. But you may have overlooked a few things:

1. Modems provide a direct connection to the outside world through the telephone system. They don't use the network, so they just go round the firewall.
2. Modems provide an essential maintenance route for business-critical equipment that might not even be part of the network (such as the telephone system, or voicemail system), and so are not covered by a network-based IDS/IPS .
3. Modems provide a maintenance interface to many pieces of infrastructure equipment that may be running either a bespoke operating system or else a heavily customised embedded flavour of mainstream O/S, neither of which may be suited to the installation of a host-based IDS.

A policy is an essential starting point. But a policy is only a document. How can you know how effectively it is being communicated without the tools to monitor and enforce it? How can you be sure that even where modems are authorised that they have been configured in accordance with best practice?

Like our existing clients, you'd probably be amazed to see how often this proves not to be the case, even where policy dictates it should be.

Again, a good approach, but not entirely without flaws. In this case there are two scenarios that need to be taken into account:

1. Where equipment contains an embedded modem, it is not uncommon for the modem to reset to a configuration where it will automatically answer incoming calls. This is essential for ease of maintenance. If a device locks up, sometimes the pragmatic solution is to have someone local to the device simply cycle the power, allowing a remote support technician to regain dial-in access.
2. Most telephone systems allow calls to be redirected internally. Consequently, by configuring call-forwarding from an externally accessible direct dial (DDI) line to an internal (non-DDI) modem line makes that modem instantly accessible to the world at large. This clearly poses a much more widespread risk.

Even today, for all but the smallest organisation, this is likely to be untrue. Modems are integrated into all sorts of equipment: everything from the telephone system to the fax machine, air conditioning system (HVAC), power management/monitoring/backup system... even the vending machine! For many organisations, some level of (out-of-band) modem access is essential. How else can you manage the network infrastructure if the network itself is down? Or manage equipment on remote sites that have no network infrastructure?

Unlikely. Modems are everywhere. They are embedded into servers, disk arrays, telephone systems (including the latest VoIP PBXs!), building level uninterruptible power supplies, utility monitoring and metering equipment... (Of course, you won't know exactly how pervasive they are until you look.)

With the widespread availability of domestic broadband and fibre services, and the maturity of secure VPN access, this might be true... for end-users. However, you will almost certainly have remote modem access for support engineers: either your own, or third-party suppliers. In fact, if you use external suppliers, it's almost certain that remote access will be required to meet service-level agreements - and remember, the systems that they might be supporting could be ones that aren't ordinarily included in the security mix (like power or environmental management systems).