Everyone’s heard of Stuxnet. But what does it mean to us now?
In any economic climate, businesses desire reliability and predictability in their processes. Thanks to Stuxnet, there’s now more awareness of security improvements on the plant floor. Since insecure systems are a threat to predictability, and unpredictable systems are not safe, this is definitely a good thing.
So, if your management threw money at you and said, “fix our processes,” what would you do? For that matter, what would you do if they left out the money part?
Here are some actionable thoughts to consider in the areas of design, operational monitoring and incident response.
Design to minimize the unexpected. Use physical network isolation and access control lists to control communication to and from your different SCADA control networks.
Do not share physical networks with non-SCADA systems. This includes office email, video monitoring and voice over IP. As much as possible, know what’s on the network without having to look at network traffic.
Design an environment and related processes for deployment of untested, zero-day patches. Most SCADA vendors have application-level redundancy and provide cost-effective duplication at the operator HMI side. Use those systems effectively to mitigate the risk of deploying untested patches.
Don’t design assuming you can test patches. For example, try using a phased patch deployment process. This results in a more resilient SCADA environment equipped to handle both expected and unexpected operational realities.
Avoid any monitoring approach that requires excessive manual monitoring and calibration. The resources needed to perform manual tasks are hard to find and difficult to keep. Many intrusion prevention systems (IPS) and security event and incident management systems (SEIM) are very costly to implement and maintain. When using these systems, look for opportunities to minimize their need for tuning to function effectively. An easily understood physical architecture will help tremendously in reducing the tuning required to eliminate false positives. Non-intrusive intrusion detection systems (IDS) are good options here, as their false positives should not cause service interruptions.
Make sure you’ve stacked the deck to minimize risk in your favor. Any steps you can take that do not add to your monitoring overhead should be considered. This includes automatic-updating endpoint protection and antivirus systems. Most SCADA vendors have a preferred list of supported applications. Work with your SCADA vendor to address these issues. Some vendors also have prebuilt IDS / IPS solutions tuned specifically to monitor their products. These are often worthwhile.
Always use audience limitation. If one network doesn’t need to talk to another, put in a simple rule or access control list to keep that from happening. Above all, keep it simple and focus your efforts on being able to respond quickly to a security response.
False positives — or false alarms — cost money. Most visible unknown behaviors are first identified as operational incidents. Make sure your security incident response team is connected to the help desk incident response environment. Not every incident is going to be a security issue, but the ability to escalate to a security team and have them monitor overall incident patterns will minimize false positives.
At a multi-location company, keep the SCADA architecture as consistent as possible from site to site. Have standard product-level approaches that need minimal location-specific documentation to describe. Wherever possible, use meaningful naming standards for SCADA \ HMI hardware and network devices. A good set of standards and governance for your SCADA \ HMI environment is one way to address this need. You can partner with security people and your SCADA vendor to develop these standards.
Put your incident response teams in a position where they are effective, even without detailed documentation.
Have any other methods that improve predictability? Let us know in the comments.