Navigate the complex terrain of cybersecurity in the Middle East with insights into the challenges faced by security teams in hybrid and multi-cloud environments.
“What you don’t know can’t hurt you” is a perplexing adage. Images of wandering barefoot around a dark cellar strewn with mousetraps are enough to discredit it. And yet, even as headlines highlight the dangers of ignorance in cybersecurity, some still trust their toes will make it through intact. Every security professional from Abu Dhabi to Rabat knows that is wishful thinking at best.
It is hard to capture the extent to which Middle East security teams have been incapacitated due to a lack of visibility into their environments. One way might be to invoke 19th-century schoolmaster Edwin A. Abbott’s satirical novella, Flatland. SOC professionals are but line segments and polygons trying to wrap their two-dimensional heads around the cubes and pyramids of the modern IT setup’s cloud, multi-cloud, and hybrid environments. In other words, they are blind, confused, and powerless.
On-premises and cloud security are different beasts whose saddling may look similar — less risk, safe data, compliant infrastructure. However the methods employed to secure each vary wildly. The cubic space of the cloud is orders of magnitude more complex than the 2D flatland of on-premises architecture. But infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), software-as-a-service (SaaS), and serverless computing environments are often managed by those trained in on-premises environments. And therein lies the problem.
DMZs and S3s without TLC
For example, a current environment may use Azure for running Windows applications, AWS or Google Cloud for large-scale Web apps or advanced analytics, and an on-premises cloud for compliance-sensitive data storage and operations. The SOC has to ensure its team is versed in each platform, but many non-technical decision-makers think the additional work created for IT and security teams by multiple clouds is less than it is. Each cloud comes with its unique attack surface. Double the number of clouds, and you will nearly double the knowledge and labour required to protect the IT stack.
When operating a physical data centre, organisations generally define a DMZ in which a range of security protocols are enforced. Monitoring is tight, and authentication rules are strict, so predicting the inbound and outbound routes an adversary would have to use for successful infiltration and exfiltration is easy. If the workloads fulfilled by this data centre were to be migrated to the cloud, its DMZ would become more logical in its implementation, often leading to holes in the protections it delivered while on site. The act of migration has introduced vulnerabilities straight out of the gate, and rectifying these flaws is a complex proposition. Managing a cloud-hosted DMZ requires specialised expertise that on-premises security architects often need to possess.
For example, Amazon Web Services (AWS) uses a public resource called Simple Storage Service (S3) to store data in objects rather than files. Since these objects are meaningless outside their S3 bucket, they are considered safe. However, if an attacker gained access to the bucket, they could read or exfiltrate content without the tenant ever knowing. This AWS problem is one of many ongoing issues plaguing multi-tenant cloud setups. Attackers can travel inroads and out-roads in scenarios that would be flagged in on-premises environments but escape the notice of cloud tenants.
Update fate
Remember that every service in the cloud is endowed with its features and controls. Some of these allow external communication that can go unnoticed. Cybersecurity teams must allow each of them and devise ways to monitor each, apply policies, and block each if necessary. This is a mammoth task in a hybrid, multi-cloud environment, and even if the SOC can somehow accomplish it, another challenge pops up.
Updates. Cloud providers “improve” their services steadily, tweaking tools and adding new ones or changing default settings and policies from restrictive to permissive. Let us assume for a moment that the provider informs the tenant of every change promptly. Each addition is still a potential vulnerability. Something somewhere that used to be a security hole but was plugged by the security team may be rendered unsafe again by an update. Also, the team will have to attend to the flaws introduced to new and existing services that the organization does not even use because attackers can still leverage them to gain access. It is staggering how many real-world breaches can be tied back to flaws introduced as part of an update.
It is worth circling back to the on-premises model for some scenario comparison. If an organization had full control over the data center, with a physical DMZ in place and a team that thoroughly understood the inner workings of all OSes and platforms, what would happen at update time? First, neither the CIO nor the CISO would install applications that were unnecessary. Shadow IT notwithstanding, both tech teams would ensure the suite is composed only of useful components. Of course, on-premises data centers suffer from update backlogs, where known vulnerabilities remain unpatched because of a lack of resources and disagreement on priorities.
Your lightbulb moment
What you can’t see can wound you deeply. Tiptoeing around mousetraps is no substitute for replacing the lightbulb. SOCs must gain a broad and deep understanding of the differences between on-prem and cloud operations. Hybrid and multi-cloud have become the norm across the region’s IT setups. This irreversible trend calls for a measured strategy. Allowing each business unit to choose its own cloud without close consultation with IT and the SOC is a recipe for complexity and inevitable catastrophe. Instead, remember that each cloud is associated with risk and workload. Attackers rub their hands with glee at the mousetrap opportunities exposed by cloud-inflated attack surfaces. Do not make their life any easier by wandering around with the light off.
