BREAKING NEWS: Improve Tab to Terminal Connections in Battery Pack Manufacturing      Plessey helps top Dutch grower boost tomato yield in trial of LED and high-pressure sodium hybrid lighting      Toshiba’s New Stepping Motor Driver IC has an Anti-Stall Feedback Architecture      Arrow Electronics accelerates IoT endpoint creation with new ARIS EDGE platform      Simple to customise AC Power Sources at low off-the-shelf prices from Powerstax     
Industrial Networks Require Centralized Security Orchestration
Tuesday, January 24, 2017

By Larry O’Connell, Microsemi Corporation and Roger Hill, Veracity Security Intelligence


Security architectures are evolving as networks become more flexible.

Security architectures are evolving as networks become more flexible.

As industrial networks increasingly interconnect with the wider Internet, OT infrastructure managers will need industrial strength security tools equivalent to their IT counterparts’.

Today’s industrial network security is typically done in isolation or by implementing a firewall between the corporate and industrial network. Efforts to secure these networks on a broader scale typically involve costly network topology changes or network downtime, negatively impacting revenue, productivity and even safety in certain situations. But what if industrial network administrators could quickly and seamlessly add security applications and policies to existing networks centrally? What if it were possible to do this with minimal downtime and without increasing network complexity? That’s the promise of a new top-down paradigm for industrial network security — one built around centralized security orchestration based on programmable security zones executed in a distributed way.

A False Sense of Security

If recent cyber attacks teach us anything, it is that we can no longer assume industrial networks are protected simply because we think they are isolated from the Internet (another assumption that is increasingly false). Take Stuxnet, the computer worm believed to have destroyed a fifth of Iran’s centrifuges used to separate nuclear material. The attack vector was a simple USB thumb drive. In a classic “man in the middle” attack, the worm inserted malware into the PLC controlling the centrifuges and into software controlling the PLC. It then sent invalid commands to the PLC, causing the centrifuges to tear themselves apart while at the same time causing the software to report “status normal” indicators back to human operators.

Then there is the notion of completely isolating a modern industrial network from the Internet. That can actually make the network less secure because it is harder to manage, because issues are harder to diagnose, and because isolated networks are more difficult to scale, reconfigure, or extend as companies adopt new technologies, update supply chains, or adapt to new competitive opportunities and threats. A clear case is the Industrial Internet of Things (IIoT). As IIoT becomes more widely adopted, industrial organizations will increasingly seek to acquire more data at the network edge, while also taking advantage of the cloud and big data analytics in order to scale processing and make practical use of all this newly acquired data. That requires an Internet connection.

Microsemi Industrial Ethernet switch reference design. Managed industrial Ethernet switches can support local or centralized management configuration for optimal security.

Microsemi Industrial Ethernet switch reference design. Managed industrial Ethernet switches can support local or centralized management configuration for optimal security.

The upshot is that OT infrastructure managers require centralized security orchestration equivalent to what their IT counterparts have long had. Few IT managers would consider, for the sake of security, permanently disconnecting their internal networks from the Internet. Nor would they rely solely on firewalls for security under the assumption that firewalls are perfect malware filters or that employees, contractors, or visitors won’t — accidently or otherwise — introduce a piece of malware by plugging in a laptop, by inserting a USB drive, by clicking an email link, or in some other way. They have to assume that malware will get on their internal networks and will try to do harm. That’s why they employ centralized security orchestration — to acquire its five key capabilities:

To provide network-wide situational visibility — as in identifying what nodes (devices and ports) are talking to what other nodes (devices and ports), what protocols are in use, what devices are present on the network, what are the traffic volumes between nodes, etc.
To identify anomalies — as in showing how the current situation differs from historical norms or from what’s expected (e.g., traffic spikes on a port talking to the Internet during non-working hours).
To enable management-by-policy — as in setting alerts or taking other action automatically when predefined anomalies occur.
To provide centralized programmatic control — as in reacting to alerts or taking proactive steps such as to isolate subnets from the rest of the network (or the Internet), disconnect a device, or even shut down a subnet as a last resort.
To provide a single pane of glass — so network operators can do all the above without switching between interfaces, learning device-specific commands, or reading equipment vendors’ technical manuals.
These five capabilities affirm an important principal fundamental to both OT and IT: that network management and network security are inseparable. The ability to spot anomalous traffic volumes or change subnet partitioning, for example, speaks to both operational performance and security. A corollary is that you can’t have robust network management without analogous security management and vice versa.

OT’s Unique Network Challenges

But when it comes to implementing centralized security orchestration in the industrial space, OT faces challenges not typically found in IT:

Proprietary barriers abound. Industrial networks are rife with solutions that speak different protocols and obey different command syntax, as well as with end-point devices, that are tightly bound to their controllers, which in turn are tightly bound to particular supervisory software. That’s why mixing and matching solutions at different levels of the control hierarchy is very difficult — and why what should otherwise be a simple PLC switch-out, for example, often requires replacing an entire skid — incurring expensive downtime, lost production, and lost revenue. Increasingly equipment vendors are addressing this issue with software programmable “white label” devices, particularly switches, which allow for swap-outs and topology changes on the fly under remote (and potentially centralized) software control.
Limited security controls. A legacy environment defined by proprietary islands left network operators with few options when it came to implementing security policies. There was no centralized configuration capability, little to no auditing of configurations, and limited security controls at the switch itself — mainly access control lists and the ability to enable and disable particular ports. If you wanted to inspect or change port settings, you had to physically visit a switch. On a performance basis, this often led to inefficient or simply wrong network configurations. On a security basis, this meant an inability to see patterns of activity across the network that could pose potential threats and the inability to respond to those threats swiftly with minimal disruption.
Faced with these challenges, OT network managers also don’t have the luxury of simply shutting down part of their network when threats occur. So they need security orchestration even more aligned to their requirements than one might typically find in IT.

Split the Control Layer from the Data Layer

Ultimately, the best way to implement centralized security orchestration is by separating the switch’s control layer from its data layer. By defining security zones, event thresholds, and other control features in software rather than in hardware, OT can achieve the same flexible policy-driven distributed network management as IT — while overcoming OT’s inherent security and management challenges. The only other requirement is to also implement SIEM (security information and event management) software fully capable of leveraging hardware vendors committed to this type of seamless environment.

About the Authors

Larry O’Connell, product marketing director at Microsemi Corporation, has over two decades of experience in driving Ethernet switching into Enterprise, Carrier, and Industrial applications. He is currently responsible for Microsemi’s Ethernet switch silicon and software product lines.  Mr. O’Connell holds a BS in Mechanical Engineering from Tufts University and an MBA from Cornell University.

Roger Hill, CTO for Veracity Security Intelligence, has over 20 years of experience in industrial control systems in many different industrial segments. A globally recognized subject matter expert in cyber security for ICS, Mr. Hill is also a leading authority in distributed SCADA systems and Cyber Security.


Skyscraper 2

Skyscraper 3

Skyscraper 4

Skyscraper 5

Skyscraper 6