So, occasionally I get this call from somebody (vendor, end-user, investor, etc) inquiring about “the size of the security analytics market.” They are usually shocked at our answer: since there is no such market, there is no size to report.

If you recall, we [as well as myself] don’t really believe there is such a market at this time and find any discussion of its size “premature” (at least). Let’s explore this in detail – and hopefully save some of my time for loftier pursuits.

In essence, if you are in the market for a car, you are very unlikely to buy a toilet bowl or a jet plane instead. Everybody knows what is a car, what it does, how it functions [well, at some level] and how much it costs. Sure, there is a difference between a Kia and a Maserati, but such variances are easily understood by the customers. While market definition in general is hard, industrial organization (IO) economics have made a lot of practical advances towards that goal (for example, some use “the smallest area within which it is possible to be a viable competitor”). Close to home in our infosec (“cyber security”?) realm, if you need DLP, you go and buy DLP. If you need a WAF, you go get that. Even with SIEM, there is relative clarity in terms of features, benefits and prices.

Do we see ANYTHING of this sort when “security analytics” is mentioned?

There is no common feature set, no critical/core capabilities, no jointly understood need, no buyer-seller agreement on anything, no clear competitive dynamics ….

As we say in our paper“defining “security analytics” at this point simply involves looking up the words in the dictionary. There is no “security analytics market” or dedicated and purchasable “security analytics tools”; security analytics is a concept that an organization can practice, but can’t buy. Many different tools — from network intrusion prevention system (NIPS) to DLP and SIEM — use various algorithms to analyze data, thus performing analytics. Thus, if security-relevant data is subjected to analytic algorithms, security analytics is being practiced.” Along the same line, one enterprise I spoke with defined it as “ability to analyze lot of security data over long periods of time, find threats and create models” [not too specific – but hitting a few interesting things such as long term analysis, threat discovery, models, etc]

In fact, I can give you a handy analytical tool to create your very own “security analytics” vendor – right here, right now! FREE!!

Analyze it in some way (ideally not by using rules, but any algorithm will suffice – think various types of ML [supervised or unsupervised], clustering, deep anything, forensics something, text mining, etc]

Present the results in some way (ideally visualize, but – if you are adventurous – also act automatically, reconfigure, etc)

That’s it! In your mind, you are now a player in a burgeoning [in your mind] “security analytics market”…

Thoughts on Why No Security Analytics Market?

The security analytics market is a nascent attempt to productize a subset of data processing architectures and data science *without a specific problem*, likely inspired by the BI market’s success doing the same. The main challenge security brings is high rate event data that requires a large hardware investment…and much lower tolerance for “exploratory purchases”. That’s a tough combo to swallow.

Would agree big data security analytics (will call it that for convenience) is a nascent market, but all things start nascent, then some grow some don’t.

There is a “problem” – surely that is undeniable (read Krebs). It is not that is it not “specific”. It’s actually the opposite – in my mind. It is a very long tail problem – to catch today’s breach and theft activity early enough to do something constructive requires looking at lots of specific indicators of kill chain activity – and with confidence so you don’t false incessantly. And you need to do this with meaningful speed (I’ll avoid saying real time here). And because of today’s IT environment, things are highly situational. That’s enough variables to cause innovators to see if they can find a new approach.

And of course, that “new approach” may borrow some capabilities from the past. But it may also add something new. That is how it goes. Few things are truly revolutionary. Most are evolutionary.

I can accept there is disdain for those who would try to market it ahead of its maturity (btw, it took many years for BI to mature to where it is today). But, that does not mean the problem and need will go away.

We are very early in the Security Analytics game. There is clearly a market need for security analytics capability. There is no consensus as to what this capability really should look like. It reminds me of the early 1900s situation with cars. There is clearly a need, and there are some vendor offerings. Some offer cars powered by steam engines, others offer electric cars. There are also cars powered by this internal combustion engine thing that’s new, unproven and not particularly reliable.

Traditional SIEM and DLP systems are very much like steam cars. They are powered by well proven technology, but this technology has reached its limits. Splunk and the likes are a lot like an electric car. Built on technology that’s both well understood and adapted from a different area (generic log management and reporting). It does certain things well, but is ultimately not the way to go in the long run.

A proper security analytics suite is yet to be built. The technology is still in the works. Once it is built, lot’s of peiople will have their ‘eureka’ moment, and the one who builds it first will make tons of money.

Agree with Max. There is no doubt a problem in the industry. Verizon DBIR points it out well – we have the data that tells us the bad guys are in, but we cannot piece it together until 6 months after the fact. Yes, startups playing the “big data security analytics” card are clearly marketing as a disruption. But the fact that marketing may be out ahead of technology maturity, is not an argument that changes in the way we assimilate, analyze, and visualize data aren’t coming. And yes, it may be evolutionary relative to SIEMs, but there is a problem, and there is a need. And “in my mind” – I guess I need to say that given the positioning above – it is a valid effort to figure out if we can look at data in new ways to figure out early kill chain activity faster, with greater accuracy, and improved human interaction. After all, the BI space did not become a billion dollar space overnight. It took a bit of time

The problem is there. Just read the DBIR to see that we have the raw data but we don’t piece attacks together until 6 month later. As with any new market, marketing will lead product maturity, so that is what it is. But, unless you think the security market is 100% complete in its detection and prevention wisdom, new capabilities will emerge from vendors trying to skin the problem with different ways of collecting, processing and visualizIng data. At least that is true “in my mind”

We were the first to process massive amounts of full packet data, we coined BDSA and I still feel we are pioneering and forging new ground daily. In the last 3 years the ‘market’ has been defined by a number of trailblazers working in different areas of security – logs, packet capture, vulnerability analysis etc. So to a certain extent BDSA looks like a hydra or formless – that doesn’t mean it isn’t solving real problems. The market is absolutely real but it doesn’t lend itself to direct product / competitor comparison. To me this is a great thing I believe out of this diversity truly amazing products have/are/will be created.

I don’t agree with the gather data, analyse, profit style summary. However reading between the lines it looks like the author is looking for something worthy and of substance. With these new big data tool sets we should be creating revolutionary products – not evolutions on existing ones.

There’s always hidden detail. The first time we processed 100TB of full packet capture data and were able to drill down from a decade to a minute of data instantly, providing full threat and packet decode detail to an analyst to make a decision was truly a ground breaking. There’s absolute and real capabilities here.

The irony is that solving size and scale is the pre-requisite to enter the market. It’s the problem you have to solve before you can build something worthy or revolutionary.

From the comments here you can see the need for analysis of long histories and the capability to explore and explain the data. All I would say is stay tuned – there’s a community of really awesome people with incredible ideas building these revolutionary products as we speak.

Well, a lot of that hardware can be pretty cheap due to Hadoop and clustering, but other than that you are partly right. Why partly? Because there are vendors that solve real problems with algorithms and data collection/analysis. However, that does not a market make

@ Neal

Of course!! The problems with infosec are real and the solutions are needed — and there are plenty of great attempts to solve them. It would be silly to dispute that. I only make a very narrow case that a market does not yet exist. Frankly, I’d agree with your “nascent market” argument and that the market MAY eventually form.

Of course there is a need [a set of needs, rather]. In fact, we may not YET be in the early 20th century car market, but in the late 19th when some people built self-propelled horseless carriages [and the word “car” probably wasn’t born yet]

Network forensics [processing packet metadata for monitoring and response purposes] is a very real market, and few people would question that, to be honest. It is a bit unfortunately names since much of the product use is NOT about real forensics, but it is definitely there.

Except it has already been built. The technology has been out of the works for about two years now. The issue is that no individual use case has enough value to justify the cost, which creates a much harder sale, and more extensive integration.

The only case in “security analytics” that could make a claim as an exclusive niche is content anomaly detection over all data sources (packet content included), acting as a safety net behind other security tools people have already invested in. There isn’t another *way* to do that. But I certainly agree with you that all the “Bayesian” supervised methods in products out there are just flat out junk in the real world where conditions evolve constantly.

I think I have some idea about that, as you know ;). I’m talking about deployments that *demand* large hadoop/spark/metagrid/storm/etc. clusters (let’s say > 1 rack worth, at a bare minimum). To get a customer to purchase large amounts of hardware, they want to see a clear business case that is *at least as overtly valuable as that hardware*. Until these analytics solutions are *stopping things in real time*, they will be relegated to the much smaller budget for “forensic tools” at worst, or maybe in competition with SIEMs or log management at best. Oh boy!

When I said “without a specific problem”, I was referring to one that many customers agree on having, are willing to spend money on and prioritize around. Every vendor thinks they solve a specific problem (can’t raise that paper Boo Boo without “laser focus!” pew pew!)…often it just happens to be one lots of other people don’t care with their wallets about.

Don’t you think there is an obvious difference between indexing, decoding and applying rules to packets and performing machine learning to discover something *unknown* from those packets? It’s hardly innovative to take the same techniques and simply scale them.

I for one am tired of vendors blurring the meaning of analytics whenever it suits them. Charts and drill downs might be visualization and exploratory tools, but they are hardly “analytics” since they are not doing any analysis whatsoever.

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.