Network Security — 7-Layer Exposure Analysis

Onam analyzes your cloud network topology across seven layers — from VPC isolation at the top to flow-log monitoring at the bottom — to identify exposure paths, misconfigured firewall rules, and unprotected internet-facing resources. The output is a prioritized list of effectively exposed resources, not a static dump of open security-group ports: a port that is open in a security group but unreachable through the other layers is a low-priority finding, while a port reachable through every layer is a critical one.

This page explains the 7-layer model, how effective-exposure analysis works gate by gate, what each layer checks across all supported clouds, and which findings to fix first.

The 7-Layer Analysis Model

Every modern cloud has 5–10 overlapping network controls — VPC peering, transit gateways, route tables, NACLs, security groups, load balancers, WAFs, flow logs. A single layer in isolation tells you almost nothing about real risk, so the Network Security engine evaluates all seven layers top-to-bottom on every scan. Each layer asks a different question; together they answer the only question that matters: can the internet actually reach this resource, and if so, with what protection?

Why seven and not three? Older CSPM tools only check L4 (security groups). That misses the most common misconfiguration patterns — over-broad transit gateways (L1), orphaned route tables (L2), default NACLs (L3), TLS 1.0 still accepted on a public ALB (L5), missing WAF on a CloudFront distribution (L6), and disabled VPC Flow Logs (L7). The network checks are part of Onam's 10,000+ rule registry and are framework-mapped to CIS, NIST, PCI-DSS, and SOC 2.

Effective Exposure

Onam's signature network capability is effective-exposure analysis. Instead of treating "port open in security group" as a finding, the engine traces the full path the internet would have to take to reach the resource — and only flags the resource as exposed if every gate on the path permits the traffic.

Reading the chain left to right:

1. Internet — the source of every untrusted attacker; the starting state of the analysis.
2. Gate 1 — Internet Gateway — does the VPC even have an IGW attached? No IGW, no path. (For Azure this is a public IP / Front Door check; for GCP an external IP / Cloud NAT check.)
3. Gate 2 — Route Table — is there a route to 0.0.0.0/0 pointing at the IGW from the relevant subnet? Without it, traffic cannot enter via the IGW.
4. Gate 3 — Subnet Type — is the subnet public (associated with a route table that has the IGW route)? Resources in private subnets are not directly reachable even if their security group allows it.
5. Gate 4 — Network ACL — does the subnet's NACL permit inbound on the requested port? NACLs are stateless and apply at the subnet boundary.
6. Gate 5 — Security Group — does the instance's SG inbound rule permit traffic from 0.0.0.0/0 on the port? This is what most tools check; Onam checks it last.

If all gates permit the path, the resource is effectively exposed and the finding is Critical. If any gate blocks the path, the finding is recorded at low priority — the policy text is still suboptimal, but the actual risk is contained.

A typical large AWS account has hundreds of security groups with 0.0.0.0/0 rules — most sit on instances in private subnets with no IGW path. Old tools alert on all of them. Effective-exposure analysis ranks only the truly reachable ones as Critical, which is why alert volume drops sharply in the first scan.

Each effectively-exposed finding shows the full path with the specific permit at each gate, so you see exactly what to change to break the chain — and you spend remediation time on the small fraction of open-port rules that attackers can actually use.

Layer-by-Layer Coverage

Every scan evaluates all seven layers for every cloud account in scope.

Layer 1 — Network Isolation

Most lateral-movement attack paths trace back to a Layer 1 gap.

Layer 2 — Network Reachability

L2 is where "I thought this was private" findings live.

Layer 3 — Network ACLs

NACLs and security groups don't always agree — when they conflict, the NACL wins for matching traffic.

Layer 4 — Security Groups

The most-cited layer in cloud-breach post-mortems. Findings split into two severity bands.

Critical findings — inbound open to 0.0.0.0/0:

High findings — overly broad or orphaned rules:

Layer 5 — Load Balancer Security

Layer 6 — WAF Protection

Network firewalls block by IP and port; WAFs block by request content (SQL injection, XSS, OWASP Top 10).

Layer 7 — Network Monitoring

Without flow logs you can't investigate a breach after the fact.

Supported Cloud Providers

The 7-layer model applies across every supported cloud, with CSP-specific service mappings (Azure NSGs play the role of AWS security groups; GCP firewall rules play both the NACL and SG roles). Kubernetes cluster networking (NetworkPolicies, exposed Services) is covered by Container Security.

Partial means key controls are covered but not 100% of the layer's scope: OCI's native WAF service is newer and has fewer rule sets to audit, and IBM's L7 flow-log integration is being migrated as IBM Cloud retires its older monitoring service.

Key Findings to Prioritize

The ten most-encountered network findings, with default severities. Re-grade per finding type in Settings → Network Security → Severity Policy.

Every finding includes the affected resource, the full effective-exposure path where applicable, the suggested fix, and the framework controls it satisfies.

API

Network Security endpoints live under the unified platform API (/api/v1, behind the BFF gateway). All endpoints require an authenticated session and are scoped to your tenant.

# List network security findings
GET /api/v1/network-security/findings?severity=CRITICAL

# Get findings for a specific VPC
GET /api/v1/network-security/findings?resource_uid=vpc-12345678

# Get the effective-exposure path for a specific resource
GET /api/v1/network-security/exposure-path?resource_uid={uid}

Full request and response schemas are in the API reference. Webhook delivery on new Critical network findings can be configured under Settings → Notifications.

FAQ

How does effective-exposure analysis differ from a port scan? A port scan sees only what's reachable from where the scanner sits. Effective-exposure analysis evaluates the configuration of every network gate to determine reachability without sending any traffic. Onam never scans your environment from outside — analysis is purely configuration-based, agentless, and read-only.

Can a finding be both Critical and not actually exploitable? No — that's exactly what effective-exposure analysis prevents. A security-group rule open to the internet on a private-subnet instance with no IGW route is graded low priority, not Critical. Severity reflects actual reachability.

Does Onam check IPv6 paths? Yes. IPv6 routes, IPv6 security-group rules, and IPv6 NACL entries are evaluated alongside IPv4. A common finding is "IPv4 properly restricted but IPv6 open" — Onam flags both.

What about AWS Network Firewall and Azure Firewall? Supported on AWS and Azure. Onam evaluates rule groups, stateful vs stateless policy, log delivery, and rule-order anomalies (deny rules placed below allow rules that would never be reached).

Can I export the topology for offline analysis? Yes. The full topology graph (VPCs, subnets, route tables, peerings, transit gateways, security groups, load balancers, WAFs) exports as JSON or GraphML.

Next steps

• Attack Path — see how network exposure combines with IAM and data findings into full attack chains
• Container Security — NetworkPolicy coverage and exposed Kubernetes Services
• API reference — query network findings programmatically
• Book a demo — see effective-exposure analysis on your own topology