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?
By Anne Fisher, Managing Editor 9
Creating a Strategy Around Data Integrity:
Q&A with HCC Embedded’s David Brook
By Anne Fisher, Managing Editor 11
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
Editor
Chris Ciufo
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
(415) 255-0390 ext. 15
Sales Manager
Elizabeth Thoma
(415) 255-0390 ext. 17
Marketing/Circulation
Jenna Johnson
To Subscribe
www.eecatalog.com
Extension Media, LLC Corporate Office
President and Publisher
Vince Ridley
(415) 255-0390 ext. 18
Vice President & Publisher
Clair Bright
Vice President, Business Development
Melissa Sterling
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
engineers guide to Embedded Securityengineers guide to Embedded Security
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
www.eecatalog.com/embedded-security
www.eecatalog.com/embedded-security
February 2016 7
engineers guide to Embedded Securityengineers guide to Embedded Security
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
engineers guide to Embedded Securityengineers guide to Embedded Security
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
engineers guide to Embedded Securityengineers guide to Embedded Security
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
By Anne Fisher, Managing Editor
Alan Grau,
Icon Labs
February 2016 10
engineers guide to Embedded Securityengineers guide to Embedded Security
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
engineers guide to Embedded Securityengineers guide to Embedded Security
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.
By Anne Fisher, Managing Editor
David Brook,
HCC Embedded
February 2016 12
engineers guide to Embedded Securityengineers guide to Embedded Security
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.