Prove Imperva is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. DNS never finished, so the site is not Fully configured. A WAF rule blocked /search. Last night’s policy save set SQL Injection to Block Request and nobody read it. The event is Alert Only and the 403 is something else. The SIEM never received a Security log. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the exchange: a 403 can be the product succeeding. Here you learn the five Cloud Security Console tools you actually open, in order, when someone asks you to prove Imperva is working — or to say why this request was blocked.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you ship a bad change at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open WAF Policies to Disable a rule until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the Cloud Security Console. If you cannot recite the proof field, you are not ready to change a mitigation.

5. Runbook Side A → B → C

Side A proves the website is on the path and whether a security rule fired. Side B proves the attached WAF Rules policy and the Action. Side C proves the log row and who changed what. On a messy Sev-2, do them in this order until a field lights up.

Side A — Website, then Security Events

1. Prove the website is Fully configured

   Log in to the Imperva Cloud Security Console. Top menu bar: Application. Sidebar: Websites. Open the site on the ticket. Official status values (Web Protection — Websites): Fully configured — traffic is protected and accelerated. Partially configured — traffic is not completely secured (DNS and/or SSL incomplete). Not configured — none of the website’s domains are fully configured. Disabled. If the status is not Fully configured, stop. There is no WAF Action to hunt yet.

2. Open Security Events, not the policy editor

   Same Application menu. Sidebar: Security Events. Official: the page displays a log of security events detected by Imperva; events are created when a security rule is triggered; you view events per session, then drill into specific requests. Filter the website + the UTC window on the ticket. If the user pasted an error page, filter the Incident ID (Cloud WAF Error Pages and Codes).

3. Read the session, then the request

   Help groups these as WAF Sessions. The WAF Sessions by violation type quick filter is the pointer. The request is the proof. Quote Action, violation type (SQL Injection, Cross Site Scripting, Illegal Resource Access, Remote File Inclusion, Backdoor Protect, Application Level DDoS, Bot Access Control, custom), URL, and source IP. Official next clicks on that row include Add an exception to the WAF Rules policy and Edit directly in policy — both are writes. Isolate first.

4. If Security Events is empty, do not invent a rule

   Empty is a result. Go back to site status. Or the matching rule is Ignore (no useful event). Or the request never reached a POP. Access Logs (every request) are the next read — Security Logs only exist for suspicious events.

Side B — WAF Policies, then Action

1. Open the attached WAF Rules policy, not a cousin

   Path: Application → sidebar WAF > WAF Policies. Official: each account and sub-account includes a default WAF Rules policy, automatically applied to new websites. You can create a maximum of 1,000 policies. Confirm the policy attached to this website before you argue about a mitigation.

2. Read the rule’s mitigation — that is the Action the engine was told to take

   Create and Manage Policies: each WAF rule addresses a different threat; for each rule you set a mitigation level. Current Help default: WAF rules are set to Block Request, except Sensitive Information Leakage which defaults to Ignore. The Customer Setup Checklist still documents Cross-Site Scripting historically defaulting to Alert Only. Quote what the live policy shows tonight — do not recite a PDF from memory.

3. Treat Action as its own proof field

   WAF Settings: Alert Only sends a notification (per WAF / notification settings) and an alert appears on Security Events. It does not mean Block Request. Ignore is how a rule goes quiet. If the event Action is Alert Only and the user got a 403, you are looking at a different rule — or at origin. Help also documents Bot Access Control actions on the same Security Events page (for example Add to Bad Bots). That is not SQL Injection.

4. The per-site WAF page still exists — know which one you opened

   Older / still-documented path: Application → Websites → site → Website Settings → WAF. Official note on that page: most WAF settings are now managed by the WAF Rules policy feature. Use WAF Policies as the source of truth for mitigation. Use Website Settings → WAF when Help for a leftover control still points there.

Side C — Log, Activity Log, Audit Trail

1. Confirm SIEM logging is even on

   Path: top bar Account > Account Management → sidebar SIEM Logs > Log Configuration. Official modes: Security Logs (a detailed alert for each suspicious event), Security Logs and Access Logs (every request and response, plus security events), or None. If the mode is None, there is no SIEM row to paste. Cloud WAF customers can still read past events on Security Events (Help: 90 days) or via the API.

2. Quote official log fields, not a screenshot

   Log File Structure / Example Logs (W3C): cs-uri, cs-uri-query, sc-status, c-ip, cs-rule, cs-severity, cs-attacktype, cs-attackid, s-ruleName, cs-ruleInfo. Security events contain all access-event fields and more. Attack-type codes documented with the log: SQL Injection 0, Cross Site Scripting 1, Illegal Resource Access 3, Bot Access Control 4, Sensitive Information Leakage 6, DDoS 8, Backdoor Protect, Remote File Inclusion.

3. Activity Log is not Audit Trail

   Application → Activity Log — select a time range; this is application activity in the console. Account > Account Management → Account Management > Audit Trail — log of actions by account users, system processes, and Imperva administrators. Official example shape: WAF Rules Policy "policy1" (ID: …). Use Audit Trail when the ticket is “it worked this morning.”

4. Origin only after an Allow

   If Action is not Block Request and the user still has an error, open Website Settings → Origin Servers (also the Connectivity Report: tests run for each origin defined on Websites → Settings → Origin Servers). Healthy origin + Block Request = stay on the event. 502 after allow = origin team.

Website:         finance.lab.example
Site status:     Fully configured
Path:            Application → Security Events
Incident ID:     2048-LAB
Quote:           Action = Block Request · violation = SQL Injection · URL = /search
Policy path:     Application → WAF → WAF Policies → Finance-Baseline
Mitigation:      SQL Injection = Block Request
Log row:         cs-attacktype=0 cs-rule=… sc-status=403 cs-uri=/search c-ip=203.0.113.88
If empty event:  re-read site status · or SIEM mode = None
If “who changed”: Account → Audit Trail · WAF Rules Policy name + time

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

Proof · named field, then Closed

IEVD-01 — Prove the site is on Imperva (site status)

01:42 · P2. Priya: “finance is down, Imperva is broken.” Someone already drafted a SQL Injection exception. A colleague’s Fully configured screenshot is from www, not the hostname on the ticket.

First tool: Application → Websites → the website named in the ticket.

If Not configured or Partially configured: traffic is not completely secured. Official definitions: Fully configured means traffic is protected and accelerated; Partial means DNS and/or SSL is incomplete; Not configured means none of the domains are fully configured. Quote the status. Next check is DNS / SSL for that first domain — not a WAF rule.

If Fully configured: you proved the website object is on the path. You did not prove which rule fired. Now you are allowed to open Security Events for that website and UTC window. Status still does not cover additional domains.

IEVD-02 — Prove why this request was blocked (Security Events)

02:05 · P2. QA pasted 1'or'1'='1 into production search. Nearby users saw the Imperva error page. App wants “Imperva off until standup.”

First tool: Application → Security Events. Filter website = finance.lab.example, Incident ID from the error page, last hour. Open the WAF Session, then the request.

Proof field: Action = Block Request, violation type = SQL Injection, URL = /search, source IP = 203.0.113.88. That name is the ticket. A 403 here can be the product succeeding — the factory lesson. Contain the tester. An exception on URL + HTTP Parameter is change-control after a proven false positive, not the first click.

IEVD-03 — Prove the policy and the mitigation (WAF Policies)

02:20 · P1. Search 403s for everyone since a 21:00 policy save. Security Events already shows SQL Injection / Block Request. L1 wants the default policy detached.

First tool: Application → WAF > WAF Policies → the policy applied to this website. Read SQL Injection mitigation. Then Account → Account Management → Audit Trail for that WAF Rules policy name and time.

Proof field: attached policy = Finance-Baseline, SQL Injection = Block Request, Audit Trail shows ops@lab.example saved the policy at 21:00Z. Defaults matter: most rules Block Request; Sensitive Information Leakage defaults to Ignore. If last night someone moved SQL Injection from Alert Only to Block Request, that is the change — not “Imperva is down.”

IEVD-04 — Prove the Action (Alert Only is not a block)

02:40 · P3. App: “Imperva blocked the login page.” The page actually loaded. Someone is about to click Release Blocked Sessions on a different user.

First tool: the same Security Events row — read Action before you touch a session.

Proof field: Action = Alert Only on Cross Site Scripting for /login. Official meaning (WAF Settings): a notification is sent and an alert appears on Security Events. That is not Block Request. If a real 403 exists, it belongs to a different request — filter Incident ID, or look at Bot Access Control (attack type 4), not the XSS Alert Only row.

IEVD-05 — Prove the log row (SIEM / Access / Security)

03:00 · P3. SOC: “paste the log or it did not happen.” Security Events already shows the Block Request. SIEM is empty.

First tool: Account → Account Management → SIEM Logs > Log Configuration. Read the mode.

Proof field: if mode is None, quote that — there is no file to ship. If mode is Security Logs (or Security and Access), paste cs-attacktype=0, cs-rule, s-ruleName, sc-status, cs-uri=/search, c-ip=203.0.113.88. A screenshot of the 403 tab is not a W3C row. Activity Log is console activity, not the HTTP transaction. Audit Trail is who saved the policy, not the request.

7. Traps + close-the-ticket proof

These are the sentences that turn a contained SQLi test into an open origin. Weak close versus strong close.

Sources

• Imperva Help — View Security Events (Application → Security Events; events per session; WAF Sessions; Add an exception; Edit directly in policy)
• Imperva Help — Release Blocked Sessions (Application → Security Events → WAF Sessions)
• Imperva Help — Cloud WAF Error Pages and Codes (Incident ID → filter Security Events)
• Imperva Help — Create and Manage Policies (Application → WAF > WAF Policies; default WAF Rules policy; Block Request; Sensitive Information Leakage → Ignore)
• Imperva Help — Web Protection — WAF Settings (Websites → Website Settings → WAF; Alert Only definition; most settings now on the WAF Rules policy)
• Imperva Help — Customer Setup Checklist (historical XSS → Alert Only default — confirm live mitigation)
• Imperva Help — Troubleshoot False Positives (WAF Rules policy defines the response)
• Imperva Help — Web Protection — Websites (Fully / Partially / Not configured / Disabled; first-domain DNS caveat)
• Imperva Help — Website Security Dashboard (Application → WAF > Dashboards > Security; click type → Security Events)
• Imperva Help — Website Settings (Origin Servers and sibling settings pages)
• Imperva Help — Connectivity Report (tests per origin on Websites → Settings → Origin Servers)
• Imperva Help — Cloud WAF Log Integration (Security Logs / Access Logs / None; 90-day Security Events)
• Imperva Help — Log File Structure (cs-uri, sc-status, cs-rule, attack-type codes)
• Imperva Help — Example Logs (W3C header: cs-rule, cs-attacktype, cs-attackid, s-ruleName)
• Imperva Help — Activity Log (Application → Activity Log)
• Imperva Help — Audit Trail (Account → Account Management → Audit Trail; WAF Rules Policy entries)

Related: Blog 1 · Imperva session factory · Cloud WAF DNS / SSL / origin runbook · Attack Analytics SOC triage · Advanced Bot Protection runbook · Imperva WAAP practice dashboard