Comment by AnthonyMouse
5 hours ago
Mitigations and patches are in the same category, so now you're applying mitigations without testing. What if your new WAF detection signature has false positives etc.?
5 hours ago
Mitigations and patches are in the same category, so now you're applying mitigations without testing. What if your new WAF detection signature has false positives etc.?
The difference is that a mitigation is customer-applied, not vendor-supplied. Like it or not, blame shifts when a vendor supplies a fix that's insufficiently tested. The CrowdStrike BSOD incident from 2024 comes to mind.
As for WAF rules, those can usually be flipped on and off with a single switch.
Being able to roll it back isn't really a difference, you can revert to the previous version of a package too.
The trouble is if the WAF change e.g. messes up a redirect or turns a success response into an error response or vice versa, which confuses some other system into giving multiple users the same session cookie and gives them access to one another's accounts or writes corrupt entries to the database or whatever it is. You can revert the rule but that doesn't revert the state changes that have already happened.
There is inherently a trade off between keeping the system online, keeping the system patched and testing the patch before applying it.
> Being able to roll it back isn't really a difference, you can revert to the previous version of a package too.
Sometimes. In a world in which customers are increasingly adopting immutable infrastructure patterns and (contrary to best practice) using Launch Templates with symbolic references to `latest` versions of AMIs, this isn't always easy.
> There is inherently a trade off between keeping the system online, keeping the system patched and testing the patch before applying it.
On this we agree 100%.