How secure is my cloud infrastructure?

As organisations adopt cloud solutions across industries, cloud security and data protection remain some of their chief concerns. Is my cloud provider trustworthy and competent to ensure maximum security of all my sensitive information, like customer data? Are the cloud services my business employs properly encrypted? Are my resources stored in a way that will ensure data loss prevention and continuity of service? Is my cloud provider proficient enough in threat intelligence to protect me from potential hacker attacks? These and other questions are what any organisation needs to ask in order to protect its and customer data properly. Read about the current biggest security challenges and Google Cloud security.

Understanding cloud network security

Cloud security is a broad term that encompasses all technologies and practices that protect cloud environments, cloud applications and data. It involves cloud infrastructure, access and authorisation policy, right down to the file system. Making sure every aspect of your cloud is secure is crucial because even a single point of vulnerability can threaten your operations.

Cloud models and security responsibilities

There are three main types of cloud computing models: private (on-premise cloud), public (including Google Cloud) and hybrid clouds (a combination of both on-prem and public infrastructure). The most common cloud environment is a multi cloud, where a business uses cloud components and services from different cloud providers, such as Amazon Web Services, Microsoft Azure and Google Cloud.

In fact, most companies employ solutions from various providers and according to a recent study by Deloitte, as many as 85% of organisations have more than one cloud provider, while 25% have more than five. The multitude of clouds creates an extra layer of security responsibilities, but even with a single cloud provider, data security is of paramount importance.

Challenges to Google Cloud security

Before the emergence and growth of cloud environments, infrastructure security was constructed like a tall wall surrounding a castle: once a user was past the castle wall, they were considered “safe.” That’s not the best approach these days.

The approach with a castle wall no longer works because we have insider attacks, because we have more and more sophisticated hacker groups and because of the cloud. We can no longer trust someone just because they are within a corporate network.

Zero Trust in cloud security

When 20 big tech companies were attacked in 2009, the industry realised that even the basic tenets to cloud network security needed a serious overhaul. New security measures were devised and implemented. But more importantly, a new approach to network security was born.

Insider problem

Several factors make the previous “castle wall” defence obsolete, most notably:

Remote teams

More people work from home than ever before and internet communication (e.g. Google Workspace tools) has become the standard. Most companies rely oin VPN as their main (and often only) identity verification method. It is in essence a “castle wall” access management approach, which creates vulnerabilities and exposes sensitive data.

Threats from the inside

Many companies have a Bring Your Own Device policy, which may generate threats to security. As organisations grow, the risk of encountering bad actors within the company increases and the visibility of potential attack vectors decreases.

Multiple service providers

Operating in an ever more connected world means more organisations and individuals need to be granted access to our infrastructure. This poses new risks and needs proper network security management to protect your data and resources.

Vast and growing number of devices

Between mobile phones, smartwatches, laptops and other devices, the number of potential entry points has increased manifold over the years. Each device needs to be treated as a separate entity and a potential threat to cloud security.

The main tenet of the Zero Trust policy is that there is no implicit trust based on the asset’s location (within or outside the organisation). Every authorisation must be based on the role they have, and the tasks they are about to perform.

Individual versus group

There is an inherent complexity in the Zero Trust approach. After all, if we decide to limit employee privileges even after they go through the main barrier (login), we need to employ more security tools to keep track of their activity. The system needs to continuously collect information about the state of resources and the state of infrastructure to keep improving security.

Context policies

In order not to drown in a case-by-case security authorisations (those who use aggressive firewalls know how time consuming whitelisting every access can be), Google cloud security experts recommend a set of comprehensive policies that regulate types of users and what kind of access they should have. And these policies should be based entirely on the context (e.g. why is the employee or contractor accessing this resource and how they might need to alter it) and not on location or access credentials.

And the main Google Workspace customers are well acquainted with roles assigned to users of e.g. Google Docs. Assigning editing, commenting or viewing privileges is sufficient ,

(Dis)trust equally

It may seem counter-intuitive, but experts agree the same set of policies for assets within our organisation and for cloud infrastructure makes data more secure. We need to distrust the assets within our infrastructure just as much as those in cloud environments. Google is one of the biggest companies to use the Zero Trust approach.

If not password then what?

Even though it’s been the go-to verification method over the past decade, multi factor authentication is not as secure an option as once considered. Experts agree that passwords, push notifications, text messages, all are susceptible to phishing. “Hackers don’t hack anymore, they log in. The cheapest mailing campaign costs several dollars and you can be almost certain that someone will fall victim to it,” said Rafał Rosłaniec, Head of Technical Support at ePrinus.

FIDO authentication

One of the alternatives to passwords, which are often considered as the weakest link in cloud security, is physical key with a public/private key encryption. With that in mind, Google and Yubico founded a FIDO alliance and implemented a FIDO authentication standard.

In essence, FIDO features public key encryption, where Google holds the public key, and the private one is injected with a physical key each time authentication is required. The intermediary between the public and the private key is a browser with a specific logging window.

No phishing or spoofing attacks

FIDO is not susceptible to phishing precisely because it is a physical object with a button that needs to by pressed in order for the key to be injected. After all, a hacker cannot reach out and get a hold of the key.

FIDO is also impervious to “Man In The Middle” attacks, according to industry experts. Even if the intermediary were replaced with a fraudulent one (a spoofed login window), FIDO will simply generate an invalid token. “The token it injects will be random because it won’t know what it’s suppose to generate,” Rafał Rosłaniec explained.

Google Cloud security measures

Google Cloud security specialists also point to a vector of security threats that has been under-explored in the past but which now poses a serious and growing risk. Threat intelligence has become of paramount importance given the constant rise in the number of cyber attacks.

While in the past, most attacks were on run time, that is no longer the case. The final stage of app development is now protected by so many security tools, it is often too challenging and time consuming to devise an effective attack.

Instead, many attacks are now focused on the part of the previous stage of an app life cycle: its development. Over the past 3 years, there has been a 740% increase in supply chain attacks. According to Gartner, 45% of companies will have experienced a supply chain attack by 2025.

Supply chain vulnerabilities

The development process of any service or app has become so complicated that there is always a way to find a vulnerability and compromise the build of a system. Compromising the system supply chain is possible in so many places, securing the entire process is not an easy task.

Different actors have discovered that it was easy to take over accounts that had not made any commits in open source repositories in a long time. This way they could easily introduce a back door. He also emphasised how important it is for developers to sign each of their commits.

Assured OSS

The main reason why it is so easy to attack the development phase of an app is because software engineers use multiple tools and innumerable libraries to source solutions. Assured OSS is one of the ways in which Google secures the supply chain.

Google cloud engineers verify open source repositories and makes them available to Google Cloud customers. Currently, it has 250 java libraries in its portfolio. This is designed to prevent injections of back doors and vulnerabilities into code.

Dashboards and Binary Attestation

Other features that are aimed at app developers include dedicated dashboards in Google Kubernetes Engine and Cloud Run, which display vulnerabilities and shows how many clusters each vulnerability affects. Additionally, Binary Authorisation allows users to add attestation, like digital seals of approval to containers that have been verified and approved.

Asset-oriented architecture

In order to improve its resilience to outside attacks, Google cloud is asset-oriented not user-oriented. “If we have an asset, it is easy to check who has access to it. It is more difficult to find out which assets a user has access to. That makes attacks on infrastructure more difficult,” said Łukasz Bobrek, Head of Cloud Security at Securing. He added, however, that even small configuration errors can be exploited and can lead to compromising an entire cloud infrastructure.

While Google engineers may work hard to ensure the security of their cloud environments, it is often the smallest errors that lead to big threats and major losses. “One client had a back-end PDF generation from HTML. We managed to inject code into HTML that generated access codes in form of a PDF file. We have also seen project or even organisation-level access policies.” Each cloud entity should have exactly the type of access that is necessary to complete work and nothing more.

Shared responsibility

Given the multitude of vulnerabilities along the supply chain and within any cloud infrastructure, Google Cloud Platform, like other cloud providers, has devised its Shared responsibility model. Basically, it delineates the areas of responsibility of the service provider (Google Cloud Platform) and the user’s.

It is the cloud service provider’s responsibility to ensure the security of the cloud infrastructure and of the solutions they offer. Data protection (i.e. the content and apps the user stores on the cloud), as well as some of the access management are on the client’s side. Depending on the model (Software as a Service, Platforma as a Service or Infrastructure as a Service), the scope of responsibilities may shift towards the user or the cloud provider.

Read more about Google’s Shared Responsibility Model.

Data Loss Prevention

While ensuring compliance of data policy with the local regulation is usually the user’s responsibility, Google has made over 100 security rules available within its Data Loss Prevention policy that developers can easily deploy. “For instance, these rules can detect personal identity numbers or credit card numbers as sensitive data and therefor prevent infringing upon the regulation in the country or region,” explains Maciej Wojnarowicz, Support Specialist at FOTC.

He also pointed to the fact that many organisations have outdated access policies, a fact that becomes obvious during security audits. “Sometimes we perform an audit and discover that 14 out of 15 admins have super admin privileges. Such settings are dangerous and need to be changed,” he said. Find out more about Data Loss Prevention from our blog article.

What to do if security is compromised?

Even with the most air-tight security procedures, any system or apps may have vulnerabilities and security breach may occasionally occur. It is therefore vital to have procedures and practices in place to mitigate the problem and prevent it from escalating.

Security emergency checklist

Here’s a checklist of key steps that allow you to quickly respond to a security breach of our cloud environment.

Press pause

It is crucial to stop working on the affected service as soon as a security threat has been detected. Shut down the instance immediately.

Notify

Let all the users and other stakeholders know about the temporary shutdown of the service.

Find the problem

Identify where the the breach occurred by running diagnostic software and/or analysing the instance and its programming.

Verify

Make sure your software has all the necessary updates installed, check for recognised vulnerabilities and security patches provided by your software providers. Install all security updates.

Secure

Make sure all unaffected instances are also protected and no other systems are vulnerable to the same or similar security breach.

Reinstate

Once all relevant security controls are updated and all threats are eliminated, you can resume running your instance.

Find out more

If you’d like to find out more how to set up your cloud environments to ensure maximum security, download our free ebook.