And so let's go to the cloud, but carefully!

(To Marco Rottigni)
25/08/21

To quote a famous American saying, cloud is the best invention from sliced ​​bread to the present day!

It is one of those historical inventions that change habits, working paradigms, business processes in a soft but inexorable way, accepted by large and small companies, capable of bringing continuity and at the same time profound innovation.

Precisely these last characteristics make it powerful, to the point that for some time it has been debating the theme of hybrid cloud - that is, the one that consists of traditional and online parts, private experiences and that rely on shared providers, built on the improvement of processes that have existed for some time and whose inefficiencies are known with respect to profound innovations in the ways of doing business.

If the push - fashionable or not - of digital transformation was not enough, the recent pandemic situation has created emergencies and modus operandi that have further exacerbated the need to make processes and applications accessible remotely and omnipresent at all times. and connected from anywhere.

This has led to often hasty reactions, sometimes perceived as simplifications with significant cost reductions, often defined as "lift-and-shift" and characterized by the displacement of servers from traditional corporate datacenters into environments cloud Amazonians, microsoftese or googlici.

The projects with a more structured approach, however, have hypothesized a re-engineering of the application platforms according to the principles of Platform as a Service (or PaaS).

If from an IT and development point of view, this modern and effective approach required a fragmentation of the server into its fundamental components - such as storage, access lists, networking, databases and more - few have perceived the profound difference from the point of view of security. , especially in relation to shared responsibility.

This concept was excellently summed up by Amazon Web Services or AWS in the sentence "This differentiation of responsibility is commonly referred to as cloud security versus cloud security" and equally effectively illustrated as follows.

This scheme, used very often to educate companies to a conscious evolution of their business processes and schemes to take advantage of platforms cloud, presents a sometimes excessive simplification of the concept that I will try to explain with an example.

Let's assume that the fictitious company ACME Ricambi Motoveicoli completed its first digital transformation four years ago, implementing a server system exposed on the Internet and located in its datacenter to create a system aimed at the online sale of its products and services.

In the present case, let's assume that the solution was successful but that it turned out to be excessively complex and expensive to maintain, due to the required infrastructure.

So in 2019 the project has evolved with the move of the servers in cloud, with the hope of a reduction in costs.

Thanks to the pandemic that caused an increase in users, the need to scale resources led to costs for server replicas higher than operational efficiency, due to the monolithic structure of the servers (the haste had led to opting for a fast solution ...).

At the end of 2020 our ACME Ricambi Motoveicoli therefore opted for a complete revision of the project that fragmented the individual components of the servers, instantiating them in a balanced and scalable way in cloud. Basically the idea is to separate what normally defines a server - for example the storage or disk space, the database on which the data is stored, the rules of access to the exposed services and so on. Each fragment is configured in cloud individually, with a system that multiplies its requests as demand increases. This approach is ideal because it replicates only the components of the application mosaic that need it, optimizing the investment / performance ratio.

If from an application and operational point of view this is the correct way, from the point of view of security this requires a profound modification of the protection strategies - precisely because of the typical opacity of shared responsibility.

To understand what I mean, let's deepen a piece of the graph above:

At first glance, if you want to instantiate a storage and a database instance, the responsibility for securing everything would seem to lie with Amazon.

And it certainly is when it comes to storage and / or DB instance resilience.

What the simplified diagram doesn't tell us is that if we look more closely at these two elements in the security settings, we notice the following.

The configuration of a storage instance, for example Amazon S3 Bucket, defaults to Permissions - Bucket Policy - Principal a default value of *, which allows anyone to access exposed and reachable storage.

An Amazon> RDS instance - i.e. database - has a default database configuration with no protection from deletion.
A compromise of the environment cloud - for example for credential theft - would allow attackers to delete the database instance, perhaps after having transferred the data.

These two examples illustrate how the entire concept of security in the PaaS paradigm requires knowledge that is not normally within everyone's reach; this means the need to update the skills of the security team, an element often not considered in project planning cloud.

It would also be desirable to have specialized inventory and dynamic configuration analysis solutions, perhaps capable of spanning multiple service providers cloud. In this way we arrive at a unified and organic presentation of the vulnerable surface, directly mapped on the visibility reached of the environment multi cloud, capabilities discussed in the previous article "From raw data to usable information: visibility and observability".

The Cloud Security Alliance, an institution for the cultural dissemination of security in environments cloud, has released two important publications on which I recommend reading:

The Treacherous Twelve (The Treacherous Twelve), in which already in 2016 he listed twelve incidents in cloud the cause of which was mainly the non-observance of best practices in the configurations.

The Egregious Eleven (Gli Egregi Eleven), in which two years ago he presented the analysis of eleven important incidents whose origin was still often the wrong configuration or too permissive of the resources.

Il Cloud it is certainly the way to greater business agility and an economy of scale in IT cost control. However, the adoption of this new technology cannot ignore the updating of security skills and the enhancement of visibility, observability, detection and response capabilities suitable for this new challenge.

To learn more:

https://www.theinnovationgroup.it/ll-cloud-ibrido-leva-strategica-per-il...

https://aws.amazon.com/it/compliance/shared-responsibility-model/

https://www.qualys.com/apps/cloud-security-assessment/