What Is Embedded Systems Security?

Embedded systems security is a design methodology, implementation, and commitment that companies embrace to limit the threat exposure of the devices they build and the data these devices generate. Security for embedded devices is a full lifecycle responsibility. It starts well before the first line of code is written, includes protection in case a device falls into the hands of attackers, and continues until a device has been decommissioned.

IDC estimates that by 2025, there will be more than 55 billion connected devices.

The First Security Step for Every Embedded or IoT Project Team

Every company should have a security policy in place before an embedded project is approved and started. A security policy is a written and agreed-upon strategy and plan to address the full lifecycle security needs of the product and its data, including design, testing, delivery, maintenance, and decommissioning at end-of-life. Project teams need to fully understand the risks associated with a security breach that impacts their product. In addition, security requirements need to be agreed upon for the individual devices, the communications between devices, the network, and the data.

The CIA Triad and How It Contributes to an Embedded Security Policy

Similar to IT systems, an embedded security policy uses the CIA triad as a model for policy development. The CIA triad defines the principles needed to protect a device from unauthorized access, use, disclosure, disruption, modification, or destruction. This model helps development teams think about the different aspects of security for their project. The CIA acronym stands for confidentiality, integrity, and availability.

CIA Triad

The CIA triad helps define security needs for embedded systems.

Confidentiality

Confidentiality implementations are used to protect the privacy of data in embedded systems. This includes data in motion, data at rest or stored on the device, data being processed by the device, and data passing to and from the device.

Integrity

Integrity implementations ensure that the embedded device data has not been modified or deleted by an attacker. This includes data being generated or consumed by the embedded device as well as its programming data (the operating system, applications, configurations data, etc.).

Availability

Availability implementations ensure that an embedded device performs its intended function. This means an attacker cannot change a device’s intended functional purpose. This is of paramount importance to devices that perform life- or mission-critical tasks.

A security assessment provides a systematic approach to defining protection for the various assets of a project. Wind River® Professional Services offers security assessments for embedded customers starting a new project; these assessments include a variety of security characteristics:

  • Wind River uses industry best practices for continuous integration and DevOps to build, test, and release software.
  • Wind River is the only Linux vendor using OpenChain to certify our compliance. OpenChain is a tool that certifies and validates the open source license compliance used in a company’s distribution. This is important because, in the event of an audit, you will be able to demonstrate supply chain integrity.
  • Wind River acts as your insurance policy for compliance for your Linux-based product deployments.
  • Wind River is the only edge Linux with ISO 9001–certified development and release processes.

» Learn more

Security for Today’s Embedded Systems

As embedded systems, IoT devices, and the intelligent edge grow in numbers of deployments and new use cases, so does the attack surface and potential for security breaches. Every connected device, from small IoT home thermostats to the most sophisticated systems of systems, holds one or more potential points of entry that can be exploited by a cyberattack. With billions of devices already connected and tens of billions more coming, securing devices and protecting the data they generate is imperative.

In the embedded industry, there is a high degree of trust that companies are adhering to and implementing the most up-to-date standards for security requirements and functionality. For embedded systems with mission-critical and safety-critical applications, a comprehensive and full lifecycle security architecture is essential. Without a security-first policy, no device can be truly secure and remain secure over its deployed lifetime.

The Five Distinct Security Lifecycle Workflows

  1. Security for software development

    The software development infrastructure, where code is developed, tested, and compiled, requires extra security safeguards to ensure that there are no opportunities for either internal or external malicious actors. Many embedded developers use DevOps tools and building blocks from multiple sources. These tools and building blocks should come only from trusted sources and should include a software bill of materials. The components of the development environment should be actively monitored for CVEs and events that violate the system’s security policy. In addition, the development infrastructure should provide strict identity management and access protection to authorized individuals only. Privileged actions within the system should require multiple parties’ approval and performance.

    software development

    Designing a secure embedded system is a full lifecycle process, starting before the first line of code is written.

  2. Security for Devices — Hardware and Operating System Software

    The software and hardware used for embedded devices can include built-in security functionality. Some of the most commonly enabled hardware security features include secure boot, attestation, cryptographic processing, random-number generation, secure key storage, physical tamper monitoring, and JTAG protection. To fully leverage the hardware features, operating system software requires device drivers specific to the architecture of the underlying processor.

    Operating system software can also come with built-in security functionality. The VxWorks® RTOS includes built-in security features for secure boot (digital signed images), secure ELF loader for digitally signed applications, secure storage for encrypted containers and full disk encryption, kernel hardening, and much more. (See the VxWorks datasheet for a full list.)

    The Linux operating system also provides a number of security packages developers can use to help secure their OS platform build. Wind River Linux, a commercially provided Yocto Project–based build system, includes more than 250 verified and validated security packages. The Linux operating system can also be hardened to provide anti-tamper and cybersecurity capabilities.

  3. Security for embedded applications and container-based applications

    Embedded applications are the software designed to perform the function or specific task of an embedded system. Embedded applications run on top of the embedded operating system. Even if the underlying OS is secure, applications can require additional security features, including security testing, the use of code-scanning tools to improve security, and constant monitoring and prompt fixing of security issues.

    Container-based applications are starting to be used in embedded systems. These applications are constantly processing data, generating log files, and caching files. Application of critical security controls are put in place to ensure that application activities are not malicious.

  4. Security to protect data

    Embedded systems, IoT devices, and intelligent edge systems all process, store, and transport data. Mission-critical and safety-critical applications rely on the integrity of the data to perform intended functions, so it is essential that the embedded system has the right security functionality to prevent data leakage. This means the data, whether in motion, at rest, or in use, is fully encrypted and protected.

  5. Security services

    Security is an ongoing effort for embedded systems. It is a full lifecycle activity, from design to decommissioning. For many companies, monitoring and maintaining a device’s security posture for its full life can be best served by leveraging a third-party entity. Managed security services and security as a service are quickly becoming viable options for resource-constrained teams to get the help they need to detect and respond to threats, continuously monitor and analyze deployment operations, and make data-driven decisions to prevent attacks.

The Difference Between Embedded Security and Cybersecurity

Embedded security is designed to protect the components and software of the device. It includes features to protect the hardware, operating system, application, and data. Cybersecurity refers to additional security features that protect a device from network-initiated attacks. Both forms of security are necessary for embedded systems, IoT products, and intelligent edge devices.

Sources of Embedded System Security Standards and Requirements

embedded security

Both embedded security and cybersecurity are necessary for reliable embedded device performance across a range of industries.

Department of Defense (DOD)

The DoD provides guidelines for both device security and cybersecurity.

Food and Drug Administration (FDA)

The FDA provides cybersecurity best practices for medical device manufacturers at www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity. Proof of meeting security requirements can be required to get FDA approval of a connected medical device.

National Institute of Standards and Technology (NIST)

NIST provides security standards and guidelines for a variety of embedded segments, including electronics, energy, manufacturing, and transportation.

Federal Information Processing Standards (FIPS)

FIPS are U.S. government computer security standards specifying requirements for cryptographic algorithms. FIPS 140-3 is commonly followed in the embedded industry.

Security Technical Implementation Guides (STIGs)

STIGs are configuration standards consisting of cybersecurity requirements for specific technologies.

How Can Wind River Help?

Wind River provides a comprehensive security framework for the entire lifecycle of an embedded device. The framework includes a combination of security technologies and services and provides enhanced security capabilities for the development environment, DevOps pipeline building blocks, built-in operating system security features, OS and application hardening, data encryption, and ongoing vulnerability monitoring and fixes.

VxWorks

The market-leading real-time operating system includes numerous built-in security features to protect the confidentiality, integrity, and availability of an embedded device. These features help customers achieve purpose-driven critical safety certifications and standards required for commercial deployment approval.

» Learn more

comprehensive security

Wind River offers comprehensive security for the entire embedded device lifecycle.

Wind River Linux

The leading commercial Linux build system for embedded systems, Wind River Linux includes hundreds of validated and verified security packages. Wind River Linux is fully supported and comes with active monitoring and fixes for CVEs.

» Learn more

Wind River Helix Virtualization Platform

Wind River Helix™ Virtualization Platform consolidates multi-OS and mixed-criticality applications onto a single edge compute software platform, simplifying, securing, and future-proofing critical infrastructure solutions in the aerospace, defense, industrial, medical, and automotive markets.

» Learn more

Wind River Simics

Wind River Simics® is a full-system simulator of hardware and complex electronic systems. Simics can be used to test security vulnerabilities and security breach scenarios in a safe and controlled environment.

» Learn more

Wind River Professional Services

Professional Services provides deep industry experience to plan and design security into the full lifecycle of embedded systems.

» Learn more

Embedded System Security FAQs

What is embedded systems security?

Embedded systems security refers to the measures taken to protect embedded systems from unauthorized access, modification, or destruction.

What are some security risks associated with embedded systems?

Security risks associated with embedded systems include malware, hacking, physical attacks, and software vulnerabilities.

How can embedded systems be secured?

Embedded systems can be secured by implementing encryption and authentication measures, limiting access to critical functions, implementing secure boot processes, and regularly updating and patching software.

Why is embedded systems security important?

Embedded systems are becoming increasingly integrated into our daily lives, and they control critical functions in industries including healthcare, transportation, energy, and more. Security breaches in embedded systems can have severe consequences, including financial loss, privacy violations, and even physical harm. Securing embedded systems is essential to protect individuals, organizations, and society as a whole.

Is my embedded design secure?

A determination of whether your embedded devices are secure is based on the technology used and the operational environment. The security assessment identifies the assets of the system, the vulnerabilities of and threats to those systems, and the mitigations required to protect the assets from the vulnerabilities.

What do I need to do for Common Criteria evaluation?

Common Criteria (CC) is also referred to as the Common Criteria for Information Technology Security Evaluation. It is an international standard (ISO/IEC 15408) for computer or embedded systems. Common Criteria evaluation is technology specific and includes 14 different categories. The evaluation process verifies both security functional requirements and security assurance requirements to the target of evaluation (TOE).

What is FIPS 140-3?

Federal Information Processing Standards (FIPS) define the security standard to accredit cryptographic modules. The current version is FIPS 140-3. If a company develops its cryptographic module in-house or the code has been modified, the FIPS 140-3 standard is used is to initiate a full module certification. If the cryptographic module is used without modification, the FIPS 140-3 validation process only requires the new operating environment to meet the module’s security policy.

How far-reaching should a security plan be?

A security plan should be in place for the entire lifecycle of the product, from design to deployment to decommissioning. A security plan should be based on the risk tolerance of the company and the operational objectives of the device. Plans should include a process for continuous monitoring and updating to address emerging security concerns.

How much security is enough?

Security requirements for embedded systems differ based on operational functionality and risk tolerance. If a device performs a mission- or safety-critical function, security requirements will be more comprehensive. Even if a device puts no human in harm’s way, it might be able to be hacked for data or manipulation. Every embedded project should have a security assessment and plan.

Can I just use OpenSSL and be secure?

OpenSSL is a software-based cryptographic tool kit that provides a good start for an embedded design. However, embedded developers must consider the architecture, identified threats, and assets associated with the embedded device to determine which security features are needed and how vulnerabilities will be mitigated to secure the system.

How do I use security features of the hardware and software to secure a device?

Often, the security features built in to the hardware require a software function in the operating system for enablement. Secure boot and accelerated crypto-processing are two examples. A security assessment and plan before a project starts can help determine which features from the hardware you want to activate. The operating system and support for hardware security drivers can be required.

How can I tell if my device operating the same way it did at initialization?

One way to measure this is to calculate cryptographic checksums for specific memory areas and regions. This is done at the very end of the initialization phase. Then, as the device operates, the calculation can be retaken periodically to compare the crypto checksums. If the two calculations are different, then steps are needed to mitigate a potential attack.

What is AAA?

AAA is a security framework that controls access to an embedded device’s resources. It also enforces policies, performs audits, and aids in maintaining the integrity of a system.
  • Authentication: Confirmation or verification of the identity of the subject (a device); think of this step as a device connected to another device, with the identity of both verified
  • Authorization: A defined set of permissions for the authenticated subject (a device) to access and utilize the system resources
  • Accounting: The collection of security-related events as the system operates, to be used for audits and forensic analysis as needed