WAF++ WAF++
Back to WAF++ Homepage

WAF-PERF-030 – Caching Strategy Defined & Implemented

Pillar: Performance Efficiency | Severity: Medium | Category: Caching | Automatable: Medium

Description

All workloads with repetitive read patterns or high-latency data sources MUST have a documented caching strategy. The strategy MUST specify cache layers, TTL policies and invalidation mechanisms. CDN MUST be configured for all public static and cacheable content. Distributed cache (Redis, Memcached) MUST be used for session data and high-frequency read-heavy lookups.

Rationale

Repeated identical database queries without caching create unnecessary load on the database server, unnecessary latency for the user, and unnecessary data transfer costs. A well-configured cache can reduce database load by 60–90%. Poor caching (wrong TTLs, missing invalidation) creates stale-data problems that are harder to debug than no caching at all.

Threat Context

Risk Description

Database Overload

Identical queries hundreds of times per second saturate the database server’s I/O and CPU.

Thundering Herd

Cache expiry of many simultaneous keys → simultaneous backend requests → database failure.

Stale Data

Missing cache invalidation on data mutations → users see outdated data.

No CDN → High Latency

Static assets served from origin without CDN → unnecessary latency for users outside the region.

Requirement

  • Caching strategy MUST be documented (layers, TTL per data type, invalidation mechanism)

  • Distributed cache MUST be used for session data and high-frequency lookups

  • CDN MUST be configured for all public static content

  • Cache hit rates MUST be measured and monitored (target: >= 80% app cache, >= 95% CDN)

Implementation Guidance

  1. Analyze access patterns: Identify top-20 database queries; measure repetition frequency

  2. Create caching strategy document: docs/caching-strategy.yml with layers, TTL, invalidation logic

  3. Deploy Redis/ElastiCache: Multi-AZ, automatic failover, encryption in transit

  4. Implement cache-aside pattern: Stampede protection via lock or probabilistic early expiration

  5. Configure CDN: CloudFront/Azure CDN/Cloud CDN for static assets

  6. Hit rate monitoring: CloudWatch ElastiCache metrics; alert when hit rate < 70%

  7. Ensure invalidation logic: Every data mutation must invalidate related cache entries

Maturity Levels

Level Name Criteria

1

No Cache

All requests go to origin; no CDN; no distributed cache.

2

Ad-hoc Cache

Some things cached without strategy; arbitrary TTLs; no hit rate measurement.

3

Documented Strategy

Caching strategy document; hit rate measured; CDN active; HA Redis deployed.

4

Optimized Cache

Hit rate >= 80% achieved; automatic invalidation; stampede protection.

5

Adaptive Cache

ML-based cache warming; adaptive TTLs; intelligent edge caching.

Terraform Checks

waf-perf-030.tf.aws.elasticache-cluster-configured

Checks: ElastiCache Replication Group must have automatic failover, multi-node and encryption.

Compliant Non-Compliant 
resource "aws_elasticache_replication_group" "main" {
  replication_group_id       = "payment-cache"
  node_type                  = "cache.t3.medium"
  num_cache_clusters         = 2
  automatic_failover_enabled = true
  at_rest_encryption_enabled = true
  transit_encryption_enabled = true
}
 
resource "aws_elasticache_cluster" "main" {
  cluster_id      = "payment-cache"
  engine          = "redis"
  num_cache_nodes = 1
  # Single node, no failover
  # WAF-PERF-030 Violation
}

Remediation: Use aws_elasticache_replication_group with automatic_failover_enabled = true, num_cache_clusters >= 2, at_rest_encryption_enabled = true.

Evidence

Type Required Description

Governance

✅ Required

Caching strategy document with layers, TTL policies and invalidation mechanism.

IaC

✅ Required

Terraform configuration for Redis/ElastiCache and CDN with cache rules.

Config

Optional

Cache hit rate dashboard (target: >= 80% application cache).

Process

Optional

Cache invalidation runbook for data mutations.

Related Controls

Regulatorisches Mapping

Framework Controls

ISO/IEC 25010:2011

8.3.2 – Performance efficiency; 8.3.2.1 – Time behaviour; 8.3.2.2 – Resource utilisation; 8.3.2.3 – Capacity

AWS Well-Architected Framework

Performance Efficiency Pillar – Select the right resource types and sizes

Azure Well-Architected Framework

Performance Efficiency – Choose the right resources

Google Cloud Architecture Framework

Performance optimization – Right-size your instances

TOGAF 10

ADM Phase B – Business architecture; ADM Phase C – Application architecture

DORA

DORA 2024 – Technical practices; DORA 2024 – Performance monitoring

ISO/IEC 29119

4.4.3 – Test design techniques; 4.5.3 – Test execution

ISO/IEC 12207

8.2.2.3 – Design and development of software

ITIL 4

SVS – Service value system; DP – Design principle

BSI C5:2020

OPS-01 – Operational monitoring; OPS-02 – Operational control

CIS Controls v8

CIS 8 – Continuous Vulnerability Management

NIST SP 800-53

RA-1 – Security assessment policy; RA-2 – Security assessment controls

NIST CSF 2.0

DE.CM – Continuous monitoring; DE.AE – Anomaly detection

FedRAMP

RA-2, RA-5 (Moderate/High baseline)

SOC 2 Type II

CC6.1 – Logical access security software; CC7.1 – Infrastructure and software monitoring

TISAX

Information security – Performance monitoring

ANSSI SecNumCloud

Domain – Performance monitoring

BIO

BIO – Prestatiedoelstellingen

ENS High

op.exp.2 – Configuración de seguridad

UK NCSC CAF

B4 – System security; B5 – System performance

CMMC 2.0

RA.L2-3.8.1 – Automated monitoring

IRAP

ISM – Performance monitoring

CCCS PBMM

RA-2 – Security assessment controls; RA-5 – Security assessments

MAS TRM

Ch.5 – Technology risk governance

ISMAP

Performance monitoring and validation

FISC

Technical measures – Performance monitoring

Best Practice