33
Your systems. Working as one. Five Ways to Secure a Real-Time Distributed System Without Compromising Performance Heidi Schubert, Ph.D. Director of Research, RTI June 26, 2012

Five Ways to Secure a Real-Time Distributed System Without Compromising Performance

Embed Size (px)

Citation preview

Your systems. Working as one.

Five Ways to Secure a Real-Time Distributed System Without Compromising Performance

Heidi Schubert, Ph.D.Director of Research, RTIJune 26, 2012

Real-Time Systems

The Threat

Threats• Denial of service• Information access• Gaining control of the

system

Vulnerabilities• Belief in security by

obscurity• Dependence on physical

network isolation• Lack of operator ability to

detect a cyber attack• Malware accidently installed

through operator or supply chain

The Challenge

• Many proven security solutions for IT systems

• How to adapt these solutions for real-time?

Five Ways to Secure Real-Time Systems

1. Create a Secure Channel between Real-Time Systems

2. Secure UDP 3. Selective Encryption4. Secure Platforms5. Passive Monitoring

Communication Framework for Real-Time Systems

• Data Distribution Service (DDS)– Publish/subscribe

• Plug and play flexibility– Add new nodes at

anytime• Peer-to-peer

performance– Low latency

• Scalable• Reliable

RTI DataBus™

ConnextDDS

App 1

ConnextDDS

App 2

Peer-to-Peer

• DDS sends data directly to peer

• Anonymous publish subscribe

• Data strongly typed• Discovery process

to find which peers to send to

Real-Time Middleware

• Designed for– Performance – peer-to-peer, no brokers,

middleware tuned for low latency, data push– Availability – no single point of failure, can have

multiple publishers of the same data– Scalability – multicast data delivery, push data only

to interested subscribers• Security?

– Want to use proven security technologies without compromising real-time capabilities

Secure Data Transfer

1. Authenticate– Verify your identity

2. Securely exchange cryptographic keys3. Use keys to:

– Encrypt data– Add a message authentication code

App 1 App 2

Transport Layer Security (TLS)

• Provides– Authentication and key exchange– Encryption with symmetric keys– Message authentication

• Proven and widely used– Web browsing, email, IM, VoIP– Client-server– Primarily used over TCP

Transport Layer Security (TLS)

Image from etutorials.org

TLS/TCP for Real-Time Systems

• DDS typically runs over UDP/IP– Runs in best-effort mode for sensor data– Reliable mode – tuned for real-time

• Performance challenges with TCP– Latency – more jitter for sensor data, generally

higher– Throughput

Secure Solutions for DDS

• Use Case:– Connect separate real-time systems– Provide a secure connection into a real-time

system– Connect LANs over an non-secured WAN

1. Secure Channel between Systems

System 1Routing Service

Gateway acts as security point

System 2Routing Service

TLS

15

Secure Channel with Firewall

System 1Routing Service System 2Routing

ServiceTLS

Can use firewall as added protection

DDS Routing Service with Secure Asymmetric TCP

• WAN clients access DDS data within LAN– Clients communicate with participants in LAN not between each other– Clients behind fire-walls– Only one public address required. Only one firewall configured

• Example: Exposing a service to end-user clients

Remote App

System 1Routing Service

Remote App

Remote App

2. Secure UDP

• Use case:– Need to secure real-time data

Secure UDP Transport

• DTLS– Datagram version of the TLS protocol

• Provides– Authentication, encryption, and/or integrity

• Requires:– A Certificate Authority (CA)– An application must be configured with an identifying certificate assigned by

the CA– An application must have a private key associated with the public key in the

certificate• Standard protocol

– The protocol is highly scrutinized– Unicast only

• open source: OpenSSL

Secure DDS Transport

DDS

DTLS

DDS Discovery TrafficDDS User Traffic

Application 1

DDS

DTLS

Application 2

DTLS handshaking Encrypted RTPS

DTLS trafficApp 1

DTLS handshaking

App 2

DDS discovery

DDS user data

Performance

• Latency test– Two Linux x86 2.4 GHz machine– Send 1024 bytes packets

• DDS - one-to-one best effort average latency– UDP: 77 us– DTLS/UDP: 132 us– TLS/TCP: 291 us

3. Selective Encryption

• Use Case– Secure some data

• Secure commands, but not sensor data• Secure sensitive sensor data, but not all sensor data

– Secure discovery or meta data, but not real-time streaming data

Pluggable Transport Framework

Standard IP network

IP

UDP

• Allows for simultaneous use of multiple transports

• Allows for Secure Transports (e.g. DTLS or TLS/TCP)

DTLS / UDP

RTI Connext DDS

Real-time applications

Encrypt Discovery Traffic only

• Can configure DDS to use only certain transports for discovery:– discovery.enabled_transports QoS

• Use case: – protects meta data such as information on the

data types.– protects against an unauthorized application

joining a DDS domain

Encrypt Selected Topics

• Can configure DDS to use only certain transports for specific Writers/Readers– transport_selection QoS

W

W

R

R

R

W

W

Insecure Writer

Secure Writer

UDP

UDPDTLS/UDP

4. Secure Platforms

• A secure platform can provide security with minimal impact on run-time performance

• Secure platforms– SE Linux– Separation Kernels

Key aspects of SE Linux security

• Subjects of access control decisions enforced on Processes– So applications running on a single process cannot

be differentially secured by the kernel– E.g. All components running in an app server are

indistinguishable to the Linux kernel• Objects protected by SE Linux are:

– files, directories, inter-process communication mechanisms, ports, devices, etc.

Using SE Linux to Secure DDS Applications

• SE Linux Type Enforcements can be used to restrict access to domains– DDS maps domains to ports and SE Linux can

restrict access which processes can open a given port number

• SE Linux can also be used to restrict access to specific data– Data samples are defined by Topics in DDS– Each Topic can use a separate port

RTI DDS in a MILS Partitioning OS

• MILS separation kernel guarantees separation between processes– Time partitioning– Space partitioning– Pre-configured data flow

• Designed to keep data at different security levels separate• MILS kernel evaluated to prove it provides separation• RTI Connext DDS supports VxWorks MILS

Active Monitoring

• Intrusion Prevention Systems– Network appliance– Identify and block malware and malicious activity

5. Passive Monitoring

• Passive Monitoring on the Device– Application Protocol based IDS

• Dynamic protocol behavior monitoring• Application fingerprinting

– Host based IDS• Monitors behavior of the host• E.g. Verisys, Tripwire

• Passive Monitoring on the Network– Network IDS and anomaly detection

Conclusions

• Don’t blindly use IT security technologies on your real-time system

• Instead, use one or more of these approaches1. Create a Secure Channel between Real-Time

Systems2. Secure UDP 3. Selective Encryption4. Secure Platforms5. Passive Monitoring

Additional Resources

• Get started in less than an hour– Download a FREE trial of RTI Connext™ Messaging:

www.rti.com/downloads/connext.html

• RTI Supporting Resources– RTI website: www.rti.com– RTI security:

http://www.rti.com/products/dds/security.html – Additional RTI webinars: www.rti.com/mk/webinars.html – Follow RTI on Twitter: twitter.com/RealTimeInnov

DownloadConnextFree TrialNOW

www.rti.com/downloads