WAF, DDoS Protection + Service Mesh Basics

The VPC and ZTNA work in the last two modules controlled who can reach an application. This module covers what protects the application once traffic is allowed in, and how services talk to each other safely once they're inside. Three technologies do that job: a WAF filters malicious application-layer requests, DDoS protection absorbs floods meant to knock you offline, and a service mesh secures and authorizes the traffic between your own services. None of these is something a GRC Engineer configures byte-by-byte, but all three appear in control language ("the application is protected against common web attacks," "service-to-service traffic is encrypted"), and you need to know what each does, where it sits, and what evidence proves it's working.

WAF: filtering malicious requests at layer 7

A Web Application Firewall inspects HTTP/HTTPS requests — the actual application layer (layer 7), where the URL, headers, and body live — and blocks ones that match attack patterns. A network firewall or security group only sees ports and IPs; it cannot tell a normal POST /login from a SQL-injection attempt in the request body. The WAF can, because it reads the request content.

WAFs work primarily through managed rule sets — vendor-maintained collections that detect the OWASP Top 10 categories: SQL injection, cross-site scripting (XSS), path traversal, and so on. (You'll go deep on the OWASP Top 10 in the API Security phase; here the point is that the WAF is where those signatures get enforced for web traffic.) On top of managed rules, teams add custom rules (block a specific bad pattern), rate-based rules (throttle an IP making too many requests), and IP allow/deny lists. Common WAFs include AWS WAF, Cloudflare WAF, and Azure Front Door / Application Gateway WAF.

The central operational reality of a WAF — and the subject of your exercise — is the tuning trade-off. A WAF set too aggressively produces false positives: it blocks legitimate traffic (a customer whose search query happens to contain a SQL keyword, a partner integration that trips a rate limit). Set too loosely, it produces false negatives: real attacks slip through. Teams often run new rules in count/monitor mode first — logging what would be blocked without actually blocking — then promote rules to blocking once they've confirmed the false-positive rate is acceptable. Tuning is scoping exceptions narrowly (this one path, this one parameter) rather than disabling protection wholesale.

DDoS protection: staying up under a flood

A Distributed Denial of Service attack uses many sources to overwhelm a target with traffic so legitimate users can't get through. Protection operates at two layers:

• Network/transport floods (layers 3/4) — volumetric attacks (SYN floods, UDP/amplification) that try to saturate bandwidth or connection tables. These are absorbed by always-on edge services with enormous capacity — AWS Shield, Cloudflare, Azure DDoS Protection — that soak up the flood before it reaches your origin.
• Application floods (layer 7) — a flood of seemingly-valid HTTP requests (e.g. hammering an expensive search endpoint). These are mitigated with rate limiting, bot management, and challenges (CAPTCHA/JS challenges) — which is where DDoS protection overlaps with the WAF.

For GRC purposes, DDoS protection is largely an availability control. It maps to the availability commitments in SOC 2's Availability criteria and to resilience requirements, and the evidence is usually "the protection service is enabled on internet-facing endpoints" plus the provider's mitigation reporting.

Service mesh: securing traffic between services

A service mesh (Istio, Linkerd, Consul) addresses a different surface: traffic inside your environment, between microservices. In a microservices architecture, dozens of services call each other constantly. Historically that east-west traffic was unencrypted and unauthenticated — once inside the cluster, any service could call any other. That's the lateral-movement problem again, one layer down.

A service mesh deploys a lightweight proxy (a sidecar) alongside each service and routes all service-to-service traffic through it, giving you three things without changing application code:

• Automatic mTLS — every service gets an identity (a certificate), and all service-to-service traffic is mutually authenticated and encrypted. This is the encryption in transit from Phase 4, applied inside the cluster, and the mTLS / certificate lifecycle concept made automatic.
• Service-to-service authorization — policy decides which services may call which (the billing service may call the ledger; the public web service may not call the HR service). Least privilege for internal calls.
• Observability — uniform telemetry on every call, useful for both reliability and security investigation.

The diagram shows the layering: DDoS protection and the WAF guard the north-south edge (traffic in and out), while the service mesh secures east-west traffic among your own services. They are complementary, not alternatives — a mature environment has both.

What to carry forward

A WAF filters layer-7 requests against OWASP attack patterns, and its defining challenge is tuning to minimize false positives without creating false negatives — usually via monitor-mode rollout and narrowly-scoped exceptions. DDoS protection absorbs volumetric (L3/4) and application (L7) floods and is primarily an availability control. A service mesh secures east-west, service-to-service traffic with automatic mTLS and authorization, applying least privilege and encryption inside the environment. Together they cover the edge and the interior; the GRC skill is mapping each "protect the app" clause to the specific control and evidence that satisfies it.

In the final lesson of this phase you'll do the WAF tuning yourself: take a rule set that's blocking legitimate traffic and adjust it so attacks stay blocked while real users get through — the exact judgment call that separates a working WAF from one the team quietly turns off.