By now, everyone knows what the cloud is. Many of our readers probably have hosted services in the cloud or projects underway to migrate to it. That is because, while it has changed significantly since Salesforce started with its SaaS in 1999, it’s a model that, as we know it today, has been around for well over a decade.
It is true that the number of players has grown significantly, processes have been consolidated and the number of services has increased (and continues to do so), and new standards, organizations and certifications have appeared (and continue to do so) linked to this new paradigm, but with more or less detail, we are now understanding what this “cloud” thing is all about.
And perhaps the problem is that “we are now understanding” or “with more or less detail”, because it is clear that, always generalizing, there is still a long way to go in the adoption and integration of purely cloud practices, and of course, in the implementation of the secure cloud. And that is precisely the idea of this series: to start from that “more or less detail” to gradually increase the degree of depth.
Like many things in life, it all starts with a first question, the most obvious one, the one we should all ask ourselves, if we have not already done so: is the cloud safe? The answer, even more obvious: “depends on who you ask “. If you ask a cloud provider, their answer is clear: “of course”. If you ask me, it’s as safe as you want… or your CFO lets you.
Because in the end, as the well-known slogan says, the cloud is nothing more than someone else’s computer, and it is important not to lose sight of that at any time. Therefore, your security depends on who that other person is and how the security of that other computer is approached.
That same question can be asked about any computer or IT infrastructure in an organization, and the answer will be the same. Is a firewall secure? The manufacturer will tell you yes, but the reality is that it depends on how it is configured, updated, audited, etc. The cloud is still an extension of your domain to be protected, and it is up to you how to protect it (including the access of that other one, which in many cases is assumed to be a necessary inconvenience, or we simply tend to ignore it). Integrating services in the cloud, or migrating an application a public cloud environment, implies an extension of our attack surface and therefore requires measures to protect it.
Just as when we propose a new application or system to offer internal or external services we must define a security strategy to protect these environments, when we propose moving to the cloud, we must take into account at least the same security considerations… plus others that we will see in future posts.
Under this premise, the first factor to take into account is the famous “Shared Responsibility Model”, or as I call it: I sell you a service and how you configure it is your problem. This is the basis of our strategy. This is not new either; using the example of the firewall, if I purchase one of these devices already upgraded, and I don’t open any port to the Internet, I could say that I have some security guaranteed by the manufacturer, associated to the design and implementation of the device (yes, we know: “The only system which is truly secure is one which is switched off and unplugged locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it” – Gene Spafford).
However, from that moment on, the responsibility for the correct configuration, for keeping the equipment updated, and therefore for its security, belongs to the buyer (of us, you know). This means that, although we will cover this in future entries, in the event of a possible cyber security incident, the responsibilities will be ours, and it will be complicated to claim compensation or responsibilities to these cloud suppliers. In the same way that no one would ever think of suing Checkpoint because a network protected by a firewall whose first rule is ANY:ANY has been breached.
The second important factor to consider is our approach to the cloud. We are going to divide this into two areas: on the one hand, we must consider the type of service we need or are going to implement. That is, whether we are going to contract infrastructure services (IaaS), platform services (PaaS), or application services (SaaS). This is important, not because one or the other is better or worse from a security point of view, but because according to this decision we will have to adapt our security solutions.
The second area is the global model of our infrastructure, “infrastructure” understood as any element that provides IT services to our organization. Without going into the possible combinations, we can have elements in our facilities (on-premise), in private cloud services, in public cloud services or off-site and mobile (edge computing). Just as with service models, for each approach we will have to consider different strategies. In fact, in this case, the market trend is to move towards hybrid multi-cloud environments, in which services are hosted by different cloud providers, mobile or on our premises, which further complicates the security strategy, that needs to consider each particular case for us to sleep as peacefully as our beloved job allows.
Although in many cases, working in the cloud is perceived as a simple extension of our infrastructure to other environments, the reality is that this thing goes much further. Leaving aside new security solutions or attack scenarios, the concept of the cloud changes the paradigm of security, development, operations, and cost management in IT. Now we must not only control classic security elements, but also manage environments where not everything is under our control; small changes in cloud environments can have greater implications than before, such as the exposure of data to the outside world; it’s worth mentioning that the most notorious cases of cloud security incidents have NOT been related to new attack vectors or undetectable ATP, but deficient configurations of, for example, S3 buckets.
There is no doubt that all this opens an exciting world of security (and lots of new headaches), in which we will delve into future entries, with permission of the coronavirus, teleworking and whatever the future holds for us.
