Good practices of safe development in industrial control

Posted date 26/12/2024
Author
INCIBE (INCIBE)
Good practices of safe development in industrial control blog cover

Among the priorities of the most widespread industrial cybersecurity standards and regulations, a new, more comprehensive approach to industrial control equipment can be seen. Standards, such as IEC 62443, increasingly emphasize cybersecurity risk management throughout the life cycle and supply chain of industrial equipment. This presents several advantages for those following the standards:

  • Prevent cybersecurity vulnerabilities. These problems were usually corrected retroactively, requiring more resources and less effective solutions.
  • Transfer responsibilities from the end customer using the product to suppliers with greater knowledge and ability to act on the equipment they supply.
  • Create opportunities for collaboration between customers and suppliers in cybersecurity.
  • Highlight the cybersecurity capabilities of industrial equipment as product benefits, making them attractive qualities that can be included in product marketing, while promoting cybersecurity awareness in the marketplace.

However, despite the advantages of incorporating cybersecurity from the beginning of the life cycle and the requirements of new regulations, it is observed that the vast majority of manufacturers still do not know how to address these new measures. Especially, in one of the most critical stages of the process, the product development stage, where they move from the design to the actual product, develop the code, build the hardware and establish the connections between components necessary for the product to function.

To help in this critical stage, this article aims to help solve this discrepancy between criticality and lack of awareness, providing information and advice on good practices for safe development and its application to industrial control equipment.

Cybersecurity risks during development

The first step in the process of safe development of industrial equipment is to answer the question: What should we protect ourselves against during the development of industrial equipment? 

Two types of risks can be distinguished during the development stage:

  • Organizational risks: those that affect the organization's development processes.
  • Risks of the product under development: risks against which the equipment under development must defend itself throughout its useful life.

Organizational risks are managed through the usual cybersecurity procedures that an organization should establish internally and should not be forgotten during the development stage. 

On the other hand, product risks are the focus of good development practices. Addressing these risks during product development, when product features can still be altered and refined, is much more effective and efficient than doing so retroactively.

These risks must be identified and modeled by the company before the start of the development process. This exercise generates the main source of information that will feed the definition of security measures for the new product.

Best practices for secure cyber development

The following section contains recommended safety practices, selected and commented on for their relevance and contribution to the safety maturity level of industrial equipment development. For greater readability, they have been classified in (approximate) chronological order in which their application should be taken into account during development.

Product ecosystem

The product must have, from the beginning, an internal architecture that complies with the principles of:

  • Safety by design: the passive elements of the architecture must contribute to the safety of the product.
    • Safety must be taken into account as a fundamental factor from the moment the product is conceived.
    • The number of different elements required should be reduced, leaving only those that are essential. This applies to hardware, software and the connections involved.
    • If existing components on the market are to be used, it is worthwhile to look for components with safety certificates or at least with safety measures relevant to the identified risks.
    • If the components are self-developed, security requirements should be defined and included from the outset, not as patches at a later date.
       
  • Security in depth: creating a multi-tiered architecture that makes access to critical elements difficult. 
    • Entry points to the product (web services, communication channels, connection ports...) must be identified and protected.
    • There should be no direct paths between entry points and critical elements. 
      • If the product has several components, the critical components should be segmented.
      • If the product is a single computer, segmentation should be defined in the internal logic or in the computer hardware itself (execution privileges, different connection interfaces, etc).
  • Least privilege: the equipment used must allow restriction of access to functions and information, according to the needs and role of the users.
    • Role and privilege management capabilities should be included in all products that require interaction with users.
    • Because of the nature of industrial equipment, it is likely that we do not have the technical capabilities for complete management. But these inherent limitations should be identified in order to seek alternative solutions. 

Product Operation and logic

The measures to be applied in this section will depend to a large extent on the type of product, but general principles of application can be identified for all case:

  1. Define product capabilities. In industrial environments it is essential to be able to rely on the equipment to behave as expected. The operator of a robotic arm has to be sure of the movement, the robot is going to make before starting it, otherwise it could cause accidents and physical damage. Therefore, it is useful to answer what are the capabilities of the product and what are its limitations.
  2. Apply safety limits. There are products that will have limits that, for safety or functionality, should not be exceeded in any case, such as speed of movement, extreme temperatures, etc. These cases must be implemented in the product in such a way that they cannot be altered or manipulated.
  3. Ensure deterministic actions. For those variables or functions that must be manipulated, it is important to guarantee to the user that each product is known for each concrete action. A movement command to a robot should position the robot at the appropriate coordinates, setting the temperature in an oven should heat it to the desired temperature, etc. In this sense, not only the final result should be defined, but also how it is reached (speed, trajectory...). Outputs should always be deterministic (within their defined tolerance ranges), sources of ambiguity, boundary cases or unexpected inputs should be taken into account during development and solved before going into production.
  4. Interruption and shutdown. The execution of the product should be able to be stopped manually, or by safety elements, at any time. It is not enough that this stop is properly executed (the equipment must not restart on its own, no function must have more execution authority than the stop, etc.), it must also be completely safe. Moving elements must decelerate safely, while the stop on clamping elements (vacuum pumps, tongs, hooks...) or temperature control elements, the safe performance will depend on their condition. For example, an overhead crane moving a load, in case of a stop, should not release the load without control.
  5. Signing and version control. A record of the versions developed and deployed must be kept. Especially in the case of software, since it undergoes many modifications throughout its useful life. In addition, the software must have authorship signatures and change logs. Finally, it is advisable to have integrity controls (e.g. code hashes checks), both periodically and during software changes or updates, to avoid manipulations.

Validation of input data

Once it has been defined how a product will operate, it is necessary to control how users will interact with it. In addition to the aspects already introduced previously, such as the principle of least privilege and the need for deterministic actions, user input validation is considered an essential priority for user interaction.

This process consists of verifying each of the data entered, by users or by other teams. The product must verify that the data has the expected format and information, i.e. if a value is given to a numeric variable, the value must be a number within the defined range; if a date is scheduled for the end of a run, it must be valid and comply with everything defined in the specification.

These controls must be applied for all modifiable variables and all fields where a user can enter data, from the login and password fields of a web application to the loading of new logics to a PLC. 

Records

The product must have internal capabilities to collect information on its status, performance and interaction with other equipment. In general, all those aspects that may be relevant during the review of an equipment after a cybersecurity incident.

It is necessary to define where these logs will be stored, what types of information they will collect and how they will be labeled with the appropriate date and time. It should also be taken into account that the extraction or monitoring of these logs may be required, so it is recommended to make the equipment compatible with technologies that allow it, such as data buses or monitoring tools.

Test and verification

The verification of security functions cannot be postponed to the end of development, periodic test points should be defined throughout development.

A good starting point for defining a test plan during development is to test measures as they are implemented. In addition, tests should be performed for each of the threats and risks identified during development. It should also be defined which tests validate the performance of the product for each threat modeled during the risk analysis and run them before the end of development. 

Another good practice would be to define test stages during development to perform general tests and drills. These should include pentesting exercises and simulations of real attacks to get a complete picture of the product's security.

In general, all included development measures and principles should be tested throughout and after the development process. To define which tests should be performed for each, it is advisable to refer to recognized tools, such as the  Mitre ATT&CK, database, which can provide information on the attack techniques against which the measures should be effective.

Conclusions

In general, when creating new industrial equipment, it is a good idea to think of it as an individual item that, as far as possible, should be able to protect itself.

Traditionally, industrial users, at best, relied on network-level security measures; while, at worst, cybersecurity was not considered relevant. However, as attackers gain knowledge and experience in affecting industrial environments and, in response, regulations become more demanding; considering component-level security for those more demanding environments is becoming increasingly relevant. 

A clear example of these requirements can be seen in the IEC 62443 standard, where an entire document (IEC62443-4-1) is dedicated to safe development requirements.

The safe development of industrial equipment is the most effective tool to meet these new requirements. Ensuring that equipment is safe from the start and throughout its life cycle guarantees a higher level of safety with a minimum expenditure of resources and loss of efficiency.