The Founding of Arctic Wolf with Brian NeSmith

The early part of my career was all networking. I did network consulting for a small firm that's since been acquired by Ernst and Young. About midway through my career (though I hesitate to say how long it’s been), I jumped over to the security side of things.

In a sense, the first half of my career was spent getting people connected, and the latter half of my career has been dedicated to stopping people from connecting to things they shouldn’t.

Ipsilon was a true startup experience. That company was first acquired by Nokia and eventually sold to Checkpoint. Immediately prior to Arctic Wolf, I was at a company called Blue Coat Systems.  Blue Coat was originally known as CacheFlow. That company’s trajectory really mirrors the trajectory of my career. When I joined CacheFlow, it was all about: how do you accelerate the web? How do you make it faster through caching and intelligent optimization? Over time, as we transformed into Blue Coat, we focused on adding security features and becoming an internet proxy that monitored and controlled what people are doing on the internet.

I think, especially in a technology company, you have to be immersed in the space that you’re playing in: your customers, your technology, your competitors, etc. To build a company, you really have to understand it all. 

Our beginning thesis for Arctic Wolf came from my prior employer Blue Coat. The Blue Coat proxy produced these very voluminous logs, and we had customers that would constantly reach out to Blue Coat and ask “Hey, what about this? What's this person doing? Where is this going?” This issue got repeated so many times that it stuck with me.

I had ostensibly retired when I left Blue Coat, but it didn’t stick very well. After about six months, I called my co-founder Kim and said, “I'm bored.” And it turned out, she was bored, too. That always leads to bad things. We sat around her kitchen island and brainstormed a half dozen different ideas.  This one idea stuck with both of us.  We were both former Blue Coat people and the idea was that, there is value in the log data.  

But we also knew that organizations lacked the discipline, the capability, or the budget to get the value out of the log data. The value of the log data was predicated on a core premise in the cybersecurity industry: that you take all of these steps to protect your environment, but you have to put a monitoring capability in place to know when that protection fails. 

Yes, you need defenses: firewalls, endpoint agents, antivirus, e-mail protection, identity protection, and so on.  But, sooner or later, because humans are fallible and we do silly things, that protection is going to fail.  When it does, you have to be able to detect it.  If you can detect it fairly quickly and remediate it, you avoid any real damage.  That was the real essence of the original idea.

At first, we called it continuous monitoring. Then we called it SOC-as-a-service or SIEM-as-a-service. Now the world knows it as MDR (Managed Detection and Response).  The idea started with our deep immersion in the space, based on our experience with log data at Blue Coat.  Then we realized, that we as a security organization, could do this better than an individual company could do it themselves. Tying those two insights together was really what led us down the path to starting Arctic Wolf.

For the most part, that was always part of the idea. Our focus originally was to go beyond only offering tools to customers.  Everybody in our industry, probably 7-8 years ago, was asking themselves: “How can we produce a better tool?”  Then, they’d market it to customers as a faster tool, a more efficient tool, and a tool that finds things other tools can’t.  So, customers ended up with a lot of tools in the toolbox.  They just didn't have the time, expertise, or money to use the tools they had.   This the classic problem of SIEM. 

There's nothing inherently wrong with SIEM. SIEM is great.  It collects the log data, it has tools you build on top of it; but the care and feeding of a SIEM is complicated and you have to do it all the time. To get the value out of SEIM, it requires multiple smart people doing things over and over again.  Our idea was to focus on delivering the outcome that we want: monitoring the customer's environment and finding when it's been breached.  That was really the essence of what we were doing. 

My view was that could never be fully automated.  You would need humans, smart humans, that would be necessary to figure that out.  The classic problem in security monitoring / MDR is false positives.  It takes humans to run most of the false positives to ground, and that's why we knew we’d need to have a people component.  At first, I couldn't think of a better marketing term than Outcome-based Security, but it didn't really resonate with customers so we ended up with Concierge Security. The concierge would configure the system, set up the data, run the analytics, and then be there to help the customer if anything comes up.

First, I would remind you that we started in 2012, and for the first six years or so, not everyone would agree that we had “gotten it right”.  We didn't fit the typical profile of a SaaS startup where growth is supposed to follow a 3x, 3x, 2x, 2x pattern.  We had a slower pattern of pretty much doubling every year. 

Early on, we tried to figure out how we could reduce the friction of people buying from us.  We chose a pricing model that was very different from the rest of the industry. 

Almost everything in cybersecurity industry is about the amount of data you have to consume in order to find a signal. Therefore, most of the pricing models are built on how much log data needs to be ingested.  We chose to base it on the number of users and servers.  The reasons were: 1) nobody knows how much log volume they have and 2) as companies evolve and get new infrastructure in place, the log volumes change, changing the amount they pay, which makes them really unhappy.

The Splunk model would be a classic case in point.  Splunk customers spend a lot of time getting rid of stuff so they can reduce the cost of their infrastructure.  We chose to charge the customer based on the number of users and servers because almost all customers know how many users and servers they have. That really reduced the friction in what we were doing.  Now, the counter argument to this pricing model is: “what about the customer that generates 10x the data volume of another customer with the same number of users and servers?” My belief was that it all worked out in the average.  As long as I have the average right, I will have some customers that are sending 10x the amount of data, while most customers will cluster around the average. This has turned out to be generally true. 

This pricing model also aligns the interests of our security engineers and the customer. When our security engineers ask a customer to send over data, the customer knows we're not going to charge them more.  In the Splunk example, the customer might suspect that the Splunk rep is asking for more data to be able to raise prices by 20%. We're only charging by the number of users and servers, so it really created a mutual alliance between the Arctic Wolf security team and the customer. 

The second thing we did, which was a bit of a double-edged sword, is we chose to build a prepackaged hardware device that we shipped out to the customer that brought the data into our environment.  If we were starting over today, it would have been better to run it on virtual machine. The reason we did it was because it let us ship it to the customer, and all they had to do was plug in three cables.  We were trying to figure out how to reduce the friction in the sales process and reduce the friction in the installation process.  I think that served us well.   

The other one is that we spent a lot of time trying to build things that would scale horizontally from a technology standpoint.  It means that we had to scrimp a bit on features early because we spent more time worrying about scalability.  Now in hindsight, that was probably the right decision because we've been growing so fast that it's a wonder that the infrastructure as we originally designed has been able to keep up but it has.

The first thing I would do is try to discourage them from starting a company, because it's a lot harder than it looks.  That being said, I think the biggest thing to do, for me at least, was this idea of being willing to fail. I don't mean that you aggressively try to fail, but you’re willing to challenge your board members and challenge your leadership team.  It's a fine line that you're walking because you want to be able to listen to what everybody is saying but ultimately, you must make the decision when you're the entrepreneur.

I would say my biggest regrets have been when I let somebody talk me into something that I didn't fully believe.  I regret those more than I do anything else.  I'd rather fail doing what I wanted to do, than fail doing what somebody else told me to do.

It's not just board members, or investors, it's also members of your leadership team or people that you respect in the industry.  You don't want to close your mind, you want to listen, you want to be a part of a dialogue, but basically an entrepreneur should do what you think is the right thing to do and be willing to fail.  It's a hard thing for people to get a hold of, but it’s something I wish I had known early on.