Practical Cloud Security

Figure 1-1. User and administrator roles
2. Draw a box for the first component the user talks to (for example, the web

servers), draw a line from the user to that first component, and label the line with how the user talks to that component (Figure 1-2). Note that at this point, the component may be a serverless function, a container, a virtual machine, or some‐ thing else. This will let anyone talk to it, so it will probably be the first thing to go. We really don't want the other components trusting this one more than neces‐ sary.

2 I recommend Thre_t Modeling: Designing for Security, by Adam Shostack (Wiley).

Threat Actors, Diagrams, and Trust Boundaries | 3

Figure 1-2. First component
3. Draw other boxes behind the first for all of the other components that first sys‐

tem has to talk to, and draw lines going to those (Figure 1-3). Whenever you get to a system that actually stores data, draw a little symbol (I use a cylinder) next to it and jot down what data is there. Keep going until you can't think of any more boxes to draw for your application.

Figure 1-3. Additional components
4. Now draw how the administrator (and any other roles you've defined) accesses

the application. Note that the administrator may have several different ways of talking to this application; for example, via the cloud provider's portal or APIs, or through the operating system access, or by talking to the application similarly to how a user accesses it (Figure 1-4).

Figure 1-4. Administrator access

4 | Chapter 1: Principles and Concepts

5. Draw some trust boundaries as dotted lines around the boxes (Figure 1-5). A

trust boundary means that anything inside that boundary can be at least some‐ what confident of the motives of anything else inside that boundary, but requires verification before trusting anything outside of the boundary. The idea is that if an attacker gets into one part of the trust boundary, it's reasonable to assume they'll eventually have complete control over everything in it, so getting through each trust boundary should take some effort. Note that I drew multiple web servers inside the same trust boundary; that means it's okay for these web servers to trust each other completely, and if someone has access to one, they effectively have access to all. Or, to put it another way, if someone compromises one of these web servers, no further damage will be done by having them all compromised.

Figure 1-5. Component trust boundaries
6. To some extent, we trust our entire system more than the rest of the world, so

draw a dotted line around all of the boxes, including the admin, but not the user (Figure 1-6). Note that if you have multiple admins, like a web server admin and a database admin, they might be in different trust boundaries. The fact that there are trust boundaries inside of trust boundaries shows the different levels of trust. For example, the servers here may be willing to accept network connections from servers in other trust boundaries inside the application, but still verify their iden‐ tities. They may not even be willing to accept connections from systems outside of the whole application trust boundary.

Threat Actors, Diagrams, and Trust Boundaries | 5

Figure 1-6. Whole application trust boundary

We'll use this diagram of an example application throughout the book when discus‐

sing the shared responsibility model, asset inventory, controls, and monitoring. Right now, there are no cloud-specific controls shown in the diagram, but that will change as we progress through the chapters. Look at any place a line crosses a trust boundary.

These are the places we need to focus on securing first!

Cloud Delivery Models

There is an unwritten law that no book on cloud computing is complete without an

overview of Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Soft‐ ware as a Service (SaaS). Rather than the standard overview, I'd like to point out that these service models are useful only for a general understanding of concepts; in par‐ ticular, the line between IaaS and PaaS is becoming increasingly blurred. Is a content delivery network (CDN) service that caches information for you around the internet to keep it close to users a PaaS or IaaS? It doesn't really matter. What's important is that you understand what is (and isn't!) provided by the service, not whether it fits neatly into any particular category.

The Cloud Shared Responsibility Model

The most basic security question you must answer is, "What aspects of security am I

responsible for?" This is often answered implicitly in an on-premises environment. The development organization is responsible for code errors, and the operations organization (IT) is responsible for everything else. Many organizations now run a DevOps model where those responsibilities are shared, and team boundaries between development and operations are blurred or nonexistent. Regardless of how it's organ‐ ized, almost all security responsibility is inside the company.

6 | Chapter 1: Principles and Concepts

Perhaps one of the most jarring changes when moving from an on-premises environ‐

ment to a cloud environment is a more complicated shared responsibility model for security. In an on-premises environment, you may have had some sort of internal document of understanding or contract with IT or some other department that ran servers for you. However, in many cases business users of IT were used to handing the requirements or code to an internal provider and having everything else done for them, particularly in the realm of security.

Even if you've been operating in a cloud environment for a while, you may not have

stopped to think about where the cloud provider's responsibility ends and where yours begins. This line of demarcation is different depending on the types of cloud service you're purchasing. Almost all cloud providers address this in some way in their documentation and education, but the best way to explain it is to use the anal‐ ogy of eating pizza.

With Pizza-as-a-Service,₃ you're hungry for pizza. There are a lot of choices! You

could just make a pizza at home, although you'd need to have quite a few ingredients and it would take a while. You could run up to the grocery store and grab a take-and- bake; that only requires you to have an oven and a place to eat it. You could call your favorite pizza delivery place. Or, you could just go sit down at a restaurant and order a pizza. If we draw a diagram of the various components and who's responsible for them, we get something like Figure 1-7.

The traditional on-premises world is like making a pizza at home. You have to buy a

lot of different components and put them together yourself, but you get complete flexibility. Anchovies and cinnamon on wheat crust? If you can stomach it, you can make it.

When you use Infrastructure as a Service, though, the base layer is already done for

you. You can bake it to taste and add a salad and drinks, and you're responsible for those things. When you move up to Platform as a Service, even more decisions are already made for you, and you just use that service as part of developing your overall solution. (As mentioned in the previous section, sometimes it can be difficult to cate‐ gorize a service as IaaS or PaaS, and they're growing together in many cases. The exact classification isn't important; what's important is that you understand what the

service provides and what your responsibilities are.)

When you get to Software as a Service (compared to dining out in Figure 1-7), it

seems like everything is done for you. It's not, though. You still have a responsibility to eat safely, and the restaurant is not responsible if you choke on your food. In the SaaS world, this largely comes down to managing access control properly.

3 Original concept from an article by Albert Barron.

The Cloud Shared Responsibility Model | 7