# Presentation: 434805

## An Architectural Concept for Intrusion Tolerance in Air Traffic Networks

- Jeffrey Maddalon
- Paul Miner
- {jeffrey.m.maddalon, paul.s.miner}@nasa.gov
- NASA Langley
- 22 Oct 2003

## Slide 2

- SPIDER Intrusion Tolerance

**Notes:**
Let’s consider an air traffic network.  
Let’s consider the types of communication (controller – controller, controller – air, air – air)
This assumes a “happy day” scenerio, that is, that everything works correctly and there are no attacks on the system.

## Slide 3

- SPIDER Intrusion Tolerance

**Notes:**
Let’s consider how these types of communication can be compromised
destroy critical infrastructure
Inject invalid messages (duck and aircraft)
Install malicious software and start a coordinated attack.

## Desired Security Properties

**Confidentiality**  No unauthorized disclosure of information
**Integrity**  No improper alteration of data
**Availability **System always completes authorized actions
- From Jean-Claude Laprie*, Dependability - Its Attributes, Impairments, and Means, *In Randell, et al. Eds., Predictably Dependable Computer Systems, Springer-Verlag, 1995

- SPIDER Intrusion Tolerance

**Notes:**
 Lets get a little more specific about what sorts of properties a secure system should have.
This model is just one, there are other models.
Talk about confidentially, integrity, availability
It is interesting that the security community (both national security and e-commerce) is most concerned with confidentially than with Availability, 
In the air traffic world, availability is more important than confidentially.  In other words, the “denial of service” attacks are a nusiance in the commerical world, but can be life threatening in the air traffic world. 

## Intrusion Resilience

- Make the system difficult to enter
- Firewalls, strong encryption, up-to-date security patches, etc.
- Add monitoring so intrusions can be handled quickly
- Automated network monitoring, audits, network isolation, etc.
- Great techniques, but they are not enough...

- SPIDER Intrusion Tolerance

**Notes:**
When one starts thinking about making a secure system, their first steps are to make the “Intrusion resilient”

This involves two things: (Read slide)

In preparing for this talk I found two articles that have recently appeared
Reuters October 7th, 2003: the source code for the video game “Half Life II”  was stolen.  How? The hacker apparently knew who one of the game developers was, broke into the e-mail software.  Used this compromise of the e-mail system to installed spying software on the game developer’s computer.  Once the hacker had the password to the system, he stole the code.
You might say that the problem was that the system was connected to a public network and that an air traffic network should never be connected to a public network.
For that I will offer this Sydney Morning Herald story from September 5, 2003:
(read story)

## System Protection Goals

- Attackers look for the
- weakest link, so we need
- not just strong barriers,
- but ...
- strong barriers *and*
- redundancy

- SPIDER Intrusion Tolerance

**Notes:**
My point with these two stories is that: Attackers look for the weakest link.... (read slide)
In other words the metaphor should be a medieval castle, instead of a Great Wall of China.
The people who built the castle, expected that at some point the walls would be compromised.  And just because one security measure was compromised, the security of the whole castle is not compromised.

## Intrusion Tolerance

- Ability to preserve Availability and Integrity, in presence of bounded number of compromised network nodes
- A compromised node may exhibit
- Crashed (unable to deliver any service)
- Unable to deliver timely service (e.g. Denial of Service)
- Uniformly corrupted data (consistent misinformation)
- Arbitrary behavior (includes malicious human-directed behavior)

- SPIDER Intrusion Tolerance

**Notes:**
You might ask how can one build an intrusion tolerant network?

## Fault-Tolerance (FT) and Intrusion Tolerance (InT)

**Similar**
- Worst case scenario in FT is arbitrary behavior
**identical to InT worst case**
- Easily detectable failures (crash, omission) are similar in both domains

**Different**
- Fault arrival rates are not comparable
**In FT: independence of failure**
**exponential fault arrival rate**
**multiple fault scenarios are rare **
**In InT: expect coordinated attack **
**potential for simultaneous arrival of multiple faults**

- SPIDER Intrusion Tolerance

## What is SPIDER?

- A family of fault-tolerant architectures
- Scalable Processor-Independent Design for Electromagnetic Resilience (SPIDER)
- A system built using SPIDER can continue to operate with
- arbitrary malicious failures
- many easy-to-detect failures
- multiple simultaneous failures

- SPIDER Intrusion Tolerance

**Notes:**
I will assume that most people here already know what SPIDER is, so I won’t go into detail.
(read slide)
Notice how SPIDER was designed to continue to operate with multiple, arbitrarily bad nodes.
In this way SPIDER is well-positioned to be deployed in intrusion tolerant enviroments.

##  ROBUS Topology

- PE 1

- PE 2

- PE 3

- PE N

- BIU N

- BIU 3

- BIU 2

- BIU 1

- ROBUSN,M

- SPIDER Intrusion Tolerance

## SPIDER Fault Tolerance

- ROBUS Guarantees
- All processors attached to a good port will observe identical message streams
- All processors attached to a good port will by synchronized within a bounded amount of time
- All processors attached to a good port will have correct and consistent diagnostic information
- From these guarantees SPIDER can provide
- Interactive Consistency (Distributed Agreement)
- Distributed Diagnosis
- Clock Synchronization

- SPIDER Intrusion Tolerance

## Intrusion Tolerance and SPIDER

- With enough good (not compromised) nodes, SPIDER can still provide service
- Standard versions of fault tolerant protocols that can withstand a bounded number of faulty nodes
- deemed too expensive in both time and space to be of practical use
- variant of SPIDER protocols might provide cost-effective Intrusion Tolerance
- Fault arrival rates are different between fault tolerant and intrusion tolerant systems
- SPIDER architecture designed for multiple active faults

- SPIDER Intrusion Tolerance

## Arbitrary Network Structures?

- ROBUS can use a distributed implementation (not necessarily optical)
- Can generalize the bus-oriented structure to establish a intrusion tolerant version of classical network topologies
- Rings
- Hub and Spoke
- For any particular network topology, there is a corresponding intrusion tolerant topology (at cost of adding redundant links and nodes, and ensuring independence of failure)
- Many existing network structures may include sub-networks capable of supporting this idea

- SPIDER Intrusion Tolerance

## Network Concept

- RMUs

- BIU/PEs

- BIU/PEs

- SPIDER Intrusion Tolerance

## Formal Verification

- Sound concepts with poor designs can result in security issues
- A poor design of these protocols could cause security problems
**Solution:** formal verification
- SPIDER fault tolerance properties have been formally verified
- We expect any modifications to provide intrusion tolerance will also be formally verified.

- SPIDER Intrusion Tolerance

## Summary

- Intrusion resilience vs. Intrusion tolerance
- Techniques from fault tolerance used to achieve intrusion tolerance
- The SPIDER fault tolerant architecture may be adapted for intrusion tolerance

- SPIDER Intrusion Tolerance