Connecting Mimecast or Proofpoint (email security)

If you already run Mimecast or Proofpoint in front of your mailboxes, connecting either one here brings its own threat detections into the Qorionix SIEM incident queue. Both are secure email gateways with their own detection engines - Mimecast's Targeted Threat Protection (TTP) logs and Proofpoint's Targeted Attack Protection (TAP) events are already pre-triaged by the vendor, the same way a GuardDuty or Defender for Cloud finding is. Neither connector needs an OCSF field mapping the way a raw log source does, because there is no raw log to normalise - the vendor has already decided what happened.

Mimecast

1. 1

   Create an API 2.0 application

   In the Mimecast Administration Console, open Administration -> Services -> API 2.0 Applications and create an application with the Threat Remediation product.

2. 2

   Note your regional API base URL

   Mimecast is region-specific. Your account's regional API base URL is shown under Account Settings - copy it exactly rather than guessing a default.

3. 3

   Copy the Client ID and Client Secret

   Both are shown once, at creation time.

4. 4

   Connect it in Qorionix

   Under Integrations -> Catalog -> Mimecast, choose Cloud security alerts, paste the base URL, Client ID and Client Secret, and press Test and save. URL protection, attachment and impersonation TTP events already logged appear after the first poll.

Mimecast's TTP logs carry no severity field of their own - a click event is just a click event. Qorionix infers a severity from what the gateway actually did about it: a URL or attachment that Mimecast blocked outright is treated as lower severity than one a user clicked through after an override warning, which in turn is lower than one that was fully permitted with no protection triggered at all. This is an inference from the recorded action, not a value Mimecast itself assigns.

Proofpoint Targeted Attack Protection

1. 1

   Create a Connected Application

   In the Proofpoint TAP Dashboard, open Settings -> Connected Applications and create a new application. This gives you a Service Principal and a Secret - Proofpoint's own credential shape for the SIEM API, distinct from a username and password or an OAuth client.

2. 2

   Connect it in Qorionix

   Under Integrations -> Catalog -> Proofpoint Targeted Attack Protection, choose Cloud security alerts, paste the Service Principal and Secret, and press Test and save. Recent clicks and blocked messages already logged appear after the first poll.

Proofpoint's TAP API reports events in three separate sections - clicksBlocked, clicksPermitted and messagesBlocked - and Qorionix infers severity from which section an event came from rather than from any field Proofpoint labels as severity. A clicksPermitted event, where a user actually clicked a malicious link before Proofpoint's own URL rewrite caught and blocked it, is treated as higher severity than a clicksBlocked event, where the rewrite stopped the click before it ever reached the destination. A messagesBlocked event, where the message itself never reached the mailbox, is treated as lowest of the three.

What you see once it is polling

• A new Mimecast or Proofpoint event appears as an incident in the same queue as everything else, tagged with its source connector.
• A re-poll of an event already imported does not open a duplicate incident - both connectors follow the same poll-and-dedup shape that Amazon GuardDuty and Microsoft Defender for Cloud use, matched on the vendor's own event id. See Connecting Amazon GuardDuty or Microsoft Defender for Cloud for how that polling and incident-creation behaviour works in general - Mimecast and Proofpoint are wired the same way, into the same cloud-alerts pipeline.
• The sender and recipient addresses on the underlying message are recorded as entities on the incident where the vendor's event includes them.