Policies for Building the Defense-in-Depth System for Industrial Control Networks
For the sake of ICS security protection, we can build a defense-in-depth system by implementing the following policies:
- Application whitelisting (AWL)
- Proper configuration and patch management
- Attack surface reduction
- Defensive environment setup
- Authentication management
- Secure remote access
- Monitoring and response
Though the seven policies can block more than 90% of attacks, ongoing continuous monitoring is required to identify certain attack means. In addition, some security administrators may overlook alerts concerning anomalies of a relative low severity which are highly likely to be APT attacks initiated by hackers to target ICSs. Making a correlative analysis against the anomaly information to identify potential security issues can not only reduce the pressure of the administrator, but also better protect ICS security.
The security monitoring and response policy refers to security monitoring of the communication process of control devices at the field control layer and workstations at the process monitoring layer.
The ICS security monitoring and alerting system can be set up by using three steps:
- Deploy security devices applicable to protect ICSs, for example, using industrial control firewalls or IDSs for border protection and employing abnormal behavior monitoring systems or asset identification systems within the industrial control network. Deploying these underlying security systems in the industrial control environment can greatly improve the security of ICSs.
- Above all these underlying security systems, use a monitoring audit and analysis system to aggregate, extract, and make a correlative analysis of alert records and logs generated by underlying devices and dig hidden information out of these records to have a grasp of the overall security trend of ICSs.
- Forecast the future security posture. If necessary, provide necessary security measures and adopt more friendly visualization technologies.
Currently, the industrial control network security monitoring and alerting solution is still in its infancy of implementation. According to security requirements and vulnerabilities in industrial control device, we should develop security products tailor-made for ICSs to provide the preceding seven policies to protect the industrial control environment by focusing on various threat points.
Build Security In
Information technology (IT) touches upon many fields. Generally, it can be classified as hardware device, software application, and information data. As hardware device control and information data operation handling need to be implemented by software, software is the “soul” of the system and program code is a specific form of manifestation of software. Arguably, code is a core element of informatization construction as well as a key priority of security protection of information systems and infrastructure.
Trends towards globalization of IT procurement encourage countries or enterprises to purchase information system products from a greater diversity of sources, further complicating the IT supply chain. This is true for software. In many cases, software systems are essentially a combination of the self-developed, purchased, open-source, and outsourced code. VeraCode’s statistics show that 30% to 70% of homegrown software contains third-party code that take on the form of open-source components and commercial or outsourced shared libraries or components. This makes software development more efficient, but undoubtedly poses a great challenge to software security and
controllability.
In particular, in recent years, high-risk vulnerabilities have been frequently revealed in prevailing underlying open-source components such as Struts 2 and OpenSSL, and Stuxnet hit Iran and BlackEnergy targeted Ukraine, which are two malicious programs exploiting vulnerabilities in underlying software to arbitrarily compromise ICSs. In view of all these, countries and enterprises have gradually focused more attention on the security of the software supply chain, open-source software, and software installed on critical infrastructure, having enacted related national security regulations and strategies.
For software security assurance, we should discover and fix vulnerabilities in software systems as early and quickly as possible. As the original form of software, source code has a rich set of semantics. Ensuring that secure source code is written is in line with the Build Security In (BSI) principle, enabling us to discover all sorts of issues in the software as soon as possible. This is the case for ICSs. For ICSs, BSI should focus on the source code security of industrial application software, slave devices, and other intelligent devices, as well as the security of communication protocols:
- Hackers should have a good knowledge of the embedded operating system so as to successfully plant and execute a virus in it. This is also true for a slave device. The operating environment and point of entry are key to solving this issue: Without support from the operating system, the virus has no place to play its game; if the firmware is encrypted, hackers who cannot decrypt the firmware will be unable to understand the underlying mechanism; if protocols or interfaces are made proprietary or restricted to a given scope of addresses, there is no way for hackers to access them. For this reason, industrial control equipment providers should develop protocol stacks, control algorithms, hardware platforms, BIOS, and deterministic microkernel independently, and encrypt the firmware,
raising the threshold for hackers intruding into the systems.
Multilayer data communication encryption and protection technologies should be deployed to ensure data integrity and confidentiality. That is to say, these technologies should run through the operation layer, network layer, control layer, filed bus layer, and wireless layer; data should be transmitted in noncleartext to prevent data listening and tampering.
To be continued.
