imperva/cloud-waf

VendorImperva, Inc.
AuthorCrowdStrike
Version1.3.1
Minimum LogScale Version1.142.0
Use Cases

SecOps

Web application attacks prevent important transactions and steal sensitive data.

Imperva Cloud Web Application Firewall (WAF) stops these attacks with near-zero false positives and a global SOC to ensure your organization is protected from the latest attacks minutes after they are discovered in the wild.

The parser normalizes data to a common schema based on CrowdStrike Parsing Standard (CPS) 1.0. This schema allows you to search the data without knowing the data specifically, and just knowing the common schema instead. It also allows you to combine the data more easily with other data sources which conform to the same schema.

Installing the Package in LogScale

Find the repository where you want to send the events, or Creating a Repository or View.

  1. Navigate to your repository in the LogScale interface, click Settings and then Packages on the left.

  2. Click Marketplace and install the LogScale package for (i.e. imperva/cloud-waf).

Configurations and Sending the Logs to LogScale

  1. First you need to configure Imperva Cloud WAF log integration. The preferred option for sending logs from Imperva to LogScale is to choose Push Mode to Amazon S3.

  2. Once this configuration is completed, your logs will be automatically transferred from the Imperva cloud repository to your pre-defined AWS S3 bucket.

  3. Then you need to configure LogScale to collect data from AWS S3 buckets using the imperva-cloudwaf. See the documentation for cloud: Ingest Data from AWS S3 and self-hosted Ingest Data from AWS S3 deployments to send logs directly from S3 bucket into LogScale repository.

Refer to Imperva log file structure to get additional details about recorded events.

Verify Data is Arriving in LogScale

Once you have completed the above steps the data should be arriving in your LogScale repository.

Package Contents Explained

This package parses incoming data, and normalizing the data as part of that parsing. The parser normalizes the data to CrowdStrike Parsing Standard (CPS) 1.0 schema based on OpenTelemetry standards, while still preserving the original data.

If you want to search using the original field names and values, you can access those in the fields whose names are prefixed with the word Vendor. Fields which are not prefixed with Vendor are standard fields which are either based on the schema (for example, source.ip) or on LogScale conventions (@rawstring).

The fields which the parser currently maps the data to, are chosen based on what seems the most relevant, and will potentially be expanded in the future. But the parser won't necessarily normalize every field that has potential to be normalized.