Today’s cybersecurity landscape is confusing and difficult to navigate. There are thousands of vendors selling different flavors of security solutions for embedded systems and networks.
Solutions range from antivirus software to encryption to intrusion detection systems to compartmentalization, and beyond.
All of the above have value in our war against cybersecurity threats, but what’s the difference between them? And what are the best solutions to protect embedded systems?
The big problem
First, let’s remember that one of the major reasons our systems are vulnerable is because they run software — and all software is flawed. On average, there are approximately 15 bugs per thousand lines of code, and about 10 percent of these bugs can be turned into exploitable vulnerabilities1.
Network-based attacks can take over a device’s processor by exploiting software vulnerabilities in the application or operating system. Threats include buffer overflow attacks, control-flow hijacking, and code injection; these three classes of attack combined represent 90 percent of today’s network-based attacks.
So, which of the many different cybersecurity solutions available today will best protect embedded systems from attacks that prey on software vulnerabilities?
Cybersecurity software is, well, software. And because it’s software, it’s inherently flawed. Even modestly-sized cybersecurity software totals up to one million lines of code. That’s 1,500 exploitable vulnerabilities in software that is supposed to act as protection. More sophisticated intrusion detection systems are ten times that.
Software has bugs and layering buggy software on top of buggy software is not a good idea. It just leaves companies and individuals more exposed.
Encryption & cryptography
When a vendor says they have a “secure processor,” what they mean in today’s world is that they have added encryption and maybe cryptographic key management to a standard processor or in a specialized co-processor. They do this in hardware to make it faster than running encryption software on the standard processor.
This is an example of communications security. Their “secure processors” ensure that any data going to and from the device is encrypted, making data theft or exfiltration impossible, or at least a huge amount of work for an attacker.
Encrypting communication is important and even vital in many situations, but it doesn’t warrant calling the processor a “secure processor” because it doesn’t protect against attacks that prey on software vulnerabilities.
Attackers can still exfiltrate data by bypassing encryption routines. An attacker can exploit a software vulnerability, execute a buffer overflow, inject code, and take over the processor. Once they have done that, securing communications is meaningless.
Some vendors offer processors with added security in the form of compartmentalization. This means they create isolated compartments inside of memory to separate trusted and untrusted areas. As a result, if an attacker can infiltrate the system, they are confined to one compartment, constraining the amount of damage possible.
Compartmentalization may limit an attacker’s impact, however, it does not protect against the exploitation of software vulnerabilities in the first place. And it doesn’t stop an attacker from finding and exploiting a vulnerability in the “trusted” area of memory — especially since, in practice, people are putting more and more code into these trusted areas that are still subject to the 15 bugs per thousand lines of code rule.
Embedded devices need embedded security
The cybersecurity problem must be addressed at the root cause: the attacker’s ability to take over the processor in the first place.
Today’s processors, however, are highly vulnerable because they are based on Von Neumann’s 1945 Stored Memory Processor architecture. Over the years, the architecture has been optimized to be smaller, faster, and cheaper, but security has never been part of the mix.
Von Neumann’s architecture doesn’t account for the additional information a processor needs to ensure that it does only what the application designer intended. Processors will blindly execute the instructions they receive, and they have no way of knowing whether an instruction came from a trusted source or a malicious attacker.
Complex software will always have exploitable bugs because software is written by humans and humans make mistakes. Our processors need computing security. They need to be modified to make them immune to attacks that prey on software vulnerabilities. They need to be given the intelligence to distinguish between good and bad instructions, and the ability to stop malicious instructions at the processor-level before any damage can be done.
The bottom line
Our world of IoT and embedded devices is highly vulnerable and under attack, and as the number of connected devices increases, so does the volume and sophistication of cybersecurity risks.
Security must become a priority. Our devices need both communications security and computing security.
We need to secure our communications so people can’t siphon off corporate or national secrets, or steal identities and other personally identifiable information. Communications security is accomplished by using well-established cryptographic algorithms to encrypt and decrypt communications.
We also need to secure our computing devices to protect against the inevitable and unavoidable vulnerabilities in software that enable attackers to hijack processors. That’s computing security. As Larry Ellison, CTO and Chairman of Oracle noted, “Even the best hackers have not figured out a way to download changes to your microprocessor … You can’t alter the silicon.”
Security at the process level — and the systems they are embedded in — is essential to creating an immunity to the cyberattacks of tomorrow.
Jothy Rosenberg is CEO & Founder of Dover Microsystems. As a serial entrepreneur, Dover Microsystems is the 9th tech startup that Jothy has founded and/or run since 1988. Earlier in his career, Jothy ran Borland’s Languages division where he managed development of languages including Delphi, C++, and JBuilder. He earned his BA in Mathematics from Kalamazoo College and his PhD in Computer Science from Duke University.
1Maguire, Steve. Writing Solid Code. Microsoft Press, 1993.