Month: October 2019

In 2018, the Robot Operating System 2 (ROS2) launched as a successor for ROS1. At ROSCon 2019 several speakers shared their experience in moving from ROS1 to ROS2. Lessons were shared in two separate talks: the Autoware project, and a demo port by Rover Robotics.  

The Autoware project took the opportunity to restart the design of their software to work better for ROS2. Autoware started as Autoware.AI, which is open-source software for self-driving vehicles. They based the software on ROS1, which was great for prototyping. However, there are three reasons why Autoware was not suitable for building certifiable products. The main reason is that ROS1 is not certifiable, and achieving this would take many years and people’s effort. Determinism and memory safety of the Autoware AI application was not also possible. Last but not least, there is less than 6 years of the support life left, as the end of life for ROS1 is specified as 2025. Therefore, Autoware decided to start autoware.auto as new software, which was more work but proved to give better long-term results. 

Moving to ROS2 provided several benefits over ROS1. One benefit was managed launching, where you can specify in what order nodes launch. Another benefit was the DDS communication protocol, which can pass messages around with zero-copy, saving both CPU and memory resources. In terms of development they spend more effort on having increased test coverage, more and better understandable documentation, and more continuous integration to get the software certified. 

To ensure continued happy use of the existing Autoware stack, the engineering team added support for the new project to the old project. This was achieved by adding a ROS1 bridge. This way new high-quality features are introduced in the new project, while keeping current existing contributors happy. In terms of contributors: because of the higher expected quality, Autoware needed to have a higher test coverage, a design document for every major contribution, and writing for and testing of deterministic execution. To encourage both current contributors and new contributors, people working on Autoware are mentoring them. They walk through the process of contributing to Autoware with potentially interested contributors, who are also given frequent encouragement. 

A second talk was given by Nick Fragal and Nick Padilla, both working at Rover Robotics. They also used ROS1 for sharing common robotics code, and to minimize rewrites of common tasks. They want to use ROS2 to share reliable robotics code. The technical steering committee for ROS2 contains many people from large companies who take reliability seriously, and thus it can be expected that ROS2 will be adopted by many companies. This provides ROS2 with a lot of promise. 

Fragal talked about their application: a t-shirt delivery robot which brings t-shirts to attendees at a conference. They made a demo using ROS1 and wanted to port it to ROS2. The initial port went smooth, but when they give a new demo at a conference with slow wifi, they ran into problems. 

The underlying reason was the DDS protocol, which did not run well over a slow wifi link. To solve this problem, they looked at the parameters which can be tweaked to make DDS work better on slow wifi. They also compared different implementations of the DDS protocol and worked together with suppliers to improve their implementation. Eventually, multiple DDS providers could be used to bring the software on the robot up within 10 seconds. The take-home message is to choose a DDS middleware that has zero-copy to prevent issues related to moving around images in your memory. 

Overall, Rover Robotics estimate they spent approximately 60% of their time looking at the communication protocol when porting this demo. However, now that it is working better (for everyone) they hope to focus 90% of their effort on their navigation and application code. 

Elastic recently released Elastic Endpoint Protection, a new feature for integrated security built upon Elastic’s acquisition of Endgame. With Endpoint, Elastic is combining their SIEM product and endpoint security into a single solution built on the Elastic stack.

Earlier this year, Elastic announced the addition of Elastic SIEM to their product suite. A SIEM (Security Information and Event Management) aggregates and analyzes log data from a variety of sources and attempts to identify threats and breaches. Braden Preston, director of product at Elastic and product lead for Endpoint, described the Endpoint product, in a conversation with InfoQ, as a “fully integrated vertical solution from SIEM to endpoint without the need for additional modules”.

Elastic’s SIEM showing a detailed view of anomalies (credit: Elastic)

Endpoint security refers to methods of protecting the corporate network when accessed via remote devices. Endgame’s endpoint protection product was originally built using the Elastic Stack to facilitate the parsing and analyzing of log data. As Preston explained, this made the partnership between Elastic and Endgame a logical fit. Nate Fick, former CEO of Endgame and now general manager of Elastic Security, elaborated:

Stopping attacks as early as possible is the goal. That requires the best preventions and the highest fidelity detections on the endpoint. The combination of Endgame’s leading endpoint protection technology with Elastic SIEM creates an interactive workspace for SecOps and threat hunting teams to stop attacks and protect their organizations.

As Preston explained, the Endpoint solution does not rely fully on third party sources to provide threat intelligence nor does it require a constant network connection for protection. With endpoint protection solutions, there are two main models. In the first model, lists of known threats and attack vectors are routinely downloaded to the remote machine. The endpoint software scans for threats that match the lists and blocks anything that matches.

Endpoint employs a different approach which Preston described as Attack Technique Focused. In this approach, the system analyzes for anomalies in real-time that match pre-described attack behaviours. Preston explains that while the attacks can change and be adapted, the techniques that are used during an attack are finite. As he described, this provides deeper protection as attack techniques cannot be changed polymorphically in the same way attack signatures can; as in the approach taken by polymorphic malware.

Endpoint takes a layered approach to endpoint security. With this release, Elastic has incorporated their machine learning models to process the data collected from the SIEM to the endpoint. Coupled with that, the endpoint protection has a machine learning malware protection model that works to stop malicious executables and macros. This is trained and delivered on a periodic interval. The final layer addresses OS level attacks and is updated on a regular basis, typically following critical OS updates.

According to Preston, the team is enhancing Endpoint’s prevention models that autonomously stop attacks to continuously protect endpoints without requiring additional modules or deployment complexity. While Endpoint already ships all its data in the new Elastic Common Schema, the team will continue making endpoint security a native experience in the Elastic Stack. Earlier this year, Elastic introduced their common schema as a means to provide a consistent way to structure data in Elasticsearch to streamline analysis of data from multiple sources.

Early reviews of Elastic’s SIEM offering have been fairly positive. Upguard compared Elasticsearch and Splunk and found that Elastic’s offering just beat out Splunk on criteria such as community support and learning curve. However, some reddit users called out that there is limited firewall support for the SIEM at this time, with support only for Palo Alto Networks and Cisco ASA.

Elastic’s Endpoint Security features are available under the Elastic License. As previously covered by InfoQ, this means that the features are available to users of Elastic’s open-source models or their SaaS offering, Elastic Cloud. However, users of AWS’s Open Distro for Elasticsearch or their fully-managed Elasticsearch Service offering will not have access to these new features.