Cloud VPC Treated as a Trusted Zone
OrbitHR, a 300-person HR SaaS provider, has migrated its flagship application to a single AWS VPC with a /16 CIDR. It has 42 security groups, 9 of which allow 0.0.0.0/0 to TCP 22 or 3389; no egress filtering; no WAF; and a Direct Connect to the head office. Engineers connect from home directly to public instance IPs. The CTO argues that 'the cloud provider secures the network' and that the VPC is therefore a trusted zone. A recent external scan found an exposed PostgreSQL port and a forgotten bastion host. The board wants a network security architecture review that applies ISO/IEC 27033 fundamental concepts, without a wholesale re-architecture in the next quarter.
1. Apply zones, conduits and trust boundaries to the VPC. What flawed assumptions should the review challenge?
Read the worked answer
Apply the 27033 concepts: assets have different sensitivity, so group them into zones, and control traffic between zones through defined conduits. The VPC is not one trusted zone. Public-facing web tier, application tier, database tier, management/bastion, and the Direct Connect office path each need a boundary. The security groups with 0.0.0.0/0 on 22/3389 are uncontrolled conduits; the exposed PostgreSQL port is a broken boundary; engineers connecting directly to public IPs bypass any management zone. The CTO's shared-responsibility argument is a category error: AWS secures the cloud infrastructure, but OrbitHR owns configuration, identity, routing and security groups. Trust should be based on identity and policy, not on network location. Prioritise: close 0.0.0.0/0 admin rules, move management to a bastion/SSM path with MFA, restrict database to app-tier security groups, add egress filtering and a WAF, and log VPC flow logs. This is a risk-based triage, not a re-architecture.
2. Prioritize the remediation actions for the next quarter and define evidence that each is effective.
Read the worked answer
Prioritise by exploitability and blast radius. First, remove public SSH/RDP and the exposed PostgreSQL port; these are directly exploitable and the scan already found them. Second, decommission or rebuild the forgotten bastion and enforce MFA on administrative access. Third, segment the database and app tiers with security-group references, not CIDRs, and add egress restrictions to break command-and-control and data exfiltration paths. Fourth, add VPC flow logs, GuardDuty-style detection and WAF for the public app. The board should see a 30/60/90 plan with owners and evidence tests: external scan clean, no admin ports open, flow logs queryable, WAF blocking test attacks. The wholesale re-architecture can follow; the immediate goal is to remove the known exposed paths and establish monitoring. Record accepted residual risks for the quarter, especially where application dependencies prevent immediate egress filtering.
3. Explain defense in depth and shared responsibility to a board member who believes the cloud provider's network security is sufficient.
Read the worked answer
Defense in depth means multiple independent controls so one failure does not expose the asset: identity/MFA, network segmentation, host hardening, WAF, logging and monitoring, patching, and incident response. The shared-responsibility model divides infrastructure security from configuration and data security; it does not make the VPC a trusted zone. OrbitHR should assume the cloud network is hostile and apply least privilege between tiers. The board review should contrast the current flat trust with a target zone/conduit model and show how each control contributes. The argument 'the provider secures the network' fails because the scan found an exposed database and a bastion that OrbitHR configured. The correct claim is that AWS secures physical and virtualization layers, while OrbitHR must secure IAM, security groups, routing, encryption, logging and application code. That framing justifies the remediation budget without blaming the provider.