Security Lifecycle Report: Shedding Light on ICS Network Usage and Threats

Dec 04, 2015
5 minutes

Most of our users in ICS/SCADA during their initial evaluation of our products went through an evaluation called an “SLR” or Security Lifecycle Report (formerly called an Application Visibility and Risk Report).

We offer this free assessment as a way to provide users a detailed view of what applications and risks are running in their industrial control systems environment. Among other benefits, the SLR can be conducted in a monitor-only configuration where the next-generation firewall, instead of being deployed inline, is installed passively in “tap mode” to monitor network traffic. While passive, the appliance provides detailed layer-7 visibility to applications, ICS protocols, content, threats, and users. The SLR tool has been a big eye-opener to many OT security professionals as “interesting” and unexpected findings always come up. Some findings are immediately actionable and other findings give insight to risks that may need further planning and investment to be properly addressed in the long term.

The SLR allows end users to validate that the traffic (apps, users, content) expected to be running in the ICS/SCADA environment is indeed present. These include the common ICS protocols and applications, management applications, database/historian apps and on some occasions, custom applications. ICS environments are usually static and if change happens, it is often implemented methodically over a longer period than is typically seen in IT networks. This static nature makes it easy to identify anomalies against a baseline. The SLR for this reason is ideal for detecting risky and malicious traffic.

Some examples for this category of traffic that we have found in ICS/SCADA networks include the following:

  • Risky internet-facing applications – Engineers wanting to use internet-based apps for work collaboration, remote access, or leisure find ways to connect to the Internet whether via the business network or by setting up ad-hoc broadband networks in the OT. We have found Dropbox and Wuala (cloud storage), Bittorrent and eMule(P2P filesharing), TeamViewer (collaboration), Skype (Voice/Video), Facebook (social media) and similar applications. We’ve even found gaming applications on an offshore rig! While not malicious in nature, these applications are highly risky in terms of compromising network performance and opening pathways that could be used by attackers to breach the ICS.
  • Unknown / Encrypted Traffic – Sometimes this ends up being legitimate, custom traffic created by the end-user. For example, we sometimes run into cases where a serial protocol such as IEC 60870-5-101 traffic is tunneled over TCP. This can be easily fingerprinted subsequently through the creation of a custom application identifier or “App-ID”. For unassignable, unknown traffic, further analysis is required to determine whether it may be associated with risky/malicious applications or command and control traffic. We also sometimes run into encrypted traffic like SSL/SSH, which may be normal. For example, SSH is frequently used in ICS for remote system management. SSL is more rare in ICS and when found typically prompts investigation to determine what exactly the SSL traffic is and why it is needed in the environment.
  • Known Malware and Exploits – In five recent SLRs conducted in South America, four of the networks we analyzed were found to have the Conficker malware. Accidental malware infection is very common in ICS and initiated via adjacent networks, dual-environment mobile devices (IT & OT), or removable media. Whatever the case, this discovery often prompts a revisiting of network segmentation as well as mobile device and removable media policies. We are also able to identify risky ICS protocol commands, for example warm restarts. These commands are so significant in terms of disrupting uptime that they may be deemed as exploits. When found, they typically are part of normal routine or maintenance events, but may also be anomalous when sourced from unusual security zones, machines, or users.
  • Zero-day Malware/APTs –In those same five networks in South America, of the three that used Palo Alto Networks WildFire service, two of them found zero-day malware. Zero-day attacks are of course much more serious than known malware in that the unknown nature may be indicative of a targeted campaign from an Advanced Persistent Threat (APT).
  • Command and Control Traffic – Using our Threat Prevention service and behavioral botnet report, we are able to detect suspicious outbound traffic to domains and websites. When present, such traffic may suggest an advanced malware infection. For example both Conficker and even ICS-specific attacks like Stuxnet and Energetic Bear have associated CNC fingerprints that can be detected and stopped. The behavioral botnet report is a more heuristic approach to assessing potential malware infections with callback features when specific fingerprints are not available.

Don’t be one of those users who assume that their ICS is safe just because there is a firewall at the IT-OT perimeter and because there are strict usage policies. Attackers and internal employees are creative and motivated to get their respective “jobs” done and could intentionally or inadvertently introduce risks and threats even with these basic controls in place.

Find out the state of your ICS more conclusively with an SLR risk assessment. It is free, non-disruptive, confidential, and provides a wealth of actionable information that can be used to better secure your critical infrastructure. Contact your local Palo Alto Networks sales representative today for more information.

Subscribe to the Blog!

Sign up to receive must-read articles, Playbooks of the Week, new feature announcements, and more.