ELECTRICAL AND COMPUTER ENGINEERING DEPARTMENT HEADS ASSOCIATION

November 2018

Featured Article


Engineered Cybersecurity and the Internet of Things
By: Christopher C. Lamb, University of New Mexico

Just about anyone today can recognize that we are on a downward trend with respect to the security of our computer systems. Not only are we undergoing a drastic changes in how systems are compromised, the nature of those compromises is changing for the worse as well. Cybersecurity flaws are exploited by various governments1  as well as criminal elements, and criminal elements are becoming more organized2. The overall pace of compromise is growing, as is the cost levied against us all as our information is stolen, our credit cards copied, and our credentials reused by attackers. We have become more dependent on the internet than ever to deliver our movies, our music, and to order the things we need. If we are going to continue to use the internet as we do today for the next decade, we need to rethink the importance of security in everything we design and build.

Fortunately, much of what affects the market today stems from problems we have already solved. While we are not likely to fix the problems we do not yet know of, we can certainly do something about the ones we can recognize, especially ones we have already recognized and fixed. And there is much more of this than you would think, particularly when building, configuring, and delivering system software.

And particularly if we are dealing with the Internet of Things.

IoT devices are remarkably similar to consumer-grade networking equipment. They are installed in people’s homes, by people who are non-technical, and just want the stuff they bought to work. And yet, we seem to be convinced that we need to recreate the same flaws in IoT equipment that we solved with networking equipment years ago.

For example, IoT equipment is frequently delivered using old, out of date system software, using homegrown protocols, and non-existent encryption3. We can and do better than this in other areas - there’s no excuse for this today. As of 2018, we deliver networking equipment with unique administrative passwords. We implement strong encryption. We require HTTPS. We can implement secure solutions - we just decide not to.

IoT projects can and should draw heavily from established software development practice. We need to implement strong code practices to ensure secure code production (as we do with other attributes, like performance and usability, of course), as we have been doing for years in other domains. This is pure software engineering practice. We can use code reviews, secure coding practices, and automated analysis tools to help ensure appropriate design and implementation.

There is a wide variety of secure code auditing tools that exist today that have been widely used in other areas. Two of the most common tools (for the C programming language at least) are ITS4 and RATS. Both of these tools are fairly simple. ITS4 can generate a fair number of false positives, and neither tool will detect design flaws, but they will find things like buffer overflows and race conditions.

We have a wide variety of dynamic analysis tools we can use as well. Valgrind is still one of the best dynamic analysis tools available, and it is free. Another approach that experienced engineers can use is to build a set of macros that will allow you to compile your code for x86 based processors. IoT processors very rarely use the x86 architecture as it’s just too expensive for these kinds of applications, so we will generally be targeting ARM or MIPS architectures. Some of these architectures are remarkably different from x86, and may in fact use extensions or alterations to the C language. Being able to compile this code for x86 can make dynamic analysis something you can integrate into your a development build system rather than something run on development boards.

This applies to embedded operating systems as well. Prior to deployment, we need to understand the attack surface of the entire system, not just the code we might write to run on that system. And we need to minimize this attack surface as much as possible. In systems where we have more control over running code, this can be significantly easier. When you’re configuring an operating system for an IoT device, things can become more complicated. We must understand exactly what is installed in the operating system, and we need to ensure that it only contains services the device  needs and will use.

This means that we need to ensure that SSH is removed, as well as FTP, TELNET, and the like (unless we have specific reasons to include them). We may need to embed some kind of web server, but if we do, we need to know exactly how it works and install the most recent version possible. We need to be deliberate in how we configure these systems, and not blindly accept any configuration defaults. Just like we do with low-cost networking equipment today.

After all, we understand and have been working with secure coding standards and rigorous development processes for decades. As a community, we know how to do these kinds of things, we just choose not to do them in IoT applications. That right, choose.

But why would we choose not to?

Well, we have a long list of excuses. We are too busy, or the product does not have enough budget, or the project margins are too small to justify significant engineering effort. As IoT devices become more prevalent in our homes, and start to migrate into industry (as the new buzzword industrial internet-of-things seems to indicate they will), this approach will become less and less supportable. The odds of a significant lawsuit involving a compromised cloud camera trained on a driveway is much lower than that for a similar camera used to monitor water levels in a water treatment plant. Of course, we don’t need to wait for such a lawsuit to force us to start securing systems - we can just do things the right way today instead.

Like most things, the majority of cybersecurity work is not glamorous - it’s just good hygiene. And today’s engineers need to be taught what this means. Most engineers are going to focus on ensuring a project is functionally complete, and evaluate progress on how quickly and how well they can deliver that functionality. But good cybersecurity is related, and doesn’t take that much extra focus. Students need to learn how to review code; what library calls aren’t safe4; how to monitor a product’s technical basis once it’s delivered to ensure that it remains secure; and how important it is to be able to update products when things go wrong. They need to know where to look to find information on the security status of libraries or systems they might use, and what that information means when they find it5. They need to understand system and application hardening, and secure programming practice6. And much of this information is available today - students just need to learn that they need to look for it, and use it.

For the first time, we have a compelling argument for investing in the security of systems we build. In the past, justifying effort on securing deployed systems was difficult as the investment had no real return. Today, things are changing. Executives are being held responsible for the security of their products7, and this trend does not seem like it will reverse. More and more managers, technical, financial, or business, understand the real risks and impacts of insecure products. The time for engineered security is here - we just need to make it happen. And we can start with our students today.

4 https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html

5 https://nvd.nist.gov

6 https://dwheeler.com/secure-programs/

7 https://www.forbes.com/sites/greatspeculations/2014/05/08/targets-ceo-steps-down-following-the-massive-data-breach-and-canadian-debacle/#4f4699df2ba6

 


 
 Follow ECEDHA on Twitter
 


 

View the latest issue!

On Demand Webinars
From Concept to Communications: Putting the
ECEDHA Brand Toolkit to Work

In partnership with Tailfin Marketing
 
New Tools for State of the Art Research and
Industry-Ready Students
Sponsored by Keysight Technologies
 
A Case Study on Connected Maintenance Reliability
Sponsored by Fluke Corporation
 
Rethinking Electronics Fundamentals
Sponsored by National Instruments
 
Oscilloscopes for the Classroom
Sponsored by Keysight Technologies

E-mail the event date, name and link to information@ecedha.org to be added to the calendar.

March
22-26, 2019:

 2019 ECEDHA Annual   Conference and ECExpo
 Hilton El Conquistador -  Tucson, AZ

Support ECE education! 
Become an ECEDHA Corporate Sponsor

Exhibit and sponsorship opportunities for 2019 are now available!


>> View Sponsorship Prospectus

Contact Kim Simpao
for more information
+1-773-315-7779 (mobile)
ksimpao@ecedha.org

Corporate Members


 


 

 
 


 

 

 

 
 



 Mouser

National Instruments 

 quanser

 
 

 Texas Instruments