Skip to content

SYSTEM Cited by 1 source

VIPRE Integrated Email Security (IES)

What it is

VIPRE Integrated Email Security (IES) is a cloud-native email-security product built entirely on AWS to detect and stop business email compromise (BEC) — the social-engineering / impersonation class of attack (urgent wire transfers, "confidential legal matter," thread hijacks, QR-code quishing) that slips past traditional link/attachment-based Secure Email Gateways (SEGs). It integrates with Microsoft 365 via secure APIs with no MX-record change, so it deploys without re-pointing mail flow.

It is a worked example of a distributed, event-driven detection pipeline on AWS: durable claim-check ingest, fan-out/fan-in multi-engine ML detection, inline + post-delivery remediation, and a CDC-backed search/analytics plane with per-tenant isolation.

(Source: sources/2026-10-13-aws-stopping-business-email-compromise-with-ai-driven-email-security)

Architecture — four layers

1. Data ingestion (durable claim-check)

Every incoming email stream is a discrete job. The raw payload is committed immediately to S3 (cited at 11 nines / 99.999999999% durability as the rationale for using it as the payload store), and only a lightweight reference to that S3 object is enqueued in SQS. The queue decouples ingest from downstream processing and absorbs unpredictable traffic spikes. Stateless microservices on ECS + Fargate pull SQS jobs, fetch the S3 payload, and start detection. This is the canonical queue-decoupled serverless claim-check shape.

2. AI/ML detection (fan-out / fan-in, layered intelligence)

A multi-stage workflow runs multiple engines in parallel, coordinating phases with fan-in / fan-out patterns (concepts/scatter-gather-query). Four kinds of analysis:

  • Static — email treated as passive data; definitions, rules, signatures, heuristics, and classifiers are updated via hot reload.
  • Behavioral (sandbox) — links/attachments are detonated in a monitored sandbox and run through ML classifiers; ML classifiers are versioned and shipped alongside the sandbox Docker images; rule/heuristic updates arrive via S3 + S3 events.
  • Semantic (NLP) — email text runs through a pipeline of multiple bidirectional transformer models doing NER + coreference, intent summarization, zero-shot classification, and semantic-similarity matching. Models are strongly versioned, packaged in Docker images on ECR, run with PyTorch, and scheduled on NVIDIA GPUs. Heuristics and classified embedding datasets are updated separately through Apache Parquet packages on S3, with Amazon MWAA (managed Airflow) orchestrating the data-pipeline workflows.
  • Contextual intelligence — correlates global (customer-independent IoCs, reputation/classification feeds) and local (sender reputation, trust lists, roles) signals into the analysis context; discovered risk is fed back into a security data lake so emerging risks are caught quickly.

3. Response & remediation (control plane)

This layer is the platform's control plane: it translates detection verdicts into automated action via customizable Action Rule Definitions (match expressions against the aggregated threat model → remediation workflows).

  • Inline mode — the service acts as a final gateway, quarantining high-severity risk (confirmed malware, severe BEC) before mailbox delivery to keep dwell time minimal.
  • Release workflows — admin release (full visibility into audit logs, engine scores, raw payloads to safely release false positives) and end-user self-release (secure metadata digest for low-risk bulk mail; all actions audited).
  • Post-delivery clawback — native mail-provider API integrations execute programmatic clawbacks, retracting malicious messages from inboxes after delivery to neutralize "time-bomb" threats and prevent lateral movement.

4. Search & analytics (CDC pipeline)

Every state change and verdict is published as an event to an Amazon MSK cluster (durable, ordered, scalable). Events are consumed, enriched with metadata (user, group profile), and committed to Amazon RDS as the long-term auditable system of record. Change data capture (CDC) streams RDS updates in real time into OpenSearch for sub-second analytical queries (concepts/change-data-capture). The search API powers dashboards and reports; queries and results are strictly scoped by the client's tenant ID, enforcing multi-tenant isolation. CloudWatch provides monitoring/governance across the whole pipeline.

Operational numbers

  • >500,000 messages/day in production; designed to scale to millions.
  • Sample 24h EU+NA: 517,726 scanned (376,847 EU + 140,879 NA); 5,508 BEC detected (3,853 EU + 1,655 NA) ≈ ~1% of messages.
  • P95 latency (hourly avg): 1.4–15 s sandbox-off; 39–78 s sandbox-on. The sandbox detonation step is the dominant latency contributor.

Why this shape

  • Durability-first ingest. Committing the payload to S3 before anything else means a crash anywhere downstream never loses an email; the SQS job is just a pointer, so the queue stays cheap and spiky traffic is absorbed.
  • Fan-out/fan-in lets independent engines (static/behavioral/semantic/ contextual) scale and fail independently while a coordinator joins their verdicts — the sandbox stage can be toggled off for a ~5–50× latency win when speed matters more than depth.
  • CDC-backed search keeps the OLTP system-of-record (RDS) authoritable while serving sub-second analytics from OpenSearch, with tenant-ID scoping as the isolation boundary — a textbook RDS → search-index CDC pipeline.

Caveats

  • Vendor product on AWS, not an AWS-internal system; the post is a solution write-up with a Marketplace CTA. Architectural signal is genuine but no deep internals are disclosed (engine counts, sandbox/GPU fleet sizing, MSK topology, RDS engine/size, CDC mechanism).
  • P95 numbers are hourly averages over a sample window, not a steady SLO.

Seen in

Last updated · 854 distilled / 2,448 read