Part of the Akamai WAF Defense Guide - Akamai WAF telemetry reveals infrastructure topology, service dependencies, and attack patterns applicable beyond edge-protected services. How security operations become competitive intelligence through systematic attack analysis feeding application development teams.

WAF as Infrastructure Intelligence: Attack Pattern Analysis Beyond Perimeter Protection

The Strategic Value Beyond Blocked Attacks

Enterprise security teams measure Web Application Firewall effectiveness through defensive metrics: attacks blocked, false positive rates, incident response times. Dashboards report billions of malicious requests prevented. Executive presentations emphasize threat protection value.

This framing positions WAF as cost center - necessary security investment providing defensive capability but not generating business value.

Alternative perspective: WAF telemetry is infrastructure intelligence revealing:

Undocumented service dependencies - Traffic patterns expose API calls between microservices that architectural diagrams don't show. Security teams discover which services actually communicate at runtime vs. documented design.

Attack methodology evolution - Observing how adversaries probe your infrastructure reveals tactics applicable to services not yet protected by WAF. Application teams can harden defenses proactively.

Third-party integration risk - Partner API consumption patterns highlight authentication weaknesses, data validation gaps, and availability dependencies invisible in contract negotiations.

Performance optimization opportunities - Traffic analysis identifies inefficient API usage patterns, redundant requests, and caching opportunities that infrastructure teams missed.

Organizations treating WAF purely as security control miss strategic value. Those analyzing telemetry systematically transform security operations into competitive advantage.

And at the end of the day, you will spot that handful of requests, hidden in a massive DoS attack, that gave control of your servers to a botnet. You will contain, analyze and patch as a professional - just another day.

Service Discovery Through Traffic Analysis

Enterprise architectures evolve faster than documentation updates. Microservices proliferate across cloud environments. Development teams deploy integrations during rapid iteration cycles. Central architecture teams maintain outdated diagrams.

WAF deployment creates forcing function: all internet traffic routes through evaluation layer, generating comprehensive telemetry about what actually communicates with what.

The Undocumented API Problem

Discovery scenario at UK financial institution:

Architectural documentation showed mobile banking application communicating with three backend APIs:

• Authentication service
• Account balance service
• Transaction history service

WAF traffic analysis revealed mobile application additionally called:

• Internal fraud detection API (undocumented)
• Legacy mainframe adapter (scheduled for retirement)
• Third-party credit scoring service (unknown to security team)
• Development environment endpoint (should not be production-accessible)

Implications:

Security risk - Fraud detection API lacked rate limiting (assumed internal-only). Credit scoring service transmitted PII without encryption over internal network (assumed isolated). Development endpoint exposed debugging information.

Operational risk - Mainframe adapter scheduled for retirement would break mobile app or become a jumpserver for attackers. No migration plan existed because dependency was unknown.

Compliance risk - Credit scoring integration processed personal data without documented GDPR data processing agreements.

None of these issues are visible without WAF traffic analysis. Traditional network monitoring showed encrypted HTTPS traffic between services - opaque without application-layer visibility.

Remediation process:

1. Extract all unique API endpoints from 30 days WAF logs
2. Correlate with architectural documentation
3. Identify undocumented endpoints (services in traffic but not in docs)
4. Interview development teams to understand purpose
5. Assess security posture of newly-discovered services
6. Update documentation and apply appropriate controls

This process always discovers 'new' dependencies across the organization. Some legitimate but unknown to security. Others were misconfigurations requiring immediate remediation.

Note: Akamai provides traffic monitoring API where you can analyse endpoints as well. The downside is that there's a threshold under which endpoints are not reported. What we used with a great success were custom rules that would temporarily monitor domains or paths in the Akamai WAF: real time, full reporting.

Attack Pattern Analysis for Unprotected Services

Organizations deploy WAF for internet-facing services but maintain internal applications without edge protection. These internal services face different threat model (authenticated users, internal network access) but not zero threat.

Value proposition: Attacks against edge-protected services reveal adversary capabilities applicable to internal infrastructure.

Translating Edge Attacks to Internal Defense

Attack pattern observed at WAF: SQL injection attempts targeting customer portal login form. WAF blocks exploitation attempts. Security team investigates.

Analysis reveals:

• Attackers tested dozens of different SQLi payloads
• Three payloads triggered unusual application response times (potential blind SQLi vulnerability)
• Geographic distribution suggests automated scanning tool
• User-agent strings match known vulnerability scanner signatures

Strategic question: Do our internal applications have similar vulnerabilities?

Response actions:

Immediate: Security team audits internal applications for SQL injection vulnerabilities matching observed patterns. Discovers two internal admin tools with similar input validation gaps.

Proactive: Development teams receive attack pattern brief showing specific SQLi techniques attempted. They review code for vulnerable patterns before attacks reach internal services.

Systematic: Automated security scanning incorporates attack patterns from WAF telemetry. Testing regime expands to include real-world attack techniques observed at edge.

This transforms reactive edge protection into proactive security improvement across entire application portfolio.

Here's a strategic question: what is of a greater value for your company: keep internal traffic 'internal' or make irregular traffic patterns visible in 'public' Akamai WAF? There was an instance when we forwarded internal certificate requests to Akamai WAF as we did not trust internal network as such.

Attack Sequencing Intelligence

Sophisticated attackers don't attempt single exploitation technique. They probe defenses systematically:

Observed attack sequence:

Phase 1 (days 1): Reconnaissance

• Subdomain enumeration across a large number of DNS domains
• Technology fingerprinting (identifying frameworks, libraries)
• Login page discovery
• Rate limit testing
• API endpoint mapping

Phase 2 (1-2 weeks later): Vulnerability scanning hidden in a DoS attack

• SQL injection testing
• Cross-site scripting probes
• File inclusion attempts
• Authentication bypass tests
• ... a full attack list

Phase 3 (several weeks later): Targeted exploitation

• Focused attacks on vulnerable endpoints discovered in Phase 2

WAF blocked exploitation at every phase (some services were switched to WAF protection between Phase 2 and Phase 3). But the attack methodology is valuable intelligence:

For internal services: Implement defenses against this specific sequence. Reconnaissance detection (unusual endpoint enumeration), vulnerability scanning alerts (systematic testing patterns), anomalous data access monitoring (bulk downloads).

For incident response: When attacks against internal services are detected, security team knows which subsequent phases to expect. Proactive defense before attacker progresses.

For security awareness: Development teams understand how attackers actually operate, not theoretical scenarios from training courses.

Third-Party Integration Risk Assessment

Organizations integrate third-party services for specialized capabilities: payment processing, identity verification, fraud detection, analytics platforms. Contract negotiations focus on functionality and pricing. Security assessment reviews compliance certifications.

Recently - even 'simple' websites are being outsourced, using organization's domain name. How do you ensure the third-party makes sure your 'domain' is not compromised?

WAF telemetry reveals actual runtime behavior beyond contractual promises.

The Partner API Consumption Pattern Problem

Contract specifies: "Real-time fraud scoring API with 99.9% uptime SLA."

WAF telemetry reveals actual usage:

Request volume: 840,000 API calls monthly
Expected volume: 120,000 (based on transaction count)
Discrepancy: 7× overconsumption

Investigation findings:

Mobile application calls fraud API for every user action, not just transactions:

• Account balance checks → fraud scoring (unnecessary)
• Settings updates → fraud scoring (unnecessary)
• Transaction history views → fraud scoring (unnecessary)

Cost impact: Fraud service charges per API call. Unnecessary calls cost $47,000 monthly in avoidable fees.

Performance impact: Each fraud API call adds 120ms latency. Unnecessary calls degrade user experience for non-transactional actions.

Security impact: Transmitting user behavior to third-party for non-fraud scenarios raises privacy concerns. GDPR data minimization principle violated.

Development team integrated fraud library following vendor documentation examples - which showed calling API for all user actions "to maximize fraud detection coverage." Nobody evaluated whether this made sense for non-transaction scenarios.

Remediation: Update integration to call fraud API only for financial transactions. Reduce API consumption 85%. Monthly cost reduction: $40,000.

WAF telemetry made the overconsumption visible. Without traffic analysis, the cost and privacy issues would persist indefinitely.

Authentication Weakness Discovery

Partner integration for customer verification:

Documentation specifies: "OAuth 2.0 authentication with client credentials flow."

WAF analysis reveals concerning pattern:

API calls from partner: All requests include same Authorization header value across 30-day observation period.

Expected behavior: OAuth tokens should rotate regularly (industry best practice: hourly to daily refresh).

Actual behavior: Partner using long-lived credentials without rotation.

Security implication: If credentials leak (employee departure, code repository exposure, logging to insecure system), they remain valid indefinitely.

Escalation: Security team contacts partner, discovers they don't implement token refresh "for operational simplicity."

Risk mitigation: Implement rate limiting specific to partner integration. If credentials compromise, limit blast radius through request throttling.

Contract renegotiation: Include token rotation requirement in next renewal. Escalate to vendor management if partner refuses security improvement.

This visibility exists only because WAF evaluates all traffic. Traditional integration monitoring focuses on availability and performance, not security hygiene.

Performance Optimization Intelligence

Security telemetry contains performance insights:

The Redundant Request Pattern

Customer dashboard application:

WAF logs show:

• Page load triggers 17 API calls
• 11 of 17 return identical responses
• Redundant calls consume 64% of backend capacity

Root cause: Frontend framework makes separate API requests for each UI component. Multiple components display same data (customer name appears in header, sidebar, main content). No client-side caching coordinates requests.

Impact:

• Backend capacity wasted on redundant processing
• Customer experiences slower page loads
• Infrastructure costs higher than necessary

Remediation: Implement client-side state management. Single data fetch shares across components. Reduce API calls 64%. Page load time turns 'green'.

Development team knew about state management conceptually. They didn't realize magnitude of redundancy without traffic analysis showing exact request patterns.

Geographic Distribution Optimization

Global SaaS application:

WAF telemetry shows:

• 78% of European user traffic routes to US-based origin servers
• Average request latency from Europe: 240ms
• Only 22% of European traffic routes to European origin

Expected behavior: Akamai should route traffic to nearest origin automatically.

Investigation: DNS configuration used geolocation-based CNAME routing, but European origin servers weren't registered in Akamai configuration. All European traffic defaulted to US origin.

Remediation: Update Akamai origin configuration to include European servers. European user latency reduction: 240ms → 45ms. Customer experience improvement visible in engagement metrics.

The misconfiguration existed for 11 months. Customer support received occasional latency complaints. Without WAF traffic analysis showing geographic distribution, root cause remained unidentified.

Building the Analysis Process

Extracting intelligence from WAF telemetry requires systematic process. You can only implement this if your team is not firefighting 6 days a week. Dependable WAF service gives you a chance to strengthen and improve your internet services.

Daily Attack Pattern Review

Security operations daily workflow:

Morning: Review previous 24 hours of blocked attacks

• Identify novel attack patterns (new SQLi techniques, unusual payloads)
• Categorize by attack vector (SQLi, XSS, file inclusion, etc.)
• Assess severity (theoretical probe vs. targeted exploitation)

Analysis: For high-severity attacks, extract:

• Specific payloads attempted
• Source IP patterns (single attacker vs. distributed)
• Target endpoints (which services attracted attention)
• Temporal patterns (sustained campaign vs. opportunistic probe)

Distribution: Brief development teams on observed techniques. Specific payloads become test cases for security regression testing.

Time investment: 30-45 minutes daily for security analyst.

Weekly Traffic Anomaly Analysis

Infrastructure team weekly workflow:

Data extraction: Pull 7 days of WAF traffic logs

• API endpoint request distribution
• Response code analysis (increased 4xx/5xx errors)
• Geographic traffic patterns
• Third-party integration volumes

Anomaly detection: Compare week-over-week

• Unexpected traffic increases (new integration launched?)
• Unusual endpoint access (reconnaissance activity?)
• Geographic shifts (service expansion or attack campaign?)

Investigation triggers:

• >30% traffic increase to specific endpoint (investigate cause)
• New endpoints appearing in traffic (undocumented service?)
• Third-party integration volume spike (misconfiguration?)

Action items: Route findings to application teams for investigation. Review internal application testing checklists, ensure new attacks are covered.

Time investment: 2-3 hours weekly for infrastructure engineer.

Monthly Service Dependency Mapping

Architecture team monthly workflow:

Comprehensive analysis: Full month of traffic data

• Extract all unique service-to-service communications
• Generate dependency graph showing actual runtime relationships
• Compare to documented architecture diagrams
• Identify discrepancies (services in traffic but not in docs)

Documentation updates: Add newly-discovered dependencies to architecture records. Investigate whether undocumented services represent:

• Legitimate services unknown to central architecture (add to docs)
• Temporary development integrations (should be removed)
• Misconfigurations (fix routing)
• Security concerns (investigate immediately)

Risk assessment: For each newly-discovered service:

• Does it handle sensitive data?
• What authentication/authorization controls exist?
• Is it scheduled for retirement (creating hidden dependency risk)?
• Should it be internet-accessible?

Time investment: 4-6 hours monthly for architecture team.

What We Built at the Financial Institution

Intelligence pipeline architecture:

Data collection: WAF tuning suddenly started showing security-relevant data in dashboards. Data pushed to Splunk.

Analysis automation:

• Daily: Splunk queries to analyze attack patterns, generate reports for security team. Akamai dashboards reviews.
• Weekly: Anomaly detection comparing current traffic to baseline, alerting on deviations
• Monthly: Service dependency mapping generating network graphs

Distribution mechanisms:

• Security team: Daily attack brief via Teams channel
• Development teams: Weekly Slack updates as needed
• Architecture team: Monthly dependency report with visualization

Feedback loops:

• Development teams report when attack patterns inform code changes
• Security team tracks which attack techniques get blocked vs. reach application layer
• Architecture team validates whether dependency discoveries lead to documentation improvements

Measurable outcomes:

Proactive security improvements: Development teams hardened 12 internal applications against SQLi patterns observed at WAF before those applications were exposed to internet.

Cost optimization: Third-party integration analysis revealed unnecessary API consumption across 5 vendor relationships. Annual savings: $480,000.

Architectural debt reduction: Service dependency mapping identified services 'retired' on paper but still with active production servers.

Performance optimization: Traffic pattern analysis identified 8 opportunities for caching, API consolidation, or geographic optimization. Aggregate latency improvement: 340ms average reduction.

The security investment that leadership viewed as necessary defensive cost became strategic capability generating measurable business value.

The Organizational Challenge: Security as Intelligence Function

Traditional security operations focuses on threat prevention and incident response. Expanding to intelligence analysis requires cultural shift:

Security team perspective: "We block attacks. Analysis is someone else's responsibility."

Development team perspective: "Security always says no. Why would we ask for their input?"

Architecture team perspective: "Security doesn't understand our business requirements."

These perspectives prevent intelligence sharing.

Necessary organizational changes:

Reframe security team role: Not just "prevent breaches" but "provide operational intelligence." Metrics include: attack patterns distributed to development, cost optimization opportunities identified, architectural risks discovered.

Establish distribution channels: Security team can't force development teams to consume intelligence. Need convenient delivery mechanisms (Slack digests, dashboard access, integration into existing development workflows).

Create feedback loops: Security team needs to know when intelligence is actually useful. Development teams should report when attack pattern analysis prevents vulnerabilities, informs code reviews, or improves testing.

Executive sponsorship: Leadership must communicate that WAF is strategic intelligence capability, not just security checkbox. Budget allocation for analysis tooling, staffing for intelligence function.

Once you build the technical capability, organizational processes to utilize it will take months to establish.

Initial resistance ("security team doesn't understand our applications") eroded when attack pattern briefs helped development teams pass security reviews faster (fewer vulnerabilities found because proactive hardening based on real attack patterns).

The technical implementation is straightforward. The organizational change determines whether capability translates to business value.

Related Resources

• ← Back to Akamai WAF Defense Overview - Complete Akamai security guide
• SIEM Integration → - Data collection and filtering architecture
• Cost of Interruptions → - Security operations overhead analysis
• PKI Implementation Guide → - Infrastructure security transformation

References

1. Akamai Technologies. (2024). "State of the Internet / Security: Web Application and API Attacks." Akamai Security Intelligence Group. https://www.akamai.com/internet-station/cyber-research
2. OWASP Foundation. (2025). "OWASP Top Ten 2025." OWASP Application Security Project. https://owasp.org/www-project-top-ten/
3. Gartner Research. (2024). "How to Use Threat Intelligence for Proactive Security." Gartner ID G00793401.
4. NIST. (2016). "Guide to Cyber Threat Information Sharing." NIST Special Publication 800-150.
5. Verizon. (2024). "Data Breach Investigations Report." Verizon Business. https://www.verizon.com/business/resources/reports/dbir/
6. MITRE Corporation. (2024). "ATT&CK Framework." https://attack.mitre.org/
7. Cloud Security Alliance. (2023). "Security Guidance for Cloud Computing v5.0." CSA Industry Guidance.
8. Mandiant. (2024). "M-Trends Report." Google Cloud Security.
9. Akamai Technologies. (2024). "DataStream 2 User Guide." Akamai TechDocs. https://techdocs.akamai.com/datastream2/docs
10. Wagner, C., et al. (2016). "Towards Automated Cyber Threat Intelligence." IEEE Security & Privacy.