More on the Attack Hypersurface. Cloud Estates Can Only Be Understood With Modelling. And Just Look at All the SKUs.

In a previous article I began to explore the idea of how technology infrastructure has evolved into having more than what we have historically understood as attack surface, morphing into an attack hypersurface; where a hypersurface is difficult to completely comprehend and grasp, something akin to what Timothy Morton calls a hyperobject.

Morton says:

...what we call “the world”—a place that revolves around human beings and is defined by what we can see and feel—is simply too small to cope with reality anymore. - Wired

In his theory of hyperobjects he says that we need a word, something that can describe the "strange, existential feeling" we get when we try to think about things that are too massive, too unknowable to completely understand.

Examples of hyperobjects include: black holes, oil spills, all plastic ever manufactured, capitalism, tectonic plates, and the solar system. Hyperobjects are often ancient or destined to be, like the sum total of Styrofoam and plutonium we have littered across the Earth over the past century, which will remain for millennia.

I suggest that from a technology perspective, public clouds are a hyperobject, and their attack surface is a hypersurface.

Hyperscalers are Hyperobjects

Public clouds, utility computing, hyperscalers, whatever you want to call them, have become hyperobjects. They are these almost incomprehensible things that exist on the outskirts of our cities and towns, sucking up electricity and spitting out storage, networking and computing blocks.

This tweet from notorious trickster and cloud economist Corey Quinn brought my mind back to the hypersurface.

Now, I don't know if the above is actually true, or if Mr. Quinn is "having a go" at AWS as he is wont to do. But, because the cloud is so obscure and large and filled with options and capabilities, I feel like it could be true, and that is all that matters. It. Could. Be. True. How many SKUs does AWS have? Is it possible to know? Perhaps there is an API that I could query and count...but what would that mean? If you told me a billion, I might not blink an eye.

Understanding how to use something like the cloud is one thing, but the fact that it is so difficult to comprehend how we even pay for the thing we use is another entirely.

Let’s say I want to run an app on an AWS EC2 instance. First we have to choose the instance type. Depending on your region, there are 5 different instance families. Within those instance families are 438 instance types. Then we have to select an operating system, of which there are around 16. Now, we choose our AWS region, there are about 26 of those. Finally, we need to decide how we should purchase and pay for the instances. The options are on-demand, upfront pricing (on what term and how much you’d like to pay upfront), or maybe even a spot pricing model. That’s over a million prices just for the EC2 options I have listed here (438 x 16 x 26 x 6 = 1,093,248 – there are even more nuanced options). - Infracost.io

When we start connecting all the options together, we end up with some large numbers. These "SKUs" are exponential, and the number above is just regarding the potential options for EC2 instances, which is one, relatively simple cloud object and something that we can actually hold in our head. We ask for a virtual machine, and we get a virtual machine. It's got an operating systems, disk, CPU, memory, things we're used to, things we're familiar with. It's a "computer." But what about all the other services and objects that we're not used to, such as being charged for network use?

AWS egress pricing is complex, with outbound data transfer for EC2 and S3 storage costing $0.09/GB for the first 10 TB, then dropping to lower rates. This means that if a user had 5 TB of data to transfer from EC2 storage to the internet, the egress costs would be $460.80 on AWS. While other hyperscaler cloud providers such as Google Cloud Platform and Microsoft Azure have similarly priced egress charges, smaller providers like DigitalOcean have more competitive bandwidth pricing, which can save businesses thousands of dollars a month. - DO

Putting aside the sheer capabilities of the cloud, just the pricing component of hyperscalers is really incredible to think about.

The Attack Hypersurface

As far as I can tell (please correct me if I'm wrong), the term "attack surface" was created by Michael Howard in about 2003 from this article:

...one day, I realized you could calculate the "attackability" of a product or its exposure to attack, but not necessarily its vulnerability. That is, how many features are there to attack, not necessarily exploit. If this sounds confusing, think of it this way—banks will always be subject to attack, but it doesn’t mean that all banks are flawed in such a way that they can be compromised. - https://msdn.microsoft.com/en-us/library/ms972812.aspx

He goes on to say:

Also, think of relative attack surface as Cyclomatic Complexity for security. You can learn more about Cyclomatic Complexity at https://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html.

Where Cyclomatic Complexity is:

...a software metric used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. It was developed by Thomas J. McCabe, Sr. in 1976. - https://en.wikipedia.org/wiki/Cyclomatic_complexity

Howard and his team came up with the below list for the Windows OS.

• Open sockets
• Open RPC endpoints
• Open named pipes
• Services
• Services running by default
• Services running as SYSTEM
• Active Web handlers (ASP files, HTR files, and so on)
• Active ISAPI Filters
• Dynamic Web pages (ASP and such)
• Executable virtual directories
• Enabled Accounts
• Enabled Accounts in admin group
• Null Sessions to pipes and shares
• Guest account enabled
• Weak ACLs in the file system
• Weak ACLs in Registry
• Weak ACLs on shares

Imagine trying to come up with a list like this for public cloud. (More to come in this area.)

(However, To Be Fair, Through the Use of Cloud Some Attack Surface Has Been Removed)

Now, to be fair, we have removed some of the attack surface through the use of public cloud. One example is the hypervisor. If we are willing to accept the concept of the "shared responsibility model" that some clouds, AWS for example, put forward (which I think makes sense for us, the user, to do) then we can remove some of the surface, and the hypervisor is one of those surfaces.

Hypervisors. Physical networks. Storage systems. These are all extremely complex things that the cloud subsumes and removes from (most of) our models, excepting perhaps nation states. This is a good thing. ™

The Use of Cloud Can Only Be Understood with Modelling

Hyperobjects speak to the immense, structural forces all around us, and even inside us, that we cannot see with our eyes but strive to comprehend through data or computer modeling. - Wired

On the one hand, we have the various cloud hyperobjects, AWS, Azure, GCP, coming together to form a kind of super-hyperobject, i.e. three or more things that provide similar services in completely different ways, with different APIs and configuration options and SKUs and pricing models. In order to understand any of them, we (as an industry) need to build tools to help us. And that is exactly what we have done. The clouds create their services, their prices, their configuration options, their identities and their roles, and once that is done, we build modelling systems to help us understand what we have created with the cloud.

• Cloud invented identity so we invented Cloud Identity and Entitlement Management (CIEM)
• Cloud invented millions of configuration options so we invented Cloud Security Posture Management (CSPM)
• Cloud cost is difficult to predict so we invented various tools to help understand it
• Cloud infrastructure needs to be programmed, so we've developed configuration management into tools like Terraform, but then we needed to understand the Infrastructure as Code (IaC) that we've created, so we've built tools that try to model and "scan" the IaC.

We use tools such as CSPM and CIEM to model our cloud infrastructure as best we can. Without some kind of modelling tool, it is difficult, if not impossible, to manage a relatively large cloud estate.

The cloud can only be partially understood by building infrastructure programmatically and trying to understand what's "uncompressed," and the drift over time, by using modelling tools, many of which we haven't invented yet and most of which don't see themselves as modelling tools. Reviewing cloud based infrastructure through the hyperscaler GUI seems...impossible.

PS. www2

In my previous article on the attack hypersurface, I talked about how we used to name servers like www1, www2, etc. Nice to see that still out there in the real world!