After visiting the RSA Conference (yes I walked the infamous show floor) I decided to zoom out on what I saw and think about where we are spending our time, resources, and investments as an industry.
The one thing that came to me is that we certainly spend a lot of time talking about threats. In fact, most of the marketecture pitched was based on new or “emerging” threats. And, although there were some exceptions, there was little around risks.
There are several articles online about the difference between threats and risks – my favourite here: Threat, vulnerability, risk – commonly mixed up terms. Additionally, there are many different formulas to derive risk. For example:
RISK = PROBABILITY * LOSS
RISK = ASSETS + THREATS + VULNERABILITIES
RISK = THREATS * VULNERABILITIES * CONSEQUENCES
RISK = LIKELIHOOD * IMPACT
While all the formulas can be used, I believe that assets need to be a key component of any formula moving forward when it comes to modern deployment of infrastructure to the public cloud.
Let’s break down select items in the various formulas for risk in the context of deploying your workloads and applications in public cloud.
Assets are typically people, property, or information. What is interesting in deploying in public cloud is that there is a very different operating model. You don’t own all the assets. Many of them are shared. Furthermore, your assets are often dynamic, in many cases ephemeral.
Imagine asking your IT department to rack a thousand servers, power them up, load the OS, build the network, and secure it all for just a weekend.
This concept would be laughed at in most companies before the public cloud. It is now the norm and can be done within minutes and a with just few lines of code. Because of this, the ability to understand your assets or inventory in near real-time is critical.
Threats can be thought of as things you are protecting yourself against. More specifically, anything that can exploit a vulnerability, whether intentionally, by accident, or a through a misconfiguration. Where there is damage to an asset, obtain, or destroy it.
In the case of the public cloud, understanding your threats is also very different. It is a combination of the known threats to your assets, the unknown, and the threat of misconfiguration. All too often cloud security breaches are the result of a misconfiguration or unintended change.
The consequence of security can be simply thought of as the impact of an event. Typically this is measured in several ways including: downtime, productivity loss, brand reputation, and data loss. In most cases, measuring the impact of a security event is difficult. While there are hard costs involved, it’s often the soft costs that are not as easily attributed to the event.
In public cloud there are some interesting new consequences around abuse and nefarious use of the services you are operating. Examples in the past have been where attackers use workloads to perform DDOS and send SPAM, but more recently we have seen major increases in illicit mining for bitcoin. This can end up costing companies a lot of monetary damages.
REFOCUS ON RISK
One of the exciting things about working in securing the public cloud is that we get to start over. This is a major luxury, and one we should not take for granted as defenders. Most of us have been in positions where we spend the vast majority of our time gluing technology together that was not purpose fit to integrate. We now have a new operating environment to secure. That said, I believe at this time we should think strategically around where we spend our time, resources, and money. In the past we have been overly resourced based solely on threats. We’ve previously been in the mindset around – a new threat comes out, so lets buy a new product! I mean, does everyone need an APT, AI, or widget blocker?
Alternatively, how about we step back and think about what the RISK is to modern deployment. How do we identify key assets in an ephemeral workload world? How do we know what services and API’s developers are deploying and if they are configured correctly? How do we understand new attack/threat models for services we have never deployed? And how do we understand the impact or consequence of all of this and shrink the attack surface to minimize the impact?
With that I ask you to think about what time, resources, and money you are spending on in your security practice that are focussed on threats vs. risks, and re-evaluate based on your needs when it comes to securing the public cloud.