Today I thought I would share some ideas around IT/OT Convergence and WiFi. IT/OT Convergence involves the idea of sharing common network resources in an effort to decrease the management burden and costs normally associated with operating two separate networks while maintaining the same level of security (or keeping it as high as possible). IT and OT networks have been historically isolated and segmented from each other to ensure the compromise or failure of one has no impact on the other. Having separation typically means duplicate infrastructure in each segment and also requires two different groups of people to maintain them.
WiFi and mobile computing has really opened up all sorts of possibilities in the industrial area. One use case in high demand is the mobile worker that can wirelessly monitor and control processes directly over his mobile laptop or tablet. No longer does a fixed workstation have to be manned at all times. The wireless remote operator frees up this individual and allows this person to go mobile and perform checks and maintenance throughout the plant or factory floor while still having the ability to control and monitor everything going on in his process network. One man can now do the job of what used to require two.
This brings me to my next point – Security. Obviously the implementation of WiFi on the plant floor is a requirement for the wireless mobile worker. WiFi utilizes an unbounded medium and introduces many possible vulnerabilities and increases the attack vector many times that of the traditional fixed wired workstation in a control room. If the WiFi network is setup without much thought, not only will the OT network be less secure and prone to attack but the management burden can be increased.
If the OT network is segmented from the IT network (as is usually the case) and somebody wants to implement WiFi, the first thought is to perform a survey to figure out where the access points should go and throw in a WLC. Alternatively you could install access points without a centralized WLC and utilize something like Cisco’s Mobility Express. The problem with having a WLC at each local OT network is there needs to be somebody who can manage each one, thus increasing the management burden. Management of a wireless network is often overlooked and not thought of until a vulnerability comes out (KRACK) and all of a sudden comes the realization that you have to upgrade twenty-five different WLCs. This does not scale well unless you have a team of wireless engineers but when is this the case? You can use Mobility Express but this solution still has limited options. For instance, you still need to maintain the individual sites configuration and there are no anchoring capabilities. Following the NIST’s standards of keeping traffic segmented properly, if it is desired to propagate an IT SSID in the same OT environment, a second AP that is connected to an IT network will be required. The ideal is to install a WLC in a shared process network. With a shared WLC, the management burden is reduced (one WLC upgrade!) and IT SSIDs can be anchored to an IT WLC. For the case of IT Wlans using 802.1X, the AAA can even be proxied or relayed to an IT radius server keeping both the management and data traffic segmented. All of that is good but if you do not have that shared OT network, you may be in for a bit of a struggle as the fight is real when it comes to the IT/OT network segmentation debate!
I stated the previous as a backdrop to illustrate an alternative solution that truly does utilize the IT/OT convergence principles and overcomes some of the burden. The answer is to utilize a combination of the local FW that segments the networks, Cisco AnyConnect, and the local OT domain controller. Admittingly this solution takes a bit of work however if you need to provide a secure solution and one that will work whether or not the WAN is down, then I propose the following as one solution.
As already stated, a requirement of this solution is to ensure the Wlan is available at all times, whether or not the AP can reach the centralized shared WLC or not. For this reason, the only wireless security policy that will work is WPA2 or WPA3 (PSK). FlexConnect is also required to ensure if the WAN does go down and the WLC becomes unreachable, the Process clients will still function normally.
The firewall is configured to have a dedicated trunked wireless interface consisting of an AP management Vlan and a Client Vlan. Firewall rules are implemented such that all traffic is blocked except CAPWAP traffic going to the IT WLC (UDP Port 5246 & 5247) on the AP management interface. A deny any any is applied on the Client interface blocking all traffic.
Remote Access is configured for the client to be able to VPN into the Process network via Cisco AnyConnect. The client IP address is translated via NAT and ACLs are put in place to only allow the client specific destinations. This can be done utilizing Dynamic Access Policies. Both the ACL and the appropriate AD group can be added here to properly permit or deny access based on the AD group membership. Finally, an AAA server group is added with LDAP utilized to query the local Process domain controllers.
On the IT WLC, a Process SSID is configured as locally-switched with a PSK. Client data is offloaded at the AP in a locally-switched Wlan. The access points are configured for FlexConnect and the appropriate Wlan is mapped to the corresponding Vlans. If IT SSIDs are to be propagated on the AP, these will need to be configured as centralized Wlans so that the client traffic will be tunneled up to the IT WLC.
The next step to this process is to configure the client device (Windows). Cisco AnyConnect is installed on the device and then configured to automatically connect to the Process SSID. Once associated, AnyConnect is used to VPN into the local Process domain utilizing their user credentials. This ensures that even if somebody knows the PSK, they will still need Cisco AnyConnect installed and be able to connect using somebody’s domain credentials. If security still seems to be too low, certificates can be utilized as a secondary form of authentication (Multi-Factor Authentication). If the device is lost or stolen, the user account or the device certificate can be revoked to prevent the device from connecting to the Process network. Here are the steps to connecting to the VPN:
Let me know what you think!
RF Blogger 