Ask an accomplished photographer, “what’s the best camera?” and the typical answer is, “the one you have with you.” For many folks, this means their phone. But the cause of a multi-year surge in interest in photography is more than the fact that phones contain cameras and gets into the fact that there is little-to-no overhead associated with reaping the benefits of those cameras. Have you ever read a manual for the camera in your iPhone? In other words, you pick it up and use it, without worrying about the film, f-stop/aperture, focal length, etc. Users get the benefit, without the cost (learning curve or operational effort, in this case). The same thing happens with the cloud. For years, business leaders have asked for new, cool apps that could help grow revenue, but have balked at the expense of building the necessary infrastructure to support those apps. With the public cloud, businesses can do exactly that – deploy apps immediately without building datacenters, planning resiliency, racking hardware, etc. So, effectively, getting the benefit, with a lot less cost. Which is rapidly becoming the normal expectation with regard to technology. Apps without infrastructure. Benefit without cost.
Why should security be different? It shouldn’t. But in many organizations, it clings to the old model. Many organizations I speak with still use a box-based model – even in the cloud. I’m not speaking of hardware – most “boxes” are virtual appliances, but of the management model: organizations have to do a tremendous amount of work to deploy, maintain, and use before they get the security benefit. Once racked and plugged in, hardware really isn’t all that different. This flies in the face of the business’ current expectation of technology. Let’s look at this in detail:
- Consumption, design and build:
- design your reliability, availability, scalability (RAS) approaches
- buy boxes, install boxes (you know the exact number of boxes – even if you have centralized management)
- integrate your RAS approaches into infrastructure build
- Specify apps and infrastructure to protect. Define policies.
- Monitor capacity, usage and change, health of boxes
- Add boxes/integrate when appropriate
- Patch/update boxes
- Review logs in preferred tools
- Automate (e.g., scripts, 3rd party tools) all of these steps whenever possible. It doesn’t make a box-based approach fit for purpose, and perhaps more importantly, that often brittle automation has to be maintained.
I might argue all of the above suggests 70/30 cost/benefit (in this case, maintaining infrastructure/security benefit). Which, as I’ve implied, is antithetical to cloud (treating cloud like a datacenter eliminates much of the business benefit), and in conflict with both current staffing models and business expectations.
So what does the right approach look like for the cloud? Instead of boxes, a cloud-first approach would be consumed and managed as a service. Note that we’re not talking about a pricing model that glosses over appliances, but a method of deployment and operation that eliminates much of the operational effort associated with using the technology. In other words, there are likely instances of enforcement points in your environment (e.g., gateway instances), but the user of the technology doesn’t know how many or care. The service manages itself, so admins focus on apps and policies. In detail using the same categories as above:
- Consumption, design and build
- Sign up and add accounts/VPCs
- Specify which apps and infrastructure to protect. Define policies
- Review logs in preferred tools.
Here, the cost/benefit looks more like 10/90 (maintaining infrastructure/security benefit), Even if we say the security benefit is exactly the same – which I argue that a cloud first approach will have advantages here (more on this in a future blog) – we note a massive reduction in the overhead of having network security. This is in line with cloud principles and business expectations – using technology and benefiting from it rather than maintaining it.
At a high level, the bottom line is that while much of the network security discipline is the same, the implementation must change. There are two aspects to the change – one, to address cloud-specific security problems. And two, as outlined above, organizations need to get network security in line with the cloud model, and more importantly, business expectations.
The biggest, baddest solution from a bygone era is a nuisance, not a benefit (e.g., battleships vs. aircraft carriers, ‘60s American muscle cars vs. Teslas, Kodak Instamatic cameras vs. iPhone cameras). No amount of add-ons or band-aids will make a muscle car out-accelerate a Tesla – or out-handle, or rival a Tesla on efficiency and ease of maintenance. But yet, there are examples of purveyors of box-based network security trying to do just this:
- Palo Alto Networks – the pioneer and leader in NGFW – partnering with GCP to try to look cloud-native with a box-based approach
- Checkpoint – Seems counter-intuitive to rely on Windows 2012 Server to manage security policies in the cloud
Not their fault, they are just outdated. It’s not unlike a Kodak Instamatic film camera. This is just how technology evolves and will continue to do so. In 10 years, we’ll be talking about a similarly dramatic transition.
But practically speaking, what does a service-based network security implementation look like? Some very high-level guidance for the folks who are building product and trying to break into this space:
- No direct management of infrastructure – communicate intent-based policies with a centralized control plane
- Policies normalized by, and are implemented where deemed appropriate by the control plane – note that this enforcement might be through distributed data planes, or in native cloud constructs.
- “Ilities” designed in – reliability, availability, scalability, and maintainability. Just like cloud, Admins don’t need to attend to that, as it offers them no value. Ease of use (remember the iPhone?) is another key element here. Again, back to the point of cloud: benefits, not costs.
So, how to move forward? What does a transition from network security boxes to a network security service look like? Transition is never easy – even if the end state is, you have to learn a new approach. BUT – this is the future, and those who fail to embrace it will be left behind. In our customers, we’ve seen two approaches:
- First, the gradual approach. Start with one aspect and in turn adopt others. In many cases, organizations will lead with a purely ops-oriented transition, only later following with cloud-centric policies, adoption of cloud constructs, and a cloud-native app architecture. In other cases it might be led by architecture. Often, the justification for a phased approach is around skill sets and training. There’s a shallower learning curve, but also a more gradual realization of benefits.
- The second approach to transition is often around a new app and new environment, where organizations want to go native from the start. So architecture, security policies, adoption of dynamic cloud constructs and ops are all modern. It’s a steeper learning curve but delivers immediate benefits.
My conclusion? Technologies ready for widespread adoption minimize overhead while maximizing utility. Reducing cost and increasing benefit. We’ve been there with the infrastructure that supports our apps – now it’s time for us to get there with the tech that secures them.
If you’d like to learn more about our approach to enable cloud-first network security, attend our 2.9 launch webinar on Sept 14th. Registration is open here.