Practical Cloud Security

deny by default. That is, users are granted no (or very few) privileges by default, and they need to go through the request and approval process for any privileges they require.

For cloud environments, some of your administrators will need to have access to the

cloud console—a web page that allows you to create, modify, and destroy cloud assets such as virtual machines. With many providers, anyone with access to your cloud console will have godlike privileges by default for everything managed by that cloud provider. This might include the ability to read, modify, or destroy data from any part of the cloud environment, regardless of what controls are in place on the operating systems of the provisioned systems. For this reason, you need to tightly control access to and privileges on the cloud console, much as you tightly control physical data cen‐ ter access in on-premises environments, and record what these users are doing.
1

Defense in Depth

Many of the controls in this book, if implemented perfectly, would negate the need

for other controls. Defense in depth is an acknowledgment that almost any security control can fail, either because an attacker is sufficiently determined or because of a problem with the way that security control is implemented. With defense in depth, you create multiple layers of overlapping security controls so that if one fails, the one behind it can still catch the attackers.

You can certainly go to silly extremes with defense in depth, which is why it's impor‐

tant to understand the threats you're likely to face, which are described later. How‐ ever, as a general rule, you should be able to point to any single security control you have and say, "What if this fails?" If the answer is complete failure, you probably have insufficient defense in depth.

Threat Actors, Diagrams, and Trust Boundaries

There are different ways to think about your risks, but I typically favor an asset-

oriented approach. This means that you concentrate first on what you need to pro‐ tect, which is why I dig into data assets first in Chapter 2.

It's also a good idea to keep in mind who is most likely to cause you problems. In

cybersecurity parlance, these are your potential "threat actors." For example, you may not need to guard against a well-funded state actor, but you might be in a business where a criminal can make money by stealing your data, or where a "hacktivist" might want to deface your website. Keep these people in mind when designing all of your defenses.

While there is plenty of information and discussion available on the subject of threat

actors, motivations, and methods,₁ in this book we'll consider four main types of

threat actors that you may need to worry about:

• Organized crime or independent criminals, interested primarily in making

money

• Hacktivists, interested primarily in discrediting you by releasing stolen data,

committing acts of vandalism, or disrupting your business

• Inside attackers, usually interested in discrediting you or making money

• State actors, who may be interested in stealing secrets or disrupting your business

1 The Verizon Data Breach Investigations Report is an excellent free resource for understanding different types

of successful attacks, organized by industry and methods, and the executive summary is very readable.

2 | Chapter 1: Principles and Concepts

To borrow a technique from the world of user experience design, you may want to

imagine a member of each applicable group, give them a name, jot down a little about that "persona" on a card, and keep the cards visible when designing your defenses.

The second thing you have to do is figure out what needs to talk to what in your

application, and the easiest way to do that is to draw a picture and figure out where your weak spots are likely to be. There are entire books on how to do this,₂ but you don't need to be an expert to draw something useful enough to help you make deci‐ sions. However, if you are in a high-risk environment, you should probably create formal diagrams with a suitable tool rather than draw stick figures.

Although there are many different application architectures, for the sample applica‐

tion used for illustration here, I will show a simple three-tier design. Here is what I

recommend:
1. Draw a stick figure and label it "user." Draw another stick figure and label it

"administrator" (Figure 1-1). You may find later that you have multiple types of users and administrators, or other roles, but this is a good start.