10 Pillars of Modern Embedded: Pillar 8–Security
Pillar 8 of the Dojo Five Modern Embedded development practices is Secure: Security as a first-class requirement, accurately implemented
Poor Security
Poor security can have many consequences for your customers and for your company. The news is full of reports of DoS attacks (Denial of Service), system hijacks (taking devices over for unauthorized purposes), and data breaches.
DoS attacks disrupt service and normal business operations rendering them unusable for their intended purpose. For customers, this can range from minor annoyances to critical loss of the ability to operate. Systems may also be subject to ransom to release them back to their owners.
When devices are hijacked, their owners lose control of them. They may then be used for other attacks, such as in botnets for DDoS attacks (Distributed DoS), where large numbers of compromised devices flood other systems with overwhelming network traffic, for example the 2016 DDoS attack on DNS provider Dyn and the recent record-breaking attack on multiple cloud providers.
Data breaches result in exposure of private personal or financial data. This may be used in a variety of fraudulent activities.
Where embedded systems are part of the physical security for things like car doors and ignitions, poor security means they can be accessed or stolen. Where embedded systems provide control of mechanical systems, poor security means they may be used to cause physical damage, excessive wear, or excessive resource consumption.
These issues put your company at risk of business loss due to reputational damage, and can result in lawsuits as well as legal or regulatory actions. The new U.S. Cyber Trust Mark is an example of a regulatory step.
First Class Requirement
Security has long been a second-class requirement if it was even considered at all. It was an afterthought. But modern systems need to put it front and center. It doesn’t matter how well a system functions or performs if it’s been taken over or locked out by attackers.
Security can’t be bolted on at the end. You don’t take a system and “make it secure”. You build it in from the start, because it affects the entire system architecture. Security is not a feature, it is a framework. You build your system around this framework. Every design decision, every architectural component, every path on the PCB and every line of code should consider this.
It’s also easy to get wrong, or to break once you’ve done it right. That requires a constant focus on making design decisions that support security. Everyone on the team needs to understand the threat model and what’s being done about it. Everyone needs to be able to validate the system security at any time.
Make the system secure first, make sure it works properly while maintaining security, then worry about performance–once again while maintaining security.
Security Challenges
Security poses a number of challenges. It’s often dependent on technology that’s changing. Subsequently a system that was secure initially, becomes insecure due to technological advancements. A secure system today may be insecure tomorrow.
One risk to avoid is relying on “security by obscurity”, where it’s assumed that attackers don’t have the information or technical capability to breach it. That is until they do, leaving the system wide open.
Security is also dependent on the resources that attackers are able to apply. An appropriate level of security depends on what’s being protected and who the potential attackers are. It’s important to build a threat model to balance the security requirements and measures taken.
The harsh reality is that it’s virtually impossible to secure a system indefinitely against all possible attacks. Nation-state attackers are able to apply vast resources beyond what most companies are able to protect against. Instead, companies should focus on a reasonable approach. They should determine their security stance and budget for it. Zero security is not reasonable.
Security is, first and foremost, a budgetary decision. How much is it going to cost to break this? How much is the hacker going to benefit from it? How much am I going to lose if an attacker breaks my system? Put everything on a scale and then you can decide how much money you should invest in hardening.
Security is also complex to implement. Getting it right and keeping it right over time as new features are added takes continuous attention to detail. It’s easy for one area to undermine the security of the rest of the system. That’s why everyone needs to understand the threat model and keep it in mind as they work.
Physical access to systems also complicates security. If attackers are able to reach internal interfaces, that exposes a number of potential attack points.
Recent auto thefts via CAN bus are an example of the dual challenges of changing technology and physical access. The CAN bus provides communications between electronic devices that control various vehicle functions. This initially provided a degree of security due to its technical complexity.
However, that has changed with the availability of small, cheap CAN injector devices. Thieves are able to vandalize a vehicle to gain physical access to its CAN bus, then send control messages to direct the vehicle to unlock its doors and start its engine.
What was previously a highly sophisticated electronic security and control system, becomes the very means by which the thieves steal the vehicle.
This also illustrates why security needs to be multi-layered, assuming that outer layers of security can be breached. In this case, because the CAN bus messages are not encrypted or authenticated, it’s easy to send unauthorized commands once attackers have the technical capacity to send data on the bus.
Security Auditing
Security audits are part of the active process of implementing security. Auditors examine the system for a variety of vulnerabilities and recommend practices and mitigations to avoid them.
Auditing needs to be a regular activity, from initial system design through operation over time. This ensures that both current and emerging threats are addressed.
Audits may cover the physical electronics of a device, including its various internal and external debug and control interfaces, source code and coding practices, use of security features, communications systems, and management of security information such as device keys.
They also check for a variety of common vulnerabilities and bad practices, such as using a hard-coded default password, using a cryptographic key that is actually published in the example code for a security library, using the same key for all fielded devices, risk of buffer overflows, etc. Detailed knowledge of past security failures provides a checklist of the bare minimum that needs to be done.
Threat assessments evaluate the set of potential threats and attackers for a system. They are used to develop and maintain the threat model, as well as guide the investment of resources for security.
Penetration testing performs active measures against a system to try to defeat security. This mimics the same attacks real hackers will use.
Effective auditing, assessment, and testing require a different mindset from development. System design and implementation require a mindset of building and making things work– including making the security features work. Auditing, assessment, and testing require a mindset of breaking and defeating things; including misusing and abusing them to break the security. A feedback loop between these two mindsets helps create effective security.
Ideally, the audit should be done by an external team, as external as possible. In an ideal world, a third party should do it. The idea is to have a second pair of eyes look at your system.
Automated Tools
Automated tools can perform static analysis of code, penetration testing of systems, and scanning for vulnerable systems. See Pillar 4 “Effective Testing”.
This includes HIL (Hardware In the Loop) for blackbox or greybox testing (see Running up that HIL: A Guide to starting with HIL).
Making these part of the development process ensures that all developers maintain a security awareness as they work. They can be used in a TDD (Test-Driven Development) fashion to keep new features from breaking security (see Unit Testing For Embedded Software Development).
Interested in learning more and ensuring your team is utilizing best practices in security for embedded systems? Give us a call–we have talented engineers on hand ready to help you with all aspects of your firmware development projects.
recommended additional reading
The Open Worldwide Application Security Project (OWASP) Top 10 list is updated every few years to highlight the top 10 security vulnerabilities in systems. While it’s focused on web applications, many of the same issues apply to embedded systems connected to communications networks.
Cryptography Engineering: Design Principles and Practical Applications by Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno is a very readable introduction to cryptographic security and how to apply it.