After five-and-a-half incredible years at Palo Alto Networks I’ve joined Valtix to lead their product management and go-to-market team. Joining a startup brings some risks and also the rewards of building something useful, and it is a test of whether all that you’ve learned and talked about can be applied in meaningful ways. You have to put skin in the game. That said, what excites me about Valtix? In summary, there is a significant gap in operationalizing network security for public clouds: enterprises don’t have enough resources with expertise in network security, public clouds and automation to secure the vast number of applications being deployed in public cloud. Here’s the journey; comments welcome.
The Best Security Technologies are Commoditized
A significant number of network security technologies are commoditized including next-generation firewall (NGFW), WAF, IDS/IPS, VPN and several others. You can find the best-of-breed technologies with some easy research. For example Snort is a well established intrusion prevention system (IPS) engine with a large community of contributors that continuously enhances it. Similarly the latest rules for a web application firewall (WAF) can be found from trusted sources like TrustWave. What is hard is to use them effectively in cloud; more on this later.
The rise of cloud computing is a similar story. Amazon Web Services (AWS) combines the fundamental blocks of virtualization, services-based architecture, multi-tenancy, management systems and API’s, to provide infrastructure-as-a-service. Adding common services such as databases, networking, and storage has led to the platform-as-a-service model. Very little of these individual technologies are new. What is different is that all these can be invoked via code to operationalize an application stack or an entire data center.
Application teams and line of business’ have embraced this instant availability to improve their time to market. But the best security technologies have sadly not moved to this era. Too much of it is about designing complex architectures, deploying virtual machines with custom appliances, configuring/bootstrapping them, deploying management systems, licensing them and then comes the part about setting security policies. A lot of security teams are not equipped to deal with the fundamental change in build, deploy and run nature of applications. They don’t have sufficient time or resources for adapting this do-it-yourself (DIY) approach.
Why is Advanced Network Security Needed in Public Clouds?
As usual the right question is to first ask why. What’s the need for doing network security in public clouds? Simply put, in a shared responsibility model (see here and here) its the customer’s job to ensure that every packet hitting the VPC is not malicious. The cloud provider takes care of security of the cloud (i.e. their infrastructure), its our job to secure what’s in the cloud (our apps). The usual suspects are (a) attacks against an Internet facing website such as those running Apache Struts servers with a vulnerability, (b) data exfiltration from inside the deployment, or (c) lateral movement of attacks between applications/services of different trust levels deployed across VPC’s. None of the cloud provider controls check to see if an apt-get software update for your Linux server is connecting to cannonical.com or a command-n-control server. Is your dev system downloading infrastructure-as-code (IaC) scripts from your corporate GitHub repository or an attacker’s staged repo? Are your cloud servers distributing malware? (compute may cost hundreds per month but there can be tens of thousands and more in outbound network costs). Or is there bitcoin mining, by bad guys or malicious insiders, that connect your cloud compute into their bitcoin farm?
Note: Continuous cloud monitoring, compliance and governance tools are important. They set the guardrails of how you configure the environment and get alerts, but they don’t protect or offer any real-time protection against attacks or exfiltration. They don’t distinguish between whitelisted code repo’s in GitHub or bad ones.
The Ugly Tradeoff
The usual answer in traditional data centers is to make the perimeter hard and make app teams open tickets for making an application go live. This model obviously breaks the cloud model of building and delivering applications continuously. The alternative is to use the cloud-native network security controls which can be embedded as part of the dev process. While these controls are necessary, they are not sufficient. Security Groups are stateful firewalls from over 25 years ago! A website should only open port 443 (and maybe 80?) in the security group, but what happens to the attacks that come through that? Similarly, setting up a basic cloud-native WAF may pass compliance audits but it does not have automatic updates on the latest rules or visibility across inbound, outbound and east-west flows.
Day Zero Happens Everyday in Cloud
The answer from traditional security vendors, most of whom build excellent standalone products, is to use complex do-it-yourself (DIY) templates (just check your favorite vendor’s GitHub repo) that deploy load balancer sandwiches, auto scaling group of firewalls, serverless functions, pub-sub queues, license activation/deactivation logic, management servers and a few other things. Most of these come with a 200 page reference guide. Only enterprises with dedicated cloud engineering teams can understand, deploy and manage them. Technical support on this architecture is worth contemplating. Only the brave have ventured into this territory. Others have resorted to fantastic solutions like backhauling traffic to on-premises firewalls or tunneling their outbound traffic through their service for securing mobile users.
Even those organizations who have mastered network security in public clouds have to deal with:
- Operationalizing the DIY or backhaul model for hundreds of applications across dozens of teams. And, enabling this with short go live windows for each line of business that wants to launch a new application or updates to an existing app on a rolling basis - that’s day zero everyday (we want to prevent zero day).
- Building a consistent security posture across multiple clouds, each of whom have their special ways of doing things.
- Changes in existing cloud services, and introduction of new ones (AWS, Azure and GCP all introduced or updated dozens of services last year).
- Small staff with sufficient expertise in templates, scripting, cloud networking and vendor-specific security tools.
What’s Needed - A SaaS for Advanced Network Security in Public Clouds
Organizations move to public clouds for agility (and a few other reasons). Dev teams are enamoured with the ability to build CI/CD pipelines that allow them to build, deploy and run applications fast. This enables businesses to serve their customers without waiting for months to procure servers, customize them and then write code to run on them.
When an application is ready, whether in dev, test, staging or runtime, the security solution must be:
- Quick to discover apps - in minutes
- Easy to deploy - in minutes
- Consistent in enabling defence - in minutes
Valtix is built on a cloud-native service architecture, very much like what powers the leading cloud platforms themselves. It is built with a secure foundation that does not store any customer keys in our environment, it is multi-tenant (or can be single tenant), uses a separate control plane and data plane, and it is built for scale across multiple availability zones, regions and clouds. Simply put, Valtix is a SaaS for network security in public clouds.
More to Come
The founders of Valtix have deep experience in building scalable security architectures based on their experiences at Akamai, Cisco and Google Cloud. Future posts will elaborate on how we solve the problems outlined above and demonstrate the effectiveness of our approach.
This is what Valtix has built. I don’t see anyone else building a cloud-native network security service that solves these problems. What takes weeks and months of work, we enable in a few minutes. Using Valtix, we hope that security admins can go home at 5 pm (maybe 6) on most days and not keep working late nights to secure applications that need to go live today. We believe this is valuable to companies adopting public clouds. I am excited about this journey and the road ahead! Future blog posts will elaborate more on our approach. If you are curious to learn more, or have comments on this post, even if you disagree, please email firstname.lastname@example.org.