Qosmos

Resources

Voices from the Field: Upgrading to ixEngine v5 in Cybersecurity

In 2006, Qosmos launched the world’s first commercial DPI software development kit (or DPI engine), with the goal to help networking and cybersecurity solution developers accelerate time to market and strengthen their products. Since then, Enea’s Qosmos ixEngine has become the de facto industry standard.

Deep Packet Inspection (DPI) is a key technology running inside networking equipment and cybersecurity products. DPI software is very specific requiring special expertise for reverse engineering, creation of custom-made tools, fast reaction to protocol changes, handling of extreme packet speeds, and ability to classify encrypted traffic. This makes it costly to develop and maintain internally. So many networking and cybersecurity solution vendors outsource their DPI from a specialist such as Qosmos.

What follows is a short interview with Craig, a software developer working for a security vendor, who has been using ixEngine v4 and is currently in the process of upgrading to ixEngine v5.

 

Enea Qosmos: What is your role as an ixEngine user?  
Craig: I am part of the backend development team working on our flagship network security solution, which integrates ixEngine. The developers work with a tech lead, a product manager and two quality assurance colleagues. At the moment, we are discussing how to best integrate ixEngine v5, based on timelines and technical specs from product management. As the DPI specialist in the team, I am also the main interface with our Qosmos technical contact, Vincent.

 

EQ: How does your product leverage ixEngine?
Craig: Our cybersecurity solution runs ixEngine on top of CentOS. Our software uses the DPI to classify traffic and extract selected metadata. The information feeds an alarm generation mechanism and a database, which is then used by our customers to investigate security events.

 

EQ: What is your general impression of ixEngine?
Craig: ixEngine v5 is incredibly powerful and the API documentation is particularly good. I was able to ramp up my knowledge quickly by going through the code samples: there are lots of features, and lots of material describing the capabilities of the software. It was nice to get info ahead of time so we can have it in mind when integrating v5.

 

EQ: Any specific new features in ixEngine v5 that you like?  
Craig: I had a good discussion with Vincent about the new Custom Signature Module (CSM), which means that we can develop our own signatures in a fully automated way and load them into our product in real-time. We will be able to use the Qosmos process for standard, scheduled signature updates and our own fast signature updates for specific needs.

 

EQ: How long did it take you to fully understand how ixEngine works?
Craig: I am still learning ;-). In fact, I started reading the documentation one month before Vincent came to visit, and I was able to build a bare bones application using ixEngine. This was a good way to test and see what it would look like in our real architecture. We then spent a week with Vincent, going through the developer guide, and based on Vincent’s experience, we were able to decide what makes sense, went through code samples, and adjusted the architecture for the migration from ixEngine v4 to v5.

 

EQ: What do you think about the protocol update mechanism?     
Craig: When we need a protocol bundle (PB) update, we pull down the info from the ixEngine protobook and run scripts to generate our own software code. The new PB format in v5 is even easier to use. The update frequency is well paced and fits nicely with our own release schedule. If we need a new signature, we put in a request, which is typically fulfilled in the next ixEngine PB.

 

EQ: Thanks Craig!