An increasing number of intentional attacks are being detected that target industrial control systems (ICS), as these may be cyber vulnerable. The current best practice for cyber defense is to build a bubble of complex enterprise defenses around an ICS target, while also attempting total system isolation. This may involve creating demilitarized zones between the business network and the industrial network, banning the use of portable devices on the industrial network, ensuring that security patches are installed regularly, personnel vetting and training, system design rules, data restrictions, network segmentation and patch policies. However, no number of procedures, training and technologies can compensate for flaws in the underlying ICS.

Patching, for example, is very important, but it is also very expensive and carries some extra risks for ICS as it can impact the performance of a critical process. Weaknesses like these will always lead to vulnerabilities that can be taken advantage of by attackers unless the inherent security of ICS is improved.

An unprecedented number of security vulnerabilities have been exposed in ICS, but there are well-established strategies that can be employed to discover and mitigate security vulnerabilities and improve the inherent security. For example, to prevent against injection attacks, ICS should validate any input data received. To protect against attackers sniffing data over the network, the data can be encrypted. To ensure that configurations cannot be downloaded from untrusted sources, user and device authentication can be implemented. To find other security weaknesses in the ICS, testing can be done such as static analysis of source code, fuzz testing, and analysis of binary code.

Why Certify ICS?

Non-certified products capabilities are generic and can protect only against casual violations or non-targeted attack methods like social engineering, but secure interfaces between ICS and cloud-based preventive maintenance tools require interoperable security approaches, which is not possible with non-certified products. ICS module counterfeiting is widespread and so advanced that it is difficult to tell the difference between fake and authentic vendor products. While counterfeiting is used primarily for financial gain, rogue actors use this method as an attack vector by incorporating malware into the counterfeit product firmware. The way forward is to design systems with deeply embedded intrinsic defense which is only possible by certified products like intrinsic hardware and firmware authentication with strong encryption can identify and reject sophisticated fakes instantly, disabling this powerful cyber-attack vector. Certified products maintain their authenticity as they are easy to detect unauthorized changes to the component’s firmware and/or software, making it difficult to make unauthorized changes.

Encryption in an ICS

Encryption can be used in two basic ways in an ICS. The first is to hide the content of messages and system data. The second use of encryption is authentication, i.e., did this firmware update come from the correct source? Has it been tampered with? Is this ICS module genuine hardware? Did any new user logic for the controller come from an authorized source? Does this set point change from an authorized source? The use of encryption will provide not only unambiguous answers to these and other questions but more importantly, it can ensure that messages, code changes, and operator actions that flunk authentication are rejected. Encryption makes an ICS cyber-attack significantly more difficult.

ICS certification has three elements:

• Communication robustness testing (CRT)
  CRT examines the capability of the ICS to adequately maintain essential services while being subjected to normal and erroneous network protocol traffic at normal to extremely high traffic rates (flood conditions). These tests include specific tests for susceptibility to known network attacks.

• Functional Security Assessment (FSA)
  FSA examines the security capabilities of the ICS, while recognizing that in some cases security functionality may be allocated to other components overall system environment.
  
  
• Software Development Security Assessment (SDSA)
  SDSA examines the process under which the ICS was developed.

ISA/IEC 62443 and Security Level Requirements

The ISA/IEC 62443-3-2 standard requires that plant be broken down into security zones that are interconnected via conduits. Then, using the security risk assessment process, security levels are assigned to different zones and conduits based on the potential consequences should an attack objective be achieved within that zone. Different sets of countermeasures are required as a function of security level (1 through 4) which are cumulative and increases with each level. Although security level capability applies to the zone and conduits, ICS that exist within that zone shall also have security level capability certification.

SL1 prescribes capabilities to protect components from coincidental or casual access, misuse or manipulation of the component. Not all products in a zone need to be certified – for example, generic product capabilities may cover unintentional attacks and can therefore be used in SL 1 zones. However, SL2 zones requires certified products with additional security capabilities, like products that can uniquely distinguish between individual human or non-human users, authenticate themselves to an overall system into which they have been integrated, close inactive communication sessions that remain open as potential attack vectors, and verify the source of communications to the component - all ways to limit sources for network attacks. This means that a ICS certified to SL2 meets more of the cybersecurity requirements and provides higher levels of cyber hardening than SL1.

A recent white paper makes a strong case for SL2 as a minimum requirement for commercial off-the-shelf (COTS) products – read the paper or a summary to learn more.

ISASecure Certification

The ISASecure program is a certification scheme certifying off-the-shelf automation and control systems to the ISA/IEC 62443 series of standards. Product assessments are conducted by a global network of ISO/IEC 17065 accredited ISASecure certification bodies. ISASecure certification specifications are developed by a balanced membership including end users, suppliers, tool suppliers, cloud providers, and automation suppliers. ISASecure was founded in 2007 and offers the following certification schemes:

• Component Security Assurance (CSA) - Certification to ISA/IEC 62443-4-2
• IIoT Component Security Assurance (ICSA) - Certification to ISA/IEC 62443-4-2
• System Security Assurance (SSA) - Certification to ISA/IEC 62443-3-3
• Security Development Lifecycle Assurance (SDLA) - Certification to ISA/IEC 62443-4-1
• ACS Security Assurance (ACSSA) - Certification to ISA/IEC 62443-2-1, 2-4, 3-2, and 3-3

Conclusion

ICS restrict the ability for operators to make software changes or add security software after installation. This limits the ability to implement countermeasures, and in some cases leaves them vulnerable to attack. So, it is essential to build security into ICS starting with the manufacturers. Building in capabilities for classic countermeasures like encryption, authentication, integrity verification, intrusion prevention and secure update capabilities can provide opportunities for significant security improvements.

International standards such as ISA/IEC 62443 and established conformity assessment programs like ISASecure provide requirements for the secure development lifecycle and security capabilities that can be adopted to support built-in security. Independent certification to relevant parts of ISA/IEC 62443 can provide confidence in the inherent security of ICS.