engineers guide to embedded security - EE Catalog€¦ · February 2016 Guiding Embedded Designers on Systems and Technologies IoT Security: Past the PBJ Stage? What’s Your Take

Februar y 2016

Guiding Embedded Designers on Systems and Technologies

IoT Security: Past the PBJ Stage?

What’s Your Take on Embedded Security?

Engineers’ Guide to Embedded Security

www.eecatalog.com/embedded-security

Sponsors

February 2016 3

IN THIS ISSUE

CONTENTS

Embedded Security

Your Take on Embedded Safety and Security

By Andrew Girson, Barr Group 5

Isolation Is No Longer the Paradigm:

Q&A with Intrinsic-ID CEO Dr. Pim Tuyls

By Anne Fisher, Managing Editor 7

Will IoT Security Get Past the PB&J Stage?


Creating a Strategy Around Data Integrity:

Q&A with HCC Embedded’s David Brook


Embedded Systems Engineering is published by Extension Media LLC, 1786 18th Street, San Francisco, CA 94107. Copyright © 2016 by Extension Media LLC. All rights reserved. Printed in the U.S.

ENGINEERS’ GUIDE TO EMBEDDED SECURITY 2016www.eecatalog.com/embedded-security

Vice President & Publisher

Clair Bright

Editorial

Managing Editor

Anne Fisher

[email protected]

Editor

Chris Ciufo

[email protected]

Senior Editors

Caroline Hayes

Gabe Moretti

Dave Bursky

Creative/Production

Production Traffic Coordinator

LS Jerrett

Graphic Designers

Nicky Jacobson

Simone Bradley

Media Coordinator

Jon Franke

Senior Web Developers

Slava Dotsenko

Mariam Moattari

Advertising / Reprint Sales

Vice President, Sales

Embedded Electronics Media Group

Clair Bright

[email protected]

(415) 255-0390 ext. 15

Sales Manager

Elizabeth Thoma

[email protected]

(415) 255-0390 ext. 17

Marketing/Circulation

Jenna Johnson

To Subscribe

www.eecatalog.com

Extension Media, LLC Corporate Office

President and Publisher

Vince Ridley

[email protected]

(415) 255-0390 ext. 18

Vice President & Publisher

Clair Bright

[email protected]

Vice President, Business Development

Melissa Sterling

[email protected]

Human Resources / Administration

Darla Rovetti

Special Thanks to Our Sponsors

February 2016 5

engineers guide to Embedded Securityengineers guide to Embedded Security

Your Take on Embedded Safety and SecurityThe curiosity-invoking results to date of a first-of-its-kind survey

on safety- and security-aware embedded systems design.

Embedded device safety and security have become

imperatives in this age of explosive IoT growth.

Yet, confusion and misunderstanding surround the

attitudes and opinions of the engineers who design the

secure and safety-critical devices on which our infra-

structure and economy depend. Because of Barr Group’s

safety and security training focus, we felt it was neces-

sary to develop a comprehensive survey as a necessary

“deep dive” gauge of engineers’ current beliefs about

safety and security. Our core sample complements

traditional vendor-centric and broad industry surveys

and represents the first all-encompassing attempt to

gain clarity on the state of safety- and security-aware

embedded systems design.

INTRIGUING EARLY TRENDSWith over 2500 qualified responses from all over the

world (and still counting as I write this), we are learning

quite a bit about the state of safety and security in

embedded devices. In the coming weeks, as we close out

the survey and analyze the results, we will share this

information openly with the entire industry, so we all

can learn and improve on the safety and security of

future embedded devices.

Based on initial examination, some intriguing early

trends have appeared in the results:

Safety/reliability are significantly more important

than security, yet time-to-market and schedule

pressure trumps all. While this is to be somewhat

expected, it should concern all of us who know that

high-quality design requires proactive investment and cannot be

compromised.

Almost one-third of the products that will result from current

design projects could injure or kill someone if the product malfunc-

tioned. Clearly, safety-critical design matters.

Almost two-thirds of the current design projects incorporate two

or more processors/cores. This interesting finding demonstrates the

complexity and challenge that designers have in maintaining reli-

ability and security.

C remains the language of choice for embedded devices. I don’t

think anyone expected a different result, but the limitations of C

have significant implications for quality, safety, and security.

Most teams use formal version control and a bug-tracking system.

Diligent use of these tools is essential for maintainability and

quality.

Most teams use coding standards, though the level of enforcement

varies. Consistently enforced coding standards also enhance main-

tainability and quality.

About one-third of embedded software projects incorporate almost

no code review and about one-half use no static analysis tools.

Given that investment in these proactive techniques and tools can

result in a great reduction of costly downstream bugs and defects,

this finding is rather concerning.

In preparation for our announcement of the comprehensive survey

results at Embedded World 2016, we will be doing in-depth analysis of

the results looking for the answers to much more probing questions,

such as:

What is the correlation between devices that can kill or injure and

design teams that lag in the use of static analysis, code reviews, and

coding standards?

By Andrew Girson, Barr Group

“Almost one-third of the products that will result from current design projects could injure

or kill someone if the product malfunctioned. Clearly, safety-critical design matters.”

February 2016 6


How do design teams in Asia, Europe, and the Americas differ in

the importance they place on security and safety and in the use of

proactive techniques to improve quality?

Is there a relationship between the use of test-driven development

(TDD) and heightened security awareness?

DEMOGRAPHICS CRITICALDemographics are critical to getting a well-balanced and statistically

significant result. Because our respondent demographics are quite

broad and varied, we expect to be able to delve into these and other

more significant correlations. At present, survey demographics fea-

ture:

More than 50% of the respondents are from outside of North

America.

More than 85% of the respondents (over 2500 responses) have real-

world industry experience and are actively involved in embedded

device design projects today.

Company size and project size (in terms of people) are approxi-

mately evenly distributed from small to large companies and small

to large teams.

No single industry segment represents more than 20% of the

results and no less than 10 different segments had over 100

respondents each.

We hope that you will join us for our free webinar on March 8th, 2016,

where we’ll present this data in much more detail. Our goal is to pro-

vide meaningful information about safety and security in embedded

devices, so that we all can learn to do better. And for Barr Group, we

will use the survey results to better focus our whitepapers, webinars,

and other industry outreach so we can directly encourage and sup-

port improvement in safety and security for future embedded device

designs.

Barr Group co-founder Andrew Girson has over 20 years of experience

in the embedded systems industry, first as a senior embedded software

engineer and subsequently in executive roles as a CTO, VP of Sales and

Marketing, and CEO. He has led multiple companies to multi-year

double-digit revenue and profitability growth rates while maintaining

a distinctly technical focus on high-quality embedded, wireless, and

handheld systems. Girson holds BS and MS degrees in Electrical Engi-

neering from the University of Virginia.

Embedded Security ONLINE

Explore...➔ Top Stories and News

➔ White Papers

➔ Expert Opinions (Blogs)

➔ Exclusive Videos

➔ Valuable Articles

Sign up for the Embedded Security Quarterly Report email newsletter



February 2016 7


Isolation Is No Longer the ParadigmQ&A with Intrinsic-ID CEO Dr. Pim Tuyls

Why all the elements of the security supply chain need to be in place.

Our thanks to Dr. Pim Tuyls, CEO of Intrinsic-ID,

which likens its patented physically unclonable

functions (PUF) technology to the electronic equivalent

of a human fingerprint. Dr. Tuyls recently spoke with

EECatalog to catch us up on current and anticipated

security concerns.

EECatalog: Why was a new approach to building a com-

plete secure boot process, from silicon to the system

level, needed at this time?

Dr. Pim Tuyls, Intrinsic-ID: One reason security

measures need a holistic approach is that breaches are

becoming much more advanced and more common, and

there is more at stake. Hackers are using increasingly

sophisticated tools. And those tools are becoming more

readily available to them. There is a steady stream of

tools coming out that make it possible to attack chips in

completely new ways—including extracting the secret

root keys, which form the root of trust.

The second reason security must be intrinsic from the

silicon to the system level is that in most modern tech-

nology nodes, the embedded non-volatile memory isn’t

available for storing keys on the chip, and if keys can’t

be stored on-chip, then they are certainly not secure.

There is a need for secret keys [and along with that] very

low cost, flexible ways to generate keys, distribute keys

and store keys in the system

Thirdly, the speed with which the IoT is advancing has

brought security and trust to a completely new scale.

There will be billions of chips out there, and all those

chips will need security, because otherwise the system

and the data produced by the system of end-points can’t

be trusted.

Traditional methods, where they are available, do

not scale particularly well to systems with billions of

devices and where [using such methods] is much too

expensive and much too complicated.

Those are the three main reasons why there is a need for a completely

new approach to building not only secure boot, but also the entire

trust process in the fully connected world.

EECatalog: If the essential components of a security supply chain are

not in place, could that be compared to having a great security guard

but no ability to send him where he needed to be to do the actual

guarding?

Tuyls, Intrinsic-ID: Exactly. And [even if you can send him some-

where] if that guard can be intercepted on the road, then he cannot be

trusted anymore and your security is gone!

[By contrast] we build security up from the silicon, and this also means

we derive it from the properties of the silicon. With our technology,

physically unclonable functions, we can build chips that don’t have

any sensitive material anymore, because all the sensitive material is

encrypted with a key extracted from the silicon. The key disappears

when the chip is turned off, or even when the circuit for the keys has

been turned off.

This is a very disruptive approach to key generation, key storage and

key management that not only provides a higher security level, but

also makes it low cost and very flexible.

EECatalog: Is the area of cyber security for smart metering solutions

of interest to Intrinsic-ID?

Tuyls, Intrinsic-ID: Yes, and beyond that to the critical infra-

structure. It will become very important that we monitor our critical

systems with all kinds of sensors, And you need to make sure that

those sensors are not being tampered with and that they are sending

information that cannot be tampered with.

Back to what I was noting earlier, if your supply chain cannot be

trusted, you cannot be sure that the right sensors are there or confi-

dent the sensors are communicating properly.

Setting up security from the base, from the factory where the chips are

produced, up to the full end system will be critical for the success not

By Anne Fisher, Managing Editor

Dr. Pim Tuyls,

Intrinsic-ID

February 2016 8


only of the business models around the interconnected

world but even for society itself.

EECatalog: You have to be prepared for the worst.

Tuyls, Intrinsic-ID: Absolutely. What if, for example,

sensors in the water to detect pollution give the wrong

information? [The result is that] first many victims

may suffer before the problem is noticed, secondly the

wrong amount of chemicals needed to clean up the bac-

teria in the water may be used, resulting in too little or

too much. And either way can produce a bad result.

EECatalog: What is the best way to get ahead of the

curve when it comes to automotive security, especially

as automotive evolves to include autonomous and

semi-autonomous vehicles and the transportation-as-

a-service idea?

Tuyls, Intrinsic-ID: It is important that the automo-

tive OEMs start really driving security much more

than they are doing already.

When cars get more and more connected, and with

autonomous driving coming, cars will be getting infor-

mation from the infrastructure, including streetlights,

for example, and the cars in front of them. [So] you have

to make sure that you can trust all the information.

Because if hackers manipulate the system, the outcome

may be accidents on a scale that we have never seen

before. That is the real risk here.

And we must consider as well communication inside the

car, the communication to the infrastructure and com-

munication of the chips themselves that are being used

inside the car. Again, protection of the supply chain

from the base is very important. You want to show that

those chips that have to perform a certain functionality

have not been replaced by chips with a lower quality or

with chips that have been tampered with.

This is also why smart light bulbs have to be protected.

At first glance, one might think, “Who is going to hack

my light bulb?” But if the light bulbs are connected, you

can hack thousands or ten thousands of light bulbs at

the same time, which means if you switch them on or

off at the same time, the whole grid goes down, because

the grid has not been built [to withstand] that.

EECatalog: Is Intrinsic-ID ready to experience rapid growth?

Tuyls, Intrinsic-ID: I think we are absolutely ready. We have

built a solid customer base and the customer base is also growing

quickly. Not only have we shown that our technology works in

the real world when deployed, but also our team has established a

depth of experience on how to integrate this kind of technology in

a flexible and efficient way—one that is small enough, fast enough

and secure enough. All those trade-offs are well understood by our

team.

EECatalog: What should systems integrators and embedded

developers take away from this conversation?

Tuyls, Intrinsic-ID: They should be evangelists to ensure secu-

rity gets built into systems. Systems integrators and embedded

developers need to work with their management and convince

them that security measures in embedded solutions and in sys-

tems in general have to be taken very seriously. To ensure this

they should select security solution providers who have expertise

in robust security solutions that scale from the hardware- and

software-level to the entire system. Security needs to be fully

integrated and not implemented in isolation. Isolation is no longer

the paradigm.

February 2016 9


Will IoT Security Get Past the PB&J Stage? If IoT Security is starved for attention, it could well be mobile apps, automotive safety, medical

patient privacy and more that will experience something worse than just hunger pangs.

Icon Labs president and co-founder Alan Grau recently

spoke with EECatalog about IoT security challenges.

EECatalog: What are some of the challenges for secu-

rity in the IoT space?

Alan Grau, Icon Labs: A number of newer companies

in the IoT space are trying to get products out to market

quickly and establish a presence and are not security

companies, so that is one of the challenges. Even some

of the larger traditional companies moving into the IoT

have great expertise in whatever their specific market

is, industrial automation, say, or medical devices, but

they are not security companies.

EECatalog: And there is the danger OEMs could get

mired in the security details, losing development time?

Grau, Icon Labs: Absolutely. Look at the RTOS world.

At one point in time companies asked, “Should I build

my own operating system or do I want a commercial

operating system?” Finally companies realized, going

on your own, you are not going to be able to provide

a comprehensive, well-tested end-to-end solution

without making a very big engineering effort.

Part of our challenge as a company is to make sure that

our customers are aware there are solutions out there

they don’t have to build themselves.

Here’s an analogy I gave recently: When companies say,

“We need ‘security’,” it’s as if they are saying, “We need

‘food’,” then buying bread, peanut butter and jelly to

slap together one sandwich when the “food” they need

is in reality a catered meal for thousands.

They need the infrastructure to pull together something

that scales, and is interoperable and that they can use

across multiple products—products that are going to be in the field for

10 years or maybe longer and they may not understand the distinction

between a peanut butter sandwich and a catered meal for 1000 people,

until they get into it and really understand all the nuances.

EECatalog: And not understanding the peanut butter sandwich/

catered meal difference has caused problems—

Grau, Icon Labs: like the Chrysler Jeep hack—that didn’t have to

happen; it was preventable. There are several pieces of technology

that could have stopped that [for example] a firewall in the device,

machine-to-machine authentication, secure boot, secure firmware

updates—four different things, any of which would have solved that.

All [the four noted above] we provide, and it is not like we have a lock

on these ideas and nobody has ever thought about doing these things

or implemented them in other platforms, so [it is matter of] getting

the basic fundamentals into place broadly.

Researchers found on some of the top mobile parking apps that there

were vulnerabilities in the payment systems [because] they haven’t

ensured complete end-to-end security.

EECatalog: How does an IoT security challenge differ from an IT

security challenge?

Grau, Icon Labs: With IT you’ve got a server that is sitting in your

data center. It is physically protected. It is [likely] behind multiple

firewalls. To get access to the building requires significant authoriza-

tion, so right there is built in control and security. You’ve got physical

security around it, and yet these things are still getting hacked.

So now we’re going to take devices and their big sophisticated sys-

tems—Windows or [another] strong operating system with defenses

built into the operating system as well as the edge security devices

from the big security vendors—then take a device, which, instead of

being at a big expensive server, is running some little bitty operating

system on some tiny little device without a whole lot of security


Alan Grau,

Icon Labs

February 2016 10


capability at all and put it out in the

world where hackers can go steal one off

the road, plug a USB device into it, tear

it apart, and have access to the wireless

physical proximity for wireless commu-

nication. It opens up a whole new set of

attack factors. They are inexpensive so I

can go buy one on my own, tear it apart,

read the firmware off of the device and

reverse engineer it, and use that infor-

mation to go attack other ones.

It just opens up a huge set of vulnerabili-

ties and attack surfaces so even though

there is not the same level of data on

these devices it is really critical to keep

protecting them.

I wrote recently about hackers going after

medical devices and then using them to

launch an attack into the network and

steal medical data.

And HP Labs did a study last year of 10

new-ish high-profile IoT devices and did

a hard look at the security vulnerabili-

ties and they found that 70 percent had

at least one of what they classified as a

serious vulnerability, and on average,

they had 25 vulnerabilities per device

identified.

EECatalog: What should and shouldn’t

government be doing with regard to

cyber security?

Grau, Icon Labs: I don’t think they

should be asking people to put back doors

in their systems; if you do that then you

are creating a security vulnerability for

everybody to exploit.

[However] I don’t spend a lot of time

thinking about how does the govern-

ment solve this problem; I spend a lot

of time thinking about how do we build

security technologies that make it easier

for our customers to do the right things.

For example, if you go through and

look at all the modules we provide, it

can be fairly overwhelming for our cus-

tomers, so what we spending time on is

simplifying how that is packaged and

presented. That is one thing hardware

companies have helped us to do, to focus

on simplifying how we present all the

complexity so that they can more easily

understand what we are providing and

how they can implement it.

EECatalog: So that focus on simplifying

you were just mentioning is one result

of Icon Labs working with Renesas and

other not-yet-announced vendors to

integrate software onto hardware plat-

forms—is software security on the same

page as hardware security?

Grau, Icon Labs: I heard Renée James

(at the time with Intel) speak at the

McAfee/IntelSecurity FOCUS conference

last year. She made the point that Intel

has shipped literally hundreds of mil-

lions of processors with great hardware

security capability that has never been

used because the software hasn’t caught

up. Some of the software to enable the

hardware [security capabilities] is there

but [what is lacking] is the end-to-end

infrastructure to make it easy to use.

EECatalog: The embedded market is a

pretty fragmented one and that can be

challenging.

Grau, Icon Labs: Yes, the embedded

market in general is a very fragmented

market—there are still quite a few

different operating systems that are

popular and broadly used. There are a

plethora of hardware platforms.

We have been in this space for quite a

while so we have learned how to abstract

things out and make them very portable.

That is some of our value proposition—

we can go into a customer and say, “Hey,

you’ve got six different development

platforms and three different RTOSes

and all this different stuff, but we have

a core set of technologies that will scale

across all of it so that you are not having

to reinvent the wheel for each platform.”

EECatalog: Anything you would like to

add, Alan, before we wrap up?

Grau, Icon Labs: Getting back to your

hardware and software on the same

page question: We provide the ability to

integrate with a security co-processor or

hardware security elements onboard to

do things like secure key storage. And to

enable secure boot and crypto accelera-

tion. If you’ve got a development system

and it does not have those capabilities we

can emulate them in software and do a

decent job of it, but it is not going to be

as strong or as secure as if it was imple-

mented in hardware.

So we encourage companies to select

hardware platforms that have the under-

pinnings in hardware for security because

that adds a lot of value for them. However,

even if a customer we’re working with

doesn’t have [the type of hardware plat-

form just described] yet, we can still work

with them and put them on a roadmap.

Then when they move to a platform that

has those built-in hardware capabilities,

they already have the other pieces of the

infrastructure in place.

February 2016 11


Creating a Strategy Around Data IntegrityQ&A with HCC Embedded’s David BrookA call for embedded engineers to develop strategies for securely

and reliably managing embedded IoT data.

Our thanks to David Brook, director of sales and

marketing, HCC Embedded, which develops re-

usable embedded software components for Flash, File

Systems and Communications. Brook recently shared his

insights on a number of security, IoT and other topics.

EECatalog: What should the infrastructure of an orga-

nization that has adopted a software life-cycle process

appropriate for the risk the Internet of Things has intro-

duced to smart metering (to cite one example) look like?

David Brook, HCC Embedded: Process is the key to

all development that targets quality. The only method

known to engineering of reducing risk of failure

and number of software defects is to adopt a risk-

appropriate software life-cycle process. This has been

proven in aerospace, industrial, medical, and transport

for decades. Without process the quality is partly left

to luck; and given the number of variables in software

development, the chances of success are fairly low.

Process needs to govern all aspects of the develop-

ment—and must take the product from conception to

end of life. This means having a development process

and a maintenance process. The development process

is characterized by specifying the requirements and

having test cases that map to all those requirements.

Every test case must be for a requirement and every

requirement must be covered by a test case. This can

be at a high level; for example, the security of cus-

tomers’ data must be preserved, all the way down to

a detailed design level. All levels need to be traceable

and auditable. Sure, this is too much for some product

developments, but it’s important to define the risk and

then use process appropriate to that risk. Without this

step, the risks are obvious.

For example, to an embedded engineer, a smart meter

looks conceptually similar to other embedded applica-

tions—it has an embedded processor running input

and output functions to collect information and control an applica-

tion. It has flash memory to store subscriber and usage data, and it has

some kind of communications interface. However, the risk assessment

of such a device and its components needs to ensure that data, which

has real value, is stored in a fail-safe manner and protected from

unauthorized access. If the meter data was exposed or hacked then

energy bills can be tampered with and customer’s personal data could

be open to identity theft. Such risks of data loss and exposure are not

addressed simply by “careful” development or software testing. The

lessons of data-centric scandals such as Heartbleed and Apple SSL are

that a software life cycle that is appropriate for such valuable data

must be held ultimately responsible.

EECatalog: If the use of formal verification methods “catches on”

beyond those sectors where it is used already: aerospace etc., could

finding enough individuals to perform (or judge how well machines

are performing) such verification become a problem?

Figure 1: The secure storage and communication of embedded IoT data is critical in order to protect these devices from becoming vulnerable points in larger networks. While current security protocols, such as TLS, are regarded as secure if used within their design parameters, adopting a risk-appropriate software life-cycle process should be a requirement.


David Brook,

HCC Embedded

February 2016 12


David Brook, HCC Embedded: Normal economic process would

take over—if you need more quality engineers, then investments will

have to be made. This would not be a bad thing in the current climate

where very little of the revenue from all the products produced finds

its way back to software engineering. The economics have meant that

silicon vendors want software to be free, and as such many low-quality

software solutions have been dumped on the market—devaluing soft-

ware engineering in general. For the well being of the world, it would

be good to invest more of the income generated by IoT products back

to engineering the products themselves—and the logical conclusion

would be that you would get better quality—seems like a healthy feed-

back loop – but in the current market this is not working.

EECatalog: How do you see the insurers (Insurance Industry) of

enterprises influencing the actions taken to protect data that is stored

locally or communicated over the Internet?

David Brook, HCC Embedded: I am not sure it is possible for a com-

pany to insure against a security breach or leakage of data. A more

likely cause of change would be class action suits —U.S. style—that

demonstrate that corporations have not taken the handling of per-

sonal data seriously. Proving this, in the context of most IT systems,

would not be difficult. Just at a simple level, the vast majority of

system administrators who are responsible for installing both hard-

ware and software have little to no awareness of the processes that

would be required to verify that their system is fit for the intended

purpose. Do most system administrators receive from management a

detailed paper describing the high-level requirements of the IT system

and the standards they must employ for the type of work the company

is doing? Do they specify things like, “We are protecting customer’s

personal data so any system that communicates this data must reach

“X” level of quality?” I would consider this to be the basics.

EECatalog: What will be thorniest non-technical problems that could

thwart collaboration at the system-level and the reining in of freestyle

coding practices and how can those problems be addressed?

David Brook, HCC Embedded: While you cannot rein in freestyle

coding—it is the basis of 99 percent of everything we have today—

creating a strategy around data integrity will require developers to

challenge conventional practices, and engineering must require col-

laboration at a system-level.

For good reason, free-style coding is not used in applications such as

flight control. Freestyle coding should not be looking after our per-

sonal data either. Companies must look beyond the short term and be

willing to invest upfront to do things properly. A risk assessment of the

impact of data loss or damage must become part of the development

process. Some might argue that it is too expensive or unreasonable

to implement such formal methods. This makes no sense in the face

of the almost incalculable financial costs from recent data scandals

and the requirement that you assess the risk to your users. Also, like

in banking there is an economic race to the bottom that can only be

controlled by legislation—people have to be legally responsible for

handling personal data.

EECatalog: What is the role of government in all this, if any?

David Brook, HCC Embedded: There is an economic race to the

bottom in all of this—to provide services as cheaply as possible and if

you do not, you lose—similar to the mortgage disasters that occurred.

This can only be controlled with legislation similar to what exists for

automobiles, airplanes, nuclear power, etc., which mandate certain

standards must be met before companies can trade in these markets.

Otherwise the traditional company method of stumbling from one

crisis to the next is inevitable and is proven by the security failures

and breaches we are seeing on a weekly basis.

EECatalog: What can IT learn from the embedded development that has

taken place in some vertical markets about preventing loss and harm?

David Brook, HCC Embedded: IT is a huge generalization. But in

general, IT departments have very little knowledge of process. The

fundamentals of process are all roughly the same:

Define the requirements of the system

Specify the implementation

Implement

Have a test plan that maps back to the requirements. Every

requirement should have a test case and every test case should have

a requirement.

How to extrapolate this to IT is complicated when they are using so

much software and hardware that has no process of verification —and

while that remains there are always going to be gaping holes. The idea

that it is too complex to apply these methods may be true but what

that is saying is that your system is inherently risky—and you have

to recognize that. If you want to mitigate against risk then you have

to take the idea of process (including verification) seriously—and that

means including some form of validation of third party components

(almost everything in an IT system) and making sure that not only

is the component fit for purpose, but also that the processes used to

develop and maintain that product are fit for purpose

For many years, network and security RFC’s and development have

belonged in the IT sector. This is problematic for IoT designers—

embedded applications are simple and do not face the same design

challenges as IT applications. On the one hand there is a lot of soft-

ware that can be easily adopted to provide basic network and security

capability. However, IT lacks the benefits established by embedded

development in some vertical markets. For example, industrial control

devices that can affect safety have access to a mature set of functional

safety processes and standards around IEC61508. The basis of these

functional-safety standards has been adopted in medical, transport,

and many other industries where safety is relevant. If IoT devices

adopt the same approach as IT-based software, then it will suffer the

same weaknesses.

Documents

engineers guide to embedded security - EE Catalog€¦ · February 2016 Guiding Embedded Designers on Systems and Technologies IoT Security: Past the PBJ Stage? What’s Your Take