Step into cloud security

Some of you may say that cloud is nothing new and it is just someone else’s computer, and it is there for decades. While there is grain of truth in this point of view, but not nowadays, when cloud comes in its overall orchestrated, highly available and elastic form. Cloud is almost unavoidable in this day projects, that’s why it comes with the extra price in terms of security.

In this article we will try to explain with simple analogies and easy to grasp parallels, how approach to information security in the cloud is slightly different from the standard way of securing services deployed on-premises.

Cloudified solutions can preserve necessary level of security in comparison with themselves but deployed inside on-premise data centers or even deliver higher level of it. To achieve this, we should adapt our way of thinking, use different approaches, and apply best practices to the type of cloud we are on-boarding our application.

Only 10 years ago information security was one of the areas that people wanted to avoid, management had seen it as an extra cost only, and non-security engineers had seen it as an obstacle that slows down and complicates their work.

Now things are different: awareness about security topic is growing, people have understood that information has its value and price, and validation of key security principles such as confidentially, integrity or availability is a necessary part of development and investment to spend.

Although many companies have figured it out in a hard way: after they have been impacted by data breach, but there are plenty of companies that recognized the importance of security from the very beginning. Pan-Net addresses this question very seriously by enforcing «security by design» approach, where information security measures are integrated from the starting point into our product life cycle.

What do we know about traditional approach to information security

For a long time, companies have built data center for themselves, and quite often data centers have been built for a specific type of workload. That is why complete environment setup together with an estimated proper behavior of each system part had been known ahead. After building of data center was finished, its environment turned to be very rigid, static, therefore it was easier to detect anomalies.

Therefore, it was easy to build a threat model and apply necessary controls that will mitigate risks or eliminate identified threats.

Perimeter security concept plays key role in the traditional security approach. In this concept we can define network of organization as «trusted», and any other network as «untrusted». And now our security goal is to keep malicious actors away from the organization.

Complementary to perimeter security the zoning model is used in the traditional approach. Organization network is divided in zones where each zone corresponds to an organizational part (it can be unit, group of units, subsidiary, product). Those units are selected by how critical they are or by some other criteria reflecting their importance/value to organization.

House analogy

As an analogy to a on-premises data center we can use private single-family house.

Let’s image we own a house, then we have full responsibility for the protection of it, and we shall do our best for its safety, such as:

• Put good locks on your doors
• Put outdoor window shutters
• Put a fence around the house
• Install doorbell with intercom and camera
• Install penetration detection and alarm system, which will also provide you with notifications
• Install fire detection system and alarm
• Install a strongbox for the most valuable possessions (papers, money, jewelry)

The list can go long, but the main goal of all those security measures is the following:

1. Only trusted people with keys can enter the house freely.
2. Trusted guest or visitors can enter the house with limitations:
   • They either can visit only limited area, such as e.g., living room, or guest rooms.
   • Or even if they need to go to the sensitive area of the house (e.g., our bedroom, or our working room, or our heating equipment room in the basement) - they can do it only under our supervision.

All this is similar to our own on-premises data center and applications deployed there. In the own data centers, we usually implement following solutions for the technical, physical, logical, administrative control:

• Preventing:
  • Locks, cages, conditional access systems (with passwords, biometrics)
  • Password management, encryption, anti-malware software
  • Define necessary policies and procedures
• Detecting: security monitoring (IDS, logging), scanning, job rotation
• Correcting: backups, fail-over systems
• Recovering: disaster recovery procedures, out of band remote access
• Compensating: filtering proxy servers

Those solutions, methods, tools are well-known and used in every data center.

Single point of responsibility

For the comparison with the public cloud below, we shall emphasize the aspect of responsibility.

In a private house (as well as in the on-premises located DC) full responsibility about house security lays on the owner. The owner could consult with different security experts, advisers, and security systems are installed by the solution suppliers, but in the end, full responsibility about the security lays on the shoulders of the house owner.

Cloud Security

But as soon as we start talking about the placement of our application into the cloud, then from the first impression things are getting more complicated. Now we shall deploy application on an untrusted ground, where we do not own all components of the technology stack. Even if cloud provider is putting all effort to be transparent and safe, there could be some aspects of the security that they do not implement in the accordance to the best practices; issues that they are not aware of.

What add complexity to the picture, is that cloud native applications are very dynamic, with high level of agility, scalability, automation, and orchestration. They are commonly implemented in a geo-redundant way, stretched over multiple cloud regions or even multiple cloud providers in order to be protected from the complete failure of the cloud provider.

As we can see, our standard, classical way of application security, which we use on-premises, is not applicable.

Hostel analogy

For better explanation how cloud security differs from the on-premises data center security, let us use hostel analogy.

Why hostel and not hotel you may ask? Because:

• Hostel offers both one guest rooms and rooms shared by multiple guests like public cloud offers compute services (VMs) and serverless.
• All other facilities are shared between guests (like dining rooms, kitchens, bathrooms, shower, storage). This is like shared resources in the clouds (HW, APIs, storage…).
• Guests can consume only supplied facilities and cannot build their own in. The same way in the cloud, when user can bring some parts of his virtual infrastructure in, but user cannot build his own physical network, or install his own HW compute nodes.

Moreover, we can compare network of hostels with the geographically distributed cloud.

Shared use of the hostel facilities like dining room or kitchen can be called «multitenancy».

Usually, hosts do all their best to secure the hostel and its guests with the standard measures like:

• Installing locks on the front door and rooms, integrated with the key system: when each guest can have access to the front door, shared facilities, and his room, but cannot access other rooms.
• Installing individual strongboxes (safes) for guest valuable possessions.
• Organizing and equipping front desk service which typically delivers services like:
  • Access control
  • Customer support
  • Check-in and check-out
• Install some monitoring and alarm systems to detect malicious guests and other critical situations
• Develop and distribute standard living rules for this hostel
• Organize room cleaning service

As we can see list above, hostel owner is also interested and invest plenty of his resources and money into the security.

But despite of the measures, precautions, rules, and systems of the hostel, it is also each guest personal responsibility to take care about his security. E.g., most obvious guest measures are:

• Never keep your valuable belongings unattended:
  • Keep your valuable belongings (especially your IDs, credit cards, money) in the strongbox,
  • Or carry them with you.
• Have insurance for other belongings.
• Keep and not lose your key.
• Report to the front desk service about suspicious activities and potential security flaws.

And like hostel builds its service offering, all cloud providers deliver services to their clients in some kind of:

• Individual rooms (VMs, VPC in the IaaS)
• Or shared rooms (like containers in the serverless service on the cloud provider’s containers managed cluster)
• And multipe shared facilities such as LBaaS, DBaaS, App runtimes.

And like in the hostels, cloud provider implements a lot of security measures, tools and practices, and also cloud users (like hostel guests) must take care about security of their applications and workloads.

Shared responsibilities

From the analogy above we can easily see, where is the biggest difference in the security aspect between own house and hostel, as well as between data center on premises and a cloud. It is in the following:

In the on-premises infrastructure the owner takes full responsibility for the security.

In the shared infrastructure such as cloud (or hostel) both host and guest share responsibility for security.

Now we put aside our analogy and focus on the responsibilities split for the cloud and cloud users. We group them into two main categories:

• «Security of Cloud»
• «Security in Cloud»

And there are also two parties in this split:

• Cloud Provider - is responsible for the «Security of Cloud»
• Cloud User¹ - is responsible for the «Security in Cloud»

Security of Cloud

As we already said above, «Security of Cloud» is in the full responsibility of Cloud Provider. This means that Cloud Provider must ensure that their implementation of cloud services is fully secure and is aligned with the regulatory requirements.

To prove cloud readiness in terms of security usually Cloud Provider passes regular security maturity checks, which results are reflected in:

• SOC 2 Type 2 report,
• CSA (Cloud Security Alliance) certificate,
• Security report to national authority controlling cloud security,
• Or just results of self-assessment.

For instance we, in Pan-Net, invest a lot of our efforts into the security of the cloud we provide:

• Administrative security measures (procedures and process) and security control of our supply chain.
• DevOps processes: hardening, patching, security testing, vulnerability management, incident responses.
• Software level security: cutting edge encryption, protection, network scanning and code scanning.
• Physical security where server racks are installed in trusted data centers, inside secured cages.

Security in Cloud

This is basically a security of a workload (application) itself, of the workload which is deployed inside of cloud. And it is important to emphasize, that there cannot be «Security in Cloud» without «Security of Cloud» first. Figure below shows such responsibility split on the example for the Infrastructure as a Service (IaaS).

Here Service Provider is synonym to Cloud Provider, and Service Receiver is synonym to Cloud User.

And here it is quite easy to see how IaaS Cloud Provider is responsible for security from the psychical layer all the way up to hypervisor. And, in its order, Cloud User is responsible for all components above hypervisor, starting from its private network to his data.

Cloud Provider can offer additional security services (as a shared services), which assist in delivery of different security protections and practices for the on-boarded workloads. But it is in the responsibility of the Cloud User to enable and configure them.

But it is important to clarify, that each consumed by the Cloud User security service from the Cloud Provider comes with its own split of responsibilities, similar to SaaS model. And for each consumed security service responsibility split is different.

What to do to protect your application in the cloud

Now we know what the main differences between on-premises and cloud security models are, and we can describe the way to secure our workload in the cloud more practically. Let’s start from the list of things we need to consider when we are planning on-boarding to cloud:

• Regulatory requirements and other constraints.
• Functional and non-functional requirements that cloud needs to fulfill.
• Supporting services provided by cloud provider.

Step 1: Cloud security assessment

First step before on-boarding your application on cloud is to assess the cloud provider(s) of your choice. It can be, that your application has specific requirements to the level of cloud security, that are coming from standardization bodies, legislative or some other authorities. Therefore, before you start to deploy your application into the cloud, you shall search for proofs of its security compliance, such as:

• ISO, PSI/DSS, BSI C5 reports,
• assessment report in the CSA Star registry.

Note: By my experience, cloud providers with strong security are more than happy to share proofs with their customers.

Step 2: Cloud security services assessment

In this step the main question to answer is:

• What security services are offered by cloud provider, that can help you to implement your application in the cloud in a secure way?

For instance, Pan-Net Cloud provides its customers with the following range of security services:

• Web Application Firewall as a Service Webshield
• Repository for secrets (SSH keys, tokens)
• Security groups
• Short living certificates

While it is not mandatory to consume them from the cloud provider, because all those security components and services can be built and integrated by the application owner himself. But this might cost plenty of extra DevOps resources and increase time to market, while cloud provider’s services can shorten time to market and simplify application architecture and implementation. It is like if you would bring your own lock, keys and strongbox into the hostel, or use provided by the host.

One more important requirement to the provider during this step of assessment we want to check is how cloud provider is growing its security:

• How is it engaging with new security services and standards.
• What is the velocity of introduction of new security services and standards.

One of the indicators of this can be, e.g., how its cryptography is up to date with the latest NIST standards.

Step 3: Cloud transparency assessment

Another practically important criterion for choosing secure cloud provider is a transparency about its incidents. Status page is one way how today cloud providers communicate with customers and inform them about the status of cloud they are implementing. Status page reflects all incident that can impact availability of cloud services exposed to and used by cloud users.

Incident management of cloud provider is also assessed at this step. It is important to check, how cloud provider reacts on incidents or vulnerabilities, and are they detected by cloud provider’s systems. This may look like a small detail but can later affect security of your application and workload.

Step 4: Review and adapt application to cloud

After we picked cloud provider, it is time to focus on the application itself. As it was mentioned above, cloud native applications are agile and scalable. It means they can grow and shrink number of their components depending on current workload requirements.

Virtual networking is now dynamic as well as cloud storage resources - everything is created and destroyed on-demand. This agility makes static perimeter protection techniques inapplicable. So, application now must incorporate dynamic way of network protection: SDN, dynamic network policies, dynamic security policies, cloud monitoring, encryption of interfaces, integration with Cloud Provider security services. And every time you implement another security layer into your application on the cloud - always remember about shared responsibilities described above.

Simplicity and cost factors

We shall also remember about the cost factor. Implementation of all necessary security practices such as identity management, certificates management, network load balancers, DoS/DDoS protection, auto scaling, key management system, web application firewall and other protection tools is much easier in the cloud, because those services are built to be public, therefore they are built to be:

• Easy to use.
• Automated.
• Auto scaling.
• Secure by design.
• Monitored by design.
• Well documented.
• Expose easy to use APIs.

and, more importantly, to be consumed on the PAY AS YOU GROW model.

This makes clouds ideal for a small- and mid-sized projects who have very tight budgets on start. And with the proper use of cloud security services, they can deliver applications with a strong security for a affordable costs.

While building the same level of integration, availability, scalability, agility and security on-premises requires huge INVESTMENTS UP-FRONT.

Finally, what about claims that “Cloud is not secure”?

Many times, we have been approached with this statement: «Cloud is not enough secure». And we hope that in this article we were able to show that such claims are simply not true.

Clouds are secure but security of the application in cloud requires different way of thinking, architecture, integration, trust. And when developer (Cloud User) understands where responsibly border lays, he can adopt its application and practices accordingly and deliver required level of security for its cloudified application.

Because cloud security services are used by tens or hundreds of thousands of applications, cloud provider has even bigger interest in the delivery of high class «Security of Cloud» and services helping customers improve their «Security in Cloud».