Guide: Creating custom watchlists for our specific tech stack

The default feeds and watchlists provided by even the most reputable threat intelligence platforms, such as Mandiant, often suffer from a critical lack of contextual relevance for specialized infrastructure. As an architect operating across AWS, GCP, and Azure with a service mesh and Kubernetes-centric stack, I've found the generic "Critical Vulnerability" alerts to be a source of significant noise. The key to operationalizing threat intel is to engineer precision—transforming a broad feed into a targeted, actionable signal for your specific environment.

This guide outlines a methodology for constructing custom watchlists within the Mandiant framework, focusing on our tech stack's unique attack surface. The core principle is to map external indicators (CVEs, threat actor TTPs) to internal inventory and configuration data.

### Foundational Data Correlation

First, you must establish a pipeline that enriches Mandiant intelligence with your internal asset registry. For example, a CVE report is only critical if you run the affected software version in an exposed context. We achieve this through a combination of Terraform state files, container registry metadata, and service mesh configuration.

```hcl
# Example Terraform to tag resources with stack components
resource "aws_instance" "istio_ingress_gateway" {
ami = data.aws_ami.optimized_ami.id
instance_type = "c5.large"
tags = {
"Component" = "istio-ingressgateway"
"K8s_Cluster" = "prod-us-east-1"
"ManagedBy" = "terraform"
}
}
```

### Constructing the Watchlist Logic

A useful watchlist must filter and prioritize based on layered criteria. I propose a multi-stage filter applied to the raw Mandiant feed:

* **Stage 1: Technology Stack Filter**
* Accept only indicators related to: Kubernetes (kube-apiserver, etcd, specific CNIs), Istio/Envoy, Terraform/CloudFormation, AWS S3/GCP IAM/Azure AD specific misconfigurations, and container runtime vulnerabilities.
* Reject broad Microsoft Windows or Adobe Flash alerts irrelevant to a cloud-native stack.

* **Stage 2: Environmental Context Filter**
* Correlate accepted indicators with your CMDB or cloud provider metadata. A CVE for GCP's Dataflow is only relevant if your `gcloud asset list` shows it in use.
* Weight indicators higher if the affected component is internet-facing (derived from Istio `Gateway` resources or AWS Security Group analysis).

* **Stage 3: Tactical Relevance Filter**
* Prioritize TTPs from threat groups (e.g., FIN11, APT29) known to target cloud credentials, container orchestration, or data exfiltration from object storage.
* Incorporate internal security telemetry—e.g., if a suspicious IAM role assumption is detected, elevate related credential phishing indicators.

### Operationalization via Automation

The final watchlist should not be a static PDF or dashboard. It must be an automated feed integrated into your CI/CD and security orchestration. For instance:

1. A Python script consumes the filtered Mandiant feed via their API.
2. It cross-references with a daily dump of container images from your registry, checking for vulnerable digests.
3. Positive matches generate a structured alert (e.g., in Slack, PagerDuty) and, crucially, a Jira ticket pre-populated with context: the vulnerable service owner (from service mesh labels), the associated Terraform module, and suggested patch versions.

Without this level of integration, threat intelligence remains an academic exercise, divorced from the operational reality of maintaining complex, multi-cloud infrastructure. The goal is to create a closed-loop system where intelligence directly informs and triggers remediation workflows within the same tools used for deployment.