Since the U.S. water treatment facility incident in February 2021, many questions have been raised around awareness and countermeasures that can prevent similar incidents and reduce the risk for the public.

At first glance, security programs based (for example) on ISA/IEC 62443-2-4 addressing maintenance would have at least three or four requirements addressing similar remote access issues: SP.07.03BR, SP.07.04BR, and other requirements; as well as mandating the capability to identify every remote connection, its purpose, its location, and its ID from the remote client; and obtaining approval from the asset owner prior to each use. In addition, SP.03.09BR asks about enabling the capability to ensure that all commands are valid, initiated, and/or approved by an authorized person in the approved direction. Components and systems suppliers following the ISA/IEC 62443 series, from Part 4-1: Secure product development lifecycle requirements, would have use cases covered for situations like this. 

Incidents like the recent one at the water treatment facility are fully preventable. We need responsible asset owners and a committed supply chain.

How to Build Secure Systems

We are used to hearing that security is only as strong as the weakest link. An immediate thought is that we need to select components with built-in security capabilities to build our system (or system of systems) based on the risk tolerance of the organization. In an ideal world—in a green field situation—it sounds like the perfect solution.

We are evolving from a reality of legacy components that may not have all the necessary built-in security capabilities. Even so, those capabilities needed to mitigate risk can be implemented by integrating security capabilities across the system or sub-system to which these components belong; adding the procedural steps to configure, validate, test, maintain, and respond to events that cause stress and disruption; and aligning organizational and technical capabilities to achieve an effective and efficient operational risk management.

Building resilience is the way to incorporate an ability to adapt to risk—by aligning organizational and technical capabilities to achieve an effective and efficient operational risk management. It is still a common belief that business continuity is just a technology problem that the technology professional in the organization has to solve by adding redundancy and proper backup and recovery planning to IT or OT. Legal, financial, communications, human resources, and organizational training are all aspects that have to be considered while building operational resilience for an organization. Policies, processes, and procedures coordinate the operational activities performed by people and technology with a specific organizational mission.

Sustainability of these organizations is dependent on the proper identification of critical technology and people, as well as the associated protection mechanisms, to keep the focus on the organizational mission—based on a defined and known risk appetite and tolerance.

In the same way that people are hired, get trained, get deployed to perform services across the organization, and get further developed ("upskilled") over time to fit their purpose, technology has its own lifecycle. Hardware and software systems are created, planned, designed, developed (own or externally by a third party), acquired or integrated, implemented, tested, commissioned, operated, and maintained.

Early identification of the risks of the critical process to be automated allows the possibility of planning an efficient defense in depth strategy—fit to purpose—since the inception of the components, sub-systems, and systems enable operational risk management. Being able to translate the security needs early in the system development lifecycle helps the organization meet its operational goals.

To ensure the consistency of the operational risk management process over time, risk tolerance and security requirements need to be updated based on changing conditions in alignment with the business organization. Technology and procedures demand the same maintenance during the operation phase.

From the perspective of asset owners, the expectation is that their system providers and the associated supply chains would acknowledge the resilience requirements and their dependencies from conceptual development to decommissioning.

The ISA/IEC 62443 series picked up the glove. The secure development lifecycle defines security requirements based on market and industry needs, going through a full threat model to properly allocate security functions by either building them into components, integrating them into systems, or performing manual or semi-manual processes to be applied during the life span components, sub-systems, and systems.

Comparing the assumptions made during the threat model analysis with the actual deployment scenario is a fundamental step to balance the resilience objectives from an asset owner’s organization and the components, sub-systems, and systems offering. Understanding where a potential attacker can find entry points to a system is our first layer of this kind of analysis. Next, assuming the attacker is already in, one must determine how to contain the damage and insert more hurdles lining up layers of defense to keep risk tolerance in check.

Integrating, configuring, commissioning, validating, testing, verifying, and maintaining a defense in depth model throughout a 20-to-30-year lifetime demands commitment from the system supplier. This is the challenge that the ISA/IEC 62443 series takes into consideration. Consumer goods usually have a lifespan of just a few years—they are not designed to have a further production usage. Hence, the long-term commitment from the supply chain may not be there.

Suppliers and asset owners are investing deeply in their path to digital transformation. Digitizing the operating model and forming alliances with external partners through digital channels demands readiness from the organizational and technological perspective.

Cybersecurity—and ultimately, building a resilience model—are prerequisites for moving forward in the complex execution of such an endeavor.

Interested in reading more articles like this? Subscribe to the ISAGCA blog and receive weekly emails with links to the latest thought leadership, tips, research, and other insights from automation cybersecurity leaders.