Why Soluble?

Posted by Rich Seiersen on February 20, 2020
Rich Seiersen
Find me on:

 

soluble_bear_run

 

Simplify Security For Stuckees

If asked why we started Soluble, I might jokingly reply, “To hasten the demise of security as we know it.”  The truth is that software defined everything (cloud native, serverless, Kubernetes etc)  is doing that all by itself! In the process, a new generation of security stuckee has emerged. Their titles include DevOps, Site Reliability Engineer (SRE), DevSecOps and even Developer. 

We started Soluble to simplify security for these new stuckees. Why? As a serial CISO, I learned one hard truth: cloud native security isn’t getting done any other way. 

Security Is An Inside Job

We're not putting that $%&# In our pipeline!,” words I heard repeatedly in cloud-native organizations. One of my engagements saw dev teams producing over 30,000 software releases a year. The mere thought of putting anything in line with development was met with audible eye rolls.  

Unfortunately, security vendors were rarely helpful in these situations. This company had a complex microservices ecosystem immune to default solutions. And they had a disdain for drawn out vendor engagements. (A technical and cultural reality I would see over and over again). What I needed was a way to drop security into engineering, into DevOps, without getting in the way. Security needed to be an inside job!  

Security Meets People Where They Are!

My cofounder Rob and I met at our last place. He was the VP of TechOps (DevOps, NetOps  etc.) and I was the CISO. 

Rob’s DevOps team rallied around a clever solution he built for managing hybrid infrastructure as code. The people it helped the most were developers. It’s not that developers cared about what his DevOps team built – they didn’t. What they did care about was that their code got shipped and the underlying stuff worked. Which it did!  

Much of Rob’s success with developers came from his philosophy of “meeting people where they are” and “don’t get in the way.”  His philosophies lined up with my thoughts on making security an “inside job.” I started to push my budget, time and effort his way. It was the most practical thing for me to do: shift more security to DevOps. They were the new cloud-native security stuckee!  

Long story short, we shared a principled view on how to get cloud native security deployed. We decided to put these principles into practice for everyone.  

From Principles To Micro-Products

We built an innovative SaaS platform for delivering managed security micro-products into Kubernetes clusters. But it’s our product principles that drive us.

We use our principles as a filter for micro-product decision making. If what’s proposed offends these ideas it will offend cloud native engineers! Here’s a sample of our principles: 

  • Autonomy and Agency
  • Immediacy of Satisfaction
  • Beat the Competing Model 

Autonomy and Agency

Soluble defends an engineer’s autonomy and agency while supporting security outcomes. It’s based on the belief that organizations get more value when individual engineers are empowered to act on their own creative motives. We would call such an engineer an “autonomous agent.” 

Products that dilute an engineer’s ability to do their job autonomously and creatively offend this principle. Most enterprise security products are very dilutive to this principle often requiring: 

  • Collective buying power to acquire,
  • Other (non-purchasing) organizations to deploy, 
  • Volumes of new work that is not aligned to engineer job motives. 

Offending the autonomy and agency principle demotivates engineers. It leads to undeployed security solutions that pass risk and cost onto the customer.

Immediacy of Satisfaction

When you buy a banana all you want is the fruit not the skin, but you have to pay for the skin also. It is a waste. And you, the customer, should not have to pay for the waste.” - Shigeo Shingo - Lean Manufacturing Master

At Soluble, we talk a lot about Japanese lean manufacturing. Outsiders saw lean as “better, faster, cheaper” production – insiders knew different. For them, lean was about “removing all waste that blocks customer value.” Adherents zealously eliminated everything in product development that didn’t contribute value to the customer. They labeled all that valueless stuff waste

We see waste as an epidemic in enterprise security products. Extraneous features, ancillary processing, handoffs, task switching etc. are common. These wastes even plague cloud-native security solutions – yet the promise of cloud-native is the removal of overhead that delays delivering customer value! 

Our goal is to use cloud-native development to minimize the amount of time it takes for a customer to experience value. Micro-products should produce immediacy of satisfaction. 

Beat the Competing Model

Do you know the two hikers joke? One is wearing running shoes, and the other is wearing hiking boots. The one in hiking boots asks the other, “Why are you wearing running shoes?” He responds, “I heard there are bears out here.” “You can’t outrun a bear!” exclaims the hiker with boots. To that, the other hiker says, “No, but I will outrun you!” 

At Soluble we are firm believers in beating the competing model over beating the bear. What’s a bear? It’s impossible standards of product novelty, perfect customer intelligence, or feature completeness that stands in the way of “good”. We are happy to let others (the competing model) compete with such standards.

We relish in doing things like delivering smaller features, making existing OSS usable, or putting difficult-to-implement best practices within reach. We don’t care that capabilities we consider already exist in the marketplace – in fact we like that! The need for novelty is mythology – usability is not! 

Beating the competing model lowers customer’s cost, reduces ownership overhead, and delivers a broader palate of targeted, satisfying features faster. 

Conclusion: The Managed Micro-Product Roadmap

We’ve witnessed engineers facing multi-cloud/multi-cluster deploys, decentralized CI/CD pipelines, and torrents of releases. It’s enterprise reality that flies in the face of the centrally managed and static environment most security vendors expect. That’s why we meet engineers where they are. It’s why we use principles to keep our products focused on what cloud native engineers need.

Engineers that use Soluble want to check things off their roadmap like: Scanning, Secrets Management, RBAC, Policy Management, and more. They want it done, and they want to move on. And the security teams outside of engineering want access to the data and reports coming from these activities so they can do their jobs - like responding to incidents or dealing with audits. 

This is what I wanted in the cloud-native companies I worked in. I wanted security dropped into DevOps without disruption. I had zero interest in the responsibility for operationalizing these things, and neither did they. 

This is why we created a security platform that manages multi-cluster/multi-cloud micro-product deploys - so engineers can literally check the box and move on. Only paying for what, and how much, they use. In the process security gets what they need without getting in engineering’s way. This is why we created Soluble – to drop security into DevOps.

Topics: Kubernetes, Company News, Product News

Rich Seiersen

Written by Rich Seiersen

Rich is Cofounder and CEO for Soluble. Prior to Soluble, Rich spent 20 years deep in the salt mines of security operations and development. Along the way, he became a serial CISO with stints at LendingClub, Twilio and GE. But he got his start in security startups building vulnerability management products for companies like Qualys and Tripwire. He’s also the co-author of “How To Measure Anything In Cybersecurity Risk,” and the forthcoming “The Metrics Manifesto: Confronting Security With Data.”