RidgeRun Platform Security Manual - When Is My Project Secure Enough?
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
When Is My Project Secure Enough?
There is no single set of security features that makes every embedded system secure.
The appropriate level of security depends on what the system protects, the threats it is exposed to, the consequences of a compromise, and the requirements that apply to the product.
As discussed in the previous section, the first step is to identify the project's security requirements. Once these requirements are known, the project can determine which risks need to be addressed and which security mechanisms are appropriate.
A system can be considered sufficiently protected when the relevant risks have been reduced to a level that is acceptable for the project while meeting applicable customer, regulatory, and product requirements.
Security is about managing risk
The objective of security is not necessarily to eliminate every possible threat.
In practice, eliminating all risk is usually impossible. Adding security mechanisms also introduces costs and trade-offs such as development complexity, hardware requirements, performance impact, provisioning, maintenance, and recovery considerations.
For this reason, security decisions should be based on risk.
A simplified way to reason about risk is to consider two main factors:
- Likelihood: How realistic is it that the threat could occur?
- Impact: What would happen if the threat were successfully exploited?
A threat with a high impact but very low likelihood may require a different response from a threat that is both highly likely and highly damaging.
Similarly, a vulnerability with limited consequences may not require the same level of protection as one that could expose sensitive information, disable the product, compromise other systems, or create a safety risk.
Not every project requires the same level of security
Security requirements depend heavily on the intended use and deployment environment of the product.
For example, consider three devices using similar embedded hardware:
| Device | Example environment | Security considerations |
|---|---|---|
| Development prototype | Controlled laboratory | Limited exposure, controlled physical access, and no sensitive production data. |
| Commercial connected device | Customer network with cloud connectivity | Remote attacks, customer data, software updates, device identity, and long-term maintenance may need to be considered. |
| Critical system | Industrial, medical, transportation, or other high-impact environment | A compromise may affect operations, safety, sensitive information, or other connected infrastructure. |
Although these systems could use similar processors and operating systems, their acceptable risk and required security controls may be very different.
Therefore:
More security mechanisms do not automatically mean that a system is more appropriately secured.
The objective is to implement the protections necessary to address the relevant risks of the project.
Prioritize the risks that need to be addressed
The security requirements identified during the threat analysis should be prioritized according to the risk they represent.
A simple qualitative classification can be useful:
| Likelihood | Description |
|---|---|
| Low | The attack requires uncommon conditions, significant resources, specialized access, or is unlikely in the intended deployment. |
| Medium | The attack is realistic under certain conditions or requires access that an attacker could reasonably obtain. |
| High | The attack is practical, accessible, or likely in the intended deployment environment. |
The potential impact can be evaluated in a similar way:
| Impact | Description |
|---|---|
| Low | Limited effect on the device, users, or organization. |
| Medium | Loss of functionality, exposure of non-critical information, or recoverable operational impact. |
| High | Exposure of sensitive information, unauthorized device control, significant operational disruption, safety consequences, or compromise of other systems. |
Combining likelihood and impact provides a simple way to prioritize risks.
| Low Impact | Medium Impact | High Impact | |
|---|---|---|---|
| High Likelihood | Medium | High | High |
| Medium Likelihood | Low | Medium | High |
| Low Likelihood | Low | Low | Medium |
This matrix is only a simplified example. A project may require a more formal risk assessment depending on its industry, customer, or regulatory requirements.
The important point is that security mechanisms should be selected based on identified risks rather than simply enabling every security feature available on the platform.
From security requirements to security mechanisms
Once the security requirements of the project have been identified and prioritized, the next step is to determine which security mechanisms can help satisfy them.
Security mechanisms should be selected according to the threats and security requirements identified for the system. A security feature should not be enabled simply because the platform provides it; it should address a specific security requirement.
The following are some common security mechanisms used in embedded systems:
| Security mechanism | Purpose | Example security requirement |
|---|---|---|
| Root of Trust | Establishes a trusted foundation used to verify or protect other components of the system. | The system must have a trusted foundation from which software or device identity can be verified. |
| Secure Boot | Verifies the authenticity and integrity of software before it is executed during the boot process. | Only authorized firmware must be executed. |
| Trusted Execution Environment (TEE) | Provides an isolated execution environment for sensitive operations and data. | Sensitive operations and secrets must remain isolated from the normal operating system. |
| Trusted Platform Module (TPM) | Provides hardware-backed capabilities for protected key storage, measurements, cryptographic operations, and attestation. | Cryptographic material and platform measurements must be protected by a dedicated trust component. |
| Key Management | Controls the generation, storage, access, use, rotation, and protection of cryptographic keys. | Cryptographic keys must be accessible only to authorized components. |
| Measured Boot / Integrity Measurement | Measures software components and system state so their integrity can be evaluated or attested. | The integrity state of the software stack must be measurable and verifiable. |
| Disk Encryption | Protects stored information against unauthorized disclosure. | Sensitive data must remain confidential if the storage device is removed or accessed without authorization. |
| Secure Update Mechanisms | Authenticate and validate software updates before they are installed or activated. | Only authorized and unmodified software updates may be installed. |
These mappings are examples rather than universal solutions.
A security mechanism may satisfy multiple requirements, and a single security requirement may require multiple mechanisms.
Security should therefore be considered as a system rather than as a collection of independent features.
Security should be implemented across the system
Protecting only one component may leave other attack paths available.
Embedded system security commonly involves protections across several areas:
Hardware and boot
This area establishes the foundation from which the device starts and controls low-level access to the platform.
Security considerations may include:
- Root of Trust.
- Secure Boot.
- Hardware-backed keys.
- Debug interface protection.
- Boot configuration protection.
- Device identity.
Operating system and software
Once trusted software has booted, the running system must also remain protected.
Security considerations may include:
- User and privilege separation.
- Application isolation.
- Kernel hardening.
- Trusted Execution Environments.
- Access control.
- Integrity monitoring.
- Removal or restriction of unnecessary services.
Data and storage
Sensitive information may require protection both while the system is running and when the device is powered off.
Security considerations may include:
- Disk or filesystem encryption.
- Protected key storage.
- File permissions and access control.
- Secure storage.
- Protection of credentials and configuration.
Communication and updates
Connected devices must also protect the interfaces through which they communicate and receive software.
Security considerations may include:
- Authentication.
- Encrypted communication.
- Certificate management.
- Secure OTA updates.
- Update authenticity and integrity.
- Rollback protection.
- Secure remote management.
Security should therefore be evaluated across the complete lifecycle and architecture of the product rather than at only one level of the system.
Security mechanisms have trade-offs
Security mechanisms provide protection, but they may also introduce additional requirements and complexity.
Before implementing a mechanism, consider its impact on:
| Area | Questions to consider |
|---|---|
| Performance | Does the mechanism affect boot time, storage performance, CPU usage, memory usage, or communication latency? |
| Hardware | Does it require a TPM, secure element, protected storage, or another hardware component? |
| Development | How much additional implementation, integration, and testing is required? |
| Manufacturing | Are keys, certificates, fuses, or device identities provisioned during production? |
| Recovery | What happens if authentication fails, a key is lost, or an update cannot boot? |
| Updates | Can the security mechanism be maintained safely throughout the lifetime of the product? |
| Key management | Who generates, stores, rotates, revokes, and protects the cryptographic keys? |
| Maintenance | How will vulnerabilities and security updates be managed after deployment? |
These trade-offs do not mean that security mechanisms should be avoided.
Instead, they should be considered when deciding which protections are appropriate for the risks of the project.
Security features are not independent
Security mechanisms often depend on each other.
For example:
Encrypting the disk provides limited protection if the key required to decrypt it can be easily extracted from the same device.
For this reason, security mechanisms should be evaluated as part of the complete security architecture.
Evaluate the remaining risk
After security mechanisms have been selected and implemented, the project should evaluate what risks remain.
This is known as residual risk.
For each important threat, consider:
- What protection has been implemented?
- How difficult is the attack after the protection is implemented?
- What attack paths still remain?
- What would happen if the remaining protection failed?
- Are there mechanisms to detect or recover from the attack?
- Is the remaining risk acceptable for the intended deployment?
For example:
| Threat | Mitigation | Remaining consideration |
|---|---|---|
| Unauthorized firmware replacement | Secure Boot | Are recovery and update paths also authenticated? |
| Extraction of stored user data | Disk Encryption | How is the encryption key protected? |
| Unauthorized remote access | Authentication and encrypted communication | How are credentials provisioned, protected, rotated, and revoked? |
| Physical debugging | Debug interface restrictions | Is an authorized recovery or debugging procedure still required? |
This step is important because security mechanisms reduce risk; they do not necessarily eliminate it.
So, when is my project secure enough?
There is no universal point at which every embedded system becomes "secure enough."
The answer depends on the project's threat model, deployment environment, risk tolerance, regulatory obligations, and customer requirements.
A practical security target can be considered reached when:
- The important assets have been identified.
- Relevant threats and attack paths have been evaluated.
- Security requirements have been defined.
- High-priority risks have appropriate mitigations.
- Selected security mechanisms have been correctly implemented and tested.
- Regulatory and customer security requirements are satisfied.
- Recovery and update mechanisms have been considered.
- Remaining risks are understood and accepted by the appropriate project stakeholders.
In simplified form:
The objective is therefore not to implement every available security feature.
The objective is to understand the risks of the product and implement appropriate protections until the remaining risk is acceptable for its intended use.
Once the required level of protection has been identified, the next step is to understand the available security technologies and how they can be implemented on the target platform.