Mission-Critical Iot Systems: Cybersecurity Principles
In creating an effective cybersecurity strategy for IoT systems, software architects examine obstacles that limit the security options for their target systems.
To deliver a proactive cyber defense without risking business continuity, cyber threat protection must overcome:
- Business continuity interruption due to remediation lag
- Zero-day and day-one attacks
- False positives
- Slowed performance
The obstacles that hinder cybersecurity for IoT systems must be addressed to achieve the level of security and performance needed in these systems.
With this goal in mind, we have identified five primary defense strategies:
- Automatically-generated multi-dimensional allow lists
- Automatically-embedded access control
- Automatically-embedded Control-Flow Integrity
- Enabling vendor-sourced updates
- Eliminating developer disruption
The solution involves hardening mission-critical IoT systems to their factory settings, where each layer of protection seals the device’s software against different types of attacks.
Automatically-generated multi-dimensional allow lists
To overcome multiple challenges, the backbone of cybersecurity should be deterministic (a detailed look at Deterministic Security can be found later in this article.)
Such solution leverages the deterministic nature of IoT systems. Any change, which was not authorized by the system’s vendor must imply a hacking attempt. Hardening the binaries against changes and deterministically preventing any unauthorized attempt to change them means stopping hackers before they succeed in exploiting zero-day or day-one attacks.
Allow-list of executables
The allow-list enforcement component should integrate with the OS program-loading and file-access services. All executables can be checked against the allow list, including files (operating system and applications), shared objects, and scripts. Each time any binary is loaded, its unique signature is calculated based on the content of the file and compared to a database of approved application signatures.
If the binary is on the allow list, it is permitted to run. If not listed, it is not a legitimate component originating within the device’s factory settings. As soon as malicious code attempts to be loaded to memory, the security filter stops the binary from loading.
An additional dimension of protection can allow for definition of associative execution, in which only specified applications are allowed to run each of the executables on the Allow List.
This security policy is signed with a private key to prevent tampering. The signed policy and the public key can then be embedded in the device.
Automatically-embedded access control
A protected application should perform a set of finite operations, as defined in the systems’ production software.
When applying the protection, it should be possible to specify files that will have restricted operations and access during runtime. Selected applications, identified by their hashes, can be granted access to restricted operations on the protected files.
For example, it should be possible to block remove, chmod and chown operations, and limit Read and/or Write access as needed.
Automatically-embedded Control-Flow Integrity (CFI)
CFI is essentially an allow-list at the function graph level for the application. It enables performing real-time integrity validation of function calls and function returns, to make the system self-defending and impervious to in-memory attacks such as buffer overflows and heap overflows.
A static analysis engine is used to analyze the binaries (not the source code) of the build. The engine then automatically maps all valid function-call sequences and call locations. With this call graph, the CFI engine ensures in runtime that only legitimate function calls are executed. It also blocks any attempt to load malware directly into memory.
The resulting system is no longer a potential attack surface. Once a deviation of a function call or a return pointer from the pre-defined control flow graph is identified, it deterministically infers an attempt to exploit an in-memory vulnerability within the device’s software. Proactive measures can then be taken to prevent the attack before it takes control of the targeted device.
Enabling vendor-sourced updates
Cybersecurity “overkill” needs to be avoided. If a protection mechanism is designed to block all changes blindly, it would block legitimate software updates made by the vendor. When a feature is added or enhanced, the security solution must be flexible enough to allow these updates and generate corresponding policy changes.
The update mechanism should be able to incorporate new validation rules seamlessly any time the software of the IoT device is updated, so that new components are allow-listed in the same secure manner as they were during the original build.
Eliminating developer disruption
There is an inherent conflict between better security and the need to shorten development life cycles to increase the competitive position of the product. Any solution must harden the system without developer intervention, and without adjusting development processes.
Why Is Autonomous, Deterministic Security Crucial?
Deterministic security is superior to heuristic security: deterministic validation is a distinct outcome of given circumstances, while heuristic conclusions are based on past statistics and learned behavior patterns. It is not feasible, however, to aim for deterministic protection in all types of systems and scenarios. Heuristics are therefore applied in cases where deterministic security cannot: Where changes occur frequently, and a safe baseline (“known good”) cannot be established, let alone be identical across many systems.
Heuristic methods, and related analytics and machine- learning techniques, have become the de-facto standard in IT/cloud environments, for enterprises or data centers. However, this approach fails when it is applied to environments in which it cannot deliver: namely, constrained environments. In environments such as connected/IoT devices, routers, gateways, or ECUs in vehicles, heuristics can increase risk rather than reducing it.
The cybersecurity approach must be adapted to the target environment it is protecting. The IT/DataCenter/Cloud environment is resource-rich while the IoT device environment has limited CPU speed, I/O throughput, storage and memory capacities. Newly-deployed applications on data center servers and endpoints are diverse, while those of IoT systems are limited and pre-defined. In addition, data centers can rely on continuous internet connectivity and frequent updates, and IoT devices cannot.
While in IT environments there are countless combinations and configurations, with constant updates and tolerance of a certain degree of error, networking-device and closed environments are resource-constrained, cannot rely on internet updates, and run a defined set of functions within limited space.
For a mission-critical IoT system, it is possible to define a “known- good” configuration (“factory settings”), and define a deterministic security policy, whereas each deviation from this known good can be deterministically prevented.
By automatically hardening the system at the binary level, Autonomous Security aims to create self-protecting devices. This solution reduces the need to urgently patch against newly-discovered attacks, which are deterministically prevented as changes to the device’s original binaries. The need for updates and day-to-day management, which impede both product roll-out and subsequent maintenance, is thus significantly reduced.
Turning Strategies Into Effective Protection
The Autonomous Deterministic Security model puts the conclusions drawn above into practice, effectively removing security constraints to create self-protecting devices.
Deterministic Security can protect devices against hacking attempts automatically, including zero-day attacks and exploits of known, unpatched, vulnerabilities. It does not require developers’ intervention, and does not delay product time to market.
Deterministic Protection: Embedding Native Security
Unlike laptops and servers, IoT systems are immutable. The binary code in a device can thus be sealed to prevent unauthorized changes; Only the vendor is able to modify the device, when needed. In this way, cybersecurity remains stable over the life of the device, significantly reducing the need for continuous malware signature updates and security patches.
Measuring Performance
Cybersecurity protection cannot be added to IoT systems at the expense of hampering functionality due to slow performance. Any proposed solution must be tested for acceptable levels of added processing associated with validation. There are also additional memory requirements for data structures accessed by validation code.
Impact can be estimated by a set of performance indicators, an increase in file system size, and/or a decrease in available system RAM. Final system-performance tests ensure that measurements remain within the product performance specification’s allowed limits after security is added.
Incident Response and Forensic Reporting
The Autonomous Deterministic Security mechanism can issue instantaneous threat alerts as soon as an attack is detected and blocked. These alerts identify which part of a system is being attacked, to inform the incident response team.
In accordance with best practices, self-protected solutions record any anomalous activity or attempts to access systems. These incident logs are then sent to forensic experts for analysis.
With this goal in mind, the following elements can be logged to create a detailed threat analysis report:
- File system operations
- Network operations
- Process and thread operations
- Debugging attempts
This information is used to create analytic reports that include all forensic data collected on the system around the time of the attack, including:
- The exploited process
- External connections involved
- The type of attack (e.g., malicious application or code injection)
- The malicious binary trails in the file system
This type of data enables software developers to identify and fix the vulnerabilities that leave mission-critical systems exposed to potential threats.
Anti-Tampering
Any cybersecurity solution must protect itself against any attempts to modify its own policies, remove enforcement engines, or hide malicious activities.
This type of immutability can be achieved through a combination of software and, when available, hardware capabilities that verify the integrity of the policies and protection mechanisms.
Ease of Deployment
Another practical aspect of Autonomous Security relates to the time and budget constraints under which software developers operate. With a cybersecurity tool that automatically develops a customized security policy, there is no prerequisite training for the development team. The software build is enhanced automatically with allow-listing on multiple levels, and optimizations are put in place at the binary level.
Automating Protection for The Life Of The Device
The build process that includes an effective security solution must meet these security requirements without placing a burden on software developers. Developers should not be required to learn how to deploy, configure, and manage cybersecurity solutions; nor expose the product to coding errors that could produce new vulnerabilities.
Cybersecurity solutions must be lightweight, since most resource-constrained devices are overloaded. Any security process that significantly increases the usage of the RAM or significantly degrades CPU performance will impact system operation and may result in compromised functionality.
For these reasons, we recommend the described lightweight embedded solution that automatically generates the security policy during the software build process. Overhead is minimized, so there is negligible performance penalty in both original and updated releases.
Conclusions
Manufacturers following Autonomous Deterministic Security guidelines can achieve unparalleled protection of mission-critical IoT systems, while complying with industry regulations and standards.
Deterministic embedded solutions provide numerous advantages:
- Installed and operated without the need for developer resources or ongoing administration
- Harden system binaries against foreign code or unallowed changes in runtime
- Reduce the risk of false negatives and false positives
- Provide immunity to zero-day and day-one in-memory and dropper attacks, regardless of unpatched vulnerabilities.
- Can protect software running in containers and on hypervisor VMs
- Automate the security development process, reducing the time to market
- Operate 24/7 without human intervention or Internet connectivity
- Deliver detailed threat data for comprehensive forensic analysis
- Secure embedded systems over the lifetime of the device
About Karamba Security
Karamba Security is the world leader in End-to-End product security for Automotive and IoT devices. Mission-critical IoT product manufacturers such as HP, Samsung SDS, Volvo, Stellantis and Hitachi rely on Karamba’s products and services to seamlessly protect their IoT devices against cyberattacks.
Karamba’s award-winning software enables IoT device manufacturers to secure their products against cyberattacks and meet industry regulations without interfering with their R&D teams or delaying their products’ time to market.
About the Author
Tal Ben-David is the VP R&D and Co-Founder of Karamba Security. He has over 25 years of experience in software development for high-scale, customer-facing security products. At Karamba, Tal manages the development, delivery and customer success of Karamba’s embedded security and posture management products, which are deployed in millions of devices globally.
Tal can be reached online at [email protected]/ and at our company website https://karambasecurity.co/m/.