DFLabs 3rd Party Integrations vs the Market

Posted byOliver Rochford - 17th Jan 2018
dflabs 3rd party integrations vs the market

A consistent feedback point we receive from our users is that their security technology stack is rapidly growing to keep pace with the evolving threat landscape. The days where it was sufficient to deploy a firewall, an intrusion prevention system, antivirus and an identity access management system are long gone. Enterprises are literally spoilt when it comes to selecting a wide variety of different security technologies – User Entity Behaviour Analytics (UEBA), Network Traffic Analysis (NTA), Endpoint Detection and Response (EDR), Breach and Attack Simulation (BAS), are just a few of the emerging technologies available to security teams, and this list does not even include mobile, cloud and IoT offerings that are required to secure the expanding attack surface. This can seem daunting to many organizations, not just the budgetary impact, but also the fact that every one of these technologies requires the expertise and knowledge to effectively operate them.

As a vendor offering a Security Orchestration, Automation, and Response platform that is designed to integrate with, and orchestrate these different solutions, we often have to make difficult choices as to what we integrate with, and how deeply we integrate. Our focus is on market-leading security technologies, technologies we identify as emerging but of growing importance and effectiveness, and of course also based on what our customers have deployed and ask us to integrate.

There is a trend in our market to exaggerate the amount of 3rd party integrations. Marketing collateral often cites hundreds of different 3rd party tools, yet rarely differentiates between the depth of the integration, whether these are truly bidirectional and whether they certified by the 3rd party. As an example, any solution that supports Syslog can claim to support hundreds of 3rd party technologies. It’s an open standard and many solutions can forward syslog message to a syslog collector. But that does not necessarily mean that the solution also has out of the box parsers to normalize the messages, or that there are automation actions, playbooks or report templates available that can parse and use their content.

Reducing this to a pure quantitative marketing message also entirely misses the point. Organization only really care about the technologies they have deployed, or are planning to acquire. The quantity here is entirely misleading. More importantly, users are not stupid. They will see through this charade at the latest when conducting a proof of concept. And at that point any vendor following this approach has some uncomfortable explaining to do. No relationship, personal or business, gets off to a good start based on fudging the truth.

I have rarely seen an RFP that was based purely on a quantitative measure of supported 3rd party integrations, so it is baffling why marketers believe this to have any impact.

At DFLabs we have decided to go a different way. We want to clearly state which of our integrations are bidirectional as opposed to only based on data ingestion, and which integrations are certified, or compatibility tested by our integration partners.

While at first glance this appears to put as at a disadvantage, we trust in the intelligence of our customers. We hope that it will help them to make better-informed decisions and they give us credit for being honest and realistic.