Proofpoint Email Protection + TAP

At a glance

Vendor	Proofpoint — Email Protection (gateway) + Targeted Attack Protection (TAP). Optional modules: Email Fraud Defense (EFD), Closed-Loop Email Analysis and Response (CLEAR).
Source type	email
Vendor ID (slug)	proofpoint-tap
Base URL	https://tap-api-v2.proofpoint.com — fixed for all TAP customers. EFD and CLEAR endpoints live under the same host.
Auth method	HTTP Basic Auth with a TAP service credential pair. Paste as <service-principal>:<service-secret> in the Draxis Credentials field; Draxis base64-encodes and sends Authorization: Basic ... on every call.
Schedule default	daily — override to hourly for tighter response on the 24h-delivered KRI.
Licensing	Core TAP KRIs (VAP, delivered, clicks, BEC, campaigns) work on any TAP SKU. DMARC enforcement KRI requires Proofpoint Email Fraud Defense (EFD). Reported-phish false-negative rate requires Closed-Loop Email Analysis and Response (CLEAR). Tenants without those modules get 0 on the affected KRIs with a warn log — uncheck them in the UI if you don't want a 0 misread as a clean posture.
Availability	New in 2026.04.

Required scopes & roles

Proofpoint TAP uses service credentials — not user passwords. Create a dedicated service credential under Settings → Connected Applications → Create New Credential. The credential is scoped to a set of API groups; grant only:

• SIEM API — reads /siem/messages/{delivered,blocked}, /siem/clicks/{permitted,blocked}, /siem/issues. Backs the delivered, clicks-permitted, and BEC KRIs.
• People API — reads /people/vap. Backs the VAP KRI and is used as the Test probe.
• Campaign API — reads /campaign. Backs the credential-phishing campaigns KRI.
• Forensics API — optional, reserved for future threat-detail enrichment. Safe to grant up front; the current 7 KRIs don't call it.
• EFD APIs — required only if you have Email Fraud Defense and want the DMARC KRI to populate.
• CLEAR APIs — required only if you have CLEAR and want the reported-phish FN-rate KRI to populate.

Service credentials are read-only by nature; TAP doesn't expose write endpoints to third parties through the v2 API. No risk of over-permissioning here — grant what matches your modules.

Setup steps

1. Sign in to the TAP admin console (https://threatinsight.proofpoint.com/). You need an admin account with permission to manage service credentials.
2. Create the service credential. Go to Settings → Connected Applications → Create New Credential. Name it draxis-connector. Description: "Read-only access for Draxis risk KRI ingestion."
3. Select the API scopes matching your module licensing (see Required scopes above — at minimum SIEM, People, Campaign).
4. Copy the Service Principal and Service Secret. Proofpoint shows the secret once — copy both values into your password manager immediately. If you lose the secret, you'll need to delete the credential and create a new one.
5. Combine into a Basic-Auth string. Draxis's Credentials field expects principal:secret as a single string. Example: abcd1234-5678:supersecretstring. Paste that into Draxis; Draxis base64-encodes it server-side.
6. (Optional) Restrict by source IP. Proofpoint supports IP allowlisting on service credentials — add the Draxis egress range after confirming the connector works.

Wire it into Draxis

1. Open Settings → Integrations in your tenant.
2. Click Add integration and pick Email Security as the source type.
3. Pick Proofpoint Email Protection + TAP from the vendor dropdown. Draxis auto-fills the TAP base URL, Basic Auth method, and daily schedule.
4. In Credentials, paste <service-principal>:<service-secret> as a single string (example in step 5 of setup above). Draxis encrypts it server-side with encryption.key before storage.
5. Click Test. Green means Draxis called GET /v2/people/vap?window=30 successfully — the message includes the VAP count so you can verify the right tenant scope.
6. Under KRIs to import, tick the KRIs you want Draxis to manage. All seven pp_* KRIs are checked by default; uncheck the DMARC and reported-phish KRIs if you don't license EFD or CLEAR (otherwise 0 will be recorded as the value and could be misread as a clean posture). Selected rows are created on save with the seeded thresholds. Unchecking a previously-imported KRI deletes it on save.
7. Save. The connector runs daily by default; use Run now from run history to trigger the first sync immediately.

KRIs produced

Slug	Meaning	Derivation
pp_vap_count	Very Attacked People (30-day window)	GET /v2/people/vap?window=30, read totalVapUsers.
pp_malicious_delivered_24h	Messages with a threat delivered (not blocked) in the last 24 hours	GET /v2/siem/messages/delivered?sinceSeconds=86400&format=json, count of messagesDelivered[]. TAP re-classifies messages after delivery as new intel arrives; this KRI captures retroactively-confirmed threats.
pp_malicious_clicks_post_delivery_7d	Clicks TAP permitted in the last 7 days (clicked before URL was flagged)	GET /v2/siem/clicks/permitted?sinceSeconds=604800&format=json, count of clicksPermitted[].
pp_bec_impostor_7d	Impostor / BEC detections in the last 7 days (delivered + blocked)	GET /v2/siem/issues?sinceSeconds=604800&threatType=impostor&format=json, sum of messagesDelivered.length + messagesBlocked.length.
pp_dmarc_enforcement_pct	% of owned domains at DMARC p=reject	GET /v2/efd/dmarc/domains, compute count(domains where policy=='reject') / count(domains) * 100. Requires EFD module — 403/404 → records 0.
pp_reported_phish_fn_rate_pct	% of user-reported phish TAP had classified as clean	GET /v2/clear/reports/summary?window=7d, compute falseNegatives / totalReports * 100. Requires CLEAR module — 403/404 → records 0.
pp_cred_phish_campaigns_30d	Credential-phishing campaigns targeting the org in 30 days	GET /v2/campaign?interval=PT720H, count of campaigns where type contains "credential" or equals "phish".

Each row is a slug the connector writes to. Draxis creates the matching kri rows automatically when you check them in the KRIs to import section of the integration form — no manual API call or seed script needed. Thresholds shown in the table are the seeded defaults; you can edit them freely in the KRIs tab afterwards.

Vendor quirks

• One API root, multiple product modules behind it. TAP, EFD, and CLEAR all answer on tap-api-v2.proofpoint.com, but each module is separately licensed. The connector assumes TAP-core and tolerates 403/404 on EFD and CLEAR endpoints — the affected KRIs record as 0 with a warn log.
• Service credentials are not user credentials. You cannot use a human admin's TAP login for API access. The credential pair under Settings → Connected Applications is the only supported auth. This is good — service credentials are scoped to specific API groups and cannot perform admin actions.
• SIEM feeds are delta-based. Each query returns only messages/clicks in the requested sinceSeconds window. There's no cumulative "current state of threats" endpoint — the daily schedule rolls a fresh 24h window. If the connector misses a run, the 24h window is gone (messages older than 24h aren't re-queryable via this feed).
• "Clicks permitted" is a specific TAP concept. TAP rewrites URLs and evaluates at click-time. A permitted click means the URL was not yet classified as malicious when the user clicked; TAP may later re-classify the URL. The KRI captures how often TAP's click-time race is lost.
• BEC detection counts both delivered AND blocked impostor messages. Blocked ones didn't reach users (good), but they still indicate active impersonation pressure. Use the threshold to track attack volume, not just residual risk.
• DMARC KRI interpretation. p=reject is the strictest DMARC policy (fully blocks spoofed mail). p=quarantine is partial (sends to spam); p=none is monitor-only. The KRI counts only reject as "enforced" — tune the filter in the connector if your org treats quarantine as enforcement too.
• Reported-phish FN-rate depends on CLEAR data quality. CLEAR tracks user-submitted phish reports and cross-references against TAP's classification. If users aren't actively reporting phish through the Proofpoint report button, this KRI is low-signal (small denominator). Combine with a separate "user reports volume" KRI for a complete picture.
• Campaign classification is best-effort. Proofpoint's campaign engine clusters related messages and assigns types like "credential phishing", "imposter", "malware", "spam". The KRI filters on type containing "credential" or equal to "phish". Adjust the filter (one-line change in the connector) if your tenant uses a different taxonomy.
• Rate limits. TAP's documented API rate limit is 1800 req/hour per service credential. The connector makes ~7 calls per run, well under any cap even at hourly scheduling.
• SIEM feed cap. Each SIEM endpoint returns at most the last 24 hours regardless of sinceSeconds — a 7-day click count uses sinceSeconds=604800, but if TAP only retains 24h of click data for your SKU, the count will be lower than you'd expect. Confirm with your Proofpoint account team what retention you have.
• Credential rotation. Service credentials don't auto-expire, but security best practice is quarterly rotation. Rotate by generating a new pair, updating Draxis, then deleting the old pair — a short overlap is safe.

Troubleshooting

• HTTP 401 on Test — the service-principal:service-secret string is wrong (usually a copy-paste issue — missing colon, extra whitespace) or the credential was deleted in the TAP console. Regenerate and re-paste.
• HTTP 403 on a specific endpoint — the service credential is missing that API scope. Edit the credential in Connected Applications and add the missing scope.
• pp_dmarc_enforcement_pct is 0 and the run log says "EFD module not available" — you don't have Email Fraud Defense licensed. Uncheck the KRI in the integration form to remove it from your dashboard, or request an EFD trial from Proofpoint.
• pp_reported_phish_fn_rate_pct is 0 and the run log says "CLEAR module not available" — same as above but for CLEAR.
• All KRIs are 0 on a brand-new TAP tenant — TAP needs a few days of mail flow to build VAPs and campaign attribution. Expected on day 1; re-check after a week.
• rowsSkipped > 0 and rowsWritten = 0 — your tenant hasn't imported any KRIs for this integration yet. Open the integration in Settings → Integrations, tick the KRIs under KRIs to import, and save.
• Still stuck? Open a support ticket with the run ID (from Run history) and we'll dig in.