As a Cloud Security Architect, I find myself asking the same basic questions to assess the risk profile of an application. This article is written to provide a working model for application teams and program managers to understand their own risk profile.

As part of my duties, I work with development teams to guide their transition to the cloud. Since these applications are currently in a datacenter, virtually all of the infrastructure decisions, e.g., network accessibility, storage encryption, etc., are made by an operational team. However, when migrating to the cloud, these infrastructure decisions now become the responsibility of the application teams. This new level of control and responsibility requires a greater understanding of their environment, which is a learning curve for most teams.

When engaging with a new application, I begin with three basic questions:

• Where is your compute? Where is your house?
• How accessible is your application? How easy is it to get to your home?
• How do you protect your data? Are your documents safe?

Of course, the responses to those questions will open up another series of questions.

The rest of this article will explain why these question are fundamental and how they can affect your risk profile.

Where is your compute, a.k.a., “What type of house do you have”?

If someone was assessing the likelihood of a burglar breaking into your home, they would want to know the type of dwelling you have. Securing a 16 bedroom mansion is very different than securing a houseboat.

In the modern cloud, there are many options for compute. There is the traditional “bare metal”, where you effectively rent a whole computer, or new “serverless” options, where your code magically runs in the cloud. Each compute model has its security pro’s and con’s. 

Referring to the prior examples, bare metal is like building and maintaining your own home – you are responsible for the roof, plumbing, etc. Translating that back to technology, this means you have to patch it, make sure you have the appropriate logging, etc.

Serverless has no maintenance, its like the cloud vendor will provide you with a temporary mobile home, but you have no control over where this home is or who your neighbors are. You are relying on the cloud vendor to make sure your code is protected from other people’s code and they cannot get into your home and steal your data.

As an application team, think about which compute resource fits your needs. Ease of use is important, but consider what controls are lost when you adopt the cloud provider’s framework. In every application, this tradeoff will be different, but consider the likelihood and risk of someone accessing your compute resource.

How accessible is your application, a.k.a., “How easy is it to get to your home and are there security gates”?

Now we know the type of home we will rent, the next question is where will the house be located. The more people can get to the front of your house, the less secure you are.

The good news is that cloud providers have very strong network tools to create your own virtual private cloud (VPC), which is like having your own gated neighborhood. Furthermore, its possible to have more secure sub-divisions within the gated community. Generally, the biggest concerns are about how these controls are setup and configured.

When deploying your application, consider which components need to be accessible by the outside world. Ideally, only a few components would be publicly accessible. All the other components should be in their own private sub-division. Furthermore, you could even have specialized sub-divisions, i.e., only a small set of components can access sensitive databases.

The other control would be to make sure only authorized people can access your community. This would be like providing people with a temporary pass which is validated at the security gate before letting them enter the neighborhood or a sub-division.

Finally, make sure all your network traffic is encrypted. Many applications still send unencrypted data within their network since they consider it “safe”. Network encryption is relatively easy to implement and will raise your security profile immensely!

How do you protect your data, a.k.a., “Are your documents in a safe and are they in plain English”?

When setting up home security, you have to plan for the inevitability that someone will break in and steal or read your documents.

Let’s start with valuables: the most obvious thing to do is to put them in a safe. In this case, the safe is storage or a database, which require the appropriate credentials. Also, make sure that you send your credentials using an encrypted channel, you don’t want to send your credentials in clear text!

The second control is the document itself. Is the document in plain English? If they have cracked open the safe, could they read your documents? A second control would be to encrypt the content of the document, i.e., translate it to a secret language that only authorized people can read.

In most cases, teams will chose to do one or the other, i.e., secure the storage or encrypt the data. There may be some cases, e.g., absolutely critical business data, where you decide to do both.

Final Thoughts..

In my experience, there are “macro” and “micro” concepts around cloud security. I don’t expect everyone to understand “micro”, e.g., PKI encryption, etc. However, I do believe all program members should understand the “macro” and understand how their security profile aligns with their business risk profile.

Having a common understanding will enable teams to engage the business, and ultimately their customers, about how their privacy is protected.