How It Works

Tangate is a two-component system: Deckard runs in your AWS account and handles enforcement and analysis, while the Tangate backend distributes threat intelligence rules and ingests lean telemetry.

Component Overview

Deckard (Customer-Side)

Deckard is a set of AWS resources deployed via CloudFormation into your account:

  • Analysis Lambda — Python 3.12, 512MB, 15-minute timeout. Runs hourly via EventBridge. Fetches logs, merges rules, runs AI analysis, updates the blocklist.
  • Lambda@Edge — Node.js 20.x, attached to your CloudFront distribution as a viewer-request trigger. Reads the blocklist from S3 and enforces it at the edge.
  • Customer Dashboard — Standalone HTML file that runs in your browser and connects directly to your S3 bucket using the AWS SDK. No server required.
  • EventBridge Rule — Triggers the analysis Lambda on an hourly schedule.
  • Secrets Manager — Stores your Tangate API key and AI provider API key securely.

Tangate Backend

The Tangate backend runs at api.tangate.com and provides:

  • Static rules files served via S3 + CloudFront (no Lambda in the read path)
  • Telemetry ingestion endpoints (API Gateway + Lambda)
  • Self-service signup with Stripe Checkout billing
  • Subscription entitlement verification

Data Flow

CloudFront Access Logs
        │
        ▼
┌─────────────────────┐
│  Analysis Lambda     │ ← Runs hourly (EventBridge)
│  (your AWS account)  │
│                      │
│  1. Fetch logs       │
│  2. Fetch rules ─────┼──→ Tangate Rules CDN (S3+CloudFront)
│  3. Load local rules │
│  4. Merge rules      │
│  5. AI analysis ─────┼──→ Your AI Provider (Anthropic/OpenAI/DeepSeek)
│  6. Update blocklist │
│  7. Write decisions  │
│  8. Send telemetry ──┼──→ Tangate Backend (lean signals only)
└─────────┬───────────┘
          │
          ▼
   S3: blocklist.json
          │
          ▼
┌─────────────────────┐
│  Lambda@Edge         │ ← Every CloudFront request
│  (your CloudFront)   │
│                      │
│  Read blocklist (5m) │
│  Match → 403         │
│  No match → pass     │
└─────────────────────┘

Lambda@Edge Enforcement

The edge function runs on every viewer request to your CloudFront distribution. It is stateless and makes no external calls at request time.

How it works:

  1. On cold start (or every 5 minutes), reads s3://{bucket}/deckard/blocklist.json
  2. Caches the blocklist in memory for 5 minutes
  3. For each request, checks the client IP against blocked IPs and CIDRs
  4. Checks the User-Agent header against blocked user agent patterns (partial match)
  5. Checks the query string against blocked query patterns (partial match)
  6. If any match is found, returns a 403 Forbidden response
  7. If no match, passes the request through to CloudFront unmodified

Blocklist format:

{
  "version": "abc123",
  "generated": "2026-03-05T14:00:00Z",
  "blocked_ips": ["1.2.3.4", "5.6.7.8"],
  "blocked_cidrs": ["192.0.2.0/24"],
  "blocked_user_agents": ["BadBot/"],
  "blocked_query_patterns": ["eval("]
}

Analysis Pipeline

The analysis Lambda executes a 17-step pipeline on each hourly run:

Step Action
1 Load config from Secrets Manager
2 Fetch CloudFront logs from S3 (only files newer than last run marker)
3 Fetch rules from Tangate (global, elevated if enabled, instance-specific)
4 Load local rules from s3://{bucket}/deckard/local-rules.json (if exists)
5 Merge rules: global → elevated → instance → local (local wins)
6 Load runtime config from s3://{bucket}/deckard/config.json (sampling rate)
7 Parse log entries, extract candidate IPs and patterns
8 Apply blocklist rules — mark known-bad immediately
9 Sort AI candidates by request count descending (highest traffic first)
10 Apply sampling gate — skip candidates based on sampling rate
11 AI analysis for remaining unknowns above suspicion threshold
12 Update blocklist at s3://{bucket}/deckard/blocklist.json
13 Write decision log at s3://{bucket}/deckard/decisions/{date}/{timestamp}.json
14 Write SIEM output at s3://{bucket}/deckard/siem/{date}/{timestamp}.json
15 Update run marker at s3://{bucket}/deckard/.last-run
16 POST lean telemetry to Tangate
17 Send heartbeat if no logs processed (early exit at step 2)

Rules Hierarchy

Rules are merged from four sources in order of precedence:

Priority Source Description
1 (lowest) Global Curated open-source threat intelligence
2 Elevated Additional rules (available with elevated protection enabled)
3 Instance Rules specific to your deployment
4 (highest) Local Your local-rules.json file in S3

Local whitelist wins over everything. If you whitelist an IP in your local rules, it will never be blocked, regardless of what the global threat intel or AI analysis says. See Rules and Blocklists for details.

Threat Intelligence

Tangate ingests from curated open-source threat intelligence sources nightly, covering botnet C2 infrastructure, compromised IPs, malicious user agents, and attack URI patterns. Rules are normalized, deduplicated, and distributed as the global ruleset.

See Threat Intelligence for details.

Telemetry: What Leaves Your Account

Only lean aggregate telemetry is sent to the Tangate backend. This is health signal data, not security data:

{
  "instance_id": "customer-xyz",
  "status": "success",
  "run_summary": {
    "log_files_processed": 12,
    "requests_analyzed": 84231,
    "blocks_applied": 89,
    "ai_calls_made": 4,
    "sampling_rate": 0.5
  },
  "blocklist_state": {
    "ip_count": 47,
    "user_agent_count": 12
  }
}

No individual IPs, no decision details, no raw traffic data. The Tangate backend receives only aggregate counts and health status. All detailed security data (blocklists, decisions, SIEM output) stays in your S3 bucket.

Telemetry is best-effort. If the Tangate backend is unreachable, telemetry is skipped and the main pipeline continues unaffected.

Failure Modes

Scenario Behavior
Tangate backend unreachable Analysis continues with last known rules (cached in S3)
AI provider unreachable Analysis skips AI, applies rules-only decisions
Local rules file malformed Local rules skipped, error logged to CloudWatch
Tangate backend down long-term Edge enforcement continues from cached blocklist indefinitely

Next Steps