Developing safer, more secure software for Industry 4.0
Author : Steve Howard | SCA Product Evangelist | Perforce Software
01 December 2022
Industry 4.0 introduces the exciting concept of connecting people, machines & other physical assets into one seamless digital ecosystem. However, this means that, more than ever, there is massive dependency on software – particularly embedded software – and connectivity. And, while software & connectivity accelerate Industry 4.0’s potential, they also introduce more safety & security risks.
This article was originally featured in EPDT's H2 2022 IoT & Industry 4.0 supplement in the December 2022 issue of EPDT magazine [read the digital issue]. And sign up to receive your own copy each month.
As Steve Howard, SCA Product Evangelist at enterprise software development, configuration & lifecycle management specialist, Perforce Software explains here, the risks range from privacy concerns and supply chain logistics to damage to people, property and reputation. For example, a failure within a smart factory could negatively impact production, customers, manufacturers and products. Worse still, a failure of critical infrastructure or a potentially dangerous industrial system could cause large-scale disruption and even the loss of human life…
Concerns for the safe operation and potential impacts of industrial electronics have been around as long as industrial automation itself. What’s changing with Industry 4.0 is ubiquitous connectivity – and as a result, the exposure of these systems to the outside world, and therefore to potential malicious actors. Of course, for there to be a cyberattack on a software system, there needs to be a vulnerability – or more commonly, several vulnerabilities – that can be exploited. The vast majority of vulnerabilities and failure causing defects within software systems stem from the development or modification of the software itself. So, understanding where software fits across Industry 4.0 can be a useful starting point.
The cobots are coming: robotics, big data & IoT
A recent blog published by the National Institute of Standards & Technology (NIST) in the United States helpfully divides Industry 4.0 into four overlapping elements. The first of these is cyber-physical systems (CPS) and cobots. According to NIST, “cyber-physical systems are smart systems that include engineered interacting networks of physical and computational components”. CPS typically combine sensors and sensor networks with embedded computing to monitor and manage the physical environment. An example might be a pump or compressor, with computing and control components comprising sensors and actuators.
Cobots — essentially robots that interact with a human in a shared workspace — are being adopted to handle a variety of tasks, such as assembly and packaging, and like a traditional industrial robot, typically have a programmable mechanical arm. However, NIST’s blog notes that cobots’ “close coordination with humans requires a risk assessment to protect workers and equipment”.
The second element of Industry 4.0 identified by NIST is the combination of the internet of things (IoT) and big data. As a network of components and systems to connect and interact, the IoT is already highly dependent on software, as are the big data activities of collecting and processing data from all these physical objects to provide a rich mine of information for future improvements. NIST’s third element is cloud manufacturing (CMfg), creating a virtualised service-based set of resources and capabilities and, once again, is driven by software. The fourth and final element is automation, enabling greater efficiency, production scale and autonomy – and reducing human effort and risk. And again, much of this automation, today and in the future, will be written into software, rather than pure mechanics or electronics.
Considering all these elements, the size and complexity of the combined digital and physical landscape is immense. Size and complexity inevitably lead to challenges for the safety, security and reliability of systems. Similarly, the sheer number of endpoints — systems, apps, robots, sensors and other components, plus people — is vast, and therefore, so is the potential attack landscape. As NIST’s blog also notes, “With Industry 4.0, communications and cybersecurity cannot be viewed as isolated processes”. And software is the glue combining all these elements.
However, this increased focus on software is new territory for many traditional engineering and manufacturing firms. They are not software experts, let alone software safety and security experts. This is not a new problem: similar transitions have been experienced in other verticals, such as automotive, where over the past ten years, the average car has transitioned from a complex piece of mechanical engineering into a computer (or data centre) on wheels, with data and connectivity at the heart of everything. This same transition is now occurring in industry – and this is where domain experts and standards bodies can really help.
Coding guidelines for Industry 4.0
The IEC 61508 standard – Functional safety of electrical/electronic/programmable electronic safety-related systems – has been widely used in the development of safety-critical industrial controls for many years. Compliance with the standard encourages best practices to discover and eliminate design errors and omissions — defined as the safety lifecycle — and a probabilistic approach to account for the safety impact of failures within the systems. In general, IEC 61508 does produce higher quality, safer and more reliable systems. With the arrival of Industry 4.0, it now needs to continue to do that for ever larger, more complex and more connected systems at scale.
The IEC 62443 standard is intended to address this cybersecurity requirement for “operational technology in automation and control systems”. It provides a thorough and systematic set of cybersecurity recommendations. The standard is used to defend industrial networks against cybersecurity threats. Essentially, IEC 62443 will help protect Industrial Automation & Control Systems (IACS) from security breaches where, if a cyberattack is successful, external agents would gain access to sensitive data, disrupt or shut down the systems, and even cause entire industrial systems to break down. Part 4-1 directly applies to software development.
IEC-62443 Part 4-1 defines a secure development lifecycle (SDL) for the purpose of developing and maintaining secure products. This lifecycle includes security requirements definition, secure design, secure implementation (including coding guidelines), verification & validation, defect management, patch management and product end-of-life.
Coding standards, or guidelines, capture many person-years of expertise and act as blueprints for developing code that minimises ambiguity, complexity and confusion — greatly reducing the probability of introducing errors. Whether mandated as part of compliance with an industry standard, or simply for internal quality control purposes, coding standards build-in quality and security from the ground up.
Security-focused coding guidelines include the likes of CERT (Computer Emergency Response Team), CWE (Common Weakness Enumeration), OWASP (Open Web Application Security Project) and DISA STIG (Defense Information Systems Agency Security Technical Implementation Guides). The CERT C and CERT C++ coding standards are particularly suited to security for embedded software, which will account for the bulk of all software within industry 4.0. For example, the CERT C Rule ARR30-C: do not form or use out-of-bounds pointers or array subscripts. Such “out-of-bounds pointer” vulnerabilities could be used by an attacker to overwrite an arbitrary memory location with an attacker-supplied address, typically resulting in arbitrary code execution, which is why it is important to guard against them.
Since the application of coding standards, which can include hundreds of different rules, and cases of rules, involves significant manual effort, they are typically used in conjunction with a static code analysis (SCA) tool. SCA tools, or Static Application Security Test (SAST) tools within a security context, analyse software without actually executing the code.
Early static analysis tools performed only structural analysis of the software, checking for simple coding errors that would lead to issues or vulnerabilities — for example, the use of a hard-coded password or other credentials within a connection to an external resource. However, modern static analysis and SAST tools are capable of finding much more complex defects and vulnerabilities that traditionally only dynamic analysis of the software would have detected.
This is made possible by the advancement in whole-program dataflow analysis, meaning that in addition to those more obvious structural issues within the code, it is also possible to detect issues and vulnerabilities based on the control flow through the software, which account for many of the more complex rules from modern coding standards, like CERT, which would also be much more difficult to spot for the human code reviewer. Indeed, the IEC 62443 standard outlines the framework for how to enforce security standards compliance, and an important part of that framework is the use of static code analysis tools.
SCA and SAST tools detect software defects and vulnerabilities as early as possible within the development phase, ensuring maximum possible development productivity. Running automatically in background mode, the additional workload on developers is reduced, while providing the reassurance that they are creating secure code. SAST tools are therefore also a natural fit for Continuous Integration (CI) processes, where the same principals of detecting and fixing as early as possible also apply. And because static tests are typically very fast – in contrast to dynamic test execution times – it is possible to run them as part of every CI job for a new branch commit or pull request.
So, while Industry 4.0 expands the potential for software-related safety and security vulnerabili-ties, there are steps that can be taken to mitigate these. Industry standards, coding guidelines, SAST tools and simply engendering a more “safety-first” and “security-first” mindset during software development can all make a huge difference.
More information...
Contact Details and Archive...
