In today’s increasingly IP-based control rooms, isolating an ICCS is no way to protect it from external threats. David Cohen explains how the world has moved on

In the two decades since integrated communication control systems (ICCSs) became the main platform for control room functions, efforts to ensure their security have changed very little.

These critical systems need to maintain security and immunity from web-based viruses and intentional hacking. The first systems focused on getting high reliability systems to market, but an increased awareness of vulnerabilities pushed suppliers to declare the ICCS an ‘island’, with no connections to the outside world. This attitude is still prevalent today – but how long can it continue?

Initially, ICCS were conceptually simple systems that integrated telephone and radio voice services into a common platform. The main interfaces to the outside world were usually limited to:

• networking to remote operator positions;
• networking to the (then analogue) radio system;
• and networking between ICCS switches.

These network interfaces were predominately implemented over fixed links generally owned by the blue-light service in question and often deploying proprietary or ‘closed’ protocols. Thus the concept of an ICCS ‘island’ seemed reasonable and the vulnerability of the ICCS system remained minimal.

But then the BT Enhanced Information Service for Emergency Calls (EISEC) came along. This service necessitated a TCP/IP connection between the ICCS and the remote BT database, which was often implemented over the Internet. It presented a point of network vulnerability that is frequently addressed by the introduction of a firewall.

Compromised security

In terms of the security provided by these firewalls that isolate the ICCS, there is always a compromise between absolute security and operational requirements. If the firewall configuration is too loose (in order to accommodate flexible working) it may be more open to attacks; if the configuration is too tight, the firewall may well affect the ICCS’s operational functions.

Over time additional ICCS developments have seen the introduction of further external interfaces to other services such as GIS mapping, vehicle location, and mobile data, all of which may well require additional firewalls to maintain the concept of the ICCS as an island.

Today, modern ICCS systems have evolved yet further, with many IP-based connections now required to blue-light internal systems and into the outside world.

For example, external system interfaces typically associated with ICCS and control room installations include:

• mobile messaging systems
• automatic number plate recognition (ANPR)
• GPS-based systems
• traffic data
• meteorological data
• digital radio systems
• mobile and personal data systems
• alarm, alert and remote sensor systems
• external database access (insurers, criminal justice system)
• computer-aided dispatch (CAD) systems
• CCTV.

In addition, traditional telephony solutions used to support ICCS calls are now being replaced with IP telephony systems (which encode voice traffic as computer data packets and pass them over a computer data network rather than separate voice circuits). This only adds to the complexity of responding to the security issue: not only must the data network be secured against attack, but the voice data itself (and the IP telephony switches that manage it) now operates in the computing domain and so must be protected from compromise.

A simpler interface

ICCS solution developers – facing increasing levels of complexity in system design – are also looking at the introduction of Enterprise Service Bus (ESB) technology to simplify the interface between the systems. An ESB acts as a standardized interface and messaging mechanism for all applications in a system – a ‘middleware’ layer that can transmit and translate data.

As with most modern networking and data transmission systems, TCP/IP is normally used as the underlying protocol stack on which an ESB is built. Again, the use of these IP-based ESB technologies within the control room environment will only make it harder to adopt ‘island’-based security policies.

The result is that managers of blue-light control rooms need to reassess the security of their systems. One answer will be to consider the control room as a holistic, single entity rather than the sum of its systems (each of which may have its own security policy). This may mean installing the necessary security controls (including firewalls) at the perimeter of the control room – or even in the corporate network – rather than at each control room system interface.

Whatever the solution, the control room needs a new security policy framework to move from the piecemeal approach that has protected ICCSs for the last 20 years. This should be underpinned by three factors:
(中國(guó)集群通信網(wǎng) | 責(zé)任編輯：陳曉亮)