Blog post

Tricky: Building a Business Case for A Deception Tool?

By Anton Chuvakin | September 23, 2016 | 2 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?


  • 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:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • 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.