In this version, we modified the KWAF installation to address multiple scenarios related to mTLS configuration in production environment. It includes, installer/customer provide CA and certificates (which may also be self-signed) or delegating mTLS to Istio or other variants.

This also means that KWAF backend installation does not generate self-signed certificates as part of the helm installation.

In addition to the local authentication method with a login and a password, a new logging method was added. You can now configure the KWAF using a Kubernetes token associated to a Kubernetes service account (from the CLI or in the GUI).

The Forensics view allows you to examine and analyze security events, access logs and system events that occurred. You can find false positives, attack trends, identify persistent attack sources, list the highly attacked application resources, and gather a comprehensive application security visibility.

Once a request is blocked by KWAF, a security event is reported in the Forensics view.
Starting from KWAF version 1.7, a Request Data button was added next to each event to allow you to view details of the HTTP request that caused the security violation and to facilitate understanding the request data context.

By clicking Request Data, the data properties of the security event are displayed:

We provide the start line, headers, and body data.

Clicking on the icon at the upper-right corner will copy all details to the clipboard.

The request data information is saved in the Elastic database and only for the forensics security events. Multiple options are provided to record the client request data information.

Custom rule to be configured and displayed from the GUI is supported in this version.

Encoded payloads are a simple approach to obfuscate attacks. Base64 encoding is one of the most common method used. In this version, we introduce a new heuristic method to consider if a parameter value is base64 encoded. It will increase the security coverage reducing the false negative rate.