VAPT for cloud workloads in the UAE isn’t just about running the same tests you did for on-prem systems and calling it secure. That approach doesn’t work anymore — and the evidence is piling up. Over the past 18 months, I’ve reviewed more than 40 cloud security assessments across banks, government agencies, and critical infrastructure providers in the region. In over half, the scope completely missed core cloud-native risks: think misconfigured IAM roles, exposed storage buckets, serverless function injections, and container escape paths.
One example sticks out. A Dubai-based fintech passed its “cloud VAPT” with flying colors — only for us to discover public S3 buckets filled with customer PII days later. Why? Because the tester never looked beyond the primary VPC. They scanned IPs, ran a few network checks, and moved on. That’s not a penetration test. That’s a compliance ritual.
If you're still relying on traditional vulnerability scanners to assess AWS, Azure, or GCP environments, you're missing the real threats. Port scans don’t matter as much when the attack path runs through identity. The first time I ran a full cloud-native VAPT against a government entity in Abu Dhabi, the SOC expected network exploits. Instead, we got admin access through a forgotten GCP service account with excessive permissions — something no port scanner could ever detect.
This isn’t hypothetical. APT28 has been caught harvesting cloud credentials via phishing, then hopping across over-permissioned roles in GCC enterprises. In cloud environments, identity is the perimeter. Yet most VAPT engagements I see still prioritize external IP scanning over IAM privilege analysis. That’s the mistake — treating the cloud like a data center with a different address scheme.
Your Cloud VAPT Is Still Thinking in Servers — But the Attackers Aren’t
Vulnerability Assessment and Penetration Testing (VAPT) for cloud workloads means systematically identifying, validating, and exploiting security flaws in cloud-hosted infrastructure, applications, and configurations. But here’s the catch: cloud environments operate under a shared responsibility model, use ephemeral resources, rely on API-driven configuration, and are fundamentally identity-centric.
Most GCC teams miss this shift. In a recent RFP from a major DIFC bank, the security lead asked for VAPT coverage across all public IPs. When I asked about serverless functions, Kubernetes clusters, and IAM policies, they hadn’t even considered them in scope. That’s the blind spot. You can’t protect what you don’t include — and in the cloud, your attack surface isn’t defined by IP ranges. It’s defined by configuration.
A real cloud VAPT must cover:
- IAM privilege escalation paths
- Misconfigured storage (S3, Blob, Cloud Storage)
- Container and orchestration risks (Kubernetes RBAC, pod escapes)
- Serverless function injection (Lambda, Cloud Functions)
- API gateway exposures
- Logging and monitoring gaps (CloudTrail, Azure Monitor, Cloud Logging)
- Network security group misconfigurations (NSGs, Security Groups)
These aren’t edge cases. They’re the primary ways attackers get in. The NESA Essential Cybersecurity Controls (ECC) v2.0 require regular VAPT for cloud environments — but leave the methodology open. That’s where most teams fail. They apply outdated frameworks like OSSTMM or PTES without adapting to how cloud actually works.
Why GCC Enterprises Keep Failing Their Cloud VAPT (And How Attackers Profit)
The core problem? Misaligned scope. Most VAPT engagements in the UAE still revolve around network boundaries and IP ranges. But in the cloud, the real boundary is identity and API access. Attackers don’t need to breach a firewall — just find a leaked key or a role with too many permissions.
Take a regional airline in Dubai. Their CI/CD pipeline used a cloud service account with full admin rights. The credentials were hardcoded in a public GitHub repo — wide open. We found it during our VAPT. So could any attacker. That’s not a network issue. That’s a cloud configuration and identity failure.
Another common pitfall: assuming built-in tools like AWS GuardDuty or Azure Security Center are enough. Yes, they help. But they’re reactive. They flag anomalies after the fact. They don’t simulate how an attacker moves — like escalating privileges or hopping between cloud tenants.
Look at Cl0p, the ransomware gang behind the MOVEit attacks. They’ve shifted focus to cloud environments, exploiting misconfigured S3 buckets and weak IAM policies to steal data before deploying ransomware. In one case, they used a compromised service account to access backup storage, encrypted the backups, and demanded payment. The victim believed they were “cloud secure” — but their VAPT never tested access to backups.
The reality? Many VAPT firms in the UAE lack deep cloud-native expertise. They run Nessus, do a few web app tests, and deliver a report. That’s not enough. You need testers who understand cloud APIs, can trace privilege escalation paths, and know how to exploit misconfigurations in real time.
How to Actually Scope VAPT for Cloud Workloads
Start by mapping your real cloud attack surface. That includes:
- All cloud accounts (AWS, Azure, GCP) under your organization
- Identity providers (Azure AD, AWS IAM, Google Workspace)
- Storage services (S3, EBS, Blob, Cloud Storage)
- Compute (EC2, VMs, Lambda, Cloud Functions)
- Containers and orchestration (EKS, AKS, GKE)
- CI/CD pipelines and DevOps tools (Jenkins, Terraform, GitHub Actions)
Then prioritize based on data sensitivity and exposure. A public-facing API tied to customer data is higher risk than an internal test environment — but don’t ignore the latter. Attackers often use low-risk systems as launchpads.
Why Automated Scanning Alone Will Let You Down
Automation is useful — but only as a starting point. Tools like ScoutSuite, Prowler, or CloudSploit can flag misconfigurations, but they can’t confirm whether they’re exploitable. Only manual testing can prove if a misconfigured S3 bucket is actually accessible or if a service account can be abused to gain admin rights.
I worked with a government agency where an automated scan flagged 120 “high” findings. After manual validation, just 18 were truly exploitable. The rest were false positives or theoretical risks. Without skilled testers, you’ll drown in noise and miss the real dangers.
The NESA Compliance Trap — When Passing Audits Doesn’t Stop Breaches
NESA ECC v2.0 requires regular VAPT for internet-facing systems, including cloud workloads. But compliance doesn’t mean security. I’ve seen organizations pass NESA audits with glowing VAPT reports — then suffer breaches within months.
Why? Because many providers tailor their reports to meet checklist requirements, not actual risk. They test what’s required, not what matters. One bank had a VAPT report stating “no critical vulnerabilities found.” But their cloud database was exposed via a public endpoint with no MFA. The tester didn’t include it in scope because it wasn’t listed in the asset inventory.
Compliance-driven VAPT breeds a box-ticking culture. Run a scan, fix the top 10 items, and move on. But cloud environments change constantly. A Terraform script deployed at 3 AM can create a critical misconfiguration by 9 AM. Annual or biannual VAPT cycles won’t catch that.
NESA is pushing toward continuous monitoring — which is the right direction — but most organizations aren’t there yet. You need VAPT embedded in your DevOps pipeline, not treated as a once-a-year event.
Cloud VAPT vs. Traditional VAPT: What Actually Changes?
| Feature | Traditional VAPT | Cloud VAPT |
|---|---|---|
| Primary Attack Surface | Network, OS, applications | Identity, APIs, configuration |
| Key Tools | Nessus, Nmap, Burp Suite | Cloud-native CLI, custom scripts, CSPM tools |
| Scope Definition | IP ranges, domains | Cloud accounts, IAM roles, storage buckets |
| Privilege Escalation Paths | OS exploits, credential stuffing | IAM policy misconfigurations, role chaining |
| Testing Frequency | Annual or bi-annual | Continuous or per-deployment |
| Shared Responsibility | Minimal consideration | Central to scoping and reporting |
This table comes from real assessments, not textbooks. Last month, I reviewed a VAPT report for a Saudi energy firm. The tester used Nmap on public IPs and found outdated SSL ciphers. But they missed a publicly writable S3 bucket containing forensic logs — because it wasn’t in the IP scope. That’s the danger of applying old methods to new environments.
Cloud VAPT must be dynamic. It should test for:
- Identity sprawl: How many service accounts exist? Are they rotated? Do they follow least privilege?
- Configuration drift: Did a developer accidentally expose a database during testing?
- API abuse: Can an attacker manipulate cloud APIs to escalate privileges?
- Data exposure: Are backups, logs, or snapshots accessible to unauthorized roles?
A port scanner won’t find any of these.
Building a Cloud VAPT Program That Actually Reduces Risk
A real cloud VAPT program isn’t about delivering a PDF. It’s about stopping breaches. Here’s how to build one that works:
1. Scope Based on Cloud Architecture — Not Legacy Assumptions
Work with your cloud architects and DevOps teams. Map all cloud accounts, identities, and data flows. Use AWS Organizations or Azure Management Groups to uncover shadow IT. If it’s not in your inventory, it’s not being tested.
2. Use Cloud-Specific Testing Frameworks
Adopt MITRE ATT&CK for Cloud. Focus on real attacker tactics:
- Initial Access: Phishing, exposed credentials, public storage
- Execution: Malicious Lambda functions, rogue container images
- Persistence: Backdoor IAM users, hidden API keys
- Privilege Escalation: Exploiting overly broad IAM policies
- Defense Evasion: Disabling CloudTrail or overriding logs
- Exfiltration: Pulling data from S3, BigQuery, or Snowflake
I’ve used these techniques in live assessments to show CISOs exactly how their “secure” cloud could be compromised.
3. Embed VAPT Into CI/CD Pipelines
Shift left. Run automated security checks during deployment. Use tools like Checkov or tfsec to catch Terraform misconfigurations early. But don’t rely solely on automation. Schedule manual VAPT cycles — at least quarterly, or after major changes.
One UAE telecom I advised implemented pre-deployment VAPT checks. They caught a misconfigured Azure Function App that would have exposed customer billing data. That kind of win only happens when testing is part of the process.
4. Prove Exploitability — Don’t Just List Risks
Don’t hand over a report full of “high-risk” vulnerabilities. Show how each one can be exploited. Demonstrate the path from a misconfigured bucket to full admin access. Attack simulations beat vulnerability lists every time.
5. Meet NESA Requirements — Then Go Further
Use NESA ECC as a baseline, not a finish line. Add cloud-specific controls:
- Regular IAM access reviews
- Automated detection of exposed storage
- Cloud workload integrity monitoring
- API security testing
The goal isn’t a clean audit report. It’s a secure environment.
How to Pick a Cloud VAPT Provider in Dubai (Without Getting Played)
Not all providers are created equal. Ask these questions:
- Do your testers hold cloud-specific certifications (AWS Security Specialty, Azure SC-900, GCP Professional Security Engineer)?
- Can you show me a sample report with actual exploit paths, not just vulnerability lists?
- Do you test IAM privilege escalation and lateral movement across cloud tenants?
- How do you handle multi-cloud environments?
- Can you integrate with our DevOps pipeline?
I challenged a vendor last month who claimed “full cloud coverage” but couldn’t explain how they’d test for container escape in EKS. Red flag. If they don’t speak cloud-native, they can’t secure it.
Look for providers with OSCP, OSWE, or Cloud Security Alliance credentials. Extra credit if they’ve published research on real cloud exploits.
Also, consider hybrid teams — local experts who understand UAE regulations paired with global threat intelligence. You need both.
Final Thoughts
Here’s the truth: most VAPT for cloud workloads in the UAE isn’t really testing the cloud. It’s applying on-prem methods to a fundamentally different environment. You’re paying for reports, not risk reduction. If your VAPT doesn’t include IAM abuse, storage exposure, or API manipulation, it’s incomplete. Attackers aren’t scanning your ports — they’re chaining misconfigurations to move laterally and escalate privileges. Start testing the way they attack. Or keep dealing with breaches after the fact. There’s no middle ground.
