Improving Efficiency & Quality of Patient Care With Connext DDS Reply

case and code medical device interoperability rti connext dds use case

Interoperability between medical devices can improve both the quality and efficiency of patient care, saving lives and money. Fortunately, with the help of FDA’s recent recognition of medical device interoperability standards and advent of the Industrial Internet of Things, interest and investment in medical device interoperability are increasing.

RTI Connext DDS is particularly well-suited as a communication platform for medical devices. It supports the Data Distribution Service (DDS), the only interoperability standard designed for real-time systems. It features peer-to-peer communications and automatic discovery, so does not require servers or system administration. It is also easy to integrate with existing applications, devices and hospital IT systems.

One serious challenge today is “Alarm Fatigue.” This is the focus of RTI’s new Case + Code example. According to a FierceHealthcare article, hospitals rank alarm fatigue as top patient safety concern. Alarm fatigue occurs when clinicians and nurses become overwhelmed with constant noise of false alarms and turn alarms down or off.

case and code medical dds use case

RTI’s newest Case + Code Example illustrates how RTI Connext DDS can be used to counteract alarm fatigue in hospital or clinical settings. The implementation correlates data coming from different medical devices (in this case Pulse Oximeter and ECG) via the RTI Connext DDS data bus; it then generates alarms based on alarm probability values. The result is significantly fewer false alarms.

cc5

For technical details of the Case + code example, please visit our github repository.  You can copy the code and use it in your own implementation as you see fit. Any questions or technical difficulties? Don’t hesitate to post it on RTI’s community portal at http://community.rti.com.

Guest Post: Accelerating the IoT – Adding Security in Legacy Systems Reply

This post, penned by Geoff Revill, was originally published on linkedIn (here). We liked it so much that we wanted to share it with you all. Thank you, Geoff!

rti connext dds secure

For the most part, the Industrial Internet aspect of the IoT won’t happen until we can figure out a way to build security into legacy deployed systems. There is trillions of dollars of deployed systems that essentially rely on physical security measures, replacing these systems with shiny new cyber-ready systems will take decades. Accessing their wealth of data via the Internet is a major security challenge – few of these systems were designed to be secured against cyber attack. So the wealth of shareable sensor data and industrial insights remains locked in proprietry system deployments. In many cases that’s just the way the owners like it, and for many there is no real reason – yet – to open up their systems to the Internet. But the innovative large scale entities that find ways to open up their systems could unlock a mobile-like app phenomena – becoming the Apple or Google of the IoT age. It’ll take a bold move by an even bolder entity to do this, but with high risks come high rewards. And if they don’t, be assured Apple or Google or similar will gradually encroach on that Industrial home turf.

This is why I found this story so fundamentally exciting ( http://bit.ly/1uWkyb4 ) because it defines a way to secure the transport infrastructure of pretty much any SCADA style system. It even includes a rapid prototyping scripting interface to allow continuous evolution of cyber-defence techniques with instant deployment capability. It combines fundamental security techniques with a truly agile response mechanism – and fine grain control of what information can be let out of the cyber-walled garden and what has to stay securely locked in. Even better its based on technology the worlds largest defence agency has already tried tested and found to be securely acceptable – if it’s good enough to defend the lives our brave fighting men then surely its good enough to consider for the innovative first movers in the Industrial Internet of Things?

Make Your Distributed System Cyber-Secure Reply

rti connext dds secureHow do you approach such a challenge? The larger your distributed system is, the more attack points you require to secure and defend it against hackers, and yet at the same time, the more varied your authorized access levels need to be. You may need to facilitate maintenance, updates and upgrades, monitoring and many other system-wide tasks, each requiring differing access rights to many overlaid sub-elements of your distributed system.

Defending distributed systems is usually done in one of two ways:

  1. Physical security. The larger, distributed system is secured by isolating the systems to be protected from cyber-interaction.
  2. Simplified lock-down. Security is achieved by minimizing access rights to a few privileged employees with high security clearances/special permissions.

Both solutions deny access to the full potential that the Internet of Things is meant to enable, while massively restricting the flexibility required for day-to-day operational procedures. So the lack of security becomes a business benefit trade off.  But why would you ever knowingly trade away value in your operational infrastructure?

In IT systems the problem is largely delegated to the database – with data access rights defined and limited through authorization and authentication methods, as well as the usual encryption of critical data where needed.  But few real-time systems store their time critical data in databases due to the performance hit or cost issues.  Yet it’s the data in motion that needs protection in real-time systems, this is the critical business asset.

In some systems another issue comes into play –the ability of a hacker to alter control parameters becomes a safety issue as well as a brand reputation and data value loss problem.  The consequences of which can be far more far-reaching than the mere loss of some data.

So what’s needed is database style defense tools that operate across a system infrastructure.  This is exactly what RTI Connext DDS Secure is designed to do.

protectTheGrid

One tool chain to manage authentication, access control, encryption, access privileges and security monitoring.

In fact with the RTI tools you can go further, and enable agile attack response tool development just like Rajive did when he built a secure SCADA infrastructure with PNNL – in fact he showed this toolchain can be applied retrospectively to legacy distributed systems deployments.

Connext DDS Secure – the best defense for your cyber-enabled infrastructure – plug it in today!

Additional information on Connext DDS Secure:

If you have any questions, please don’t hesitate to ask! We’re here to help.

How PNNL and RTI Built a Secure Industrial Control System with Connext DDS Reply

Connext DDS Secure Demo Team

The Pacific Northwest National Laboratory (PNNL) is located in the beautiful wine country region of Washington state. Their cyber-security research team and I just pulled off a flawless demo for a new secure solution for interconnecting commercial devices and applications used in the electrical power grid. The amount of effort it took was quite intense.

Our secure solution stopped eavesdropping and man-in-the-middle attacks, and it raised alerts for various insider attacks including identity spoofing by malicious actors. In contrast, the legacy interconnections used in practice today were susceptible to eavesdropping, man-in-the-middle attacks, and insider threats!

Legacy SCADA Systems

Supervisory Control and Data Acquisition (SCADA) systems are used to monitor and control industrial equipment.  Many industries deploy SCADA systems, including oil and gas, air traffic and railways, power generation and transmission, water management and manufacturing.  The electric utilities are major users. Scheduling, optimizing and controlling electric power generation and transmission require powerful real-time SCADA systems.

generic SCADA system

As shown in the figure above, there are five components in a typical SCADA system:

  1. The field-based remote measurement and control equipment (called remote terminal units, or RTUs) used to manage the flow of power at an electrical substation. The substations are typically at remote locations, and usually not attended by people.
  2. Programmable logic controllers (PLCs), relays or intelligent electronic devices (IEDs) used to automate tasks within a remote unattended substation.
  3. A control center with a set of central computers to manage the remote equipment located at various remote substations, and to process, analyze and archive the real-time data.
  4. A communication system to interconnect the substations to a control center.
  5. The operator interface (human-machine interface, or HMI) at a control center to allow human operators to supervise and manage the flow of electric power.

Much of the critical national infrastructure using SCADA today is showing its age. These SCADA systems were designed for reliability and personnel safety; implicit trust of all components and communication was the norm.  Restricting physical access is currently the only practical security method for much of the critical infrastructure such as the electrical power grid. For the most part, SCADA systems do not consider the threat from malicious intruders. This situation is changing with increased connectivity to the Internet and personal computers. The most prevalent threat is connecting to external networks through modern technologies like Ethernet and the Internet Protocol (IP). Although using these technologies makes systems functional and efficient, it unfortunately also opens our critical national infrastructure to cyber attacks.

Ultimately, these systems should adhere to the “Three Tenets of Cyber Security”:

  • Focus on the critical data communication
  • Control access to the data
  • Detect and defend against attacks

Applying these tenets to SCADA systems requires a framework that can securely communicate sensor information effectively in a real-time environment, connect this information to analysis technologies and work in the unique SCADA environments.

Solving SCADA Challenges with DDS

RTI teamed up with PNNL to build a solution. Our architecture used the open standards-based Data Distribution Service (DDS) message bus to securely interconnect devices and applications.

SCADA DDS Security Solution

We created a rapid application development kit for DDS so the attack detectors could be quickly created and modified using the light-weight and extensible Lua scripting language.  Detectors could be added and modified without disrupting a running system or interfering with the critical data path.

We developed a data-centric “any-to-any” interoperability paradigm for interconnecting existing SCADA applications and devices that could be speaking a variety of other protocols. Our architecture allowed various SCADA protocols to be plugged into a secure DDS DataBus.

Secure Scalable SCADA Architecture using Connext DDS Secure

The solution architecture enabled rapid development and reconfiguration of attack detectors which could monitor and interpret the communications between devices and applications speaking various protocols. The architecture scaled horizontally, allowing new devices, applications and attack detectors to be added incrementally, without disrupting existing components.

For the demonstration at PNNL, we selected devices and applications that speak the DNP3

protocol, the most widely deployed protocol on the US electric power grid.

SCADA equipment setup

On the transmission substation, we deployed real-world devices (SEL 351A, SEL 451, GE L90) and on the control center we deployed HMI apps (Wonderware, Triangle Microworks SCADA Data Gateway), commonly found in the US electric power grid.

Implementing Security with Secure DDS

In the retrofit demonstration, we replaced the DNP3 link between the control center and the substation with a modern WAN network running an early access version of RTI Connext DDS with security extensions. Everything was compliant with the recently adopted DDS security specification.

Implementing an effective DNP3 connection

Effective DNP3 was established between the devices in the transmission substation and the applications in the control center by tunneling the DNP3 messages over the RTI Connext DDS DataBus. DDS security extensions allowed only authenticated components on the bus, and furthermore allowed only components with “write” permissions to modify data, and only components with “read” permissions to access data. The ScadaConverter unobtrusively exploded the DNP3 payloads into a data model suitable for analysis by the AnomalyDetector(s) written in Lua, leveraging the rich structured data modeling capabilities of DDS for data in motion. The detectors continuously published metrics and raised alerts when anomalies were detected. You can see the logical data flow above.

Testing showed that our solution was able to securely tunnel DNP3 traffic between unmodified legacy SCADA devices and applications. We found that the secure DDS infrastructure did not negatively impact the operation of the testbed transmission substation environment. Control system communication between client and slave devices was not interrupted.

At the same time, our solution was able to thwart eavesdropping and man-in-the-middle attacks. The data-centric attack detectors were able to tap into the flows and raise alerts for various insider attacks including identity spoofing by a malicious component, unauthorized firmware upgrades, unsupported requests, high risk commands and denial of service. In contrast, the legacy SCADA communications were susceptible to both man-in-the-middle attacks and insider threats.

Conclusion

Our open standards-based extensible solution architecture built on Connext DDS with security extensions enables operators to monitor, analyze, visualize and respond to evolving attacks. It can leverage open-source and commercial off-the-shelf technologies as well as new anomaly-detection technologies. It can collect security status and process it to detect attacks that target industrial control systems. The solution lays the foundation for real-time detection capabilities, greatly increasing network reliability and defensibility of industrial control systems from cyber attacks. Overall, it’s a timely, much-needed solution, given the current state of industrial control systems.

Want to learn more?

Connext DDS, Robotic Limbs, and the Borg Reply

Has our CTO been assimilated by the Borg and given new fancy limbs for becoming part of the collective? No. No he hasn’t. Phew!

But while Gerardo was visiting ESA Telerobotics and Haptics Laboratory (ESA/ESTEC), they let him try out their awesome human arm exoskeleton.

A big thank you to the team at ESA Telerobotics and Haptics Laboratory for sharing their work with us, and for this great picture of Gerardo. We’re looking forward to seeing your progress!

For more information on this project, view Andre Schiele’s TED Talk (go to 2h19min).

One Admin Console To Debug Them All! Reply

ac-blog-1

Better DDS Debugging with Admin Console

How can you debug a program when data is not flowing? It’s difficult to even diagnose a data flow issues since Quality of Service (QoS) can vary from one application to another. The problem can be compounded by the sheer scale of a system, as well as the integration of subsystems in a heterogeneous environment.

To ease debugging, the RTI Admin Console in Connext DDS 5.1 has added real-time match analyses. Each time a new DataWriter or DataReader is discovered, Admin Console evaluates its QoS as it relates to the other DataWriters and DataReaders associated with that topic. This evaluation is updated as the system changes.

ac-blog-2

Let’s say a specific DataReader deadline is compatible with a specific DataWriter. Then assume an application changes the deadline of that DataReader to make it incompatible with the DataWriter. Admin Console is notified of the updated QoS (through Discovery) and updates the match status.

So, what does it look like? Well, let’s walk through the user interface elements. First, the Physical View shows that the System, Host (balancerock in this case), and processes are in an error state.

The DDS Logical View also gets in on the act by showing the Topic which has the error. The DDS Logical View provides a DDS-centric view of the system by putting Topics under their respective Domains.

ac-blog-3

We click on the ‘Square’ Topic to bring up the Topic Editor. While there are two DataWriters, only one of them is mismatched. The DataReader is shown as ‘Partially matched’ because it matches one DataWriter but not the other.

ac-blog-4

We select the mismatched DataWriter and turn our attention to the ‘Match Analyses’ tab to discover the reasons for the problem.

ac-blog-5

It seems there are two problems; the Ownership and the Deadline QoSes are mismatched.

Did you notice that the QoS policies in the first column are formatted like hyperlinks? That’s because they are hyperlinks. If you click on the Ownership hyperlink, Admin Console shows you the compatibility documentation for the Ownership QoS policy. The other hyperlink points to the Deadline QoS policy.

IoTDevCon 2014 Reply

Did you happen to attend IoTDevCon and catch Stan’s talk on IoT Protocols? We hope you enjoyed it and took away some valuable insights. If you couldn’t attend, you don’t need to miss out on the fun! Here’s what you might have seen if you were in the audience:

IoTDevCon - Internet of Things Protocols
And here are the slides:

Enjoy — and please feel free to ask questions and leave your feedback in the comments.

UPDATE: Connext DDS 5.1 & Heartbleed Reply

heartBleedThe Heartbleed bug is serious, with the potential to expose user passwords and other sensitive information.

The vulnerabilities created by the Heartbleed bug have been identified in certain versions of the OpenSSL cryptographic software library. More information about the bug can be found at www.heartbleed.com.

OpenSSL is used for certain features in RTI Connext DDS such as the Secure WAN and TLS transports. RTI Connext DDS 5.1.0 shipped with a version of OpenSSL that is affected by the Heartbleed bug.

OpenSSL version 1.0.1g addresses the heartbleed bug (see the OpenSSL security advisory here: http://www.openssl.org/news/secadv_20140407.txt). RTI has built and tested OpenSSL version 1.0.1g against RTI Connext DDS 5.1.0 and made it available on the RTI Customer Portal. Any customer who is using RTI Connext DDS 5.1.0 and OpenSSL should replace their existing OpenSSL installation with the new version.

If you are using a different version of RTI Connext DDS, you are not affected by the vulnerability and no action is required.