In Part 1, we established the security foundation for defending an OCI tenancy against the Treacherous 12. We showed how shared responsibility, OCI platform protections, identity, least privilege, break-glass access, and protected recovery work together to reduce blast radius and build resilience into the tenancy from the start. Together, these controls help answer an important question: who can make critical changes to the tenancy, and can the business recover if those controls fail?

In this blog, we build on that foundation by asking the next question: if an attacker gains a foothold, how far can they move, what can they reach, and how quickly would we know?

The focus on movement and visibility connects directly to several Treacherous 12 risks: insecure interfaces and APIs, advanced persistent threats, denial of service, account hijacking, malicious insiders, and abuse of cloud services. These threats are different on paper, but in a real tenancy they often converge around the same design choices: network segmentation, governed entry points, egress control, API exposure, logging, Cloud Guard, SIEM integration, and response workflows. [1], [7], [19], [20], [48], [49], [50], [51]

The design principle is simple: if an identity or workload is compromised, the attacker should not automatically gain a path to other applications, databases, sensitive data, administrative services, or recovery resources. Network segmentation and access controls should limit how far the compromise can spread, while logging and detection should make suspicious behavior visible before a small incident becomes a large one.

Network segmentation is a blast-radius control

Connectivity is an essential part of any business solution. Applications need to reach databases, on-premises environments need to connect to OCI, and users need access to the services they depend on. But connectivity without security in the design is not enough. The network must enable the business while also controlling which systems can communicate and limiting how far a compromised workload can reach. Network architecture therefore serves both the business need for connectivity and the security need to limit blast radius.

When we design an OCI tenancy, workload segregation should show up in multiple places: compartments, VCNs, subnets, routing, network security groups, firewall placement, DNS design, and logging. Production and non-production should not be casually reachable from each other. Shared services should not become a flat transit path to every workload. Administrative access should not reuse the same path as application traffic. Sensitive databases should not sit behind rules that were created for convenience and never revisited.

A hub-and-spoke model is useful because it gives the tenancy a place to centralize shared controls. The hub can carry inspection, egress control, DNS, connectivity to on-premises, and security tooling. Spokes can isolate application environments, business units, or sensitivity levels. A hub-and-spoke model is not a requirement for every tenancy; the broader objective is to avoid accidental flatness. Oracle networking guidance describes hub-and-spoke as a recommended architecture for many OCI deployments because it supports centralized firewalls, traffic inspection, management nodes, and east-west inspection between VCNs. [53]

Several Treacherous 12 threats can lead to the same problem: an attacker gains an initial foothold and attempts to move toward more valuable resources. Whether the foothold comes from a compromised account, an insecure API, or an exploited workload, network segmentation helps limit how far the attacker can go. The next question becomes: what other resources can the compromised workload reach, and does it actually need access to them?

Use NSGs to keep network intent close to the workload

Security lists still exist, but network security groups usually express workload intent more cleanly. A subnet-level security list can become a broad rule bucket over time. An NSG can be aligned to a role: web tier, app tier, database tier, integration tier, administrative access, or backup path.

One advantage of using NSGs is that network access can be expressed in terms that are easier for security and application teams to understand and review. A rule that clearly states the app tier can reach the database tier on the required port is easier to review than deriving the same intent from a long subnet rule set that has accumulated over several years. OCI documentation describes NSGs as a way to apply security rules to a set of VNICs, and also notes that Zero Trust Packet Routing (ZPR) can be used with or in place of NSGs for managing network access to OCI resources. [54]

Network rules should not become a dumping ground for exceptions. Each rule should have an owner, a purpose, and an expected lifetime. A rule created for a temporary application requirement and never revisited is configuration drift, not security design.

ZPR helps separate security intent from network topology

Traditional network security relies heavily on IP addresses, route tables, and firewall rules. These controls remain important, but expressing and maintaining security intent through network topology alone can become increasingly complex as applications span compartments, VCNs, clusters, and regions. Zero Trust Packet Routing (ZPR) adds another way to define which resources should be allowed to communicate, based on security attributes and policies rather than relying only on network location.

ZPR lets teams express communication intent using security attributes and policies. Instead of only asking whether one CIDR can reach another CIDR, the design can ask whether a resource with one security attribute is allowed to communicate with a resource with another security attribute. Oracle’s ZPR material describes this as intent-based network security, and the cross-VCN support announcement explains that ZPR can help define and enforce consistent trust boundaries across VCNs through human-readable policies. [19], [20], [21], [22]

ZPR’s intent-based approach can help reduce unintended connectivity that an attacker could use for lateral movement. A database should not be reachable simply because a network route exists, and a sensitive service should not be accessible merely because it shares a network path with less sensitive workloads. ZPR does not replace good VCN design, NSGs, routing, or inspection; it complements these controls with a policy layer that explicitly defines which resources are allowed to communicate.

For customers, a practical way to think about ZPR is that network topology enables connectivity, while security intent determines which communication should actually be allowed.

Insecure interfaces and APIs are not only an application problem

The Treacherous 12 calls out insecure interfaces and APIs because cloud environments are API-driven by design. In OCI, that includes the OCI control plane, customer applications, integration endpoints, API Gateway deployments, Functions, Kubernetes services, load balancers, and custom applications exposed to partners or users.

API security is not only an application team concern. API exposure is also a tenancy design decision. Where is the API exposed? Is it public or private? Is TLS enforced? Is authentication centralized? Are authorization decisions explicit? Are request limits applied? Are logs enabled? Can API activity be correlated with identity activity and network activity?

OCI API Gateway can provide governed HTTP/S interfaces for services such as OCI Functions, OKE, and other back ends, and Oracle documentation describes policy enforcement capabilities such as authentication and rate limiting. [55] OCI WAF protects applications from malicious and unwanted internet traffic and can be attached to enforcement points such as load balancers or web application domain names. [56]

OCI API Gateway and OCI WAF provide a more controlled way to expose applications and APIs. Public endpoints should be placed behind the appropriate security and API management controls rather than exposed directly when a governed entry point is available. Use API Gateway where API mediation, authentication, authorization, request validation, rate limiting, and logging are needed. Place public applications behind WAF, and use private endpoints and private routing when an API does not need to be accessible from the public internet. Keep the entire API path visible through logs, metrics, and alerts.

API security extends beyond application code. An otherwise well-designed API can still introduce risk if the tenancy exposes it unnecessarily to the public internet, applies weak authentication or authorization, lacks rate limiting, or does not provide sufficient logging and monitoring.

Denial of service requires layered thinking

Public APIs introduce another security concern beyond confidentiality and authorization: availability. The Treacherous 12 includes denial of service because an attack that makes a critical service unavailable can be just as damaging to the business as a data compromise. For OCI customers, the first distinction is between volumetric network attacks and application-layer abuse.

OCI provides Layer 3 and Layer 4 DDoS protection as part of the cloud offering, while application-layer protection still requires design choices such as WAF policy, rate limiting, load balancing, bot controls, caching strategy, and application resilience. Oracle DDoS guidance describes OCI Layer 3/4 mitigation as part of the core offering, and WAF documentation covers Layer 7 mitigation. [57], [58]

DDoS protection is not a single checkbox. Public applications should be designed with layered protection: resilient DNS and load balancing, WAF, rate controls, health checks, autoscaling where appropriate, runbooks for traffic surges, and operational visibility into whether an event is a real user spike, a misbehaving integration, or an attack.

DoS is also where cost and security intersect. An abusive or compromised workload can affect availability while also creating unexpected consumption. Budgets, quotas, service limits, and resource-creation alerts therefore belong in the security conversation. Abuse and nefarious use of cloud services can begin with the ability to create resources, send traffic, or consume capacity without enough oversight.

Detection turns design into operations

Preventive controls cannot address every attack path. Attackers may still probe public endpoints, abuse APIs, compromise credentials, or attempt lateral movement. The tenancy therefore needs enough visibility to show when something unusual is happening. Security logs should be enabled, centralized, retained, and monitored through the customer’s enterprise SIEM or, when that integration is not available, OCI Logging Analytics. [48], [49], [50], [51]

Security monitoring depends on more than one log source. OCI Audit logs show control-plane activity. Service logs show what supported services are doing. VCN Flow Logs help with network visibility. WAF and API Gateway logs help explain public and API-layer activity. Network Firewall logs help with inspected traffic. Data Safe helps with database activity. Cloud Guard helps connect configuration and activity signals into security problems.

OCI Cloud Guard examines resources for configuration weaknesses and users or operators for risky activities, and it can suggest or take corrective action depending on configuration. [59] OCI Logging integrates with Connector Hub, which can move logs to targets such as Object Storage, Streaming, Notifications, and Logging Analytics. [60]

The operational question is straightforward: if a security-relevant change or event occurs in the tenancy, will the right team know about it?

• If a new public endpoint appears, who is alerted?

• If a route table changes, who reviews the change?

• If an administrator creates an overly broad IAM policy, who detects it?

• If a database shows unusual activity, who investigates it?

• If a WAF rule begins blocking unexpected traffic, who reviews the event?

• If a backup bucket policy changes, who verifies that the recovery path is still protected?

A secure tenancy should have clear answers to these questions before an incident occurs.

Key takeaways from this blog

First, design the network for containment, not just connectivity. Use compartments, VCNs, NSGs, routing, firewall inspection, and ZPR policy design to make lateral movement harder.

Second, treat APIs and public endpoints as governed entry points. Use WAF, API Gateway, private endpoints, authentication, authorization, rate limiting, and logging so APIs do not become unmanaged doors into the tenancy.

Third, make detection operational. Enable the logs that matter, centralize them, retain them, and monitor them through the enterprise SIEM or OCI Logging Analytics. Cloud Guard, VCN Flow Logs, WAF logs, API logs, Network Firewall logs, and Data Safe signals should feed an investigation path, not sit unused.

Part 1 established the tenancy foundation through shared responsibility, identity, least privilege, and recovery. Part 2 builds on that foundation by reducing attacker movement and increasing defender visibility. Together, containment and visibility improve the defender’s position: the attacker has fewer paths through the tenancy, while the security team has more signals to detect and investigate suspicious activity.

Part 3 will shift from building the tenancy correctly to operating it securely over time through governance, vulnerability management, continuous assurance, and configuration-drift detection.

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.
  53. [53] ⁠Oracle Architecture Center — Identify VCN Topology and Specifications — Hub-and-spoke topology, centralized firewalls, traffic inspection, management nodes, and VCN design guidance.
  54. [54] ⁠Oracle Docs — Network Security Groups — NSG concepts, security rules, and relationship to Security Lists and ZPR.
  55. [55] ⁠Oracle Docs — API Gateway — Governed HTTP/S interfaces, authentication, authorization, rate limiting, and API deployment controls.
  56. [56] ⁠Oracle Docs — Overview of Web Application Firewall — WAF protection for internet-facing endpoints and malicious or unwanted internet traffic.
  57. [57] ⁠Oracle Architecture Center — Learn About Deploying Layer 3 and 4 DDoS Prevention on OCI — OCI Layer 3/4 DDoS mitigation as part of the core cloud offering.
  58. [58] ⁠Oracle Docs — WAF Layer 7 DDoS Mitigation — Layer 7 DDoS concepts and application-layer mitigation through WAF.
  59. [59] ⁠Oracle Docs — Cloud Guard — Monitoring OCI resources for configuration weaknesses and risky operator/user activity, with recommendations and response actions.
  60. [60] ⁠Oracle Docs — Connector Hub — Moving data between OCI services for logging, notifications, streaming, Object Storage, and Logging Analytics workflows.