Venetian fortress Methoni in Greece

What does Secure by Design mean for Embedded Development?

Why is This Needed?

For a long time, the topic of information security was neglected, because in the market the demand for functional requirements is greater than the demand for non-functional requirements. Information security is a non-functional requirement, and implementing it costs money and time. Why should you do it anyway?

The advent of networked devices (IoT, IIoT, Things, etc.) means that devices that were previously secure by design in their intended environment (no connection to the Internet) are now no longer secure.

Where are we Today?

In domains that are already heavily regulated, such as medical, automotive, avionics, rail and finance, the relevant standards have already been adapted and information security is mandatory.

The call for (minimum) standards for all industries is growing. It is foreseeable that the area of information security will soon be regulated, as has already happened for EMC and functional safety.

Who Demands Secure by Design?

Standards, such as the EU Cybersecurity Act, IEC 62443, or medical standards 745/2017 (MDR) and 746/2017 (IVDR), require that the Secure by Design principle be applied to the development and operation of devices.

What does Secure by Design mean?

IEC 62443 has its own standards section that addresses this topic, namely Part 4-1: Secure product development lifecycle requirements.

The Medical Device Coordination Group also follows the Secure by Design approach with its recommended action MDCG 2019-16 (Guidance on Cybersecurity for medical devices).

The applied process model defines eight practices and pursues a Defense-in-Depth strategy.

Practices for a Secure Development Lifecycle (SDL)

All practices together define the necessary processes that must be in place and established to guarantee Secure by Design, and thus the Defense-in-Depth strategy, throughout the entire device lifecycle. The practices are often applied iteratively.

Further, IEC 62443 defines a maturity model, which is similar to CMMI to prove the fulfillment of the requirements regarding information security. The goal of the maturity model for the development organization is to demonstrate the quality of information security and for the device user to evaluate whether the quality is sufficient for the intended use.

Practice 1 - Security Management

Ensure that all security-related activities are planned, documented and executed throughout the lifecycle of the device.

To do this, it is best to create a security plan, in a similar way as a safety plan in functional safety.

Practice 2 - Specification of Security Requirements

Ensure that the information security requirements of the device and the assumed security context are documented.

At the beginning of the specification lies the creation of a specific threat model for the device. The goal of this model is to systematically identify potential threats, such as structural vulnerabilities or lack of appropriate safeguards, and derive the security requirements for the device. The requirements must take into account the entire life cycle, i.e. from development to decommissioning of the device.

It is essential that the model is regularly reviewed and updated as needed (e.g. in response to the emergence of new threats), even if the device itself does not change.

Documenting the assumed security context ensures that developers and users have the same understanding of what the intended use of the device is. E.g. it clarifies questions such as: Is there physical device protection? Is the device behind a firewall? This information helps developers make appropriate design decisions.

Practice 3 - Security by Design

Ensure that device information security is considered in all phases of development, i.e., from system architecture to detailed design.
Here, the focus is particularly on the internal and external physical and logical device interfaces, which must be identified and characterized.

Furthermore, several layers of defense (Defense-in-Depth strategy) must be provided. This means that each layer has an assigned responsibility and reduces the attack surface of the next layer. Each layer must assume that the underlying layer may be compromised. The design of the layers is based on the threat model (Practice 2) and follows a risk-based approach.

Up-to-date security-relevant technologies, such as Secure Boot, encrypted communication, etc., must also be applied.

Practice 4 - Secure Implementation

Ensure that security requirements for hardware and software are implemented correctly.

This is done using specifications (design specifications, programming guidelines, etc.) and reviews (peer review, static code analysis, etc.).

Practice 5 - Security Verification and Validation

Ensure that the device meets all security requirements and that all test activities are documented.

Security tests occur at various points in the development cycle and cover the following aspects:

  • Tests that all security requirements (Practice 1) are met
  • Tests of the effectiveness of threat defenses (e.g., testing each layer of a layered defense strategy)
  • Testing for known vulnerabilities (e.g., MITRE, OWASP)
  • Penetration testing (discovering vulnerabilities)

Tests can be automatic (unit testing, fuzzing, vulnerability scanner, etc.), manual (test lists, penetration testing, etc.) or combined.

Practice 6 - Management of security-related Issues

Ensure that all reported security issues are included and addressed according to the other practices.

Possible internal and external sources that discover and report security issues are:

  • Testers (verification and validation)
  • Suppliers of third-party components
  • Device users (integrators, service personnel, etc.)

Practice 7 - Security Update Management

Ensure that security updates are made available for a device in due time.

At a minimum, security updates must be regression-tested.

Practice 8 - Security Guidelines

Ensure that user documentation exists that describes how to securely configure, operate, maintain, and dispose of the device.

It is especially important that the user knows in what context the device can be used securely.

What do you need to do to Live Secure by Design?

For those who already have an established process landscape for development, such as CMMI or aSPICE, the step is small. Define processes for the new practices and add those processes to your process landscape. Train your staff and use lessons learned from your development projects to iteratively improve your information security processes.

If you don't already have an appropriate process landscape, this is the time to address it. No one can avoid the topic of information security anymore. And as outlined in this blog, processes are the be-all and end-all for Security by Design.

Do you need knowledge or support for creating development processes or implementing your development project? We are glad to support you!

Alois Cavelti

What is Your Opinion? Please comment here!

Keywords/ Tags


No Comments

What is Your Opinion?

* These fields are required

Share On

Let us discuss your idea/ your project