- Most cloud incidents trace back to misconfiguration, not zero-days: public storage, excess IAM permissions, disabled or ignored logging
- The shared responsibility model splits the work between provider and customer, and the split is exactly where organisations get confused
- Assessors expect you to produce working access logs and encryption evidence, not just a policy document
- Continuous configuration scanning catches the drift that a once-a-year audit misses entirely
Why cloud incidents are mostly configuration failures, not exploits
A public cloud platform is not inherently weaker than a data centre you own. What changes is who is responsible for what, and how fast a mistake becomes visible. Internet-wide scanners index newly created storage endpoints and exposed management ports within hours, sometimes minutes. An attacker does not need a zero-day when a bucket, a database, or an admin console is reachable with no authentication at all. Across the incidents that get discussed openly in the region, the pattern repeats: an object storage container set to public read, a service account with permissions nobody ever scoped down, a virtual machine with a management port open to any address. None of this requires skill to exploit. It requires someone to notice it before an outsider does.
The shared responsibility model, and where it breaks down
AWS, Azure and Google Cloud each secure the physical infrastructure, the hypervisor, and the managed control plane. The customer secures everything built on top: identity configuration, network rules, data classification, encryption keys, and what gets exposed publicly. Providers publish this split clearly, but organisations still treat "we are on a major cloud platform" as equivalent to "our data is secure." It is not. A hyperscaler patching its own infrastructure does nothing for a storage bucket an engineer set to public during a rushed deployment and never revisited.
Where cloud environments actually fail
Storage left open by default or by habit
Object storage services are usually private by default now, which is progress, but defaults get overridden constantly: a developer needs to share a file quickly, sets a bucket to public, and forgets to revert it once the deadline passes. KYC documents, backup exports, and log archives are the categories that show up in these incidents most often, because they are large, infrequently reviewed, and easy to forget about once the project that created them ends.
Identity: excess privilege that nobody prunes
Cloud IAM is additive by design. It is easy to grant a role broad permissions to unblock a project and hard to remember to revoke them once the project ships. The result is service accounts and users holding administrator-level access for workloads that need read access to one folder. When credentials leak, whether through a phished user or a hardcoded key in a repository, the blast radius is set entirely by how much access that identity was carrying, not by how the attacker got in.
Logging that technically exists but nobody reads
Most cloud platforms log everything by default now. Fewer organisations route those logs anywhere useful, keep them long enough to matter, or alert on the events that indicate a bucket was made public or a permission boundary was widened. Logging without alerting is an audit trail you discover after the fact, not a control.
What regulators actually expect
NESA's framework addresses encryption of data at rest and in transit, role-based access control, and retention of audit logs, and assessors expect evidence of each, not a policy that describes them. None of that cares what the marketing material for your cloud provider says. Assessors ask for evidence: show the access control list, show the encryption configuration, show the log retention setting, show the last time someone reviewed either. A policy document with no corresponding configuration is not evidence.
Controls that actually reduce risk
Continuous configuration monitoring
A cloud environment drifts. Someone opens a port for a debugging session and forgets to close it. Someone adds a permission to unblock a deploy on a Friday. A one-time assessment catches the state of the environment on the day it ran and nothing after. Continuous posture monitoring, whether through the cloud provider's native tooling or a dedicated platform such as Microsoft Defender for Cloud, flags that drift as it happens instead of at the next audit cycle.
Identity: least privilege as a default, not a project
Start every new role or service account with the minimum permission set the workload needs, then expand only when something breaks. This is slower up front and considerably cheaper than discovering six months later that a compromised token had organisation-wide access. Identity platforms like Microsoft Entra ID support conditional access and just-in-time privilege elevation, but the tooling only helps if someone owns the process of reviewing and pruning access on a schedule.
Encryption and key management as a baseline, not a feature to enable later
Encryption at rest and in transit should be the default for every workload handling regulated data, and key management should sit somewhere the cloud administrator's own compromised credentials cannot reach unilaterally. Customer-managed keys are more operational overhead than provider-managed keys. For data in scope of NESA obligations, that overhead is usually the point.
What a cloud security assessment actually checks
A cloud-focused penetration test or configuration review is not the same exercise as a network VAPT engagement, though the two overlap. It looks at storage permissions, IAM policy attachments, network security group rules, exposed management interfaces, and whether logging and alerting actually fire when a control is bypassed. Structured VAPT against cloud assets finds the specific bucket, role or security group that is wrong today, which a generic compliance checklist will not surface. This piece on cloud VAPT and S3-style bucket risk goes into how that testing actually finds exposed storage before an external scanner does.
Common questions
Is a data breach the biggest cloud security risk in the UAE?
Data exposure is the most common outcome, but the root cause is almost always one of three things: a misconfigured permission, an overprivileged identity, or logging nobody watches. Treat those three as the risk, and data breach as the symptom.
Does security awareness training actually reduce cloud risk?
Only when it is specific. Generic annual training that covers phishing in the abstract does little. Training that walks staff through what a public storage alert looks like, how to verify a suspicious login prompt, and who to contact when something looks wrong changes behaviour because it maps to decisions people actually face.
Is multi-factor authentication enough to stop cloud account compromise?
MFA closes the most common path in, credential phishing, but it does not fix an overprivileged role or a public bucket. It reduces the odds of an attacker getting a foothold; it does nothing for what that foothold can reach once they are inside.
A short checklist for a cloud security review
Confirm every internet-facing storage endpoint has explicit access controls, not default settings. Pull a report of every identity with administrator-equivalent access and justify each one. Confirm logging is enabled, routed to a location someone actually monitors, and alerts on permission and exposure changes. Confirm encryption keys for regulated data are customer-managed where the obligation calls for it. Then repeat this review on a schedule, because none of it stays true by itself.
