A few new fronts are emerging in the battle between physical and logical separation of SCADA WAN’s. When we perform assessment and architecture projects we always ask if there are any new applications or changes expected in the near future. Increasing we hear that IP cameras and VoIP phones will be installed at the field sites and potentially traveling over the physical SCADA WAN. Is this an issue?
First we need to take a step backwards. Asset owners have been struggling with a similar issue with sharing a physical IP WAN for enterprise (corporate) and SCADA traffic. In most instances there are valid and important business reasons for having connectivity networks to both at the field sites. And importantly, IP WAN’s are expensive.
Using security features such as firewall rulesets, ACL’s, VLAN’s and others, an asset owner can logically separate the SCADA WAN from the Enterprise WAN. Sounds good, but there are two main potential vulnerabilities that could lead to significant risks:
- The security features are improperly configured through human error. This logical separation is very detail oriented, and a single mistake could have serious security ramifications. How do you prevent these mistakes not only at deployment but over time?
- The WAN infrastructure equipment, typically routers, switches and a few firewalls, could have a newly discovered vulnerability that allows an attacker to undo the logical separation. An attacker on the enterprise can then attack the SCADA systems.
So asset owners have been facing a tough decision. Do they accept those risks, and perhaps put in some compensating controls? Or do they spend the many millions of dollars to deploy and maintain separate physical WAN’s for the enterprise and SCADA networks? We have seen asset owners take both sides of this issue. It is their choice to accept the risk or not with the full understanding of the issues.
Surveillance and VoIP
Now prominent in asset owner plans are to deploy IP cameras and other surveillance systems in field sites for monitoring physical security. Sounds like a great idea. However, what are the security implications of allowing traffic between the field sites and the security system servers that are most likely on the enterprise network?
The second future use of the WAN is for Voice over IP (VoIP). Have a VoIP phone in the field site that can talk to any phone in the organization. Again, understandable business driver for this, but this means there is a potential path to attack the WAN infrastructure from a large set of IP addresses on the enterprise network. VoIP is an increasing target of the hacking community as it gets more widely deployed. Is this risk acceptable for the benefits? Do most users have a corporate mobile phone that would work at the field sites in lieu of the IP phone?
VoIP is not an area of expertise at Digital Bond today. The best security architecture for VoIP may be covered in a future podcast if I can find the right person to talk with.
Decisions with a Shared Physical WAN
If the Physical WAN is already shared for enterprise and SCADA use, the additional risk of extending the logical separation and use for Surveillance and VoIP is minimal. It adds some additional complexity to the configuration, but if the skill set exists to do it right for enterprise and SCADA it is likely to succeed for Surveillance and VoIP.
Of course, Quality of Service (QoS) becomes even more important with the increased use of the WAN. Insure that the SCADA WAN has required bandwidth and priority so a storm on any other logical network does not create a DoS for the SCADA WAN.
Decisions with a Separate Physical WAN
If you have a separate Physical WAN for the enterprise to the field sites, simply add the surveillance and VoIP to this network.
Decisions with a SCADA Physical WAN that does not have Enterprise Traffic
The hardest decisions are when an asset owner does not allow enterprise traffic over the physical SCADA WAN. What is the risk in allowing surveillance and VoIP traffic over this WAN?
- Determine what the minimum communication is required through the firewall that forms the security perimeter between the enterprise and SCADA networks.
- Determine if any of this communication can be mediated through a system on a DMZ.
- Determine if the communication / information can be originated/pushed from the SCADA network to the enterprise network.
In general, my gut feel, and other caveats to cover the risks of generalizations, allowing surveillance over the SCADA network is likely to involve less risk and more benefits. Communication will probably be restricted to a couple of security servers on the enterprise and the idea of putting a system in the DMZ is likely to work. There also are not a lot of alternative short of creating a separate physical WAN.
A VoIP implementation is likely to require connectivity between all the phones on the enterprise network and all the phones on SCADA network. This communication may pass through a server, but the communication path would be there. Also, there are often alternatives to VoIP such as mobile phones and standard dial-up lines.
The main warning here is to think through any decision to add non-SCADA traffic to the physical SCADA IP WAN. Don’t let a project start and expectations be set until the right level of management has accepted the risk.]]>