When I was preparing for the Certified Cloud Security Professional exam, the Cloud Security Alliance Treacherous 12 kept showing up as one of those frameworks that sounds simple until you try to apply it to a real cloud. The Treacherous 12 is memorable because it puts cloud risks like data breaches, weak identity, insecure APIs, account hijacking, data loss, and shared technology vulnerabilities into plain language, but the real learning starts when we ask: how do we defend an Oracle Cloud Infrastructure (OCI) tenancy against these threats? [1]
That question is also central to my work as a Cloud Security Architect. It also connects to my own development as I pursue a master’s degree in cybersecurity, with a long-term aspiration to serve as a CISO. That leadership lens changes how I think about tenancy design. The goal is not simply to enable controls, but help customers reduce business risk, limit blast radius, support recovery, produce evidence, and build a security posture.
For customer engagements, that means helping organizations set up their OCI tenancies correctly from the beginning: identity, compartments, network segmentation, logging, detection, data protection, backup, recovery, and governance. Through Oracle’s Maturity Acceleration Program, this work becomes more than a checklist. It becomes a structured way to help customers understand where they are today, what risks matter most, and which design decisions will help reduce blast radius over time.
The Oracle CISO Perspectives and A-Team material reinforces the same pattern we use with customers every day: start with an OCI Landing Zone architecture, adapt it to the customer’s security requirements and operating model, and establish the right tenancy foundation before production workloads arrive. Identity, compartments, network segmentation, logging, monitoring, alerting, data protection, backup, recovery, and governance should be designed into the tenancy from the start, not added later after workloads are already running. These guardrails determine how well the tenancy can withstand the Treacherous 12. [2], [3], [4], [5], [9], [15], [52]
This series connects the CSA Treacherous 12 to the real decisions that shape an OCI tenancy: identity design, compartment structure, network segmentation, security logging and monitoring, data protection, and recovery. Logs should not simply exist somewhere in the tenancy. They need to be enabled, collected, retained, and monitored through the customer’s enterprise SIEM or, where that integration is not available, through OCI Logging Analytics. [1], [7], [48], [49], [50], [51]
The Treacherous 12 in plain English
The CSA Treacherous 12 was published as a cloud-specific threat taxonomy. Even though CSA has since continued the Top Threats research stream, the Treacherous 12 gives OCI customers a practical lens for asking which risks are reduced by Oracle’s platform architecture and which risks depend on tenancy design, configuration, and operations. When we design an OCI tenancy, that principle becomes practical through workload segregation, separation of duties, compartment boundaries, and network segmentation. Oracle reduces certain risks through the way OCI is built and operated, but many controls are shaped by how the tenancy is configured: who has access, which workloads can communicate, where sensitive data is stored, how security logs are enabled and monitored, and how backup and recovery paths are protected. [1], [2], [13], [25], [26]
- Data breaches
- Insufficient identity, credential, and access management
- Insecure interfaces and APIs
- System vulnerabilities
- Account hijacking
- Malicious insiders
- Advanced persistent threats
- Data loss
- Insufficient due diligence
- Abuse and nefarious use of cloud services
- Denial of service
- Shared technology vulnerabilities [1]
The Treacherous 12 bring the right OCI tenancy decisions into focus before workloads arrive. This is not about memorizing services or following a generic checklist. It is about understanding the defensive pattern: what Oracle builds into the platform, what customers must design into their tenancy from the start, and what needs to be monitored, validated, and operated continuously after workloads go live. [1], [2], [3], [13], [25], [26]
Blog 1: Start with the shared responsibility line
The easiest way to misunderstand cloud security is to treat the shared responsibility model as a diagram you acknowledge once and then forget. In practice, it is the map that tells you where to spend your time. Oracle secures the underlying cloud: facilities, hardware, service enclaves, control-plane protections, and the security architecture of OCI itself. You secure what you deploy: identities, policies, network paths, workloads, data protection, monitoring, and response. [2], [13], [25], [26]
This distinction is not academic. It keeps you from solving the wrong problem. You should understand OCI’s infrastructure protections because they directly reduce risks like shared technology vulnerabilities and some advanced persistent threat paths. But you should also be honest about the parts Oracle cannot do for you: whether your administrators use MFA, whether a storage admin can delete backups, whether a bucket is public, whether your logs leave the tenancy, or whether your recovery process has ever been tested. [2], [6], [13], [25], [26], [29], [40], [44], [48]
Figure 1: Shared responsibility framing for the Treacherous 12 in OCI.
What Oracle handles before you configure a single policy
Oracle’s CISO security executive overview makes a point that is easy to miss: OCI security is not only a set of optional services. Several protections are architectural. Hardware root of trust, off-box network virtualization, tenant isolation, and always-on encryption are designed into the platform so that the baseline is stronger before a customer starts configuring workloads. [2], [13], [26]
Hardware root of trust matters because firmware-level compromise is a different class of problem from a normal operating system vulnerability. If the host below your workload cannot be trusted, everything above it becomes questionable. Oracle’s published architecture describes a process intended to establish a known-good hardware foundation when servers are provisioned. From a Treacherous 12 perspective, that reduces exposure to system vulnerabilities and deeper infrastructure persistence techniques. [1], [2]
Off-box network virtualization is the design decision I find most important. In many virtualized environments, the hypervisor carries a lot of responsibility. It launches VMs, allocates resources, and may participate heavily in network virtualization. That concentration creates a tempting target. OCI moves network virtualization away from the host hypervisor and onto isolated SmartNIC-based hardware. The practical result is that a compromised workload does not automatically inherit the ability to manipulate the network control plane. That is a direct answer to shared technology risk and lateral movement risk. [1], [2]
Always-on encryption and tenant isolation round out the foundation. Data at rest is encrypted by default, public APIs use HTTPS, and OCI’s control-plane separation is designed to keep tenants isolated from each other and from Oracle staff access to customer workloads. Those controls do not eliminate your responsibility to classify data, manage keys, or control access. They give you a stronger starting point. [2], [13], [25], [26]
Shared responsibility reminder: Provider-side controls reduce the baseline risk. They do not replace tenancy design. The mistake is either ignoring the platform architecture or assuming it protects every customer-side decision automatically. [2], [25], [26]
Identity is the first control plane
Insufficient IAM controls, account hijacking, and malicious insider risk all converge at the identity layer. In CSA terms, this maps to insufficient identity, credential, and access management. In OCI tenancy design, the practical question is how users, groups, identity domains, policies, credentials, and privileged access are governed. Identity is not simply how users sign in; it is how authority is granted across the tenancy. It determines who can create networks, expose services, access data, rotate keys, delete storage, modify policies, and change logging. If IAM controls are over-permissive or poorly governed, the blast radius of every other threat grows. [1], [27], [28], [29], [39]
The Oracle CISO ransomware guidance recommends a pattern that should become normal practice: break-glass tenancy administrators. Keep a very small number of highly protected accounts for emergency tenancy administration. For most customers, one or two local break-glass accounts is a practical range: one is the minimum, and two provides resilience if one credential, MFA method, or recovery path is unavailable. These accounts should not be federated, should not be used for routine work, and should be protected with strong MFA, such as a FIDO security key, hardware security key, or tightly controlled authenticator app. The MFA factor should not depend on a single employee’s personal device. For higher assurance, separate custody of the password and MFA device so that emergency access requires an approved process, not one person acting alone. [6], [29], [30], [31], [32], [33], [34]
Daily operations should happen through federated, role-based accounts with scoped permissions. The admin who manages storage should not automatically be able to delete protected backups. The network team should not automatically manage databases. The DBA team should not automatically change identity policy. This separation of duties limits blast radius and makes privileged access easier to monitor, review, and revoke. [15], [24], [27], [28], [29], [32]
MFA should be mandatory, whether it is enforced through the enterprise identity provider or directly in OCI. For day-to-day administration, the stronger pattern is to integrate OCI with the enterprise identity provider, enforce MFA, and manage users and groups through the central identity lifecycle. Federation and SCIM matter because OCI access should follow enterprise access governance. When someone joins, changes roles, transfers teams, or leaves the company, their cloud access should change with them, not depend on a separate manual cleanup step. [27], [29], [32], [34], [35], [36], [37]
Least privilege in OCI is powerful because IAM policy language is readable, but that readability can create a false sense of safety. A broad policy that allows a group to manage all resources in a tenancy is still broad, even if it is easy to read. Administrators should design groups around operating roles, scope policies to the right compartments, and periodically review effective permissions. As the tenancy grows, the hard question is rarely, “What does this one policy say?” The harder question is, “Who effectively has what access after policies, groups, dynamic groups, compartments, and user memberships are considered together?” Policy analysis can help administrators reason about that combined view, while Oracle Access Governance can help turn access review into an ongoing governance cycle through certifications, access reviews, and orphan account detection. For mature environments, deny policies can add hard guardrails for sensitive actions, but they should be used carefully. They are not a replacement for least privilege; they are a way to explicitly block access paths that should remain prohibited even when broad permissions exist elsewhere. [17], [18], [28], [35], [36], [37], [38], [39]
Policy design principle: One hardening idea from the ransomware guidance is to allow storage administrators to manage buckets while excluding DELETE permission for protected backup paths. The exact policy depends on your tenancy, but the principle is universal: routine admins should not be able to destroy the recovery path. [6], [28], [38], [39], [45]
Data protection is where breach and loss meet
The Treacherous 12 separates data breaches from data loss. In real incidents, the two often arrive together. Ransomware-style attacks are a good example: the attacker wants to make data unavailable, may exfiltrate it, and then tries to destroy or corrupt backups so recovery becomes a negotiation instead of a procedure. [1], [6], [7], [8]
Oracle’s CISO cyber-resilience series is useful because it frames ransomware defense as Protect, Detect, and Recover. Protect reduces the chance and blast radius of compromise. Detect shortens dwell time. Recover gives you confidence that you can restore from backups the attacker could not reach. That last phrase is the important one. Backup is not enough if the same compromised identity can delete the backup. [6], [7], [8], [45], [46], [47]
For structured data, Oracle-managed backup and recovery services can provide important isolation patterns. For object storage and unstructured backup copies, versioning, retention rules, and immutability controls help turn a destructive delete into a recoverable event. For the highest-value recovery copies, separate the recovery path from the production path. Oracle’s cyber-resilience architecture frames this through Vault enclave and Safe Restore enclave patterns: immutable storage, restrictive IAM, specialized recovery accounts, private buckets, logging, and Cloud Guard or Security Zone controls that help protect recovery data from accidental exposure, unauthorized change, or destructive activity during an incident. [8], [44], [45], [46], [47]
Figure 2: Vault enclave / Safe Restore enclave pattern for protecting the recovery path from compromised production credentials. Author-created diagram based on Oracle Architecture Center cyber-resilience guidance for Vault enclave and Safe Restore enclave patterns. [45], [46]
Security Zones are worth highlighting because they move selected controls from detection to prevention. Cloud Guard can detect risky configurations and surface findings, but a Security Zone policy can stop certain actions from succeeding in the first place. For example, OCI Security Zones can deny operations that would violate the assigned security zone recipe, including creating or modifying an Object Storage bucket so that it becomes public. For sensitive compartments, the Oracle-managed Maximum Security Recipe or a carefully designed custom recipe can reduce the number of security-critical decisions that depend on individual perfection. That matters for data breach and data loss scenarios, where preventing a risky configuration is stronger than discovering it after the fact. [40], [41], [42], [43], [44]
A practical ending for Blog 1
If you only take three actions from Part 1, make them these: understand what OCI already secures below the tenancy, clean up identity before you scale, and protect backups as a separate security domain. That combination does not solve every Treacherous 12 risk, but it changes the economics of an attack. An attacker who gets one password should not get the whole tenancy. An admin mistake should not expose critical data. A ransomware actor should not be able to delete the only path back to business. [1], [2], [6], [8], [25], [26], [29], [40], [45], [46]
That reading path starts with the threat model and the shared-security boundary. The CSA Treacherous 12 gives us the cloud-risk lens, but Oracle’s Shared Security Model and OCI Security Overview help translate that lens into responsibility: Oracle secures the underlying cloud infrastructure and operations, while customers are responsible for how workloads, identities, networks, data, logging, and recovery are designed and operated inside the tenancy. The Oracle Field CISO overview of OCI security is a strong companion read because it explains the security-first platform design that sits below the customer tenancy, including defense in depth, isolated network virtualization, and hardware root of trust. [1], [2], [25], [26]
The second action is identity. Before a tenancy scales, customers should review identity domains, federation, MFA, group design, compartment-scoped policies, break-glass access, and effective permissions. The A-Team material on OCI tenancy security best practices, IAM Identity Domains, and IAM policy best practices is useful here because it moves the discussion from “enable IAM” to “design an access model that limits blast radius.” The IAM best-practices whitepaper, break-glass guidance, OCI Policy Analysis blog, and Oracle Access Governance material extend that same idea into emergency access, policy review, access certification, and ongoing governance. Deny policies can also be considered for mature environments, but only as carefully tested guardrails layered on top of least-privilege design, not as a replacement for it. [3], [27], [28], [29], [30], [31], [32], [35], [36], [37], [38]
The third action is recovery. The CISO Perspectives ransomware articles are the right follow-up for the protect-detect-recover mindset: reduce the likelihood of a successful attack, detect signs of malicious activity, and plan recovery for ransomware-style threats. Oracle’s cyber-resilience architecture then makes the recovery-domain concept more concrete through Vault enclave and Safe Restore enclave patterns, including separate administrative boundaries, immutable storage, restrictive IAM, locked retention rules, and controls that help prevent backup and recovery services from being weakened or disabled. For database-heavy environments, the Oracle MAA ransomware-resiliency blog is a useful companion because it focuses on protecting and recovering Oracle databases. [6], [7], [8], [45], [46], [47]
The “admin mistake should not expose critical data” point is where preventive controls belong in the story. Security Zones and the Oracle-managed Maximum Security Recipe are worth reading alongside the A-Team custom Security Zones article because they show how some risky actions can be denied at create or update time, such as creating a public Object Storage bucket in a protected compartment. That is stronger than relying only on after-the-fact detection, especially for sensitive data compartments. [40], [41], [42], [43], [44]
Finally, none of this works well without monitoring. Security logs need to be enabled, centralized, retained, and actively reviewed through the customer’s enterprise SIEM or, when that integration is not available, OCI Logging Analytics. The A-Team Logging Analytics security dashboards article fits naturally here because it focuses on security-related OCI logs, triage, detection, and investigation for customers who need native OCI visibility. [7], [48], [49], [50], [51]
Sources and further reading
This article draws from public Oracle CISO Perspectives, A-Team Chronicles, Oracle documentation, OCI Architecture Center guidance, Oracle Cloud Infrastructure blog posts, GitHub reference assets, and Cloud Security Alliance research. The bracketed source numbers in the body are clickable links to the corresponding source pages. Source titles below are also clickable.
1. [1] Cloud Security Alliance — The Treacherous Twelve: Cloud Computing Top Threats in 2016 — Original threat taxonomy used as the organizing framework.
2. [2] Oracle A-Team — CISO Perspectives: Oracle Cloud Infrastructure Security Executive Overview — OCI security foundations, security-first architecture, platform-level protections, isolation, encryption, and trust boundary context.
3. [3] Oracle A-Team — OCI Tenancy Security Best Practices Guide: Overview — Tenancy security control areas, CIS alignment, and security posture overview.
4. [4] Oracle A-Team — Security Best Practices Guide for New OCI Tenancy — New tenancy workflow: learn, plan, execute, test, and verify.
5. [5] Oracle A-Team — Security Best Practices Guide for Existing OCI Tenancy — Existing tenancy workflow: discover, assess, remediate, and monitor for drift.
6. [6] Oracle A-Team — CISO Perspectives: Protecting your OCI Tenancy Against Ransomware Attacks — Protect-stage controls, compartment design, break-glass administration, least privilege, MFA, ransomware attack profile, and blast-radius reduction.
7. [7] Oracle A-Team — CISO Perspectives: Detecting Malicious Activity and Signs of an Attack Against your OCI Tenancy — Detection-stage controls, OCI Logging, Audit logs, service logs, VCN Flow Logs, Cloud Guard, SIEM export, and OCI Logging Analytics.
8. [8] Oracle A-Team — CISO Perspectives: Advanced Cyber-Resilience in OCI — Recovery from Ransomware Style Threats — Recovery-stage thinking, data integrity threats, cyber-resilient backup and recovery, separation of duties, immutable vaulting, clean rooms, and safe restoration environments.
9. [9] Oracle A-Team — CISO Perspectives: Using the Oracle Cloud Infrastructure OCI CIS Landing Zone for Security & Compliance — Landing-zone and CIS benchmark mapping for compliance outcomes.
10. [10] Oracle A-Team — Understanding OCI Services to Meet Regulatory Compliance: A CISO Perspective on Aligning Cloud Security Architecture with Compliance Outcomes — Compliance as designed, implemented, monitored, and continuously validated control outcomes.
11. [11] Oracle A-Team — CISO Perspectives: Security and the AI Shared Responsibility Model — Related CISO perspective extending shared responsibility thinking into AI workloads.
12. [12] Oracle A-Team — Oracle CISO Perspective: Mythos, GPT 5.5-Cyber, and the CISO’s New Threat Model — Related CISO perspective on machine-speed vulnerability discovery and attack-chain compression.
13. [13] Oracle Docs — Oracle Cloud Infrastructure Security Guide — Core OCI security service and best-practice documentation.
14. [14] Oracle Architecture Center — Learn About Cyber Resilient Architectures that Protect Data from Ransomware — Cyber triad, ransomware recovery framing, Protect/Detect and Respond/Recover concepts, and cyber-resilience architecture context.
15. [15] Oracle Architecture Center — Deploy a Secure Landing Zone That Meets the CIS OCI Foundations Benchmark — Terraform-based CIS-aligned landing zone reference architecture, including compartments, groups, policies, and segregation of duties.
16. [16] Oracle Cloud Infrastructure Blog — Boost your OCI Security for Free with Easy CIS Resources — OCI Security Health Check, Cloud Guard, CIS benchmark assessment cadence, and practical CIS posture review.
17. [17] Oracle Cloud Infrastructure Blog — OCI Policy Analysis: Tool Overview — Unofficial OCI policy analysis tool for reviewing IAM policies, dynamic groups, user permissions, and effective access across compartments and users.
18. [18] Oracle Cloud Infrastructure Blog — OCI Policy Analysis: Strategy and Development Insights — Development background and effective-permission analysis concepts for growing OCI environments.
19. [19] Oracle Docs — Overview of Zero Trust Packet Routing — ZPR concepts, security attributes, intent-based policies, enforcement model, and relationship to existing network security controls.
20. [20] Oracle Cloud Infrastructure Blog — Introducing Zero Trust Packet Routing with Cross-VCN Support — Cross-VCN policy support and unified intent-based network security across OCI networks.
21. [21] Oracle Security — OCI Zero Trust Packet Routing — Product overview for ZPR, intent-driven network security, and data-exfiltration protection through approved communication paths.
22. [22] Oracle Cloud Infrastructure Blog — First Principles: Robust Data Breach Protection with Zero Trust Packet Routing — Conceptual background for ZPR and separation of network security intent from network topology.
23. [23] GitHub — OCI Security Health Check Standard Edition — Security Health Check README and current CIS OCI Foundations Benchmark support.
24. [24] GitHub — OCI Core Landing Zone — Terraform modules for deploying a standardized CIS-aligned OCI foundation with compartments, groups, and IAM policies for segregation of duties.
25. [25] Oracle Docs — Shared Security Model — Shared responsibility framing: Oracle secures cloud infrastructure and operations; customers secure workloads, VCNs, IAM, data, applications, and governance inside the tenancy.
26. [26] Oracle Docs — Security Overview — OCI security pillars and the distinction between Oracle-managed platform security and customer-managed workload security.
27. [27] Oracle A-Team — OCI IAM Identity Domains Best Practices — Identity-domain design, federation, administrator minimization, and lifecycle considerations.
28. [28] Oracle A-Team — OCI IAM Policies Best Practices — Least-privilege IAM policy design and the importance of getting IAM policy structure right.
29. [29] Oracle Docs Whitepaper — Best Practices for Identity and Access Management in OCI — IAM planning, compartments and identity domains, default-domain admin considerations, MFA, federation, least privilege, and break-glass account guidance.
30. [30] Oracle A-Team — Securing OCI Break Glass Accounts: Best Practices — Practical break-glass recommendations: dedicated local IAM user, strong MFA, separate password and MFA custodians, monitoring, alerting, testing, and credential rotation.
31. [31] Oracle A-Team — OCI Break-Glass from an OCI Point of View — Break-glass access as an exception to normal least-privilege and separation-of-duties operations.
32. [32] Oracle Architecture Center — Manage Identities and Authorization Policies — MFA, federation, service-level administrators, emergency user persona, one or more break-glass accounts, and monitoring administrator activity.
33. [33] Oracle Docs — Configuring FIDO Authenticator — FIDO MFA configuration using external devices such as YubiKey or internal authenticators such as Windows Hello and Mac Touch ID.
34. [34] Oracle Docs — Identity Domains with the Security Policy for OCI Console Sign-On Policy — OCI Console MFA policy, administrator MFA, all-user MFA, FIDO, mobile app passcode, mobile app notification, and bypass-code considerations.
35. [35] Oracle Docs — Access Governance — Oracle Access Governance overview for access visibility, access provisioning, permission analysis, policy management, anomaly identification, and remediation.
36. [36] Oracle Docs — Configure Integration Between Oracle Access Governance and OCI IAM — Integrating Oracle Access Governance with OCI IAM as an authoritative source and managed system, including OCI IAM groups, application roles, policy certification, and group-membership certification.
37. [37] Oracle Docs — Certify Group Memberships with Identity Collections Review Campaigns — One-time or periodic group membership certification campaigns for OCI and Oracle Access Governance systems.
38. [38] Oracle Docs — Deny Policies — OCI IAM deny policies as an opt-in feature, explicit deny behavior, precedence over allow policies, administrator exemptions, and operational caution.
39. [39] Oracle Docs — IAM Policies Overview — OCI IAM policy syntax, including subject, verb, resource, location, and conditional policy structure.
40. [40] Oracle Docs — Overview of Security Zones — Security Zones, recipes, Maximum Security Recipe, operation denial when a recipe policy is violated, public-bucket prevention, and Cloud Guard integration.
41. [41] Oracle Docs — Security Zone Policies — Security Zone policy categories and enforcement behavior for resources in protected compartments.
42. [42] Oracle Docs — Managing Recipes in Security Zones — Custom recipes and recipe management for Security Zones.
43. [43] Oracle A-Team — Safeguard Your Tenancy With Custom Security Zones — Custom Security Zones as preventive controls that stop weak configurations from being created.
44. [44] Oracle Docs — Object Storage Buckets — Public bucket behavior, anonymous unauthenticated access, and caution around enabling public access.
45. [45] Oracle Architecture Center — Incorporate Cyber Resilience Capabilities into your OCI Tenancy: Plan — Vault enclave and Safe Restore enclave planning, nested compartment or separate tenancy, retention rules, locked retention, restricted access, Cloud Guard, and Security Zones for backup protection.
46. [46] Oracle Architecture Center — Learn About Cyber Resilience Pillar in OCI — Production enclave, OCI Vault enclave, Safe Restore enclave, immutable backups, administrative air gaps, separate identity domains or tenancy boundaries, and recovery testing.
47. [47] Oracle MAA Blog — Ransomware Resiliency: Defending and Recovering Oracle Databases from Ransomware — Database-focused ransomware defense and recovery guidance.
48. [48] Oracle Architecture Center — Aggregate Oracle Cloud Infrastructure Service Logs Using Third-Party SIEMs — Centralizing OCI Audit logs, service logs, and security events into enterprise SIEM platforms for monitoring and securing OCI tenancies.
49. [49] Oracle Docs — Logging and Logging Analytics Strategy — Audit logs, service logs, custom logs, VCN Flow Logs, and OCI logging strategy.
50. [50] Oracle A-Team — Security Fundamentals Dashboards using OCI Logging Analytics — OCI Logging Analytics dashboards for customers without a dedicated SIEM, including identity, network, and security operations monitoring.
51. [51] Oracle Cloud Infrastructure Blog — Oracle Cloud Infrastructure Security Fundamentals Dashboards using OCI Logging Analytics — OCI Logging Analytics for security-event aggregation, near-real-time monitoring, alerting, triage, and investigation.
52. [52] Oracle Docs — OCI Core Landing Zone — OCI Core Landing Zone as a secure, scalable environment based on OCI reference architecture for landing business-critical workloads.