Earlier this year, Barr Group’s Embedded Systems Safety and Security Survey uncovered that of the embedded systems projects currently under development, approximately 25% of the designs with internet connections are part of what we call “The Internet of Dangerous Things”—projects that can kill or injure someone. We also asked these designers if security requirements are part of their design spec. A shocking 22% said no. That’s right—22% of the designers of connected devices that can potentially kill or injure a person don’t have any security requirements for their projects at all. This is a problem.
Mirai. Brickerbot. Stuxnet. These are just a few of today’s viruses and worms to attack vulnerable embedded systems and IoT devices, and the list is growing. Now, we know that for legacy systems, our ability to patch every potential point of entry will be impossible. However, for all current and future embedded systems, there’s no excuse. Security is now a necessity. And as a designer of embedded systems, choosing to ignore security in our projects makes us part of the problem.
So how can we fix this? Here are six points to consider:
1. Don’t Ignore Security!
As stated in the Association for Computing Machinery (ACM) and IEEE’s code and rules of ethics, as professional embedded-systems engineers, we have an ethical duty to NOT ignore security. In ACM code of ethics Rule 1.2, entitled “Avoid Harm to Others,” the document emphasizes the importance of using best software practices. Also discussed is the necessity for engineers to assess the “social consequences” of the systems, and our obligation to “blow the whistle” when either members of the development team or management intentionally neglect to take action to correct a product’s known safety-related risks. This is especially important for projects where end users could be killed or injured due to product failure.