4 reasons not to use mod-security

@anonymouse

 

 

At a minimum the following three recommendations do not appear to be met by mod_security.

 

 

"Inspect web services messages, if web services are exposed to the public Internet. Typically this would include Simple Object Access Protocol (SOAP) and eXtensible Markup Language (XML), both document- and RPC-oriented models,in addition to HTTP."

 

 

There does not appear (and Ivan can correct me if I'm wrong) to be a mechanism within mod_security for fully inspecting XML for the purposes of preventing attacks (which is the purpose of PCI DSS). Excessive nesting of elements, schema poisoning, etc...are nearly impossible to detect without the ability to parse XML and inspect it as a DOM, something that mod_security does not appear capable of providing.

 

 

"Automatically receive and apply dynamic signature updates from a vendor or other source. In the absence of this capability, there should be procedures in place to ensure frequent update of WAF signatures or other configuration settings."

 

 

For mod_security this support is completely absent. There does not appear to be any centralized method or procedures supported by The Apache Foundation to meet this requirement. I assume Breach has addressed this in their support model.

 

 

"Some ecommerce applications may require FIPS hardware key store support. If this is a consideration in your environment, make sure that the WAF vendor supports this requirement in one of their systems and be aware that this feature may drastically increase the cost of the solution."

 

 

Obviously if this is the case, then mod_security does not support this one.

 

 

In the end, it is up to the PCI auditor to determine whether the environment is considered compliant or not, and whether the chosen WAF (if there is one) is acceptable. But given these requirements there are environments in which mod_security does not appear to fulfill the recommended guidelines for meeting PCI DSS compliance.