Rather than presenting a "Frequently Asked Questions" (FAQ) section on modem security, we thought that we would depart from the norm 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 some erroneous preconceptions of how their systems are organised, rather than on any 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.cybercrime.gov/juvenilepld.htm). In another, a disaffected former employee used a support modem to deliberately destroy data on a customer order system (www.usdoj.gov/criminal/cybercrime/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 - 5th Ed 2005)

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.)

Undoubtedly, a digital telephone system gives some measure of protection. Primarily, it restricts the ability for someone to just plug into any random telephone jack and hook up a modem. Better still, from a prevention point of view, given that digital telephone systems have different electrical characteristics, connecting an analogue modem is likely to 'fry' the device making repeat infractions less likely. However, there are three points that need to be considered:

1. adapters are available that are compatible with digital telephone systems. These can either plug into a digital telephone socket itself (Konexx Digital Wall Interface), or else act as a handset converter (Ositech Five of Spades). Both allow connection of ordinary analogue modems.
2. some digital handset manufacturers provide direct support for their own analogue add-on adapters (e.g. Siemens optiset E, optiPoint 500)
3. digital PBXs are often configured with some analogue capability, typically to provide analogue lines to desktop faxes. It's simple for an individual to insert a splitter cable into a fax line and piggyback a modem onto it

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?

That's exactly as it should be, according to both BS7799 and the Payment Card Industry Security Standards. (Though, 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.

For all but the smallest organisation, this is likely to be untrue. Modems are ubiquitous, and 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?

That is possibly true, but it misses the point. These days modems are more commonly associated with providing remote dial-in support for infrastructure systems, rather than dial-out access for PCs.

Unlikely. Modems are everywhere. They are embedded into servers, disk arrays, telephone systems, 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 ADSL 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).

If you belong to an organisation of any size, this is likely to be wishful thinking. It's probably truer to say that you only have a few that you know about. From our extensive audit experience (encompassing well in excess of 1,000,000 calls), we typically detect 0.5% - 1.5% of all an organisation's direct dial lines as attached to modems configured to allow dial-in access. Or put another way: 5 - 15 modems per 1000 lines. That's potentially an awful lot of unpoliced access routes that are outside the protection of your firewall. Furthermore, the metrics tend to be the same, irrespective of organisation size or business sector.

It's an unfortunate truth that workloads tend to increase, rather than vice versa. This is especially true with the rapid advances in Information Technology. New technologies tend to get adopted alongside existing technolgies: supplementing rather than supplanting them. Yet each new technology brings with it it's own threats and risks, all of which have to be considered and addressed. Without a balancing increase in staffing, prioritisation is a fact of life that we all have to live with. However, a fundamental prerequisite for proritisation is an understanding of the extent of your exposures. For example, how would you rate the priority of securing a key piece of networking equipment that has no password and is publicly accessible through an unsecured modem? Or a building access control system, running on an old version of Unix that hasn't been patched for 8 years? Both of these are real-world examples that we discovered during telephone system audits. In both cases our clients were completely oblivious to these specific vulnerabilities before we conducted the audits.

Prioritisation might be inevitable, but you really can't prioritise what you don't know about.