CCSK · Domain 4
Infrastructure, Networking and Cloud Workload Security
About 14% of the exam
Software defined networking
What changed
- Control plane split from forwarding
- Networks defined by software policy
- Overlapping address ranges can coexist
Security gains
- Default deny is genuinely practical
- Policy applied by tag or label
- Isolation without physical cabling
New risks
- Misconfiguration replaces cabling mistakes
- The controller becomes a target
- Packet capture is often unavailable
In a software defined network the policy engine is the firewall, so protecting the control plane protects the whole fabric
Virtual network constructs
- Virtual network
- your isolated address space
- Subnet
- a routed slice of that space
- Security group
- stateful policy around a workload
- Network access list
- stateless filter at the subnet
- Route table
- chooses the next hop
- Peering
- direct path between two networks
- Transit hub
- many networks through one router
- Private endpoint
- service reachable without the internet
Segmentation strategies
- Separate accounts give the strongest boundary
- Virtual networks separate environments cleanly
- Subnets separate tiers within an application
- Security groups separate individual workloads
- Peering gives reachability, not isolation
- Blast radius is a design decision
Micro-segmentation
- Default deny between every service
- Explicit allow for known flows
- Policy written against labels, not addresses
- Workload identity survives address changes
- Stops east-west lateral movement
- Identity aware proxies extend it further
Zero trust for workloads
- Authenticate the workload, not the network
- Cryptographic identity issued to each workload
- A service mesh enforces mutual TLS
- Software defined perimeter hides the service
- Unauthenticated scanners receive no response
- Authorization decided for each request
Workload types and their controls
Virtual machines
- Golden image and patch pipeline
- Host agent for runtime detection
- Instance credentials from the metadata service
Containers
- Image scanning before admission
- Registry signing and provenance
- Runtime isolation on a shared kernel
Serverless
- Function permissions scoped tightly
- Ephemeral runtime limits persistence
- Dependencies are the attack surface
Container security
- Never run with the privileged flag
- Drop capabilities and disallow new privileges
- Read-only root filesystem where possible
- No host path mounts from workloads
- Scan images and rebuild, never patch
- Signed images only from trusted registries
Kubernetes controls
- Network policy default deny per namespace
- Admission control enforces the policy bundle
- Pod security standards at restricted level
- Workload identity instead of static secrets
- Block pod access to the metadata service
- Audit logs record every control plane call
Serverless security
- One role per function, least privilege
- Secrets from a manager, never variables
- The event source is untrusted input
- Dependency provenance matters most here
- Ephemeral runtime frustrates persistent implants
- Concurrency limits contain runaway abuse
Immutable infrastructure
- Build once
- image produced by a pipeline
- Deploy many
- identical instances from one image
- Never patch live
- replace rather than modify
- Configuration as code
- reviewed like application code
- Drift
- any change is a signal
- Rollback
- redeploy the previous image
- Ephemeral hosts
- short lives limit persistence
- Image pipeline
- hardening happens once, upstream
If a running host cannot be changed then any change you observe is either an incident or a broken pipeline
Runtime detection
- Kernel level sensors watch system calls
- An unexpected shell inside a container
- Outbound connection to a new destination
- Baseline behavior then alert on deviation
- Flow logs reveal lateral scanning
- Metadata service abuse is a strong signal
Hybrid and edge connectivity
- Dedicated circuits give predictable performance
- Tunnels encrypt over shared transport
- Extend identity, not just the network
- Edge locations shorten the path
- Encrypt even inside the provider network
- Hybrid doubles the policy surface
Infrastructure attack paths
Entry
- Exposed management interface
- Vulnerable image from a public registry
- Overly broad ingress rule
Escalation
- Privileged container reaching the host
- Instance credentials taken from metadata
- Overpermissive workload identity
Movement
- Flat network with no east-west policy
- Shared secrets reused across services
- Peering treated as a trust boundary
Know the order
- Harden the image
- Sign and scan
- Admit by policy
- Isolate by default
- Watch at runtime
Every control that runs before deployment is cheaper and more reliable than the one that runs after it
Rapid recall: pick the control
- Stop lateral movement
- micro-segmentation with default deny
- Block an untrusted image
- admission control with signatures
- Prevent container escape
- no privileged, drop capabilities
- Authenticate a workload
- issued identity in a mesh
- Credential theft from metadata
- session tokens and hop limits
- Anomalous system call
- kernel level runtime sensor
- Predictable hybrid latency
- a dedicated private circuit
- Configuration drift
- immutable redeploy
Reference strip: network, segmentation, workloads, identity, detection
Network
- Software defined and policy driven
- Default deny east-west
- Labels rather than addresses
- Private endpoints for services
Segmentation
- Accounts, networks, subnets, workloads
- Blast radius decided deliberately
- Peering is not isolation
- Hub routing domains separate tenants
Workloads
- Golden images and immutability
- Signed and scanned containers
- Least privilege function roles
- No privileged containers anywhere
Identity
- Workload identity over static secrets
- Mutual TLS inside the mesh
- Metadata service hardened
- Short lived credentials only
Detection
- Kernel sensors at runtime
- Flow logs for lateral movement
- Admission decisions logged
- Drift treated as an incident
Quick exam traps
- Trap: Peering two networks provides segmentation between them
- Trap: A privileged container is safe inside a trusted cluster
- Trap: Patching a running container in place is acceptable practice
- Trap: Network policy written by address is stable in a cluster
- Trap: Serverless removes the need for least privilege
- Trap: Encryption inside the provider network is unnecessary
- Trap: The provider secures the guest operating system in IaaS
cybercertprep.com · original revision sheet written from the public body of knowledge