Hello
There are origin stories focused on “what”, usually a towering problem that clamors for people’s attention. There are also “who” stories where the people take center stage, their indomitable will poised against crazy odds of failure.
Our story is neither of those. Open Raven started with the question of “How?” Let me explain.
Last Winter, Mark & I found ourselves on a rare, shared break from the security market trenches. Since we both love building products, our conversation frequently turned to the products and businesses we admired. And it was quickly apparent that almost none of these were security companies. With nearly 50 years in the industry between us, we should have been able to name plenty of examples. We couldn’t.
The dialogue quickly turned to how to remedy the situation. Our guiding question was along the lines of “If you were to build a company and technology that genuinely advanced the industry, how would you do it?” Our answers, and the foundations of Open Raven, are the following.
Build a platform, not a tool
Tools are aimed at a well-defined, tightly scoped problem. You use them inside an existing business process and set them down after. Just like a screwdriver. They are absolutely necessary. The issue is that the security market is littered with tools built by both security vendors as well as those adding in protection features to their products and services. The end result for short-staffed and frequently overwhelmed security teams is that they have a massive toolbox, but are on their own to figure out how it all fits together. When talking to CISO friends and other practitioners, It’s plainly obvious that it’s asking too much of them.
In contrast, a platform introduces a process that can be adopted and modified to the tastes of the owner. It takes on a bigger, less bounded problem. The platform knows it will have to work with what’s already inside the customer’s environment, making what’s already there easier to use, more cohesive. It takes your messy collection of tools and fits them together neatly in a toolbox. It allows the customer to focus on the problem at hand versus struggling to determine how it all fits together and where to go first. It is not, however, the often reviled “single pane of glass”, but rather the “single control pane” or the backbone of a program. Better optics alone aren’t enough to solve serious problems like data security.
Open source
While security teams are chronically understaffed, the security community itself is larger and than ever before. And with the shift to cloud and DevOps, there are increasingly more people who can code on security teams. While they may not want to take on the challenge of building a platform, they can certainly extend one to meet their needs or hire someone else to do so. They can harness the combined efforts of a growing community versus a single organization. This is a common complaint we heard, “Why does Vendor X insist on doing their own integrations? Where’s the APIs? The open model for connectors?”
Further, people are much more willing to contribute if they know the platform they are investing in is poised to flourish independent of the people who created it. The concept is by no means novel, companies like Mulesoft, Kong and Hashicorp have already proven it works outside of security. How could the same approach be harnessed to tackle a big cyber security problem such as data protection?
Care deeply about design
Nearly every conversation about the alarming shortage of security professionals quickly becomes a topic about outsourcing or perhaps in its better moments, training. Why should it not equally focus on simply designing products that lower the time and expertise required to get the job done?
This begins with the initial deployment, what we and many others call the First User Experience (FUE). Far too often a sales engineer is required to hold the customer’s hand as they take their first steps with a product. In an age where cars can drive themselves, is it really too much to ask for a security vendor to build a product that’s quick to deploy and doesn’t require a sherpa?
How could we strike a balance between enabling specific use cases and allow the user to solve the problems that matter to them the most in the way that suits them best? The products we love show us how things can be done and then let us take over the steering wheel. An example is starting with a set of default queries (“Where are all my instances of ElasticSearch accessible on the Internet?) and then providing a set of flexible rules and filters to encourage creativity and exploration.
How about dashboards? We think showing a garden variety of 10 different graphs at once and leaving the user to determine what they think is important is a little... lazy. Why not create a single, clear picture for the user so they can easily see what matters the most and start exploring from there?
Accept the full customer job — not just the parts you like
It’s become fashionable to talk about customer empathy when building products in recent years. This is a good thing. The better an organization understands and engages with its customers, the better chance it has of building something truly special.
The danger of obtaining a deep understanding of customer problems is that it can take you to “unsafe” places. It can challenge your assumptions about what you need to build. It can frustrate the boundaries of existing product categories. This needs to be ok. We saw this plainly as we dove deep into what was happening in data security. Conversations with CISOs and cloud leaders plainly indicated given how easy it is for data to be duplicated and moved, no one felt good when asked if they knew where all their important data stores were located.
Given this common concern, is it really ok to assume that an asset, vulnerability or cloud management product will solve it for us?
Clearly there’s a gap to be filled based on our conversations, not to mention the non-stop parade of accidental data exposures.
Maybe you should simply take everyone else’s data and massage it into a single picture to find all the data repositories?
That not only makes the FUE a big ask for a bunch of data (painful for most) but it’s also the easy answer that leaves readily exploited gaps as you scramble to get access to a bunch of different systems. In contrast, accepting the full job means you have to both play nicely with others by taking their data *and* roll up your sleeves by creating your own. This is understandably harder and sets you on a longer journey but it’s both more valuable... and a lot more fun.
Talk, don’t shout
While the customer problem and product are necessarily on center stage, the organizations we admire put equal thought and energy into how they go-to-market. They engage the market with meaningful dialogue. They listen more than they speak. Raffles, ball pits and circus performers at a conference booth? Never.
The “how” of creating a company whose marketing and sales are as compelling as their product started with the team and our brand. Our first hire? Our creative director. The brand? An approachable logo that anyone could draw with a little effort. Further, a style that emphasizes warmth and sophistication over testosterone.
This naturally extended to how we launched the company. While we are immensely proud of our team and investors, we felt the best early stage companies were the quiet ones. The businesses that emphasized keeping their heads down and getting work done until they had something meaningful to announce and contribute to the industry dialogue. Which brings us to today.
Join us
We’re excited to share our journey with you and invite you to join us as we aim to reinvent data security for a modern era. Whether this means trying the Open Raven platform, contributing code, partnering with us or becoming part of our team, there’s room enough for all.
