What Is Embedded Systems Security?
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.
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.
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
-
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.
Designing a secure embedded system is a full lifecycle process, starting before the first line of code is written.
-
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.
-
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.
-
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.
-
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
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.
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.
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.
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.
Wind River Professional Services
Professional Services provides deep industry experience to plan and design security into the full lifecycle of embedded systems.
Embedded System Security FAQs
Embedded systems security refers to the measures taken to protect embedded systems from unauthorized access, modification, or destruction.
Security risks associated with embedded systems include malware, hacking, physical attacks, and software vulnerabilities.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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
What is Functional Safety | Wind River
What Is Functional Safety?
In the overall safety of a system or piece of equipment, functional safety is the element that relies on automatic protection operating correctly and predictably in response to inputs or failures. It must be able to handle worker error, hardware failure, and a fluctuating operating environment. Functional safety applies to any segment (aviation, automotive, industrial, medical, transportation, and others). Its goal is to protect humans from injury or death and to prevent life-threatening damage to equipment and facilities.
Mission-Critical Systems
A mission-critical system cannot fail. Autonomous vehicles with crash sensors must not kill people, for example. The safety of lives is the basis of all functional safety certifications.
In a world that is increasingly connected, data sharing and telematics availability are critical for connecting and updating mission-critical systems and devices.
Autonomous equipment must react to environmental cues to function safely around people and other machinery.
If you have a connected autonomous system, or any connected system, you must prove that its safety-critical elements are secure, or you run the risk of a malicious actor interfering with system safety and the integrity of your data.
To address the challenges and achieve success with these systems, users must bring together platforms with different types of operating systems. The safety-critical features of real-time operating systems added to an open source Linux-based solution can address the software-centric functions of a future that is more automated, autonomous, and statistical.
Embedded Systems and the Intelligent Edge
The next generation of embedded devices is being built with cloud-native technologies that allow companies to explore new use cases at the edge. Today, embedded systems and the applications they run are leveraging the processing power of the cloud and artificial intelligence (AI) and machine learning (ML) technologies to enable greater insights and decision-making at the edge of the network, where devices are deployed.
Operational and environmental data gathering from the intelligent edge is used to improve functionality, ensure safety, and make real-time business decisions.
A mission-critical system cannot be functionally safe if it isn’t secure. End-to-end security for updates, control, and feedback is crucial.
The Difference Between Safety and Security
Safety means no injury or loss of life is caused, whether deliberately or not. Security means that people, facilities, operations, data, and more are protected from loss, interference, theft, or negative changes, and that no deliberate harm is caused. Another way of putting this is that safety means protecting the world from the system, whereas security means protecting the system from the world. Both are crucial, but a system cannot be functionally safe if it isn’t secure.
Why Is Functional Safety Important?
Functional safety in systems, equipment, or devices is essential for safeguarding human lives and preventing human injuries or environmental damage. Its purpose is to use specifically designed hardware equipment and/or software systems that operate to automatically prevent life-threatening, injury-causing, dangerous failures, or that control or halt such failures if they occur so as to stop further danger or threats.
Main Aspects of Functional Safety
As humans increasingly interact with autonomous or semi-autonomous systems, automatic safety functions become an essential part of the end-to-end system.
The all-encompassing objective of functional safety is to prevent risk to human lives caused either directly or indirectly from the operation of a hardware or software system. This includes preventing risk caused by damage to equipment, property, or the environment. The critical factor at play is the appropriate and correct implementation of one or more built-in, automatic protection functions known as safety functions, which constitute a safety system or safety-related system.
The scope of functional safety is end-to-end, in that it must treat any function of a component or subsystem as part of the operation of the entire system’s automatic protection function. Thus, although the standards for functional safety focus on electrical, electronic, and programmable systems, in practice functional safety methods must extend to the nonelectrical, nonelectronic, and non-programmable components of the system.
To deliver functional safety is to provide assurance and evidence that a hardware or software system meets the properly specified functional safety requirements through certification via the appropriate testing and accreditation bodies.
Functional Safety Certification
Any claim of functional safety for a component, subsystem, or system should be independently certified to the proper recognized functional safety standards. A certified product can then be claimed to be functionally safe to a particular safety integrity level (SIL) or performance level (PL) in a specific range of applications. The certificate and the assessment report that describe the scope and limits of performance are provided to the customer.
Certifications should be completed by independent organizations with experience and strong technical depth (electronics, programmable electronics, mechanics, and probabilistic analysis). Functional safety certification is performed by accredited certification bodies. Accreditation is awarded to a certification organization by an accreditation body. In most countries there is one accreditation body. In the United States, the American National Standards Institute (ANSI) is the organization for functional safety accreditation. In the United Kingdom, the United Kingdom Accreditation Service (UKAS) provides functional safety accreditation.
Functional Safety Standards
There are functional safety standards for various industries, including aviation, automotive, industrial, medical, transportation, and more. For the industrial sector, IEC 61508 is the functional safety standard. Functional safety certification programs for IEC 61508 standards are offered globally by several recognized certification bodies, including Intertek, SGS, TÜV Rheinland, TÜV SÜD, and UL.
Other functional safety standards that have been derived from IEC 61508 include international standards IEC 62304 for medical device software and the ISO 26262 road vehicles functional safety standard for automotive equipment for all automotive electronic and electrical safety-related systems. For railway transportation, there is EN 50126/8/9.
For the aviation market, the U.S. Federal Aviation Administration has enacted a similar process for functional safety certification. Known as RTCA DO-178C for software and DO-254 for complex electronic hardware, these are applied throughout the aerospace industry. For Europe, the corresponding certification is EURICAE ED-12C.
RTCA DO-178C – Aerospace
DO-178C, Software Considerations in Airborne Systems and Equipment Certification, is the principal document that the FAA, EASA, and Transport Canada certification agencies use to review and approve all commercial software-based aerospace systems.
DO-178C DAL A
DO-178C by itself does not guarantee safety aspects of the software running in a system. In the system design, the safety attributes and their functions must contain and conduct mandatory additional system safety tasks to implement and demonstrate clear and objective evidence of meeting the specific safety requirements. As specified by DO-178C and as required by the certification authority bodies, the correct Design Assurance Level (DAL) must be established using comprehensive analysis to establish the software level A–E. Any software that commands, controls, and/or monitors safety-critical functions should receive the highest DAL, Level A.
ARINC 653 – Avionics
ARINC 653 (Avionics Application Standard Software Interface) is a software specification for space and time partitioning in safety-critical avionics real-time operating systems. It allows the hosting of multiple applications of different software levels on the same hardware in the context of an integrated modular avionics (IMA) architecture.
IEC 61508 – Industrial
IEC 61508 is the industrial functional safety standard.
ISO 26262 – Automotive
ISO 26262 is the functional safety standard in the automotive industry.
EN 50128/9 – Railway
EN 50128 is the functional safety standard for software for railway control and protection.
EN 50129 is the functional safety standard for railway safety-related electronic systems for signaling.
IEC 62304 – Medical Devices
The international standard IEC 62304 specifies lifecycle requirements for the development of medical software and software within medical devices. It has been adopted by both the United States and the European Union and so can be used as the benchmark for compliance with regulatory requirements in both these markets.
Functional Safety Software Development and Considerations
The future will be autonomous. How can our platforms evolve and continue to solve customer challenges while incorporating software-centric features such as machine learning and computer vision — all while maintaining safety criticality in a connected world?
A Safety-Certified Real-Time Operating System
Any device or system that is mission critical will also need to be safety certified. If you need to guarantee that the brakes function or that the ailerons will work, you will need a real-time operating system that is certified for the specific standards within its market, be that aerospace, defense, automotive, industrial, medical, or rail.
You’ll also need functional safety consideration and support applied throughout the product lifecycle, including the legacy-device stage.
Finally, as silicon manufacturers move toward multi-core environments, you will need operating system support for these devices and systems.
A Customizable Linux Development for AI, ML, and Deep Learning (DL)
To address autonomous middleware and AI challenges going forward, most development will be on Linux. As the most popular development operating system for AI, ML, and DL, it will be critical for minimizing the distro size for devices out in the field.
In a safety-critical use case, however, this means introducing Linux into a system that typically requires an RTOS. A device may require an RTOS for guaranteed performance, for example, but coupled with AI/ML algorithms that are mostly associated with Linux. Developers and customers need applications and systems that span both types of operating systems, and system integrators are needed to work on both sides of this equation.
A Hypervisor for Interoperation
With modern silicon containing two to eight cores on a single system-on-chip, in today’s complex systems a safety-certified RTOS and an embedded Linux OS are no longer two different control units spanning a network. Instead these two very different operating systems run side-by-side on a single system-on-chip. In this scenario, having a means to monitor both sides with high-speed communication is critical. A hypervisor that is certified, fast, and able to manage the host operating system(s) becomes essential.
A hypervisor enables multiple operating systems with different characteristics to run on a single system-on-chip.
How Can Wind River Help?
In the new era of autonomy and connectivity, where it is increasingly important to identify and implement safety-related systems, Wind River® continues to lead the way. Our software runs the “can’t fail” computing systems of the most important modern critical infrastructure, including aerospace and defense, rail, automobiles, medical devices, robotics, industrial control systems, smart factories, and more.
Only Wind River offers the complete set of components that go above and beyond what is available from the rest of the market. We have the class-leading safety-certified real-time operating system; the most common commercial embedded Linux solution, based on the Yocto Project; and a safety-certified hypervisor.
Wind River also has extensive experience meeting the safety-critical standards of crucial sectors, including flight safety (DO-178C DAL A), industrial (IEC 61508), rail (EN 50126/8/9), and automotive (ISO 26262).
Functional Safety Certifiable Software
VxWorks CERT Edition
VxWorks® has an extensive portfolio in safety certification of software products, including 600+ safety certification programs with more than 360 individual customers, including more than 100 civilian and military aircraft. Its robust safety features provide advanced time and space partitioning capabilities to enable reliable consolidation of multiple applications with different levels of criticality on a single- or multi-core platform. Conformance to standards such as POSIX® and FACE™ have been leveraged in the certification of VxWorks to DO-178C, IEC 61508, IEC 62304, and ISO 26262 safety standards.
VxWorks 653
VxWorks 653 Multi-core Edition is a safe, secure, and reliable real-time operating system. It delivers an ARINC 653–conformant system by providing robust time and space partitioning on the latest hardware platforms to ensure fault containment and the ability to upgrade applications with minimal test and integration demands.
Wind River Helix Virtualization Platform
Wind River Helix Virtualization Platform has been designed to be certified and to simplify the certification of safety-critical applications according to the stringent requirements of the DO-178C Software Considerations in Airborne Systems, IEC 61508 industrial functional safety, and ISO 26262 automotive safety standards. It is an OS-agnostic edge compute platform with a real-time, embedded, Type 1 hypervisor that can manage unmodified guest operating systems running VMs and consolidating the workloads for devices.
Medical Application #1
Medical Application #2
Application #3
Application #4
VM 1 VxWorks
(Safety Critical)
VM 2 Wind River Linux
VM 3 Windows
VM 4 Third-Party OS
(Safety/Non-Safety)
Wind River Helix Virtualization Platform — Hypervisor
Multi-core Hardware
Professional Services
Certification of a system is a complex, costly, and demanding process. The A&D, medical, industrial, and security industries each have their own different but similar safety standards. Wind River Professional Services provides the safety-critical expertise to help you through the certification process.
Functional Safety FAQs
Functional safety is a set of principles and techniques used to ensure that systems and products operate safely and reliably, even in the presence of faults and errors. It’s needed because it helps prevent accidents, injuries, and damage to property. It is particularly critical in high-risk industries such as automotive, aerospace, and healthcare.
Functional safety is achieved through a combination of design techniques, testing and validation, and process management. This typically involves identifying potential hazards and risks, specifying safety requirements, designing and testing safety mechanisms, and establishing processes for managing and verifying safety throughout the product lifecycle.
There are several standards and frameworks for functional safety, including ISO 26262 for automotive systems, IEC 61508 for general industrial systems, and EN 50128 for railway systems. These standards provide guidelines and best practices for achieving functional safety, and they are often required by regulatory bodies and industry certifications.
The role of safety engineering is accident prevention, reducing the risks of human injury or loss of life associated with human error. It derives safety benefits from engineered hardware and software systems design. It is applied to product designs to make functional safety an integral part of equipment or system operations.
DO-178C is the short name for a document written by RTCA; its complete title is “Software Consideration in Airborne Systems and Equipment Certification.” The document was produced by Special Committee 205 (SC-205) of RTCA and Working Group 71 (WG-71) of the European Organization for Civil Aviation Equipment (EUROCAE). The EUROCAE name for this document is ED-12C. RTCA provides copies of this document at www.rtca.org. The document provides the avionics community with guidance for determining, in a consistent manner and with an acceptable level of confidence, which the software aspects of airborne systems and equipment comply with airworthiness requirements. The document defines several Design Assurance Levels, from Level A to Level E, based on the consequence of a failure condition. Failure of Level A software would cause (or contribute to) a catastrophic failure condition for the aircraft that would prevent continued safe flight and landing.
The certification authorities FAA and EASA require aircraft manufacturers to show their software’s compliance to the objectives defined in DO-178C. There are 66 objectives for Level A. Makers of aircraft and avionics that use software must always adhere to DO-178C standards in developing and testing software whenever these systems are to be approved by the FAA. A manufacturer could use another standard to certify its software to meet FAA requirements, but the burden of proof would be on the manufacturer.
The certification authorities FAA and EASA require aircraft manufacturers to show their software’s compliance to the objectives defined in DO-178C. There are 66 objectives for Level A. Makers of aircraft and avionics that use software must always adhere to DO-178C standards in developing and testing software whenever these systems are to be approved by the FAA. A manufacturer could use another standard to certify its software to meet FAA requirements, but the burden of proof would be on the manufacturer.
IEC 61508 is the standard for industrial functional safety. It specifies the functional safety standards for the lifecycle of industrial electrical, electronic, or programmable electronic systems and products. This standards document focuses on the components of an industrial device or system that perform automated safety functions, including sensors, control logic, actuators, and microprocessors.
ISO 26262, “Road vehicles – Functional safety,” is the international standard for functional safety of electrical and/or electronic systems in automobiles and road vehicles. It was originally defined in 2011 by the International Organization for Standardization, then revised in 2018.
This IEC Standard is also known as “Medical device software – Software life cycle processes.” Software is often an integral part of medical device technology, and thus gauging the safety of these devices depends on knowledge of what the software is intended to do and being able to demonstrate that use of the software fulfills those intentions without causing any unacceptable risk.
This standard provides a framework of lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. It provides requirements for each lifecycle process and further divides those processes into sets of activities, most of which are then further divided into sets of tasks.
This standard provides a framework of lifecycle processes with activities and tasks necessary for the safe design and maintenance of medical device software. It provides requirements for each lifecycle process and further divides those processes into sets of activities, most of which are then further divided into sets of tasks.
Functional safety is designed to ensure that any product automatically prevents dangerous, life-threatening, or injury-inducing incidents that threaten humans or the environment about the product. Additionally, functional safety systems can cut costs and improve efficiency of operations.
The main aspects of functional safety are to design and build automatic safety functions into equipment, a device, or a system such that it operates in a manner that prevents or stops a potentially dangerous situation or mitigates life-threatening injury to humans or to the environment about the product.
Functional safety management is the act of identifying and defining all of the activities of the functional safety lifecycle of a product, equipment, device, or system that are needed to achieve the required level of functional safety to meet the specified functional safety standard.
Functional safety ensures acceptable implementation, operation, and ongoing maintenance of the safety-related functions. This calls for the system to operate as expected when needed and to provide the required safety protection to prevent a hazardous event from occurring and causing injury to people or harm to the environment or the asset.
Certain industries are safety-critical and must comply with safety standards that are specified in their industrial sector. Here is a list of a few functional safety standards:
- IEC 61508: Functional safety of electrical/electronic/programmable electronic safety-related systems
- ISO 26262: Automotive
- IEC 61511: Process industry
- IEC 62304: Medical devices
- EN 50126, EN 50128, EN 50129: Railway application (signaling and rolling stock)
- ISO 25119: Agriculture
A functional safety assessment usually involves an audit of processes and procedures in place for a piece of equipment, a device, or a system to ensure compliance with the specified functional safety requirements for the specific industry. This includes verification for each lifecycle stage and validation of the full set of industry-specific safety requirements.
Each functional safety standard is risk based. In order to apply the standard, some specific industry criteria must be established that define the tolerability of safety risks in the operation and use of the product. It is this level of risk that establishes the stated standard, processes, and validation that must occur and be provided.
Functional safety analysis is the performance of equipment, device, or system usage or activity by a competent senior engineer or systems engineer to determine whether the safety system that is part of the product meets specifications and actually achieves functional safety (that is, it is free of any unacceptable risk). This safety assessment is a critical part of reducing systematic failures.
Automotive or car functional safety is defined and set by the international standard ISO 26262, which pertains to the electrical and electronic systems of the hardware and software components of the vehicle. It provides the requirements that must be met for the safe function of the vehicle systems and the processes, methods, and tools used during development. This functional safety standard makes sure that all appropriate safety levels are met and maintained throughout the vehicle lifecycle.
Since the first automobile rolled out, safety has been a desired feature. As cars have become more advanced, with electrical systems, compute systems, sensors, and an array of systems important to the operation of the vehicle, functional safety has become a requirement. It is important that proper functional safety standards are met that help limit the number of failures in a car and ensure the safety of the driver and passengers.
To prepare its vehicle product to be ISO 26262 compliant, the manufacturer or OEM must obtain evidence or proof from all of the Tier 1 suppliers and supply chain providers of the vehicle's components that their products are ISO 26262 compliant. Then all of this evidence or proof documentation must be packaged and submitted to an ISO-accredited certification organization for analysis and ultimate certification that the vehicle is ISO 26262 compliant.
TÜV is a German safety agency that tests equipment, devices, and systems for functional safety. Its certification for meeting functional safety standards is accepted primarily in Europe. EC is an abbreviation for European Certification. A company can use the EC’s CE mark (from the French phrase “Conformité Européene”) on products that have at least one safety agency mark from an agency recognized in Europe. Hence a product with the TÜV mark can also use the CE mark. The CE mark is recognized in Europe but not in the U.S.
For more than 125 years, the U.S.-based Underwriters Laboratories (UL) has developed thousands of safety standards for a wide variety of products. The UL mark is recognized globally. For a company to use the UL mark on any of its products, the product must meet UL safety standards and adhere to UL inspections.
For more than 125 years, the U.S.-based Underwriters Laboratories (UL) has developed thousands of safety standards for a wide variety of products. The UL mark is recognized globally. For a company to use the UL mark on any of its products, the product must meet UL safety standards and adhere to UL inspections.
Automotive Safety Integrity Level, or ASIL, is a risk classification system defined and set by the ISO 26262 standard for the functional safety of road vehicles or automobiles.
Threadsafe functions allow users to implement concurrent functions at the same time. These concurrent functions can be dependent on each other for execution, or they can be independent of each other.
The advantage of functional testing is that it helps ensure customer or end-user satisfaction by producing a higher level of defect-free products/software. It provides the process to ensure that all operation and product requirements are met. Functional testing also helps ensure that all the functionalities of an application, software, or product are working properly.
Safety integrity levels (SILs) are the relative safety levels of risk reduction provided by a safety function for equipment, a device, or a system. A SIL may also target level of risk reduction. SIL is a performance measurement required for a safety instrumented function.
DO-254 and EUROCAE ED-80 define five Design Assurance Levels, commonly referred to as DALs, that describe how critical these components are for safe flight. The DALs run from Level A to Level E, based on the consequence of a failure condition. For example, failure of Level A software would cause (or contribute to) a catastrophic failure condition for the aircraft that would prevent continued safe flight and landing.
- Catastrophic (Level A): Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft.
- Hazardous (Level B): Failure has a large negative impact on safety or performance, or it reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or it causes serious or fatal injuries among the passengers. It is safety significant.
- Major (Level C): Failure is significant but has a lesser impact than a hazardous failure (for example, it leads to passenger discomfort rather than injuries), or it significantly increases crew workload (safety related).
- Minor (Level D): Failure is noticeable but has a lesser impact than a major failure (for example, causing passenger inconvenience or a routine flight plan change).
- No effect (Level E): Failure has no impact on safety, aircraft operation, or crew workload.
Commercial off-the-shelf, or COTS, software and hardware are products that already exist and are commercially available to obtain or purchase. Synonymous terms are “off-the-shelf” or “OTS.”
SOUP is an acronym for "software of unknown (or uncertain) pedigree (or provenance).” It refers to safety-critical systems, such as software for medical systems, that have not been developed via a known software development process and may have unknown or no safety-related properties.
Code coverage testing helps determine the amount of the code that has been tested. This assists in accessing the quality of a test suite and analyzing how meticulously a given piece of software has been verified. Simply put, code coverage testing refers to the level at which the source code of the software has been tested.
As a form of subsystem hazard analysis, software hazard analysis is designed to validate specified software closed-box behavior to ensure that it satisfies system safety design constraints. Additionally, it verifies that specified software behavior meets and satisfies general software system safety design criteria.
Wind River Studio Linux Services: Security and Compliance Analysis and Remediation
Wind River Studio Linux Services:
Security and Compliance Analysis
and Remediation
Wind River offers security and compliance scanning with analysis and remediation services to help you build higher-quality code and accelerate your time to deployment.
Automated security and compliance scanning, tuned for complex embedded software systems, helps developers quickly identify and prioritize high-risk vulnerabilities and license issues. Build higher-quality code and accelerate your time to application deployment.
- A professional grade security and compliance scanner provides developers a thorough assessment of the potential risks for common vulnerabilities and compliance issues.
- A CVE and compliance scanning assessment can flag critical points of concern that require a deeper analysis to determine impact and effort to mitigate.
- Our service scans your Yocto Project Linux platform manifest and open source packages to identify vulnerabilities and license compliance issues. We use a curated collection of data sources including Yocto Project, NIST, and other public sources, as well as the Wind River Linux database of Common Vulnerabilities and Exposures (CVEs).
- We analyze specific platform layers including hardware, kernel, user space, libraries, and other system components. The high-risk issues are presented in a graphical and easy-to-read format, allowing a development team to get a snapshot of the health of their code.
Wind River offers hundreds of board support packages to help with board bring-up. Browse by the following categories:
Architecture Operating System HardwareWhat We Deliver
SECURITY SCAN AND CVE IDENTIFICATION
Scan the health of your Linux platform for all existing CVEs as they emerge. We run our professional-grade scanner and compare it to our extensive database to accurately identify potential vulnerabilities. Our engineers then provide a deep analysis of the true impact on your platform.
- Security scan of your Linux platform comprising your kernel, BSP, and shared and user libraries
- Access to our curated knowledge base of vulnerabilities and compliance issues built from public sources such as NIST, the Yocto Project, and the MITRE database of CVEs
- Detailed security report identifying all the CVEs that are open against your Linux platform
LICENSE USE IDENTIFICATION
Scan your Linux platform to provide a detailed report of all the licenses used in your platform as well as transitive dependencies.
- License scan of your Linux platform comprising your kernel, BSP, and shared and user libraries
- Ability to scan for all licenses used in your platform and categorize based on their permissiveness, copyleft, compatibility, and transitive dependencies
- Detailed license report identifying all the licenses used in your Linux Platform
CVE MITIGATION PLAN
Work with our global team of engineers to quickly identify and prioritize vulnerabilities based on a common vulnerability threshold (CVSS), severity of impact, and difficulty of attack and avoid ability. We work with you to build a mitigation plan to address prioritized CVEs.
- Detailed security report identifying CVEs open against your platform
- Prioritization of existing CVEs to fix, based on their severity and impact
- Assessment of the time and cost to make your Linux platform secure
LICENSE COMPLIANCE MITIGATION PLAN
Our team of engineers performs a deep analysis to determine the impact of the restricted licenses used in your solution. We work with you to prioritize remediation options and timing.
- Detailed license use report identifying the licenses used in your Linux platform
- Prioritization of licenses not permitted for use in your organization
- Assessment of the time and cost to make your Linux platform compliant with your license policy
CVE MITIGATION
Our team of engineers performs a deep analysis to determine the impact of the CVE on your Linux platform. We work with you to prioritize remediation options and timing. We backport, validate, and verify community-based patches before we apply them to your code. If a community solution is unavailable, we work with your engineering team to architect a technical solution.
- Prioritization of existing CVEs
- Backporting, validation, and verification of existing community patches for CVEs, applying those to your Linux platform
- Development of new solutions, if community patches don’t exist for CVEs
LICENSE USE MITIGATION
Our team of engineers performs a deep analysis to determine the impact of the restricted licenses used in your solution. We work with you to prioritize remediation options and timing.
- Prioritization of restricted licenses, with mitigation plan
- Alternate packages or development of new solutions to avoid use of restricted use licenses
FOCUS ON QUALITY
We ensure you have a high-quality and stable Linux platform, and all remediation efforts enter the Wind River continuous integration (CI) pipeline for a nightly/weekly/monthly build and test process throughout development. After remediation testing and release, Wind River will generate a new software bill of materials and documentation that can be used for project verification.
- All modifications to your platform through patches or custom engineering validated and verified before redeployment
- Nightly builds and test process leveraging the Wind River CI pipeline to ensure high quality
SOFTWARE BILL OF MATERIALS AND RELEASE DOCUMENTATION
A new software bill of materials is generated after every code modification.
- Release with all patches to fix CVE and license issues as per the mitigation plan
- Online release dashboards and reports to track fixes and progress
- Release notes to capture the CVEs fixed
COMMUNITY UPSTREAM
Wind River can be your partner and voice for the Yocto Project.
We can work on your behalf to upstream and contribute any fixes or engineered resolutions back to the
community.
GLOBAL SUPPORT
Wind River has a global team of experts to support your Linux platform. Additional support options are
available.
» See Awards and Industry Recognition for
Wind River
- Online support portal to submit tickets during the remediation period
- Review by Wind River engineers to ensure timely response
- Premium Support options for customers needing dedicated engineers well versed in their project
GLOBAL SUPPORT CENTERS
- North America
- Ottawa, Canada
- Dublin, OH
- Alameda, CA
- Detroit, MI
- Costa Rica
- South America
- Cordoba, Argentina
- (C/E Services Only)
- Europe
- Stockholm, Sweden
- Paris, France
- Munich, Germany
- Galati, Romania
- China
- Chengdu, China
- Beijing, China
- Korea
- Seoul, Korea
- Japan
- Tokyo, Japan
OPEN SOURCE LEADERSHIP AND ENGINEERING EXPERTISE
Wind River is a founding member of the Linux Foundation’s Yocto Project.
We are one of the top contributors and maintainers of several key components.
» Learn about the Yocto Project
- Leading commercial contributor with commits to the Yocto Project for the last five years
- Recent contribution of a security response tool
- Proven project governance and advocacy within the community
FEATURED Blog
From Prototype to Post-Deployment: Linux Decision Points
In the embedded industry, the lifecycle of a Linux product can last 5, 10, or even 15 years or more, so the decisions you make now and along the way will impact speed, quality, and resources for years to come. They can also create technical debt and directly impact future scalability, profitability, and the overall success of your project.
≫ Read MoreWhat Is Threat Modeling?
What Is Threat Modeling?
Threat modeling is a process for thinking through, identifying, and documenting known threats and mitigations to a system before that system is deployed. Threat modeling acknowledges that all systems face various threats before, during, and after deployment, and it helps security experts identify and mitigate those threats before they occur.
Threat Modeling and Security
Threat modeling optimizes application security by:
- Identifying objectives
- Modeling the architecture
- Identifying threats
- Defining controls to prevent or mitigate the effects of threats to the system
- Maintaining a risk register for threats that are not prevented or mitigated
- Validating that implemented controls were effective
Threat modeling is a proactive process for addressing system threats
Why Use Threat Modeling?
Threat modeling helps us make informed decisions about security postures and risk of cyberattacks. While it is possible to run multiple security scanning tools and separate third-party penetration testing engagements on a system, these occur late in the software development lifecycle, at which time the cost of mitigating threats is much higher.
Benefits of Threat Modeling
The benefits of threat modeling for an application can be summarized as follows:
Reduced cost
Threat modeling happens during the design phase, which allows threats to be addressed early in the software development lifecycle and lowers the cost of mitigation.
Better security
Documenting an application’s security architecture and creating a threat model are key steps in ensuring that an application maintains its security assurances and can defend itself against external threats.
Acceptable risk levels
A threat model allows us to take a structured approach to evaluating the security level of an application, prioritize risks, and implement risk-mitigating controls in an effort to reach a state of security assurance that falls within an acceptable risk level.
Threat Modeling Approaches
The process of threat modeling is simple, but it needs to be approached with discipline and care. Since the attack surface of any given system changes as technology changes, and since new threats are constantly emerging, we must understand and acknowledge what we know vs. what we don’t or can’t know about any modern system.
In general, there are three basic approaches to threat modeling: software centric, attacker centric, and asset centric.
Software-Centric Approach
A risk mitigation focusing on software:
- Evaluates the application being modeled
- Determines the risk
- Identifies controls to mitigate
- Requires a good understand of the application and the system it is running on
Attacker-Centric Approach
An approach that highlights the attacker:
- Puts the user into the mindset of an attacker
- Determines what is most at risk
- Needs to understand the concept of hacking
- Must have the skill set of a hacker
Asset-Centric Approach
Focusing on assets, this approach:
- Identifies assets to be protected
- Classifies assets based on data sensitivity and value potential
- Determines an “acceptable risk” level
- Takes a cyber risk–management perspective in satisfying the security auditing process
Threat Modeling Methodologies
In general, threat modeling methodologies establish a catalog of potential threats that are relevant to adversary tactics and techniques as well as attack frameworks. When possible, technology specifics are abstracted away. Resolution or mitigation of identified threats with appropriate security controls establish the security posture of the system. Many different methodologies can be used, including:
STRIDE
This type of threat model, developed at Microsoft, is software centric (developer focused) and uses the pneumonic STRIDE to categorize threats as follows:
| Threat Category | Property Violated | Threat Description |
|---|---|---|
| Spoofing | Authentication | Illegal access and then use of another user’s authentication information, such as username and password |
| Tampering | Integrity | The malicious modification of data |
| Repudiation | Accountability (Audit) | Associated with users who deny performing an action without other parties having any way to prove otherwise |
| Information Disclosure | Confidentiality | Exposure of information to individuals who are not authorized to access it |
| Denial of Service (DoS) | Availability | Attacks that deny service to valid users |
| Elevation of Privileges | Authorization | Privileged access gained by an unprivileged user, who then has sufficient access to compromise or destroy the entire system |
In the STRIDE methodology, data flow diagrams of the application’s use cases are created by decomposing them to identify system entities, events, and boundaries. Threat categories are then used to apply a general set of known threats to the system and assess the system for mitigations to these threats.
Sample data-flow diagram
The seven stages of PASTA
PASTA
Process for Attack Simulation and Threat Analysis (PASTA) is a risk-based methodology to threat modeling that takes an attacker-centric approach in identifying threats to an application. This methodology follows the seven-stage process shown in the diagram at left.
As PASTA follows an attacker-centric approach, it uses “attack trees” to depict potential attacks on a system in a tree-form diagram. The tree root symbolizes the goal of the attack, and the leaves show ways to achieve that goal. In order to leverage a threat modeling methodology that uses attack trees, one must be familiar with an attacker mindset and capabilities.
Trike
The Trike methodology, which is an open source project that uses threat models as risk-management tools, was originally created to improve the efficiency and effectiveness of existing threat modeling methodologies. It was first implemented as a tool in the programming language Smalltalk and is now implemented through spreadsheets.
Trike stages
VAST
Visual, Agile, Simple Threat Modeling (VAST) is a threat modeling methodology developed by the creators of the ThreatModeler product. Its purpose is to address the enterprise scalability gap by integrating into the full software development lifecycle (SDLC). VAST incorporates three pillars to support a scalable threat modeling solution:
AUTOMATION
- Eliminates the repetitive portion of threat modeling
- Provides ongoing threat modeling
- Is scaled to encompass the entire enterprise
INTEGRATION
- Integrates with tools throughout the SDLC
- Supports agile DevOps
COLLABORATION
- Collaborates with key stakeholders:
- App developers
- Systems architect
- Security team
- Senior executives
It is important to note here that VAST was developed to define the way that the automated tool ThreatModeler enables enterprises to threat model at scale. Therefore, full details of the stages of this methodology are not relevant here.
Security Cards
Security Cards is a threat modeling methodology developed by the Security and Privacy Research Lab (CSE) and the Value Sensitive Design Research Lab (iSchool) at the University of Washington, Seattle. Its purpose is to facilitate exploration of potential security threats for a particular system; more broadly, it aims to develop a security mindset. It is based on brainstorming and creative thinking rather than a structured modeling approach.
The Security Cards toolkit provides a deck of 42 cards grouped across four dimensions (or suits):
- Human impact
- Adversary’s motivations
- Adversary’s resources
- Adversary’s methods
Each card contains:
- Card topic
- Card dimension
- Questions to clarify and jump-start thinking
- Illustrative examples
Example security card
Threat Modeling Best Practices
It is best practice to recognize that you will never be able to completely mitigate all threats to an application. In some cases, there will be threats that you won’t be able to identify. Techniques developed in the future will add threats to your application that don’t exist now.
The creation of threat models can be guided by a security expert, but the task is not only for security experts or security teams. A comprehensive understanding of the architecture of the system, design decisions, implementation, and engineering decisions is important and necessary to create a complete threat model. This usually means bringing in experts from across the team to help create a complete picture of the system so that all threats, vulnerabilities, and mitigations can be identified.
Timing
Threat modeling is too often done toward the end of a development phase, immediately before deployment. This is too late. Threat modeling can and should begin as early as possible in the design of the system and continue throughout design and development. Identifying threats early can help avoid security-problematic design decisions and give development teams time to change the design to a more secure system posture.
How Can Wind River Help?
Wind River Simics
Modern tools can test system environments, ensure that they are properly secured, and provide your team with the confidence to work intelligently during the day and sleep peacefully at night.
Wind River® Simics® is a fast, full-system simulation platform that uses scripts to define, link, and execute virtual prototypes. Attacks can be launched automatically by reusing publicly available or in-house proof of vulnerability (PoV) in Python. In addition, simulation can be played back at any time for detailed source code–level analysis with determinism, which provides invaluable insights for threat modeling and documentation.
Wind River Professional Services and products can help identify and mitigate system threats
Wind River Professional Services
Wind River Professional Services is a team of experts ready to assist you with threat modeling training or to conduct a threat model of your application, identifying threats and mitigations on your behalf.
Threat Modeling FAQs
Threat modeling is a process of identifying and analyzing potential threats to a system, application, or organization. It’s important because it helps identify vulnerabilities before they can be exploited, enabling organizations to take proactive steps to mitigate risk and improve security.
The stages vary, based on the methodology used:
- STRIDE: Stages are defined by the organization but can be generalized as follows:
- Identify security requirements
- Decompose the application
- Create a diagram that describes how the data flows through the application
- Identify threats and their mitigations
- Validate mitigations
- Document mitigated and accepted threats
- PASTA: Follows an attacker-centric approach to:
- Define the business context of the application
- Enumerate the technology
- Decompose the application
- Analyze the threat
- Identify weaknesses and vulnerabilities
- Simulate attack
- Analyze residual risk
- Trike: Currently uses spreadsheets to:
- Define a system to develop a requirement model
- Assess risk using CRUD:
- Creating
- Reading
- Updating
- Deleting
- Compose a data flow diagram (DFD)
- Assign risk values
- VAST: Does not define stages but rather is integrated into the entire software development lifecycle (SDLC)
- Security Cards: Uses an unstructured approach and therefore does not define the stages of its methodology
- Software-centric
- Attacker-centric
- Asset-centric
The Microsoft Threat Modeling Tool (MSTMT) allows software architects to identify and mitigate potential security issues early, when they are relatively easy and cost-effective to resolve. As a result, it greatly reduces the total cost of development. It was designed for use by those who are not security experts, making threat modeling easier for all developers by providing clear guidance on creating and analyzing threat models.
The tool enables anyone to:
- Communicate about the security design of a system
- Analyze that design for potential security issues using a proven methodology
- Suggest and manage mitigations for security issues
Some common methodologies for conducting threat modeling include STRIDE, DREAD, PASTA, VAST, and Trike. Each methodology has its own strengths and weaknesses, and organizations should select the one that best fits their needs and requirements.
Regardless of what is being threat modeled, the objective is always to address four questions:
- What are we working on?
- What could go wrong?
- What are we going to do about it?
- Did we do a good enough job?
- Microsoft Threat Modeling Tool (open source)
- OWASP Threat Dragon (open source)
- ThreatModeler (commercial)
- CAIRIS (open source)
- IriusRisk (commercial)
- securiCAD (open source, commercial)
- Threagile (open source)
Assets are items that are valuable to an organization, whose loss could potentially disrupt the organization’s ability to accomplish its mission.
- What are we working on?
- What could go wrong?
- What are we going to do about it?
PASTA, or Process for Attack Simulation and Threat Analysis, is a risk-based methodology to threat modeling. It follows a seven-stage process that uses “attack trees” to depict potential attacks on a system in a tree-form diagram. It requires its users to understand an attacker mindset and capabilities.
Once threats have been identified against an application, you will prioritize mitigation by applying a risk assessment technique to each threat. Check with your risk-management organization to determine whether your company has a defined risk assessment technique you should follow. Three commonly used techniques are:
- Average ranking, or (D+R+E+A+DI)/5, which averages:
- Damage
- Reproducibility
- Exploitability
- Affected users
- Discoverability
- Probability x Impact (PxI) ranking:
- P = (R+E+DI)
- I = (D+A)
- Delphi
- This technique is a method of group decision-making and forecasting that involves successively collating the judgments of experts (security experts, in this case).
Threat modeling should involve a cross-functional team that includes representatives from areas such as development, operations, security, and business. This ensures that all stakeholders have a say in the process and that the final output reflects the organization’s risk appetite and tolerance.
The most effective and efficient time to perform threat modeling is in the design phase of the software development lifecycle. The more you shift right in the lifecycle, the more expensive it becomes to implement mitigations for the threats that are identified.
Threat modeling should be conducted regularly, ideally as part of the software development lifecycle (SDLC), to ensure that the system is continuously evaluated for potential threats and vulnerabilities. The frequency of the exercise will depend on the complexity of the system and the risk appetite of the organization.
The outputs of a threat modeling exercise typically include a list of potential threats, a risk matrix that prioritizes threats based on their severity and likelihood of occurrence, and recommendations for mitigating each threat.
Some challenges associated with threat modeling include the complexity of modern systems, the need for specialized expertise and tools, and the dynamic nature of the threat landscape. Additionally, threat modeling can be time-consuming and resource-intensive, which may make it challenging for organizations with limited resources or budgets.
Wind River Studio Linux Services Architecture and Implementation
Wind River Studio Linux Services:
Architecture and Implementation
Wind River offers comprehensive solution services by industry experts who can interpret requirements, architect options, and provide recommendations.
Starting a Linux project with a binary supplied by a hardware vendor is the fastest and easiest way to get to a proof of concept (POC). But embedded systems typically have unique, market-specific functional requirements. Moving from a POC to a deployable product takes a lot more system architecting, feature integration, and long-term management over the entire lifecycle.
Detailed planning in the initial phase is key to a successful Linux project. This planning should
include full lifecycle scope, defining functional requirements and system architecture, identifying
risks, and creating a detailed project plan.
Wind River® offers comprehensive solution services by an experienced team of industry experts who can
interpret system requirements, architect platform options, and provide recommendations for
meeting business, technical, and program goals. Their engineering expertise can help you accelerate
time-to-deployment, increase quality, lower risk, and ensure greater long-term project success.
Wind River offers hundreds of board support packages to help with board bring-up. Browse by the following categories:
Architecture Operating System HardwareWhat We Deliver
SOLUTION ASSESSMENTS
Our team of embedded experts can assess the full lifecycle requirements for your project. We look at your design architecture, security and risk tolerance, market specifications, and available hardware and software technologies to recommend a course of action.
- Security assessment of risk profile, attack surfaces, software and hardware requirements, and security plan
- Architecture assessment, including the Linux platform, hardware, and application deployment environment
- Solution assessment of software add-ons such as over-the-air (OTA) updates, OS hardening, system integration, networking, 5G integration, and more
- Documented recommendations with supporting evidence for business and technical decision making
- Security threat analysis and plan
- Architectural study with functional requirements
- Detailed compliance matrix tracing requirements to standards and specifications
- Proactive risk matrix plan identifying major risks and necessary mitigation that could impact schedule and budget
- Detailed design phase planning
LINUX PLATFORM CUSTOMIZATION, OPTIMIZATION, AND IMPLEMENTATION
Many embedded systems have unique market requirements which must be met before deployment, such as features and customizations to meet specification and standards requirements. In addition, rigid deployment environments can require additional optimizations for performance and footprint.
- Assessment integration services for architecture, security, and solutions
- Project acceleration and tuning
- Integration of Linux packages with market-specific requirements for automotive, energy, industrial, and medical devices
- Board support package (BSP) creation and optimization
- Hardware boot loaders and driver support
- Performance tuning for speed and footprint
- OTA mechanism and fielded device updates
- End-of-life services
ACCESS TO EMBEDDED LINUX EXPERTS
Work with our team to quickly identify and prioritize the vulnerabilities based on a common vulnerability threshold (CVSS), severity of impact, and difficulty of attack and avoid ability. We work with you to build release plans to address critical and prioritized CVEs and defects.
- 10 global design centers
- 150 experts
- 24/7 online support
- Dedicated project engineer as needed
GLOBAL SUPPORT CENTERS
- North America
- Ottawa, Canada
- Dublin, OH
- Alameda, CA
- Detroit, MI
- Costa Rica
- South America
- Cordoba, Argentina
- (C/E Services Only)
- Europe
- Stockholm, Sweden
- Paris, France
- Munich, Germany
- Galati, Romania
- China
- Chengdu, China
- Beijing, China
- Korea
- Seoul, Korea
- Japan
- Tokyo, Japan
YOCTO PROJECT LEADERSHIP AND ENGINEERING EXPERTISE
Wind River is a founding member of the Linux Foundation’s Yocto Project.
We are one of the top contributors and maintainers of several key components.
» Learn about the Yocto Project
- Leading commercial contributor with commits to the Yocto Project for the last five years
- Recent contribution of a security response tool
- Proven project governance and advocacy within the community
FEATURED Blog
From Prototype to Post-Deployment: Linux Decision Points
In the embedded industry, the lifecycle of a Linux product can last 5, 10, or even 15 years or more, so the decisions you make now and along the way will impact speed, quality, and resources for years to come. They can also create technical debt and directly impact future scalability, profitability, and the overall success of your project.
≫ Read More