Part 3: Protecting PLCs and Their Environment
For many years, PLCs have been insecure by design. Several years into customizing and applying best practices from IT gave rise to secure protocols, encrypted communications, network segmentation, and so on. However, PLCs programming is still done without security in mind.
PLC secure coding practices leverage natively available functionality in the PLC. Implementing these practices requires little to no extra hardware or software. They can be incorporated into the typical PLC operating and programming workflow. The implementation requires security expertise and solid knowledge of the PLCs that need to be safeguarded, their logic, and the underlying process.
As explained in part 2 of this series, the key to detecting attacks targeting PLCs is understanding the proprietary protocols that each PLC vendor developed and implemented.
The most common usage of ICS protocols is process automation using PLCs, which are configured and queried by ICS protocols. Well-known protocols in this area are Modbus, Siemens S7, and Ethernet/IP. However, on top of those widely used protocols, there exist tens of additional protocols which are used in many industrial facilities,such as Profibus, ProfiNet, DeviceNet, EtherCAT, DF-1 Protocol, DNP3- Distributed Network Protocol, and many others.
Remote management of buildings is significantly based on BACnet. It is used to control heating, air-conditioning, lighting, fire detection, and other systems.
Electrical and water companies use protocols such as DNP3, MMS, and IEC104 to monitor power systems and automate them.
ICS Protocol Dissection For Improved Security Posture
Most of the common ICS protocols lack protection by design and are susceptible to different kinds of attacks. Initially, authentication and encryption in ICS protocols were not necessary since they were made to run in isolated environments (what sometimes is referred to as “AirGapped networks”). Due to their deployment in such environments, these protocols' lack of security features went mostly unnoticed.
This changed with the addition of ICS protocols to IP, allowing for the management of ICS controllers through the Internet. This communication requires protective measures, such as end-to-end authentication and encryption or secure tunnels between trusted domains. Unencrypted ICS traffic is particularly risky since it can be intercepted and subject to manipulation attempts.
The security flaws present in the design of these protocols open the network to a wide range of potential attacks, such as the attacks mentioned in the previous posts in this series.
How SCADAfence Secures Industrial Networks
SCADAfence’s research team continually works to understand the assets in OT networks and their individual security risks. This includes understanding how assets, such as PLCs, communicate with each other and with their workstations.
This is done by analyzing the protocols each vendor uses for this communication and dissecting them, and also classifying normal vs. abnormal traffic
Documented vs. Undocumented Protocols
For some protocols, it is possible to find official documentation, making it easier to understand how the protocol works and how useful information can be extracted from it for further analysis of OT threats.
Undocumented protocols require a different approach. The protocol needs to be researched and analyzed in order to understand its nature, message exchange and other aspects.
Only then it is possible to move on to detecting the security risks and evaluating them.
Dissecting Undocumented Protocols
Proprietary protocol dissection can’t be standardized due to the unknown layers of complexity implemented by most vendors. This is where the experience of security researchers can make a big difference.
The first step in this kind of protocol analysis is to examine traffic examples of the protocol. This may be achieved by generating network traffic and capturing PCAPs files with the specific type of communication between the engineering workstation and the PLC we are interested in understanding, or by acquiring PCAPs with the relevant traffic.
At SCADAfence, we have an extensive collection of PLCs and HMIs which help us, among other methods, generate ICS network traffic and produce PCAP files containing tailored communications. This allows us to analyze specific network traffic, which includes communications via proprietary, undocumented protocols, allowing the analysis process.
SCADAfence network analysis and security platform
The SCADAfence platform is an efficient and reliable network analysis tool. It can provide valuable insights when analyzing a newly acquired PCAP file.
OT traffic often exhibits specific patterns. Typically, when beginning the protocol reverse engineering process, we will try to recognize these patterns. We must recognize the essential components that will guide our understanding of the communication structure in steps (lengths, function codes, sequence numbers, crc, and so on). Capturing a single piece of information serves as a starting point, an anchor, for further analysis, making it easier to identify additional details.
For additional information about how SCADAfence can help keep your OT network secure, or to see the SCADAfence Platform in action, request a demo today.