NOTE: This article is not only for organizations that have already been hacked… The IEC 62443 is a generic standard recognized as applicable across critical sectors such as manufacturing, energy, transportation, healthcare, and many others.
This article is the fifth episode of a series of 8, covering some of the best practices to be implemented by any organization aiming to meet the State-of-the-Art in Cyber Security for industrial and automation control systems. In that context, Security Hardening is considered as a key topic to ultimately prove that defense-in-depth strategy is followed and implemented by integrators. Activities included under this topic are mainly addressed by the eighth practices of ISA/IEC6244-4-1 dedicated to security guidelines, as well as by the ISA/IEC62443-2-4 part describing requirements for integration and maintenance service providers.
From an ISA/IEC62443 standpoint, Security Hardening practices include every activity related to the hardening of a product during post-development phases (e.g. installation, maintenance…). Exceptions are made on secure operation and secure disposal which are described through specific practices, respectively SG-5 (ISA/IEC62443-4-1, section 12.6) and SG-4 (ISA/IEC62443-4-1, section 12.5). A compliant Secure Development Lifecycle from an organization should therefore integrate such aspects through the creation of relevant documentation for product users / integrators on the way to securely integrate, use and handle a product.
This requirement recognizes that the security policies and requirements for customer sites are often different, and as a result, instructions for securely integrating the product into the customer site, configuring it appropriately and maintaining its security are necessary. Formally, a specific requirement describes those activities as follow:
As already mentioned through previous episodes of this blog series, defense-in-depth strategy is key for handling cyber security and reducing cyber risks. There are no bullet-proofed solutions therefore the multiplication of defensive technics and barriers is considered as the best approach for minimizing cyber threats all along the supply chain, right from the secure development of single components to the secure operation of complete and more complex solutions and systems. In that context, security hardening guidelines represent one of the main sets of documentation to be provided by component/system suppliers for ensuring a secure integration and maintenance of products.
Security hardening as a common topic for OT and IT
Indeed, security hardening is a known topic for IT systems but considered as even more important for OT targets where potential consequences of cyber-attacks are usually more critical. Implementation of hardening technics could differ from IT to OT but approaches are similar and the ultimate goal is the same: Exploit the security capabilities of a target, in a given environment, in the most efficient way to reduce the remaining attack surface and reach a reasonably secure posture.
Security hardening technics should be considered for any component/subsystem of a complete “system” or solution. Based on those consideration from multiple source, it is the responsibilities of the integrators and/or users to follow best practices described by product suppliers in the specific environment. This principle is the reason why SG-3 from ISA/IEC62443 requires from product suppliers to provide documentation that include guidelines for such purpose.
Typically, those guidelines specify the processes to be followed by integrators and/or users for integrating a specific target in an environment by taking care of several critical aspects, such as:
- Interfaces with other subsystems or components
- Product configurations
- Use of security-related tools to interact with the product
- Security maintenance activities (e.g. updates/patches handling)
- Incident notifications
Let’s use an example…
If we are thinking about the manufacturing of an industrial controller considered as a PLC (Programmable Logic Controllers), what does security hardening guideline means in the context of this product?
Regarding the component itself, it would be considered as an embedded device under the terminology ISA/IEC62443-4-2. A PLC is a device that typically resides usually on the lower levels of the automation system (such as level 1 and 2 of the Purdue Enterprise Reference Architecture as described in ANSI/ISA-95.00. see figure below). PLCs commonly use ruggedized hardware to allow for operation in industrial environments and are commonly based on commercial real-time operating systems (RTOS). Increasingly smart sensors and actuators are also receiving forms of process control capability. PLCs and smart sensor/actuators are programmed to execute control logic based on inputs from the process (obtained from instrumentation like traditional temperature sensors, pressure sensors, vibration sensors). The control logic’s output is used to control the industrial process (through actuators such as valves, pumps). The programming is usually done using engineering software commonly running on host devices (for example, laptops or PC workstations).
you can find below some examples of topics to be provided by the PLC manufacturers for allowing product integrators and/or users to harden the product in a specific environment, based on top-level aspects mentioned previously:
- Interfaces with other subsystems or components
- How to securely integrate the product in a complete system, using relevant API’s and protocols?
- What are the requirements/assumptions made by the product’s supplier regarding other dependent subsystem (e.g. authentication servers to be deployed and referenced for handling AAA features on products)?
- Product configurations
- What are the features for supporting asset identification and inventory on system level?
- What are the assumptions on physical protections?
- What are the general contributions to product’s defense in depth strategy?
- Use of security-related tools to interact with the product
- What are the instruction recommendations from the product’s suppliers regarding the use of tools for administration, monitoring and other interrelated activities?
- Security maintenance activities (e.g. updates/patches handling)
- What is the processes to be followed by end user / integrators for being informed about updates/patches?
- How to securely deploy an update/patch?
- In case of deployment error, how to execute secure rollback functions?
- Incident notifications
- Communication channel with suppliers (e.g. contact points, tools, templates), could be considered as out of scope of hardening technics but addressed by other ISA/IEC62443-4-1 requirements?
- Process for incident / security-related issues notifications and reporting?
This list above is non-exhaustive but should help you to think about the importance of such documentation, in the perspective of the cyber security management of a product across its entire lifetime.
What about certifications ?
It is important to be aware about the fact that, if a secure product is integrated in a solution without any specific security hardening guideline, the security capabilities of the product would not be rightly exploited and could therefore lead to weaknesses on system level. This consideration is the key reason why product certification according to ISA/IEC62443-4-2 also requires some evidences of SDLC establishment, and therefore baseline of ISA/IEC62443-4-1 compliance. A complete SDLC certification according to IEC 62443-4-1 would not be required, prior to any product certifications according to IEC 62443-4-2, however a subset of SDLC practices shall be audited anyway in the scope of product certifications.
It is crystalized through IEC 62443-4-2 via a so-called Common Cyber Security Constraints (IEC 62443-4-2, section 4.5, CCSC-4) requiring that “any secure components shall be developed and supported following the secure product development processes described in IEC 62443‑4‑1”.
Currently, the best approach that could be taken by organizations on the road to IEC62443 certification would be the following:
- Evaluate your current posture against standardized requirements through gap analysis
- SDLC certification according to IEC 62443-4-1 for getting an organizational recognition against the State-of-the-Art for secure development
- Products certifications according IEC 62443-4-2 for ultimately proposing products meeting the State-of-the-Art for technical security capabilities.
This approach would allow you to reduce costs of product certifications by firstly certifying your development processes, and getting a organizational-level recognition, and then becoming already compliant with initial product requirements
Conclusion
Even if 62443 compliance is not an ultimate target, security hardening related practices should be considered as one of the main activities and documentation to be provided to product users and integrators for ensuring complete cyber security loops across any levels of IACS ecosystems (incl. Asset owners, service providers, System suppliers, Component suppliers).
If you have any questions about security hardening practices, documentations and/or any other certification criteria, please do not hesitate to contact our cyber security specialist: Kilian Marty