Findings are not enough
Many Oracle Cloud Infrastructure (OCI) administrators lack practical methods to query and visualize their network exposure with enough supporting detail to understand what they should prioritize first, and ultimately reduce risk in their environments.
Today, we can detect insecure Security Lists or NSGs with overly permissive rules using Cloud Guard, the OCI CIS compliance script, or third-party tools. These tools are aligned with the CIS Benchmark and generate findings when rules allow access to RDP, SSH, or any service without source restrictions, potentially exposing resources to the internet.
That is an important signal, but it is not the full risk picture. To truly understand whether your assets are exposed, you need evidence of reachability.
This is part 1 of a two-part blog series:
Part 1: Gaining Visibility into Your Network Exposure in OCI: Why Context Matters
https://blogs.oracle.com/cloud-infrastructure/gaining-visibility-into-network-exposure-part1
Part 2: Gaining Visibility into Your Network Exposure in OCI: A Practical Toolkit for Prioritization
https://blogs.oracle.com/cloud-infrastructure/gaining-visibility-into-network-exposure-part2
The missing piece: rule placement and reachability
Knowing that a rule allows traffic from 0.0.0.0/0 is just the beginning.
To assess real exposure, we need to answer questions like where this rule is applied, whether the subnet is public, whether a route to an Internet Gateway exists, and whether the affected resource has a public IP.
If the rule is applied to a private subnet with no external route, the risk profile is completely different. It still deserves attention, but not the same urgency as a truly internet-exposed asset.
In practice, what we often see is findings without prioritization, alerts without reachability evidence, and teams spending time on low-impact issues while real risks remain.
From findings to real risk: the questions that matter
Moving from raw findings to actionable insight starts with a few key questions:
1. Internet reachability
- Is the rule applied to a public subnet?
- Is there a route to an Internet Gateway (IGW)?
2. Blast radius
- Which ports and protocols are open to 0.0.0.0/0?
3. Applicability
- Is the rule actually in use?
- Is it attached to any active resource?
4. Affected assets
- Which VNICs, resources, or subnets could be impacted?
These questions help determine whether immediate action is required, whether the issue can be addressed later, or whether the rule can be tightened or removed with minimal impact.
Why this is harder than it should be
In real-world environments, the challenge is understanding security rules fit into the full risk picture.
This information is often distributed across multiple compartments and regions, spread across different resource types such as VCNs, subnets, route tables, and VNICs, and difficult to correlate manually.
In large environments, navigating through all this data becomes impractical and time-consuming.
A practical approach: correlating rules, routes, and resources
Properly evaluating and prioritizing CIS findings 2.1 to 2.4 requires more than Security Rules alone.
We need to combine data from multiple sources, correlate network configuration with actual resource reachability, and analyze everything in a centralized and flexible way. A centralized dataset makes this correlation simpler. Instead of navigating multiple screens and services, we can extract relevant data from OCI, consolidate it into a single dataset, and query it to quickly answer the questions that matter.
What you will get from this series
In this article series, we will walk through a practical way to build a dataset with the network details that is needed to analyze Security Lists and NSGs together rather than separately, and to prioritize risk based on real exposure, not just findings.
The approach uses Oracle Autonomous AI Database for fast and simple deployment, native support for JSON data, and flexible querying capabilities.
Important note
The artifacts provided in this series focus on CIS Benchmark findings 2.1 to 2.4 and Cloud Guard.
They do not evaluate other protection layers, such as Zero Trust Packet Routing (ZPR), OCI Network Firewall, or third-party firewalls.
If you are using these, the approach presented here should be used as a complementary layer of visibility, not a replacement. It can also help uncover publicly reachable paths that might not be immediately visible through other tools.
What’s next
In the next part, we will show how to implement this approach in practice, using a dataset, queries, and a GitHub repository with all the necessary artifacts.
Instead of going step by step through every detail, we will focus on how to get from raw data to answers that support prioritization, without jumping between consoles.
And in a later article, we will explore how AI can further simplify this process by enabling natural language interaction with your data.
Link to Part 2: Gaining Visibility into Your Network Exposure in OCI: A Practical Toolkit for Prioritization
https://blogs.oracle.com/cloud-infrastructure/gaining-visibility-into-network-exposure-part2