5.7 Communication and Network Security Case Lab
Key Takeaways
- Case analysis should begin with business objectives, critical assets, threat scenarios, regulatory duties, and operational constraints.
- A defensible network design uses layered controls across identity, segmentation, secure channels, endpoint security, monitoring, and resilience.
- Tradeoff analysis is essential because stronger inspection, segmentation, or remote access controls can affect latency, supportability, and availability.
- Risk registers, decision memos, and phased implementation plans help leaders communicate why controls were chosen and what residual risk remains.
- The best case-lab answers avoid single-control thinking and explain how prevention, detection, response, and recovery work together.
Case scenario: hybrid claims platform
A regional insurance company runs a claims platform used by customers, employees, adjusters, and repair partners. The public portal is hosted in a cloud VPC. Core policy data remains in an on-premises data center. Adjusters work from the field using managed laptops and cellular connections. Repair partners need limited access to upload documents and status updates. The board is concerned about ransomware, customer data exposure, outage during storms, and audit findings from broad internal network access.
Start with business outcomes. Customers must file claims during severe weather events. Employees need reliable access to claims workflows. Partners need only the functions related to assigned claims. Policy databases contain sensitive personal data and must not be reachable from general user networks. Incident responders need out-of-band communication and administrative access if the primary network is degraded. These statements guide the network design better than a generic goal to improve security.
A reasonable target architecture uses a cloud edge with DDoS protection, WAF or API protection, TLS with managed certificate lifecycle, private connectivity between cloud and data center, and a restricted service tier that talks to on-premises data through approved ports. Internal users access applications through identity-aware access or VPN with MFA and device posture. Administrators use privileged access workstations or bastion services. Partners use a portal or API gateway, not broad VPN access.
| Requirement | Control choice | Residual risk to document |
|---|---|---|
| Public customer portal | WAF, TLS, DDoS, secure DNS, monitoring | App logic flaws still need SDLC controls. |
| Cloud to data center data access | Private link or VPN, firewall allowlist, mutual authentication | Link outage needs queued or degraded processing. |
| Field adjuster access | Managed devices, MFA, ZTNA or VPN, cellular policy | Lost devices and weak local networks remain possible. |
| Partner uploads | Partner portal, least privilege, malware scanning, audit logs | Partner account compromise still needs detection. |
| Ransomware containment | Segmentation, EDR, immutable backups, restricted admin paths | Recovery time depends on testing and dependency mapping. |
Decision memo and implementation plan
The decision memo should explain why broad network trust is being removed. The current flat internal access lets user workstations reach too many server networks, which increases ransomware blast radius. The future state separates user, application, data, management, partner, and backup environments. It also uses identity-aware access for remote users, monitored administrative paths, and explicit application flows. The risk reduction is improved containment, better audit evidence, and faster incident scoping.
The memo should also acknowledge tradeoffs. More segmentation can initially increase troubleshooting time. TLS inspection can create privacy and application compatibility issues. Full-tunnel remote access can increase bandwidth needs. Microsegmentation depends on accurate flow mapping. Partner access changes may require contract updates and support coordination. Leadership should see that these are managed implementation risks, not reasons to keep broad trust.
A phased plan reduces outage risk. Phase one inventories data flows, certificates, remote access groups, firewall rules, partner accounts, and monitoring gaps. Phase two implements logging improvements, MFA enforcement, certificate ownership, and firewall rule cleanup. Phase three moves high-value databases into restricted segments and pilots microsegmentation for the claims application. Phase four replaces broad partner VPN access with a portal or API gateway. Phase five tests failover, incident response, and recovery communications.
Case analysis workflow:
- Identify business services, critical data, users, partners, and recovery objectives.
- Draw trust boundaries and normal data flows before selecting controls.
- Select layered controls for ingress, egress, lateral movement, remote access, administration, and monitoring.
- Record tradeoffs, owners, implementation dependencies, and residual risk.
- Validate with tabletop exercises, technical tests, and recurring access reviews.
The final answer should sound like a security leader, not a device catalog. It should explain that a WAF reduces some web attack risk but does not replace secure coding. It should explain that segmentation reduces lateral movement but must be paired with backups and endpoint containment for ransomware. It should explain that secure remote access protects field work but must preserve claims operations during storms. Defense in depth is valuable because each layer assumes another layer may fail.
In the case scenario, why is giving repair partners broad VPN access to the internal network a poor design choice?
Which sequence best reflects a risk-based implementation plan for new segmentation?
Which statement best demonstrates defense-in-depth reasoning for the claims platform?