Embedded device cybersecurity is relatively new compared to our friends with the “big iron” in Managed Information Systems (MIS), so while there are many differences between the two domains, there are a few common concepts, tools, and techniques that we can modify for use in the embedded world.
MIS has had years of “teachable moments” (read: “abuse by hackers”) from which they have created techniques to manage before, during, and after an attack. While there are still a lot of unsecured MIS organizations it isn’t for a lack of known best practices to follow.
So, let’s look at some of the most obvious general attributes of cybersecurity and MIS:
- Solutions are bought, not created
- Can't extend or customize a solution beyond its initial functionality
- Don’t have to worry about physical security - just lock the door to the server farm
- Work with established communication standards; proprietary protocols don’t get much traction
- Cybersecurity is about detecting “data in motion.” Who is moving it? Where is it going?
- Logs can be monitored from security appliances to detect attacks in progress
- Benefit from sharing attack information among peers, because attacks are against commonly-used infrastructure and protocol standards
- Not constrained by CPU throughput or power to run those CPUs
- No tight timing requirements to be met (communications timings are not deterministic)
- Operating systems, communications, and hardware are not designed to be secure
- Operating system vulnerabilities can be used against them
- Application software and database vulnerabilities can be used against them
- Applications and implemented security solutions can be frequently updated
- Denial of service is a big threat
- Little to no control of their end points or what software users will load onto those end points
Most of these attributes are not guaranteed to be useful in the embedded domain.
In general, MIS treats their domain as a ‘naturally occurring object’ to which security mitigations are added as an afterthought.
That same list for our embedded devices looks something like this:
- We buy, modify, and create our own solutions
- Physical security is a big vulnerability
- We don’t always have to work to established standards
- We have to protect “data in motion” as well as “data at rest”
- We rarely know if an attack is in progress, or if it has even occurred in the past
- Sharing with peers doesn’t help: we should already know all the possible weaknesses
- We have constrained CPU throughput
- We may have constrained power output – often limited by battery life
- We usually have to comply to tight timing requirements
- We have to make all “links in the chain” secure. We don’t have a DMZ
- If we have an operating system, its vulnerabilities can be exploited
- Our application software vulnerabilities can be used against us
- Our products have long lives in the field, typically 10 to 20 years
- Our products are difficult to update in the field, and updates introduce new vulnerabilities
- Our products have many other requirements, unrelated to security, which are not dispensable due to security-based concerns
- Allowance for casual denial of service periods is usually designed into every embedded system. We have to anticipate scenarios such as battery failure and low power wireless communication failures
- We usually don’t allow users to select and load new software onto our devices
Wow, all those differences and yet we still refer to both domains with the same names of “cybersecurity” or “information security” (InfoSec). Could they be any more different?
This is one of the reasons why InfoSec committees who meet to discuss aspects of securing embedded devices usually miss the mark, because a large percentage of the participants come from an MIS background, not an embedded device background.
In general, the embedded domain is treated as a “customized work of art”, with the majority of the requirements proprietary to the manufacturer. This means we can add InfoSec mitigations to this work of art as it is being created, resulting in a more robust, secure device that doesn’t put additional burdens upon the end user.
In the coming blogs posts here I will address where we can borrow “tools and techniques” from our MIS brothers and sisters, as well as point out techniques unique to the embedded system domain, in order to deliver a secure embedded system.