Infraguard session on SCADA security

The quarterly Infraguard meeting was held this morning at the Metropolitan Water District Headquarters in downtown Los Angeles. The topic was securing Supervisory Control And Data Acquisition (SCADA) devices. Speakers were Jason Larsen and Jeff Tebbe, both from the Idaho National Laboratories.

Their facility at the Idaho National Laboratories is intended to provide a perfect test environment for hacking industrial control systems. According to Jeff, vendors will provide them with their latest products for "test hacks", designed to help improve the product's security. This is all done with the support of the US government, specifically the Department of Homeland Security.

The Laboratory is developing a framework for SCADA security, based on NIST (SPP-PCSRF) and Common Criteria (ISO/FIC 15408) standards. These sometimes obtuse standards documents are made more comprehensible and more modular, and a database is created of the requirements combined with the SCADA components to which the requirements apply. Based on this framework, a security assessment methodology is applied to determine the actual security assurance level of the tested component. The goal of the framework is to provide common standards for assessment, such that an assessment performed by two different teams will produce similar findings.

Generic attack methods were then discussed. An attacker must first reach the LAN containing the SCADA devices. This LAN is typically isolated from the business LAN by a firewall. The isolation is often not perfect, and successful penetration of the SCADA LAN may come from back-doors, rather than a frontal assault through the business network. Some methods to penetrate the SCADA LAN include:

• Remote Terminal Units with modem access
• Wireless interception, either of cellular or of 802.11 networks. Point-to-point microwave is actually quite difficult and expensive to intercept.
• Vendor access for service
• Control channels from IT directly to devices, bypassing the firewall.
• Peering networks with other utilities, for load balancing. A "mom and pop" utility is compromised, and the peering relationship allows compromising a much larger utility
• IT management VPN, by compromising the IT admin's desktop system
• Cross-network database links
• Hi-jacking vendor patches, and introducing Trojan horse modifications on the fly

Inherent complexities in SCADA systems tend to make them difficult to hack. Unless the hacker really understands the details of the industrial process being controlled, they can at best conduct minor vandalism (closing random switches, etc.). Vendor protocols have historically been proprietary, relying on serial busses rather than well-understood networking links. The device communication language itself is poorly if at all documented. Modifying the control communications is very difficult given this, and requires time and patience on the part of the attacker.