In academia, the difference between a scholar and a plagiarist is attribution. In technology, the same principle applies: acknowledgement – and sometimes licensing agreements as well. So let me give credit where credit is due.
My own company is a prime example of that principle. Briefly, our business involves protecting customer applications in the public cloud. We do it using a multi-cloud network security platform which is delivered as a service. Obviously, we didn’t invent clouds, SaaS, customer applications, or the key tenets of network security. But we know those technologies well and use them heavily in our solution. And, along with my friends and co-founders Praveen Patnala and Vijay Chander, we saw that there were issues and gaps affecting the way these systems interacted – gaps which not only impeded operations, but more importantly, introduced lapses that could also be exploited by hackers.
Additionally, organizations at the center of this interaction of cloud, apps, and network security have developed a new operations model – one that the on-prem (box-based) network security technologies are ill-suited for. Furthermore, the everything-is-connected, dynamic, self-serve clouds that organizations are investing in not only presents new security challenges but is also the leading target for attackers.
Accordingly, the pace of cybercrime has grown exponentially over just the past few years. So has the cost of network hacks, leaks, ransom demands, and operational sabotage. Security failures have become a tremendous source of alarm. So, we built our company to help address those concerns.
Here is what we saw: For one thing, companies that use the cloud frequently either use, or intend to use multiple clouds. They do it for a variety of good reasons: for resiliency, for independence, for related applications, for cost effectiveness, and so forth. But there are also tradeoffs that come with a multi-cloud strategy. For example, your visibility into what’s actually happening within each cloud becomes challenged. It is a problem exacerbated by the fast, almost chaotic pace of new and updated applications. Yet you can’t secure what you can’t see.
For another, there are plenty of security-related products and services out there directed to cloud users. But their security and threat prevention provisions are often deployed inconsistently across different accounts and regions, as well as implemented differently across clouds and their different security constructs, to defend the same apps against attacks or from non-compliance. There is also a hidden cost associated with deploying applications across multiple clouds with different security solutions. It’s that the control of those applications and their security provisions also become distributed – essentially multiplying the user’s staffing needs and associated overhead. Nobody wants to increase their costs of doing business.
Finally, we recognized this: many of the more traditional security products that cloud customers were using are what I like to call ‘box-based’ – virtual appliances installed on the customer’s cloud network. Box-based approaches suit neither the cloud ops model, nor solve cloud security problems, regardless of how familiar an administrator might be with box-based operations.
So, what did we learn from these observations? First, that there is an urgent need for consistency in the execution of security provisions across different clouds. Second, that the management of security needs to be simplified, both to maximize user control and to minimize staffing. Third, enterprises don’t want to ship sensitive data over the Internet to be secured – especially when there are so many options for doing it close to the app. And finally, that there is a need to align the price of security tools with what the customer is actually using – a sort of pay-as-you-go approach – as distinct from paying for everything that comes in the box, regardless.
Those were the key insights that grew out of our conversations. And just as important, we saw that most of the box-based security products never made use of off-the-shelf innovations: indigenous cloud capabilities like SaaS and scaling (e.g., Snowflake, Kafka, Kubernetes) the very reasons so many cloud customers had transitioned to the cloud in the first place. Other reasons for using designed-in-cloud solutions include native cloud functionality (e.g., AWS GWLB, NLBs, IAM integration, Secrets Manager) and well-thought-out approaches like the separation of data and controls planes. What it told us is that using those innovations and distinctive cloud features, both to deliver, manage, and price security, would provide a high-value service. So that’s what we did.
There are, of course, a lot of amplifying details about how that was done and what it means to users. And there are likely to be even more advanced solutions that others will eventually introduce. But the point I want to drive home now is this: while the solution we provide represents a valuable advance over previous security products, it also comes with a healthy dose of humility – a realization that we live in a community of innovators whose work has formed the building blocks for our own product, our market, and our contribution to the tech industry. Furthermore, Valtix has the benefit not only of all of the successful innovation that came before, but also the failures – where customers have let us know certain approaches and solution can’t or won’t work.
- The Cooperative Development of Software Solutions - August 25, 2021