Managing Data Integrity Risks for SCADA Systems

SCADA (Supervisory Control and Data Acquisition) software vendors have historically served industries that require tight controls over system configurations and data records.  As a result, modern SCADA software systems have evolved to provide a robust set of tools intrinsically designed to prevent the intentional or unintentional undetectable alteration of system data.  Most notably, the integration of electronic record management, electronic signatures, logical security, and audit trail functions are built-in or made available as optional features to provide compliance with FDA 21 CFR Part 11.

The front line defense is, of course, the security of the process network.  Physical security of all network components should be considered in the design of the system.  Production facilities, system servers, network switches, PLCs, IO modules, process instrumentation, and where possible, production workstation terminals should be kept under lock-and-key with access limited to as few individuals as necessary to operate and maintain the network hardware systems.  Logical security should be limited to a documented list of authorized individuals, with clearly delineated permissions limiting their access to only those system functions commensurate to their level of responsibility and qualification to access or generate data on the system.

Clear guidelines for establishing security for a SCADA system are provided in the National Institute of Standards and Technology, Special Publication 800-82, Guide to Industrial Control Systems (ICS) Security (Rev.2, May 2015, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r2.pdf).  The document addresses security risks for Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and other control system configurations such as Programmable Logic Controllers (PLC).

The Executive Summary of the Guide document offers examples of the types of possible incidents that might occur as a result of data security breaches or a lack of adequate data security on an industrial control system:

• Blocked or delayed flow of information through ICS networks, which could disrupt ICS operation.
• Unauthorized changes to instructions, commands, or alarm thresholds, which could damage, disable, or shut down equipment, create environmental impacts, and/or endanger human life.
• Inaccurate information sent to system operators, either to disguise unauthorized changes, or to cause the operators to initiate inappropriate actions, which could have various negative effects.
• ICS software or configuration settings modified, or ICS software infected with malware, which could have various negative effects.
• Interference with the operation of equipment protection systems, which could endanger costly and difficult-to-replace equipment.
• Interference with the operation of safety systems, which could endanger human life.

Notably, the Executive Summary does not highlight the potential loss, adulteration, or alteration to process data history stored in a SCADA database.  This risk is, however, addressed extensively throughout the document.

The Executive Summary of the Guide document highlights the major security objectives for an ICS:

• Restricting logical access to the ICS network and network activity.
• Restricting physical access to the ICS network and devices.
• Protecting individual ICS components from exploitation.
• Restricting unauthorized modification of data.
• Detecting security events and incidents.
• Maintaining functionality during adverse conditions.
• Restoring the system after an incident.

In a typical ICS this means a defense-in-depth strategy that includes:

• Developing security policies, procedures, training and educational material that applies specifically to the ICS.
• Considering ICS security policies and procedures based on the Homeland Security Advisory System Threat Level, deploying increasingly heightened security postures as the Threat Level increases.
• Addressing security throughout the lifecycle of the ICS from architecture design to procurement, to installation to maintenance to decommissioning.
• Implementing a network topology for the ICS that has multiple layers, with the most critical communications occurring in the most secure and reliable layer.
• Providing logical separation between the corporate and ICS networks (e.g., stateful inspection firewall(s) between the networks, unidirectional gateways).
• Employing a DMZ network architecture (i.e., prevent direct traffic between the corporate and ICS networks).
• Ensuring that critical components are redundant and are on redundant networks.
• Designing critical systems for graceful degradation (fault tolerant) to prevent catastrophic cascading events.
• Disabling unused ports and services on ICS devices after testing to assure this will not impact ICS operation.
• Restricting physical access to the ICS network and devices.
• Restricting ICS user privileges to only those that are required to perform each person’s job (i.e., establishing role-based access control and configuring each role based on the principle of least privilege).  
• Using separate authentication mechanisms and credentials for users of the ICS network and the corporate network (i.e., ICS network accounts do not use corporate network user accounts).
• Using modern technology, such as smart cards for Personal Identity Verification (PIV).
• Implementing security controls such as intrusion detection software, antivirus software and file integrity checking software, where technically feasible, to prevent, deter, detect, and mitigate the introduction, exposure, and propagation of malicious software to, within, and from the ICS.
• Applying security techniques such as encryption and/or cryptographic hashes to ICS data storage and communications where determined appropriate.
• Expeditiously deploying security patches after testing all patches under field conditions on a test system if possible, before installation on the ICS.
• Tracking and monitoring audit trails on critical areas of the ICS.  
• Employing reliable and secure network protocols and services where feasible.