Securing your systems

Physical and data security for seismic installations and networks.

Your equipment is a valuable asset but the consequential cost of interruptions to data caused by theft – or even by inadvertent reconfiguration – of equipment can dwarf such considerations. This document discusses the various ways in which Güralp Systems Ltd can support the security of your equipment and data.

Physical Security

The physical security of instruments, data-links, networking equipment and data consumer equipment should be considered during the early stages of planning an installation. In many situations, access prevention is sufficient but in certain installations, access detection is of equal importance. Conventional solutions – walls, doors, fences, intruder alarms etc should be deployed where appropriate.

In addition, Güralp data acquisition systems, such as the D24SxEAM, can be provided with both internal tamper detection (using micro-switches and optical sensors) and multiple tamper-monitoring inputs, which can either be connected to existing intruder detection systems or used as the basis of a stand-alone tamper detection system. The status of the tamper-detection lines is monitored thirty times per second. The monitoring system can be used to both raise external alarms and to set data-quality flags to highlight the fact that data may have been compromised.

The image shows Güralp Systems’ test vault at Wolverton. The entrance to the vault is protected by a steel door and a secondary steel fence with padlocked gate.

Data Security

If you rely on real-time transmission of your data, it is vulnerable to both interruption and interception.

The effects of data interruption can be mitigated by using the data storage facilities in Güralp Systems’ digitisers and acquisition modules. If transmission should fail for any reason, the firmware can be configured to store all data locally until it can either be transmitted over a restored link or physically collected from the device itself.

Güralp Systems’ Platinum firmware, running on DAS, EAM and NAM units, is capable of supporting multiple communications links, monitoring them for availability and automatically switching live data transmission between them when required, in order to maintain communications in the event of disruption to one of the transmission media.

Platinum firmware is password-protected and its web-based configuration interface can be reconfigured to only allow TLS-secured access, using the HTTPS protocol, preventing attempts to eavesdrop on communications. Command-line access can use the SSH protocol to prevent eavesdropping and even to replace password logins with more secure public-key cryptographic authentication.

In addition, certain acquisition modules can use hardware-based encryption techniques to authenticate network communications and digitally sign individual data packets in order to thwart attempts to interfere with data in transit.

Safeguarding Configurations

It is important to protect your data from the effects of misguided or accidental reconfiguration of digitisers and acquisition systems. Many organisations need to maintain a separation of roles so that data consumers can not inadvertently affect the acquisition process to the detriment of other users. Active reconfiguration of the acquisition parameters often needs to be restricted to authorised personnel. The remainder of this article will focus on techniques to establish and enforce this separation of privileges.

A typical scenario is illustrated below: An instrument is connected to a digitiser which, in turn, is connected to a EAM acquisition module. A modem line connects the EAM to a remote monitoring station where GSL’s Scream! software is used for control and monitoring. Similar considerations apply to other topologies. For example: if you are not using EAMs, simply ignore the relevant section.

In this situation, provided that the hardware can be secured, the only access to any of the configuration interfaces (the digitiser’s command line, the gconfig utility on the EAM and Scream!’s configuration system) is via the PC.

We will consider each of these configuration interfaces in turn:

• The digitiser’s output consists of GCF protocol data over a serial line. The only access to its command line is via the terminal pass-through facility in the GCF protocol itself.

  The EAM unconditionally disallows such access to consumers connected via a serial port (as in this example). Configuration of the digitiser must be carried out using the EAM’s interface because Scream relies on the terminal pass-through feature to implement its own configuration dialogues.

  Even when connected over a network, the EAM’s Scream! server can be configured to prohibit this pass-through using a check-box on the server’s configuration page:

  

  So, provided that the EAM’s interface can be secured, the digitiser’s command line is not available to data consumers, avoiding any risk of accidental or deliberate reconfiguration.

• The configuration interface of the EAM is available over both the network and, optionally, any of the serial ports. Terminal access via the serial ports can be disabled on a port-by-port basis. If a single serial port is to be enabled, unauthorised access to it (by physically unplugging the cable) can be detected by use of the tamper-line monitoring pins on the same connector. Network access can be restricted by the IP address of the client and a full iptables firewall implementation is available to further secure network access.

  Access to the EAM’s command line and web interface is, in any case, password protected but, once initially configured, a password is not required to access the seismic data.

  In the example given above, the only connection to the EAM is over the serial line via the modems. The data-stream flowing over this link can be interrupted by the Scream! operator (in order to access the command line) so it is safe to enable all administration features of the EAM provided that the Scream! implementation can be secured.

• By not restricting control at the digitiser or EAM, we allow full control of the installation from within Scream!. By securing the PC running Scream!, we secure the administrative interfaces of the entire system.

  To allow other users access to the data, without exposing the administrative interface, we nominate this instance of Scream! to be the administrative instance and configure it so that it forwards data but does not allow terminal pass-through. Subsequent, down-stream, instances of Scream! can safely take data from the administrative instance but have no administrative control of the digitiser and communications settings.

  To prevent down-stream consumers from being able to access configuration functions, it is necessary to disable terminal pass-through (as we saw earlier on the EAM). This is achieved in Scream! by clearing the Allow remote access to Com ports check-box in the Network Control:

  

  It is now trivial to set up additional instances of Scream! which draw their data from the administrative instance. They can be on different machines sharing a LAN or they could even be run in different virtual machines on the same PC.

  It is important that the machine running the administrative instance is physically secured. If it is possible to disconnect the serial cable, it could then be connected to, say, a laptop which could be used to interfere with the acquisition systems. Similarly, if it is possible to shut down the administrative instance of Scream!, a different instance could be started up which could then be used to circumvent the security policy. For this reason, a separate PC is recommended. Once set up, it can have its keyboard, screen and mouse removed: administrative access could then be provided only by using, e.g., Windows Remote Desktop, a product which offers password-protected access over a network to the desktop of the secured machine.

  

  Similar techniques can be used to secure a Linux server fulfilling the same role: VNC or secure X.11 connections can be used in place of Windows Remote Desktop, allowing access from both Windows and Linux clients, once suitably authenticated.

  

  Any of the client PCs can then access the seismic data. Additionally, administrative functions can be undertaken from any convenient client PC provided the operator has the correct login credentials to access the secure server.

  If it is not feasible to run the secure server without keyboard and monitor, a certain amount of deterrence can still be provided by using a password-protected screen-saver configured with a very short inactivity time-out. A user would need to know the screen-saver password in order to access the configuration functions.

For more information about any of the techniques described in this article, please contact .