Gartner Blog Network


Tricky: Building a Business Case for A Deception Tool?

by Anton Chuvakin  |  September 23, 2016  |  5 Comments

How do you develop a business case for a DECEPTION TOOL?! I just went through a whole bunch of deception vendor materials and I was unpleasantly surprised at the lack of advice from the vendors in this regard.

For sure, those few organizations adopting deception tools are struggling with this challenge. Naturally, there is no “deception budget” at most organizations and even “advanced threat budget” may or may not exist. Given that much of deception today is aimed at better threat detection, they have been decent attempts to justify the tool by hopes of better threat detection efficiency and effectiveness, cheaper alert triage, earlier detection, lower FPs (compared to what?), etc.

Others hope to push the deception vendors to broaden and eventually replace other tools (like say NTA or EDR or even UBA), but this route (apart from it being long and painful) may risk pushing vendors to build a spork – a spoon/fork hybrid that is at best mediocre at both functions. [a metaphor that was <here> has been deleted because some people were saying that it was offensive]

Along the same lines, some vendors seem to contrast deception tools with preventative tools, but in this case customers have a lot more choice: SIEM, UEBA / UBA, NTA, EDR, etc; a bunch of proven (ahem … and not so proven) tools focused on detection & response. So, your screams “buy deception, not prevention” ring kinda hollow…

The reason for this struggle is easy to explain: deep down, we all know that today the deception tools are “a nice to have”, not “a must have.” As my wise mentor once told me “sell aspirin, not vitamin” … but how? Dear vendors, please let me know how your solution is not “a nice to have” today! We’d love to hear it!

So, our running list for deception tool business is:

  1. Business case focused on improved threat detection (better detection of existing threats, detection of “better” threats, earlier detection) [so, in effect, lower detection cost and/or higher effectiveness]
  2. Business case based on high quality of alerts, pre-triaged alerts [lower triage and investigation cost]

Got much to add?

Finally:

  • Our call to action to vendors: how do you help customers establish a business case for your deception tool?
  • Call to action to customers how did you establish a business case for the deception tool you purchased?

More fun deception posts from Augusto and myself are ahead as we delve into this exciting area!

Our related blog posts on deception:

Category: deception  security  

Anton Chuvakin
Research VP
5+ years with Gartner
16 years IT industry

Anton Chuvakin is a research VP at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on Tricky: Building a Business Case for A Deception Tool?


  1. Hi Anton, you raise a great point, establishing a business case has always been a challenge when new technologies evolve to solve security challenges.

    In this regard, I would like to share some of my experience that may not give you the answers you are seeking today, but help provide some guide posts when looking at a technology like deception.

    I will start with some of my previous positions and their technologies, including the challenges with building the business cases.

    UTM/NGFW – many years ago, I was the VP of Product and Marketing for an emerging company that created the idea of bundling multiple security technologies on a firewall (Fortinet). At the time, justifying the business case was a huge challenge. Like deception, back in 2004 there was no budget for UTM/NGFW. Most companies had a separate line item for Firewalls, and a different one for Gateway Antivirus, separate for IDS/IPS, separate for Antispam and so on. After much evangelism and customer engagements, eventually the technology emerged to show how it is needed beyond the status quo of traditional products previously budgeted for.

    Sandbox – after a few more successful postings, I took a role as VP of Product for FireEye when they were starting to gain traction. At that time, the same scenario existed. No budget allocated for advanced threat tools, much less Sandboxing. So again we were left to evangelism and customer engagements. Now, budgets typically exist for Advanced Threat Detection or specifically FireEye.

    Deception – I took the role much like I took my previous roles. I know the security market well, and also felt I knew the deficiencies. When I investigated Deception with TrapX, I had the same reaction I did when I first investigated UTM, and Sandboxing. This brings a new level of visibility never before established with current solutions. It is a simple to deploy technology, and the returns are immediate (at least with our customers – even though they already have the typical UTM/NGFW and sandboxing solution).

    So, my conclusion is this. New technologies that create new markets will never have a budget assigned, and be difficult to establish a business case before they become mainstream. The reality is (like the UTM/NGFW and Sandboxing markets) early adopters will pave the way showing how much value they are getting and how much their security posture has increased. Eventually this will become more common, then customers will start to establish budgets, and the business case is born.

    I know this does not directly answer your questions, but I hope it gives you some things to think about.

    Anthony.

  2. […] we are trying to understand is how organizations are building business cases for deceptions tools. As Anton said, most of the times deception will be seen as a “nice to have”, not a “must […]

  3. […] tools as “a better IDS.” Hence our discussion of the business case for deception (here and here) was centered on detecting […]

  4. […] we mentioned a few times before, we see a lot of “deception as detection” use cases. Frankly, we see nearly all deception projects focused on threat detection (typically of […]



Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.