WAF statistics reporting

Problem to solve

Users who have enabled the WAF do not easily know what the WAF is blocking, allowing, or how much traffic it processes. This lack of visibility means it is more difficult to determine how to configure, tune, and evaluate the WAF.

Intended users

1. Users will view this after initially creating a cluster and installing the WAF, to confirm they are seeing traffic
2. Security team members will view this to see what the distribution of blocked vs. allowed traffic is

Further details

Reporting statistics and information about the WAF's behavior could be a very deep experience if we invested a lot of time in it. For this iteration, I'd like us to view it as an MVC and find a way to provide visibility with a minimal amount of product changes. Then we can get feedback on what is useful or missing and then build out a deeper experience in future iterations.

Proposal

Minimal

Display to users with the WAF how frequently the WAF:

1. Identifies Anomalous traffic
2. Identifies Total amount of traffic

Default time frame is 30 days.

• • Proposal that we put this in the security tab as a set of text boxes, similar to how we have # of vulns in the security dashboard. Would like input from others on this.

Next steps

1. Table with detailed event listings
2. View raw logs themselves in the pod logs

Permissions and Security

Users should be required to have the same permissions as they would for the security dashboard to view.

What does success look like, and how can we measure that?

1. Of all users who have the WAF installed, at least 75% view the provided information at least once within 30 days.
2. Of all users who have the WAF installed, at least 90% view the provided information within 90 days.

• This demonstrates that the users who are using the WAF actually are looking at the results and not just installing it and ignoring it.

Documentation

1. Explain how to access the statistics.
2. Explain what the statistics are showing.
3. Explain what different results could be indicating.

What is the type of buyer?

GitLab Ultimate

Links / references

1. Documentation link to how to view WAF logs

/label feature

Implementation Plan

Status

• backend Add logging sidecar to expose modsec logs to ElasticSearch !19600 (merged)
• frontend Add Threat Monitoring skeleton page !19074 (merged), !20910 (merged)
• frontend Add filter bar and associated store updates !21689 (merged)
• frontend Persist alert dismissal !22117 (merged)
• backend Add WAF anomaly summary endpoint !22736 (merged)
• backend Enable filebeat prospector to parse modsec logs as JSON !24836 (merged)
• backend Add WAF anomaly summary service - modsec aggregate query !24837 (merged)
• backend Add WAF anomaly summary service - nginx aggregate query !25273 (merged)
• backend Pass nginx request_id to modsecurity to correlate ingresses to transaction logs gitlab-org/charts/auto-deploy-app!36 (merged)
• frontend Fetch and render anomaly summary within GitLab UI !21916 (merged)
• frontend Add "Show last" filter dropdown !22487 (merged)
• frontend Align UI to latest designs (alert variant/copy, popover in header) (partially done in !21689 (merged), !21916 (merged))
• frontend Handle 204s (polling) and 404s (no data) from backend !22778 (merged)
• documentation Add docs for new page, and enable feature by default !22911 (merged), including limitation around CI-based ES installations

Decisions

• Show only Anomalous traffic. Do not differentiate blocking vs logging #14707 (comment 258358254)

Final Designs

See Designs tab