Connectivity has brought seismic change to embedded applications. The shift away from static, fixed function, device specific applications to a “cloud” connected world has brought with it a plethora of opportunities to facilitate monitoring, upgrading, enhancement, and supplementation.
On the downside, vulnerabilities in any points of a connected system accessible to unauthorised users (collectively the “attack surface”) potentially allow bad actors to compromise it. Worse, these aggressors need not have any particular interest in either you or your system. Most of the time, they will be probing anything and everything for vulnerabilities, motivated by anything from financial gain to the thrill of the chase. And their success and your bad luck can cause immeasurable harm to your products and your company – perhaps resulting in liability claims, compliance fines, reputational damage, and frantic customers seeking support.
The term “cybersecurity” (sometimes cyber-security) refers to the practice of protecting systems, networks, and data from digital attacks, unauthorized access, damage, or theft. It involves implementing measures and technologies designed to safeguard the integrity, confidentiality, and availability of information. Key aspects include identifying vulnerabilities, monitoring for threats, and responding to incidents.
Cybersecurity in the context of embedded systems involves protecting specialized computing devices that are dedicated to specific functions within larger mechanical or electrical systems. These systems, which can be found in applications like automotive controls, medical devices, industrial machines, and IoT devices, are often resource-constrained and operate in real-time environments. Ensuring their security involves addressing unique challenges such as limited processing power, memory, and the need for real-time operation.
No single defense of a connected system can guarantee impenetrability; however, applying multiple levels of security ensures that if one level fails, others stand guard. One popular analogy for this defense-in-depth approach is that of a medieval castle equipped to defend its inhabitants from siege by means of a whole host of towers, curtain walls, moats, mottes, portcullises, drawbridges, murder holes, and other devious mechanisms. And yet, despite all these defenses, castles did get compromised by aggressors.
There are also many different defenses available to connected embedded systems developers. Like castle defenses, all are helpful, but none is impenetrable. They include:
LDRA’s primary contribution to cybersecurity concerns secure coding, although the test capabilities of LDRA tools can also be used to exercise other defense mechanisms.
Secure coding refers to the principle of code design that adheres to the highest security standards and best practices. It prioritizes security and helps safeguard code from known and unknown vulnerabilities.
Secure coding places the responsibility for code security on the developer rather than a security team.
As connectivity becomes more prevalent across the safety-critical sectors, the need for guidance on the application of appropriate defenses has increased proportionately.
Security coding standards aim to ensure that software is developed to minimize vulnerabilities and protect against potential threats. By providing guidelines and best practices, these standards help prevent common coding flaws, improve overall code quality, and ensure compliance with regulatory requirements. They play a crucial role in protecting data integrity and confidentiality by promoting secure practices throughout the software development lifecycle.
Examples of secure coding standards include:
The civil aviation authorities deal with cybersecurity concerns in embedded systems through the application of the Aerospace Security Framework which provides a holistic and cohesive approach to cybersecurity across the entire aerospace industry.
DO-326B/ED-202A and DO-356A/ED-203A are specific standards that provide detailed guidelines and methods for ensuring the cybersecurity and airworthiness of aircraft. DO-326B establishes the framework for managing cybersecurity risks in aircraft systems. DO-356A offers specific methods, techniques, and best practices for applying security measures, such as conducting security assessments, implementing protective measures, and validating security requirements.
Although many defense projects adopt civil aviation standards, there are sector-specific security standards too, many of which are associated with specific military organisations. For example, DISA STIGs provide detailed guidelines for configuring and securing various information systems and software used within the U.S. Department of Defense (DoD), with the AppSecDev STIG being of particular interest to embedded software developers.
In the automotive sector, until recently the ISO 26262 functional safety standard was supplemented by SAE J3061, “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems”. It served as a foundational document for the automotive industry to address the growing cybersecurity threats posed by increasingly connected and automated vehicles. SAE J3061 has now been superseded by ISO/SAE 21434, “Road Vehicles – Cybersecurity Engineering” which serves a similar purpose.
The ISA/IEC 62443 series is a wide-ranging collection of multi-industry standards for the secure development of Industrial Automation and Control Systems (IACS). It defines a set cybersecurity protection methods and techniques to defend industrial networks against cybersecurity threats. It categorizes these techniques to apply to all stakeholders including manufacturers, asset owners and suppliers.
Cybersecurity recommendations in the medical device sector include “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” from the FDA in the USA, and emerging initiatives include the European Health Data Space in the EU.
In the rail and GTS industry, the evolution from closed, wired isolated networks to open, interconnected networks has led to a new generation of threats. EN 50128 and the EN 5012x series only deal with cybersecurity indirectly (when such threats have implications for safety), and they provide no specific guidance on how to address them. For that reason, many GTS and rail projects have specified adherence to the IEC 62443 standard (discussed above).
CLC/TS 50701, “Railway applications – Cybersecurity” defines requirements and recommendations for cybersecurity within the railway sector. It aims to ensure that bad actors cannot compromise the RAMS characteristics of railway systems. The security models, the concepts, and the risk assessment process it describes are based on or derived from IEC 62443 series standards, adapted to a rail-specific context.
Standards relating to the development of secure software applications in space include the draft ISO/DTS 20517 “Space systems — Cybersecurity management requirements and recommendations”, and some elements of NASA Procedural Requirements NPR 7150.2D.
Although the advice offered within the different sectors varies in content, detail, and maturity there are many common themes. Verification and validation techniques are used to ensure that the mitigations are effective, many of which are underpinned by the LDRA tool suite.
The concepts embraced by the shift-left principle are familiar to individuals and teams developing safety-critical applications. For many years, functional safety standards demanded a similar approach. Consequently, many best practices proven in the functional safety domain apply to security-critical applications:
Undocumented requirements lead to miscommunication on all sides and create rework, changes, and bug fixes—as well as security vulnerabilities. To ensure smooth project development, all parts of the product and the process of its development must be understood by every team member in the same way. Clearly defined functional and security requirements help ensure that this is the case.
Such requirements are likely to define a complete system for V-model developers, and merely an iteration for those applying DevSecOps—but the principle remains the same. This is not to say that software can never be used as an “intellectual modeling clay” to create a proof of concept, but the ultimate result of such experimentation should be clearly defined requirements—and production code appropriately developed to fulfill them.
The IEEE Standard Glossary of Software Engineering Terminology defines traceability as “the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another.” Bidirectional traceability means that traceability paths are maintained both forwards and backwards Automation makes it much easier to maintain traceability in a changing project environment.
Figure 1: Bidirectional traceability
Forward traceability demonstrates that all requirements are reflected at each stage of the development process, including implementation and test. The impact of any changes to requirements or of failed test cases can be assessed by applying impact analysis, which can then be addressed. The resulting implementation can then be retested to present evidence of continued adherence to the principles of bidirectional traceability.
Equally important is backward traceability, which highlights code that fulfills none of the specified requirements. Oversight, faulty logic, feature creep, and the insertion of malicious backdoor methods can all introduce security vulnerabilities or errors.
It is essential to remember that the life cycle of a secure embedded artifact continues until the last example in the field is no longer in use. Any compromise of such an artifact demands a response, a changed or new requirement, and one to which an immediate response is needed—often to source code that development engineers have not touched for a long time. In such circumstances, automated traceability as facilitated by the TBmanager component of the LDRA tool suite can isolate what is needed and enable automatic testing of only the affected functions.
For development in C or C++, research has long shown that roughly 80 percent of software defects stem from the incorrect usage of about 20 percent of the language. To address this, developers can use language subsets that improve both safety and security by disallowing problematic constructs.
Two common subsets are MISRA C and Carnegie Mellon Software Engineering Institute (SEI) CERT C, both of which help developers produce secure code. The two standards have similar goals but implement them differently. The biggest difference is the degree to which they demand adherence.
In general, development of new code with MISRA C results in fewer coding errors because it has stricter, more decidable rules that are defined on the basis of first principles. The ability to quickly and easily analyze software with reference to MISRA C coding standards can improve code quality and consistency and reduce time to deployment. By contrast, when developers need to apply rules to code retrospectively, CERT C may be a pragmatic choice. Analyzing code against CERT C identifies common programming errors behind most software security attacks.
Applying either MISRA C or CERT C results in more secure code. The manual enforcement of such standards on a code base of any significant size is not practical, so a static analysis tool is required to automate the job.
An overview of the differences between MISRA C and CERT C is shown below. The TBvision component of the LDRA tool suite and the point product LDRArules can both help in that regard.
As discussed above, security-focused standards provide another piece of the secure development solution. In safety-critical sectors, such standards frequently complement those focused on functional safety. For example, ISO/SAE 21434 “Road vehicles – Cybersecurity engineering” complements the automotive ISO 26262 functional safety standard. The TBmanager component of the LDRA tool suite can integrate developer workflows for security-critical and functional safety concurrently, should the need arise.
Static analysis is a collective name for test regimes that involve the automated inspection of source code. By contrast, dynamic analysis involves the execution of some or all source code. The focus of such techniques on security issues results, respectively, in static analysis (or application) security testing (SAST) and dynamic analysis (or application) security testing.
There are wide variations within these groupings. For example, penetration, functional, and fuzz tests are all black-box DAST tests that do not require access to source code to fulfill their function. Black-box DAST tests complement white-box DAST tests, which include unit, integration, and system tests to reveal vulnerabilities in application source code through dynamic analysis.
Taint analysis is a key component of any cybersecurity strategy. It helps identify and mitigate security vulnerabilities by tracing the flow of potentially compromised data from outside the current domain. That information is leveraged to test checks and defence mechanisms in the code to ensure that the system is sufficiently protected from bad actors.
LDRA’s taint analysis solution goes beyond the static analysis of marked tainted data. It deploys static and dynamic analysis to mark tainted data, track data flow, identify potential security vulnerabilities, and report on vulnerabilities to be addressed. This comprehensive approach not only exposes the impact of rogue tainted data on the code but also offers a means to verify the effectiveness of existing security checks and defense mechanisms. Significantly, it also provides evidence of robust protection against dynamic attack vectors like SQL injection or Denial of Service, which cannot be adequately addressed through static means alone
All the security-related tools, tests, and techniques described here have a place in each life cycle model. In the V model, they are largely analogous and complementary to the processes usually associated with functional safety application development.
In the DevSecOps model, the DevOps life cycle is superimposed with security-related activities throughout the continuous development process.
Requirements traceability is maintained throughout the development process in the case of the V-model, and for each development iteration in the case of the DevSecOps model (shown in orange).
Some SAST tools are used to confirm adherence to coding standards, ensure that complexity is kept to a minimum, and check that code is maintainable. Others are used to check for security vulnerabilities but only to the extent that such checks are possible on source code without the context of an execution environment.
White-box DAST enables compiled and executed code to be tested in the development environment or, better still, on the target hardware. The code coverage facilities provided by LDRA tools confirmation that all security and other requirements are fulfilled by the code, and that all code fulfils one or more requirements. These checks can even go to the level of object code if the criticality of the system requires it. The LDRA tool suite supports taint analysis to help demonstrate that the system is adequately protected from the manipulation of data by bad actors.
The robustness testing offered by the TBextreme module can be used within the unit test environment offered by the TBrun component of the LDRA tool suite. It helps demonstrate that specific functions are resilient, whether in isolation or in the context of their call tree.
Fuzz and penetration black box testing techniques traditionally associated with software security remain of considerable value, but in this context are used to confirm and demonstrate the robustness of a system designed and developed with a foundation of security.
Video: Developing software to be compliant with IEC 62443-4-1
Article: Developing a safe, secure system: SEI CERT C versus MISRA C
Article: Process control cybersecurity gets serious with IEC 61508 and IEC 62443-4-1 in tandem
Webinar on demand: Application of IEC 62443 series for components and IACS
Webinar on demand: Process Control Cybersecurity Gets Serious: IEC 61508 & IEC 62443-4-1 in Tandem
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707