safety reliability and security lessons from defense for iot
TRANSCRIPT
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
2 | September 26, 2016 | Approved for Public Release
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.
3 | September 26, 2016 | Approved for Public Release
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
4 | September 26, 2016 | Approved for Public Release
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
5 | September 26, 2016 | Approved for Public Release
IoT: It’s not a toy – it’s critical technology. What does that mean?
Safety
Reliability Security
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?
6 | September 26, 2016 | Approved for Public Release
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
7 | September 26, 2016 | Approved for Public Release
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?
8 | September 26, 2016 | Approved for Public Release
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.
9 | September 26, 2016 | Approved for Public Release
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.
10 | September 26, 2016 | Approved for Public Release
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.
11 | September 26, 2016 | Approved for Public Release
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”
12 | September 26, 2016 | Approved for Public Release
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
13 | September 26, 2016 | Approved for Public Release
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?
14 | September 26, 2016 | Approved for Public Release
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)
16 | September 26, 2016 | Approved for Public Release
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)
17 | September 26, 2016 | Approved for Public Release
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
18 | September 26, 2016 | Approved for Public Release
Q&A
www.curtisswrightds.com
David Jedynak, CTO – COTS Solutions
310-387-2816