When the Market Can’t Deliver, Change the Market
This post was adapted from a talk presented at the 2017 Enigma Conference in Oakland, California.
Last year, Gartner estimated U.S. companies spent $75.4 billion on security, primarily on commercial solutions. If only these products gave us $75.4 billion worth of security in return. Diminishing ROI from vendor products is a growing problem in security, particularly as security teams strive to deliver both efficiency and protection for a company’s bottom line.
Every new threat is quickly followed by an influx of new vendors who are there to help. We now see an army of vendors each claiming to have THE solution. Unfortunately, much of this is fueled by the excess of venture capital dollars sitting on the sidelines waiting to be “put to work.” While the intent may be good, we now have too many solutions that are more hype than substance.
Tension between vendors and internal security teams is nothing new, but when $75.4 billion is on the line, it’s about time we find a better way. Merely complaining isn’t productive. If the commercial landscape isn’t giving us what we want, we need to dig in and drive the market in a new direction.
First Things First: Evaluate the Options
About a year ago, Uber’s security response team began looking for a better way to triage and respond to security alerts in real time. We needed a system flexible enough to support our current process and extensible enough to support the development of arbitrary response playbooks. It also needed to support the integration of future technologies that we hadn’t yet anticipated.
Additionally, the product needed to be usable, efficient, and visually pleasing since our analysts team would spend a significant amount of their time triaging alerts within this platform. Unsurprisingly, nothing on the market had all the features and capabilities compatibilities that we required, so building our own solution emerged as a viable option early on.
In many cases when a solution doesn’t yet exist the only option is to build. But building is a significant commitment and requires an investment in engineering resources, time, and signing up to maintain it for the long run. While that sounds romantic at first, technical debt and maintenance build up quickly.
A Radical Idea: Engage the Market
After carefully considering commercial, DIY, and open source options, none of them met our requirements without significantly depleting budget and engineering resources. So, we chose to do something completely different and collaborate with an early phase startup to develop a new solution based on our specifications.
Instead of looking at how many requirements a specific product met, we looked for architecture that resembled what we would build ourselves. We also looked for a company that shared our views on product design, was willing to take our input, iterate quickly, and deliver something that we could deploy to production as soon as possible.
We surveyed the market and decided to work with Phantom, a Palo Alto based company started in 2014, that was building a security automation and orchestration platform. Although Phantom didn’t address many of our requirements at first, their architecture closely mirrored the early stages of what we wanted to build.
A Good Partnership: What to Look For
We found success in our relationship with Phantom, in large part, because we approached it as a shared responsibility. We had to be invested in each other’s success. Looking back on the first six months of our engagement, several key themes emerge as indicators of a good partnership:
- Transparency: Both sides have to be open about what they want, what the state of the world is, and what the best way to get to the finish line together is. It helps to perform a GAP analysis together and help your partner understand how the product is going to be used intimately. They should understand what success really means to you. Don’t hide behind operational secrecy or allow salesmanship to set a development schedule.
- Communication: While often under-appreciated, the ability to regularly and directly engage with our partner’s engineering team was critical. As a hyper growth company ourselves, Uber moves incredibly fast. Immediate access to the engineers working on product roadmaps and features is critical to maintaining that speed. The Phantom engineering team worked with us daily and in real-time in order to collect feedback and quickly iterate on product designs, moving quickly from brainstorms to actual implementation.
- Flexibility: When two disparate organizations come together to create something new, you must remember that there will never be 100% alignment. The vendor, by design, will want the system to be extended in ways that are not critical to you. Accept this, but actively counter designs that add too many inefficiencies or cause a lack of stability. Be creative and explore all possible ways to accomplish the end goal.
Structuring the Contract: It’s About Relationships
As you might expect, the legal agreement for this kind of relationship needs to be different than traditional contracts. Our overall objective for this collaboration was to guide and improve a product not only so it would be more useful to Uber, but also so the entire community could have access to it. As a result, the contract was written to support and drive the same objective.
The enterprise must be flexible on the approach to IP such that the startup can flourish. At the same time, the startup must agree to a contract flexible enough to accommodate changing priorities, tasks, and goals. The contract was developed to protect the creative collaboration process and ensure both parties (and the product) were better off because of it.
