In this five-part series, I’m taking a hard look at the common – and costly – mistakes organizations typically make while building a cloud architecture. Part one explained how organizations can quickly lose visibility and control over their data processing, and detailed how to avoid that mistake. Part two looked at why a DIY approach often goes wrong, and how an independent cloud networking platform solves that problem. Part three examined how easily costs can mount when organizations don’t have a cloud networking platform that enables intelligent costing and billing. In part four, I explain why an on-premise attitude toward security in the cloud weakens an enterprise’s defenses while also contributing to mounting costs.

Security is a particularly costly line item in the cloud bill. Enterprises are paying a huge cost due to an on-premise mindset, treating security separately from networking and bolt-on security. For instance:  

• Organizations deploying a physical on-premise next-generation firewall (NGFW) for workloads sitting in the cloud are still sending cloud traffic to data centers or colocation facilities. This is costly not only from an egress charges point of view but also unacceptable by latency-sensitive business-critical applications such as SAP S4/HANA or Epic health care.
• Deployment of expensive NGFW VM/EC2 in every VPC/VNET.
• Reliance on a CSP “Shared Security” model. Details can be found here.
• Reliance on uncontrolled and foreign NaaS, SASE, or SaaS-type tools to provide security requires sensitive data (HIPAA, PCI, Assets Inventory, etc.) to be shipped outside your control or network jurisdiction, increasing the overall cost and adding latency.

Security cannot be treated separately from networking. It must be part of the data plane. It must be part of the distributed cloud networking design. The bolt-on security designs are flawed and fractured. Perimeter firewalls will not work for cloud workloads. 

A layered security design is best, where the data plane provides the “firewalling” without needing any NGFW. It means that as soon as the packet leaves the EC2/VM, it is being “firewalled” without sending the traffic to some NGFW EC2/VM. This zero-trust approach improves the security posture and saves costs by reducing the data transfer charges, reducing the expensive NGFW, and eliminating unwanted or harmful traffic traveling across the network.

Recommendations

Invest in a solution where security is embedded in the data plane. The solution must allow you to create intent-based security policies. These policies should seamlessly be applied to single and multiple clouds without any refactoring. A few things to look for:

• Invest in a multi-cloud networking solution that intelligently provides distributed firewalling as part of the data plane. It must provide features such as network and micro-segmentation using a rich set of criteria and attributes such as CSP tags.
• Network behavior analytics must be part of the security architecture. Your data plane should not only be able to detect threats, malware, ransomware, and anomalies but also automatically block them as part of the self-healing capabilities. 
• A geofencing or geo-blocking feature is critical for data sovereignty and GDPR requirements. Absence of these from your architecture could incur fines or heavy penalties. That could tarnish the brand and will be costly in the long run.

Conclusion

The cloud doesn’t operate on-premises, and cybersecurity cannot either. Using on-premise tools, such as NGFW, for data residing in the cloud, for example, increases both latency and costs. Security must be integrated as part of the data plane, with a layered approach that can handle multi-cloud environments, enable network behavior analytics, and geofencing or geo-blocking. Only then can a cloud networking platform provide the foundation for a full defense.

In the final part five of this series, I’ll look at how relying solely on a CSP for recovery from an attack prolongs the mean time to recovery (MTTR), greatly escalating the costs.