Basic Concepts of RidgeRun Platform Security Manual

🚧 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.

RidgeRun Platform Security Manual from RidgeRun

Contents Pin

What do I need before securing my project?

Before selecting security mechanisms, it is important to understand what the system needs to protect and the threats it may face.

Security is not a one-size-fits-all solution. Two products using the same processor or operating system may require very different security architectures depending on what they protect, where they are deployed, who can access them, and the consequences of a compromise.

A useful starting point is to answer the following questions:

What needs to be protected?
Who could potentially attack the system?
What level of access could an attacker obtain?
Which interfaces could be used to attack the system?
What would be the impact if the system were compromised?
Which regulatory or customer requirements apply to the product?

Answering these questions provides the context needed to identify the security requirements of the project and, later, select appropriate security mechanisms.

What needs to be protected?

The first step is identifying the assets of the system.

An asset is anything whose disclosure, modification, destruction, loss, or unauthorized use could negatively affect the product, its users, or the organization operating it.

In an embedded system, assets may include:

User data: Personal, confidential, or application-specific information.
Credentials: Passwords, certificates, authentication tokens, API keys, and other authentication information.
Cryptographic keys: Keys used for encryption, authentication, firmware signing, secure communication, or device identity.
Software and firmware: Bootloaders, operating systems, applications, firmware, and device configuration.
Intellectual property: Proprietary algorithms, AI models, source code, or other product-specific information.
Device identity: Certificates, unique identifiers, provisioning information, and other information used to identify a device.
System configuration: Network configuration, security policies, application settings, and calibration data.
System operation: The expected behavior and availability of the device.
External systems: Cloud services, networks, infrastructure, or other devices that trust or communicate with the product.

Not every asset requires the same type of protection.

For each important asset, consider which security properties must be preserved:

Security property	Question to consider
Confidentiality	Should unauthorized users be prevented from reading this asset?
Integrity	Should unauthorized users be prevented from modifying this asset?
Availability	Does this asset or service need to remain accessible and operational?
Authenticity	Does the system need to verify the identity or origin of this asset?

For example, a firmware image may not need to be confidential, but its integrity and authenticity may be critical. The device may need to ensure that the firmware has not been modified and that it originates from an authorized source.

Identifying the assets and their required security properties helps determine what the security architecture must protect.

Who could potentially attack the system?

Once the assets have been identified, the next step is to consider who may attempt to access or compromise them.

Potential attackers can have different motivations, capabilities, resources, and levels of access. Understanding which attackers are relevant to the product helps avoid designing the system around unrealistic assumptions.

Examples of potential attackers include:

Potential attacker	Example
Remote attacker	An attacker attempting to access the device through the Internet, a cloud service, or an exposed network service.
Local network attacker	Someone with access to the same Ethernet, Wi-Fi, or other network as the device.
User with physical access	Someone who can physically interact with the product and access USB, storage, serial, debug, or other exposed interfaces.
Privileged user	A legitimate user, technician, developer, or administrator with authorized access who may intentionally or accidentally misuse that access.
Supply-chain attacker	An attacker is able to modify software, firmware, dependencies, updates, or hardware before they reach the final device.

A project does not necessarily need to protect against every possible attacker.

Instead, consider which attackers are realistic for the intended deployment environment and what capabilities they may have.

For example, a device installed in a physically restricted environment may have a different threat model from a consumer product that an attacker can purchase, disassemble, and analyze without time restrictions.

What level of access could an attacker obtain?

The attacker's level of access strongly influences which attacks are realistic and which protections may be necessary.

It is useful to consider several possible levels of access.

Remote access

The attacker can communicate with the system remotely but cannot physically interact with the device.

Possible attack paths may include:

Network services.
Web applications or APIs.
Cloud interfaces.
Remote management services.
OTA infrastructure.
Exposed application services.

In this scenario, the attacker may attempt to exploit a vulnerable service, obtain credentials, intercept communication, or send unauthorized commands to the device.

Local network access

The attacker has access to a network to which the device is connected.

This may allow the attacker to:

Discover exposed network services.
Communicate directly with the device.
Intercept unprotected communications.
Manipulate unprotected network traffic.
Attempt authentication attacks.
Exploit vulnerable network services.

A service that is not accessible from the Internet may still represent an attack path if an attacker can gain access to the local network.

Physical access

The attacker can physically interact with the device.

Depending on the hardware design, this may provide access to:

USB ports.
UART or serial consoles.
Debug interfaces such as JTAG or SWD.
Removable storage.
Internal storage devices.
Boot configuration pins or switches.
Internal buses.
Exposed connectors.
Recovery or flashing interfaces.

Physical access can significantly change the threat model.

An attacker with physical possession of the device may be able to inspect hardware, remove storage, connect debugging equipment, modify boot media, or attempt to extract information directly from hardware components.

For this reason, assumptions that are reasonable against a remote attacker may no longer be valid when physical access is possible.

Privileged software access

It is also useful to consider what would happen if an attacker successfully compromised part of the software stack.

Possible levels of software access include:

Application-level access.
User-level operating system access.
Root or administrator access.
Kernel-level access.

A security architecture should consider whether compromising one software component automatically exposes every asset in the system or whether additional security boundaries remain in place.

For example, obtaining root access to the operating system should not necessarily imply that an attacker can extract every cryptographic key used by the device.

Which interfaces could be used to attack the system?

After considering attacker access, identify the interfaces through which the system can be reached.

Together, these interfaces form part of the system's attack surface.

An embedded device may expose several types of interfaces:

Category	Examples
Network	Ethernet, Wi-Fi, TCP/UDP services, SSH, HTTP/HTTPS, APIs.
Wireless	Bluetooth, NFC, cellular, or other radio interfaces.
Physical	USB, UART, removable storage, exposed connectors.
Debug	JTAG, SWD, debug UART, or manufacturer-specific debug interfaces.
Software	Operating system services, applications, drivers, libraries, and third-party dependencies.
Cloud	Cloud APIs, device-management platforms, authentication services, and remote commands.
Update mechanisms	OTA updates, local firmware updates, recovery images, and provisioning mechanisms.
Hardware	External flash, internal buses, boot configuration interfaces, sensors, and peripherals.

An interface does not automatically represent a vulnerability. However, every accessible interface should be evaluated.

For each interface, consider:

Who can access it?
Is authentication required?
Is communication protected?
What operations can be performed through the interface?
Can it read or modify sensitive information?
Can it modify the system state?
Can it provide access to another security boundary?
Is the interface required in the production device?

The last question is particularly important for embedded products.

Interfaces that are useful during development, manufacturing, or debugging may not need to remain accessible after the device enters production.

Reducing unnecessary interfaces can reduce the number of possible attack paths that must be protected.

What would be the impact if the system were compromised?

Not every successful attack has the same consequences.

After identifying the assets, attackers, levels of access, and possible attack paths, consider what could happen if an attacker successfully compromises the system.

Potential consequences may include:

Consequence	Example
Data exposure	Confidential, personal, or sensitive information is disclosed.
Data manipulation	Configuration, measurements, records, or stored information are modified.
Unauthorized software execution	Modified or unauthorized software is executed by the device.
Credential or key extraction	Security credentials are obtained and potentially reused to attack the device, cloud infrastructure, or other systems.
Loss of availability	The device or service can no longer perform its intended function.
Unauthorized control	An attacker can change the physical or logical behavior of the system.
Intellectual property exposure	Proprietary software, algorithms, AI models, or other intellectual property are extracted.
Lateral movement	The compromised device is used as an entry point to attack other connected systems.
Safety impact	Compromise results in unsafe physical behavior or creates a risk to people or equipment.
Business impact	The incident results in financial loss, operational downtime, reputational damage, regulatory consequences, or loss of customer trust.

The severity of these consequences should influence how strongly the associated assets need to be protected.

For example, compromising a development device in a controlled laboratory may have limited consequences. Compromising similar hardware when controlling industrial machinery, processing medical information, or operating critical infrastructure may have a much greater impact.

The same vulnerability can therefore represent very different levels of risk depending on the environment in which the product operates.

Which regulatory or customer requirements apply to the product?

Security requirements are not determined only by technical risks.

Depending on the product, industry, deployment region, and customer, additional requirements may come from:

Cybersecurity regulations.
Industry-specific standards.
Privacy and data-protection requirements.
Customer security requirements.
Corporate security policies.
Certification requirements.
Requirements imposed by system integrators.
Requirements imposed by cloud or infrastructure providers.

These requirements should be identified early because they may influence the architecture of the product and the protections that must be implemented.

For example, a customer or regulation may require:

Protection against unauthorized firmware.
Secure software updates.
Device authentication and identity.
Protection of cryptographic keys.
Encrypted communication.
Protection of stored sensitive information.
Vulnerability management.
Security update support.
Restrictions on debug access.

These requirements should become part of the project's security requirements together with those identified through the analysis of assets, attackers, attack surfaces, and impact.

Putting everything together

The previous questions should not be considered independently.

They can be combined to describe a threat scenario and determine what the system needs to protect against.

A simple way to reason about a threat scenario is:

Notice that the security mechanism has not yet been selected.

At this stage, the objective is to define what the system needs to guarantee, rather than immediately deciding which technology should be used.

For example:

Once the security requirement has been clearly identified, the appropriate security mechanism can be selected later in the design process.

This approach helps avoid selecting security technologies simply because they are available on the platform. Instead, each security mechanism should address a specific requirement or identified risk.

From threats to security requirements

After completing this initial analysis, the project should have a clearer understanding of the elements. These elements can then be transformed into concrete security requirements.

Examples include:

Identified concern	Example security requirement
Unauthorized firmware modification	The device shall execute only authorized and unmodified firmware.
Extraction of cryptographic keys	Sensitive cryptographic keys shall not be directly accessible to normal application software.
Unauthorized access to stored user data	Sensitive stored information shall remain confidential if the storage device is removed.
Unauthorized remote commands	Remote commands shall be accepted only from authenticated and authorized entities.
Manipulation of software updates	The device shall verify the authenticity and integrity of an update before installing it.
Production access through debug interfaces	Debug access shall be restricted according to the production security policy.

At this point, the project has moved from asking:

"What security features does this platform provide?"

to asking:

"What security guarantees does my project actually need?"

This distinction is important.

Security mechanisms such as Secure Boot, hardware-backed key storage, Trusted Execution Environments (TEE), TPMs, disk encryption, secure communication, secure OTA updates, and debug protection are tools for satisfying security requirements. They should not be treated as requirements by themselves.

However, identifying a security requirement does not mean that every possible threat must be eliminated or that every available security mechanism must be implemented.

The next step is to evaluate which risks require mitigation and what level of protection is appropriate for the project.

Next: When is my project secure enough?

❯

Share This Page

Send Email Using