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

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?


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

http://arstechnica.com/security/2016/09/why-the-silencing-of-krebsonsecurity-opens-a-troubling-chapter-for-the-net/
























http://www.symantec.com/connect/blogs/iot-devices-being-increasingly-used-ddos-attacks
















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)

https://www.commoncriteriaportal.org/

https://www.commoncriteriaportal.org/

http://iase.disa.mil/stigs/Pages/index.aspx




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

[email protected]

310-387-2816

mailto:[email protected]

Technology

Safety reliability and security lessons from defense for IoT