Not that it’s news, but the public cloud is the new enterprise data center. Traditional enterprises have adopted rapidly, often in a distributed fashion, and deployed growing numbers of apps into the cloud. These organizations have taken advantage of the agility native to the cloud and put dynamic applications into dynamic networks. Security of those apps, which are built using an array of architectures (IaaS, PaaS, public and private services, etc), is still catching up, but network security, once again, is proving to be the common denominator.
Unfortunately, this new, dynamic environment has created a couple of new problems for organizations grappling with security in the cloud – keeping up with change and providing a full suite of security services. So if apps are everywhere (multiple clouds, regions, VPCs/VNets) placed by a variety of groups within the organization, and both apps and networks are in motion, the first problem is seeing and keeping up with that constant change. Not “automation” in the traditional sense (brittle scripting of pre-determine actions and responses), but technically an “automatic” capability where changes do not have to be foreseen. The second problem is really the (in)ability to provide a complete set of enterprise network security services in this environment – like firewall, cloud WAF, IPS, and TLS.
Many organizations, when experimenting with apps in the public cloud, simply backhauled traffic to use existing network security infrastructure. But as organizations exit experimentation and move more (and more critical) apps to the cloud, they are looking at re-deploying netsec. The problem is that many of the existing toolsets – public cloud-provided tools, traditional enterprise netsec tools – can’t help.
Public cloud-provided tools are cloud native – they are dynamic and scale easily. The downside is that they lack policy depth and breadth (breadth of services, sophistication of rulesets), and they are single-cloud only. Public cloud-provided tools are really only designed as a checkbox – where enterprises can hear the answer, “yeah, we have a firewall,” and check the box to move apps to the cloud.
Traditional enterprise network security tools have rich services and strong policy. Unfortunately, they are virtual appliances built for a static environment, and being a port from hardware appliances, are unmoored from the hardware acceleration they were designed for – resulting in poor performance. Traditional enterprise netsec tools were really designed for the on-prem datacenter.
Taking a step back, what’s needed in this new enterprise environment is the ability to discover, deploy, and defend.
Discover
This is not a point-in-time process, but an ongoing modeling of the environment to not only see which apps are where and how they are changing, but enable action.
- Show me all of my apps across clouds, regions, VPCs/VNets
- Keep inventory up-to-date as apps and networks change
- Provide a map for me to overlay security infrastructure and policy onto
Deploy
Again, this is a continuous action in a dynamic environment. Not only do enterprises need to deploy netsec once, but continuously in the cloud where apps and networks are changing.
- Deploy netsec infrastructure onto the model (from Discover)
- Scale infrastructure up/down as needed
- Ensure the correct policy follows the app wherever it goes
Defend
It probably doesn’t need to be said that this is a continuous process. But I’ll say it anyway: this is a continuous process, where organizations need to:
- Provide the correct suite of netsec services
- Implement in an integrated way – single data path, single policy, single telemetry feed – results in predictable performance and efficient ops
- Implement in an integrated way – no gaps (an example of a “gap” explained at https://valtix.com/blog/laying-down-the-hammer)
Discover, Deploy, Defend is the process template around which Valtix built its network security platform. Siloed, legacy tools with complex stitching using scripts, lambda functions just cannot fulfil these requirements. So, we took a clean sheet of paper approach to solving cloud netsec around this template. In order to implement, we built two components – a controller and a dataplane.
- Valtix Cloud Controller: SaaS-delivered, multi-cloud, normalizes policy across clouds, provides an evergreen model of the environment, and deploys the dataplane.
- Valtix Cloud Firewall (our dataplane): cloud-specific to take advantage of each cloud environment, multi-service gateway, automatically scales, and provides follow-the-app security.
As you can imagine, the controller does “Discover” and “Deploy,” while the dataplane handles “Defend”. Hopefully this helps explain much of why we built Valtix the way we did, and some of the advantages inherent in our approach (see our recently announced support of Transit Gateway in AWS). Thanks for reading!
