Hyperscale Security

Recently, I sat through a presentation by a network-provider-turning-into-a-cybersecurity-vendor that showed a diagram of IaaS, PaaS and SaaS and the need to secure that full stack. I agree in principle.

Apparently, though, the big missing piece in that was Network Security as a Service.

Really?

There are many challenges I have been involved in working through in cloud security the past years. But that this was the big gap never occurred to me.

The Death of The Perimeter

The combination of the migration to public cloud and working from home/anywhere accelerated by the global pandemic has led to many people to declare the death of the network perimeter. Instead of resources being safely (...) protected behind firewalls in a trusted network, suddenly we have a multiplication of end points and network connections.

This is almost invariably seen as a big problem that adds to all the challenges we already face. An alphabet soup of solution categories are offered to get around this and everybody is talking about Zero Trust Architecture. I am not disputing these are good things, but they all require a lot of effort and money to implement and operationalize fully. It seems we don't even consider that there might be benefits to the perimeter's demise.

Free Micro Segmentation

And there certainly are. Each cloud account (subscription or project, depending on your platform) is an isolated virtual data center. Aside from wide-open default VPCs (which you should nuke or neutralize immediately), there is no network path at all between that cloud account, any other, or the outside world. Each has to be configured individually, or network segments opened. Voilà, free network micro segmentation and reduction of blast radius.

Out-of-band Administration

Whether you are using the cloud web admin console or, preferably, the cloud API and Infrastructure-as-Code, you are communicating with the cloud provider's API, not via a direct network connection to the landscape inside the cloud account. This takes place entirely out-of-band from a network perspective, and may as well be an air-gap.

If you really, positively, have to have SSH access to your landscape, you can easily configure the environment to only accept network connections from selected CIDR ranges.

Identity and Authorizations

With all due respect to everybody in networking, we absolutely appreciate everything you do to ensure that networks exist – but we less and less rely on network security to keep landscapes safe. That is, we essentially treat networks as inherently hostile. Network traffic should be encrypted end-to-end to a limited set of ports. Everything between network boundaries is an API communicating over 443.

The main security control is Identity and Access Management, or Cloud Infrastructure Entitlement Management (CIEM) if you like. Who (or what service) you are, how you authenticate yourself, and what authorizations you have is the main protection. What network path the request took is increasingly irrelevant while the network traffic is encrypted anyway.

Cloud Mindset

We shouldn't build controls for a new age based on the challenges and solutions of old. Building Maginot lines of lifted-and-shifted security solutions, patched up with new tools that try to recreate the safety of old is a fool's errand. It presupposes our “trusted” networks were safe in the first place.

We have to understand how the cloud work to properly protect it against the risks we face. This allows us to see new paths, and the power it provides as well. Policies applied at organizational level on all cloud accounts in the organization provide a level of enforced controls that are nearly impossible in the data center, without really costing anything. Central logging simplify how you monitor network flows. It's not all bad. Much is much, much easier.

When you hear us cloud hoodies go off on our mythical cloud-native mindset rants, this is the sort of stuff we mean.

cloud security posts without corporate approval @jaythvv@infosec.exchange