CLOUD IS A NEIGHBORHOOD

Assaf Miron
CyberArk Engineering
6 min readSep 5, 2021

Most organizations today are in some stage in their transition to the cloud, this is no news. While listening to the Foo Fighters song “The Sky is a neighborhood”, it occurred to me that this cloud transition is like moving to a new neighborhood with big buildings (cloud vendors) that look pretty much the same from outside. So I began to wonder how organizations determine he best cloud vendor to invest their time and money in. Or more importantly, why? Do these organizations have the right “moving crew” to keep their data secure in this transition?

According to Flexera state of the cloud report, 90% of organizations say that COVID-19 accelerated their cloud plans, while some were not affected by it or had a minimum affect.

So, how do organizations benefit from making the transition? A quick Google search on “Why are organizations moving to the cloud?” shows the following benefits:

  • Reduces cost
  • “Work from anywhere”
  • Safer data storage

Reduces cost

Although some organizations just beginning their cloud transition think it would reduce costs, more mature organizations realize that if they require highly available systems, they might not see reduced costs. However, they agree that moving to the cloud can help them develop better solutions for their customers using lean startup methodology, reduce maintenance for their servers and reduce other costs (power, storage, etc.).

“Work from anywhere”

The demand for collaboration, external vendors access, and even remote work always existed. During the COVID-19 imposed quarantine, the demand for remote work or “work from anywhere” increased tenfold. Using cloud platforms allowed organizations to give their employees the ability to work remotely with more collaboration (sometimes opening some of the barriers that were made to prevent this exact access).

Safer data storage

Lost laptops are a billion-dollar business problem. The real problem is not the actual laptop; it’s the data they store. If the data is no longer on the laptop or on a server in an on-premise datacenter but stored securely in the cloud , the problem becomes less significant because security is handled by a single entity: the cloud vendor.

Organizations need to consider the cloud vendor’s shared responsibility model — especially the security part of it. The cloud vendor is only responsible for physical security and their software management layer. The customer (user) must take care of misconfigurations, as well as known web attacks and vulnerabilities for known ports. It’s true that the physical security of the cloud vendor is more robust than your ordinary datacenter, but if you as a customer do not adhere to security best practices and secure your own data it becomes vulnerable.

This year, numerous organizations were impacted by two separate breaches — one on a popular secure file sharing provider, the other on a leading employee productivity suite. In both cases, the attackers targeted sensitive information, and subsequently used exfiltrated data as leverage in extortion attempts.

So, is the data more secure in the cloud?

Cloud is a neighborhood

THE YELLOW BRICK ROAD TO YOUR DATA

The goal of most cyberattacks is reaching sensitive data. Whether personal or company related, data is what drives attackers and is, what organizations need to protect today.

Since more organizations are moving to the cloud, more data is being stored there. The role of Cloud Security Architect (CSA) was created to oversee this process and establish ground rules.

The cloud security architect’s responsibilities are growing and becoming crucial in most organizations. This is the person who knows who has access to what, maintains least privilege for any access, instructs teams to the company security base line for storing data and makes sure any cloud deployment implements security best practices.

A major attack on a financial services organization exemplified what can go wrong when cloud permissions and entitlements associated with identities are misconfigured. This breach started with a web application vulnerable to server-side request forgery (SSRF). Because of misconfigured access roles to a public cloud storage resource, the attacker was able to expose sensitive data.

Cloud providers give you a vast toolset for configuring the requirements of any of your projects, but they don’t assume responsibility for the way you use it. Ultimately, it is the CSA who must make sure doors are not left open and vulnerable.

Tip: Think of your security policy when uploading data to the cloud. Make sure you employ security best practices and least privileged policies to protect your data.

ALL YOUR EGGS ARE IN THE BASKET — IS IT THE RIGHT ONE?

Usually the goal of developing in the cloud is to reduce development cost or overall service cost. More often than not, you can break down applications to micro-services and certain tasks with cloud native services. For example, why build a queuing mechanism when you can use AWS SQS? Why create a whole user management and authentication if you can simply use Azure AD or other “as-a-service” solution?

What happens when using these services is the exact same thing that can bring your application down. Not long ago, a public cloud provider experienced a multi-hour outage that affected many of its own services, along with numerous third-party internet services, applications and websites. Although this rarely happens, it can bring a lot of noise when it does.

Whether you are using cloud native service to maintain your application or building everything you own in the cloud, you have probably realized it is not cheap. Maintaining the same level of redundancy and availability for your applications as was available on your on-premise datacenter might bring more assets, services, access rules and requirements, spread credentials (for example: IAM-based constructs: roles, permissions, etc.) and places for you, as a cloud security architect, to watch and protect.

Tip: Think on your organization’s contingency plan. You will need to implement the best practices around data protection but how? How do you plan to protect your applications and data in case of a failure (server failure, service failure, site failure, region failure…)?
Once you’ve determined that, you can verify the cost of the service, the justification of “buy vs build” and the added risk (or risk reduction) in using this solution.

WORK FROM HERE, THERE OR ANYWHERE

The cloud solved a lot of problems for remote workers. It made it possible to join meetings, collaborate and even develop code from anywhere.

On the other hand, the organization’s perimeter changed. It is no longer a question of networks, firewall and VPN but rather the question of who you are, where you connect from and what you want to do — using concepts of Zero Trust where identity is the new perimeter.

When the number of projects keeps rising to accommodate the need for “work from anywhere” and “cloud migration”, the more people are needed to access them, establish identities (for human and non-human access), and manage different roles and permissions over different resources. All this creates more room for for human errors, misconfigurations and extensive unnecessary permissions to resources. This is what attackers look for in any attack and something a cloud security architect must deal with.

Tip: “Work from anywhere” is nice, “Work securely from anywhere” is better.

When defining the ground rules of secure development, use just-in-time access and ephemeral access wherever possible to reduce standing access — and always use least privilege to any granted access to resources.

Cloud platforms have contributed much to the world. They have allowed for fast development, allowing organization to solve complex problems effortlessly — sometimes without even developing a single line of code. But is it the right thing for your organization?

Most organizations are somewhere in their cloud journey. It is inevitable, but are those organizations ready to protect their data when moving to the cloud? Are you?

--

--