Safety reliability and security lessons from defense for IoT

1 | September 26, 2016 | Approved for Public Release
Defense Solutions Division
Safety, Reliability, and Security
Lessons from Defense for
Internet of Things
David Jedynak, CTO

IoT in Defense
 Unmanned Systems
– Airborne
– Ground
– Sea
 Wide range of platforms and sizes
 Doctrine behind it: “Network-Enabled Operations”
– Translate an information advantage, enabled in part by
information technology, into a competitive warfighting advantage
through the robust networking of well informed geographically
dispersed forces.
– This networking, combined with changes in technology,
organization, processes, and people - may allow new forms of
organizational behavior.

Network Enabled Operations: A Fundamental US DoD Doctrine
Specifically, the theory contains the
following four tenets in its hypotheses:
I. A robustly networked force improves
information sharing;
II. Information sharing enhances the
quality of information and shared
situational awareness;
III. Shared situational awareness enables
collaboration and self-synchronization,
and enhances sustainability and speed
of command; and
IV. These, in turn, dramatically increase
mission effectiveness.
“Network Centric Warfare: Developing and Leveraging Information
Superiority”, David Alberts, et al, 1998 Defense has been working IoT for a very long time
Think about this in terms of the “mission” of running a
household, emergency medical services, or a power grid

A couple of final thoughts on IoT in Defense (Alberts, et al, 1998)
“Information Age technologies will provide
the means to achieve greater
interoperability and alter the micro-
economic incentives and practical
considerations that often drive us towards
point solutions. This is the rough
equivalent of moving from producing rifles
one-by-one by hand, to manufacturing them
with interchangeable parts.”
Transfer of Intelligence from
weapons and sensors to
infostructure, complexity moves
from platform to network
Decoupling of sensors and
weapons platforms from
actor
Development of new sensors and
new actors providing new
capabilities
Decoupling of sensors
from weapons - The end
of stovepiping

IoT: It’s not a toy – it’s critical technology. What does that mean?
Safety
ReliabilitySecurity
It does exactly what it needs to do
It does what it needs to do
without fail for its
operational life
It does not do what
someone else wants it to
do
Important questions:
• How do we quantify them?
• How do we verify them?
• How do we balance these?

Safety
 There are multiple standards across various industries
 Aviation standards (FAA and EASA) getting some use in
defense (most closely aligned industrial base)
 US FAA standards
– DO-178 for Software
– DO-254 for Hardware (includes “firmware” such as VHDL in FPGAs)
 Various “Design Assurance Levels” (DAL)
 “Certification” requires “Artifacts” (documentation) for audit

Design Assurance Levels (DAL) from FAA Standards
Level Failure Result General Description
A Catastrophic Failure may cause multiple fatalities, usually with loss of the airplane
B Hazardous
Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate
the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the
passengers
C Major
Failure significantly reduces the safety margin or significantly increases crew workload. May result in
passenger discomfort (or even injuries).
D Minor
Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include
causing passenger inconvenience or a routine flight plan change.
E No Effect Failure has no impact on safety, aircraft operation, or crew workload.
The same levels apply for Software (DO-178C) and Hardware (DO-254) Design and Validation
Critical Requirements Question:
What DAL is required for software (DO-178C) and hardware (DO-254) for which subsystems?

Traceability Requirements for Software (DO-178C)
Parent Requirement must trace  to child requirements / artifacts
Level
A
Level
B
Level
C
Level
D
Engineering Team
System Requirements allocated to software  High Level Software Requirements X X X X System Design
High Level Software Requirements  Test Cases X X X X Software Validation
Test Cases  Test Procedures X X X X Software Validation
Test Procedures  Test Results X X X X Software Validation
High Level Software Requirements  Low Level Software Requirements X X X Software Design
High Level Software Requirements  Software Architecture X X X Software Design
Low Level Software Requirements  Source Code X X X Software Design
Source Code  Executable Object Code X
Compiler and Processor
Architecture
Critical Issue:
The Level A trace from source code to executable object code involves total understanding of the
underlying processor architecture.

Reliability
 You must define your operational environment
– Indoors? Outdoors? Where in the world? Fixed install / mobile?
 How long does it need to last?
– Consider your warranty versus return rate
 Defense Standards to consider (all of these are available publically, e.g. everyspec.com)
– MIL-STD-810 (Environmental)
– MIL-STD-461 (Electromagnetic Effects) – Note regulatory requirements of FCC / CE are mandatory
– MIL-HDBK-217 (Reliability) – calculating your Mean Time Between Failures (MTBF)
 There are plenty of testing labs that will test to these standards and many software tools
that calculate reliability based on 217 (or improvements to it)
 There are lots of design and manufacturing decisions that go into this (e.g. IPC Class,
material types, end-of-line testing / environmental stress-screening, etc.)
 There’s a ton of information online – e.g. standard “hot” and “cold” day temperatures, etc.

Environmental Considerations – There’s MIL-STD-810 info for all
Requirement Description Notes
Temperature Operating and non-operating (storage) temperatures.
Don’t forget diurnal cycles (how’s that IoT doorbell
after 2000 day / night temperature cycles?)
Affects the grade of parts you use, e.g.
commercial (typically 0-50C) or industrial
(typically -40 – 85C)
Humidity Operating and non-operating Do you conformal coat?
Vibration Random / Sine and a spectrum This can change based on platform type
Shock “Drop” Shock and operational shock Don’t forget multiple axes
Fungus Growth in your product Materials and fungicide
Wash-down Spray type, intensity Reference the NMEA “IP” standards
Sand / Dust Based on environment
Salt Fog Especially for marine environments
Others include Altitude, explosive atmosphere, rapid decompression, etc.

Electromagnetic Considerations – There’s MIL-STD-461 info for all
Requirement Description Notes
Conducted
Susceptibility (CS)
On the power and signal lines – what can
hurt your product?
Know your environment, and the transients
(like a crank start on a car)
Conducted
Emissions (CE)
On the power and signal lines – what noise
are you putting out there?
Are you dumping current back onto a power-
line that was just turned off?
Radiated
Susceptibility (RS)
What sort of interference will hurt you? What
about industrial equipment (e.g. 200V/meter
E-field from a big radar?)
Shielding! What about cables?
Radiated Emissions
(RE)
What sort of interference are you creating?
Are you broadcasting your 100MHz clock?
This is generally what CE / FCC care about.
Extra credit – just how critical is your IoT device? Can it survive an EMP?
Hint: Search for “Nuclear Event Detector”

Security
 Very High-profile concern and Very High-profile threat
– Current DDoS on Krebs
(http://arstechnica.com/security/2016/09/why-the-silencing-of-
krebsonsecurity-opens-a-troubling-chapter-for-the-net/)
– Internet of Things is a large problem in security
(http://www.symantec.com/connect/blogs/iot-devices-being-
increasingly-used-ddos-attacks)
 Many security tools and standards available
 A lack of commitment to security is the primary vulnerability –
fix this first

Security Concepts
 Data-at-Rest
– Data stored in a device – protect with
storage encryption
 Data-in-Transit
– Data moving on a network – protect with
network encryption
 Sanitization
– How is data removed from a device so it
cannot be recovered?
 Secure boot, Root-of-Trust, code-
signing
– How do you lock down the hardware so
that only approved software runs?
 Bell-LaPudula (BLP), Biba rules
– Write-up / read-down permissions,
compartmentalization
 Multi-Level Security (MLS) and Multiple
Independent Levels of Security (MILS)
– Mixing security all in one operating
context vs. separated contexts
 Cross-Domain
– Transfer: How do you transfer data from
one security domain to another?
– Access: How do you access multiple
domains at once?
 What do you do about Tampering?

Security Resources
 Common Criteria protection profiles (https://www.commoncriteriaportal.org/)
– Pay attention to “Network Device”
 US National Security Agency “Security Technical Implementation Guides” (STIG)
(http://iase.disa.mil/stigs/Pages/index.aspx)
– Did you know that the US NSA is a big contributor to the security of RedHat Enterprise Linux and Open
Source Linux in general?
 Interesting approach “Commercial Systems for Classified” (CSfC)
– Double stack different Common Criteria products together (e.g. two nested VPNs)
 How do you consider security in your Software Development Life Cycle?
– Scanning tools?
– Information Assurance Vulnerability Alerts (IAVA), Common Vulnerabilities and Exposures (CVE), etc.?
– Penetration Tests? Certified Ethical Hacker?
 Processor vendors provide a lot of help with the low-level foundations (e.g. secure boot)

Embedded Security Architecture

MILS Network Reference Architecture
LAN
WAN 2
Route &
Protect
WAN 1
Route &
Protect
WAN N
Route &
Protect
MILS
Processing
MILS
Storage
MILS
Display
/ UI
IoT
Route &
Protect
Route &
Protect
Route &
Protect
Route &
Protect
IoT
Route &
Protect
IoT
Route &
Protect
Local Validation
Authority
Route &
Protect
Grey means unknown / mixed safety
and security level – don’t care
Safety Critical
Route &
Protect
Conditional Access System
Route &
Protect
Route &
Protect
Route &
Protect
WAN links to the rest of the GIG
(Ground / Air / Sat)

Balancing Cost – Major Drivers (High to Low)
1. Level of Safety
Standard = amount of
documentation and
process (A > B >> C >
D >> E)
2. Environmental & EMI
Testing = outside
labor per product
3. Security Testing =
capitalize this and
make it part of your
process
1. Industrial-temp parts,
materials selection,
conformal coat = all at
a premium vs.
commercial grade
2. Environmental Stress
Screening (labor
hours) = # of cycles
for test, but
remember, this keeps
internal defects from
becoming external
defects
1. Field failure rate =
every field failure /
return negates how
many 100’s of product
profit?
2. Security updates
3. BIG RISK = what if
your IoT device isn’t
safety, reliable, and
secure, and that
causes a critical
problem that leads to
legal liability?
DEVELOPMENT COST RECURRING COST SUSTAINING COST

Q&A
www.curtisswrightds.com
David Jedynak, CTO – COTS Solutions
djedynak@curtisswright.com
310-387-2816

Safety reliability and security lessons from defense for IoT

More Related Content

What's hot

Viewers also liked

Similar to Safety reliability and security lessons from defense for IoT

More from IoT613

Recently uploaded

Safety reliability and security lessons from defense for IoT