Skip to content

Update WAF documentation with expanded security details#1132

Open
mikelittle wants to merge 1 commit intomasterfrom
issue-602-update-waf-documentation
Open

Update WAF documentation with expanded security details#1132
mikelittle wants to merge 1 commit intomasterfrom
issue-602-update-waf-documentation

Conversation

@mikelittle
Copy link
Contributor

@mikelittle mikelittle commented Feb 24, 2026

Updated the following sections:

Protection against exploits — expanded to mention:

  • IP reputation lists (including AWS') and managed rules for known attack patterns
  • Blocking of sensitive files, system paths, and XML-RPC API
  • Proactive rule updates for newly discovered vulnerabilities (without mentioning the advance notice agreement)

Protection against request floods — expanded with:

  • Layers 3, 4, and 7 breakdown (network, transport, application)
  • Three tiers of rate limits described generically: CDN-level, per-container (dynamic pages), and sensitive pages (login/admin) — no exact numbers
  • I also mentioned the self-service allow-lists (but couldn't find a page to point to)

New "Monitoring & alerting" section — covers:

  • 24/7/365 global on-call team with multiple tiers
  • Internal metrics (CPU, memory, disk, scaling, network) and external metrics (error rates)
  • Urgent support ticket alerting

New "Incident response" section — covers:

  • Tiered escalation (primary → secondary → tertiary → leadership) without exact timeframes
  • Five-step incident process: creation, customer notification, updates, report, root cause analysis

I specifically didn't mention:

Protection against exploits — expanded to mention:

- IP reputation lists (including AWS') and managed rules for known attack patterns
- Blocking of sensitive files, system paths, and XML-RPC API
- Proactive rule updates for newly discovered vulnerabilities (without mentioning the advance notice agreement)

Protection against request floods — expanded with:

- Layers 3, 4, and 7 breakdown (network, transport, application)
- Three tiers of rate limits described generically: CDN-level, per-container (dynamic pages), and sensitive pages (login/admin) — no exact numbers
- I also mentioned the self-service allow-lists (but couldn't find a page to point to)

New "Monitoring & alerting" section — covers:

- 24/7/365 global on-call team with multiple tiers
- Internal metrics (CPU, memory, disk, scaling, network) and external metrics (error rates)
- Urgent support ticket alerting

New "Incident response" section — covers:

- Tiered escalation (primary → secondary → tertiary → leadership) without exact timeframes
- Five-step incident process: creation, customer notification, updates, report, root cause analysis

I specifically didn't mention:

- Exact rate limit numbers
- Specific error rate thresholds
- Exact escalation timeframes
- Details about advance WordPress vulnerability notice agreements
- Internal tooling names like PagerDuty

Fixes: humanmade/altis-documentation#602
Copy link
Contributor

@wisyhambolu wisyhambolu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@mikelittle
Copy link
Contributor Author

@rmccue A reminder you wanted final approval on this PR

currently-applied rate limits.
- **CDN-level rate limits** apply across the entire environment, tuned by our engineers based on your traffic patterns. Contact Altis
support if you need these adjusted.
- **Per-container rate limits** restrict the rate of requests to dynamic pages (PHP) on each application server.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- **Per-container rate limits** restrict the rate of requests to dynamic pages (PHP) on each application server.
- **Per-container rate limits** restrict the rate of requests to dynamic pages (PHP) on each application container.

Comment on lines +17 to +18
managed rules for known attack patterns. We also block access to certain sensitive files and system paths, and at an application level
(as set in your configuration) access to the XML-RPC API.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
managed rules for known attack patterns. We also block access to certain sensitive files and system paths, and at an application level
(as set in your configuration) access to the XML-RPC API.
managed rules for known attack patterns. We also block access to certain sensitive files and system paths, and at an application level
[access to the XML-RPC API (as set in your configuration)](docs://cms/xmlrpc/).

Comment on lines +69 to +73
We use a wide range of alerts covering both internal and external metrics:

- **Internal metrics**: CPU usage, memory usage, disk space, scaling behaviour, and network throughput.
- **External metrics**: Error rates experienced by customers, including server error thresholds that trigger alerts when a
significant proportion of requests are failing.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a little too detailed, I'd cut it back to a broader description

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add some more information about our WAF set up to the documentation

3 participants