Threat Intelligence That Changes What You Do Next
A threat feed is useful only when it changes a decision. Aegisify DI combines AWS-native detections with vulnerability exploitation intelligence and local cloud context so teams can distinguish “important in general” from “important in this AWS environment, right now.”
Combine Global Threat Signals With Local AWS Reality
AWS-native threat evidence
GuardDuty uses AWS telemetry, continuously updated threat intelligence, anomaly detection, and protection-specific data sources to generate findings tied to AWS resources and identities.
Vulnerability exploitation intelligence
CISA KEV tells you which vulnerabilities are known to be exploited. FIRST EPSS adds a probability-oriented signal estimating exploitation likelihood over the next 30 days.
DI environment context
DI correlates those external signals with asset criticality, exposure, identity, vulnerability, data sensitivity, drift, runtime findings, behavior, evidence, and application boundaries.
Use GuardDuty as Source Intelligence, Then Correlate Beyond the Finding
AWS documents GuardDuty as a threat-detection service that analyzes foundational sources such as CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs, with optional protection features for additional resources. AWS also documents continuously updated threat-intelligence feeds and machine-learning-based detection.
Suspicious control-plane behavior
Use GuardDuty and CloudTrail evidence to understand unusual API behavior, credentials, account activity, and potential privilege abuse.
Malicious infrastructure and anomalies
Bring malicious-domain/IP intelligence and anomalous network context into DI alongside the affected resource's configuration and exposure.
Resource-specific threat signals
Where enabled and supported, DI can consume runtime and protection-plan findings and correlate them with vulnerability, identity, and attack-path evidence.
Prioritize Exploitability, Not Just CVSS Severity
| Signal | What it tells you | What it does not tell you | How DI uses it |
|---|---|---|---|
| CVE / CVSS | What vulnerability exists and technical severity characteristics | Whether attackers are exploiting it in your environment | Baseline vulnerability identity and severity context |
| CISA KEV | The vulnerability is known to be exploited in the wild | Whether your specific vulnerable resource is reachable or business-critical | Raises urgency when a matching affected workload exists |
| FIRST EPSS | Probability-oriented estimate of exploitation within the next 30 days | Proof that your workload will be exploited | Adds exploit-likelihood context to vulnerability prioritization |
| AWS Inspector / native vulnerability finding | Which supported AWS resource/package/image/function is affected | Full business impact or attacker path by itself | Connects the vulnerability to actual AWS resource context |
| DI context | Exposure, identity, data, business criticality, drift, runtime, and evidence | Global attacker visibility outside the sources DI uses | Turns general vulnerability intelligence into environment-specific priority |
A CVE Becomes More Urgent When the Environment Makes Exploitation Matter
Move From Detection to Evidence Without Copying the Entire Log Estate
Start from a deterministic signal
Use provider finding identity, severity, resource, account, Region, actor, and time as the investigation anchor.
Retrieve only the evidence the case needs
Use bounded CloudTrail, CloudWatch, S3/Athena, Security Lake, or service-specific evidence queries instead of default full-log replication.
Store case evidence, IDs, hashes, and pointers
Keep an attributable evidence chain and explicit completeness state for later review, response, reporting, or assessment.
Use Authoritative Sources Without Turning Them Into Compliance Claims
CISA created the Known Exploited Vulnerabilities catalog to help federal agencies and other organizations prioritize vulnerabilities known to be exploited. CISA guidance recommends prioritizing KEVs because they represent urgent, active risk. DI can use KEV as a prioritization signal while preserving the customer's actual AWS evidence and control context.
KEV gives remediation urgency an authoritative basis
Known exploitation is different from theoretical severity. For federal and regulated teams, that can help explain why a vulnerability should move ahead of a larger backlog.
Threat intelligence is evidence input, not certification
A KEV match, GuardDuty finding, EPSS score, or Inspector finding can support a risk decision. It does not by itself prove a federal control is satisfied.
Threat Intelligence Is Stronger When Its Limits Stay Visible
DI does not pretend to own internet-wide telemetry it does not have
DI uses documented provider and public intelligence sources plus customer evidence. It should not be marketed as a proprietary global threat network.
AI may explain evidence, but evidence remains authoritative
Inspector can help summarize and connect evidence, but it cannot create a GuardDuty finding, CloudTrail event, AWS state, or exploitation fact that was never observed.
EPSS is a forecast signal
An EPSS score is useful prioritization context, not proof that exploitation will occur. DI should always combine it with the environment's actual exposure and asset context.
Coverage gaps remain visible
If the required source is disabled, unavailable, denied, stale, or unsupported, DI should report the limitation rather than infer that no threat exists.
How DI Uses Threat Intelligence
Does DI replace GuardDuty?
No. GuardDuty can remain the AWS-native threat-detection engine. DI consumes and correlates the finding with other cloud context, evidence, and workflow.
Why use both KEV and EPSS?
They answer different questions. KEV indicates known exploitation. EPSS estimates the probability of exploitation over the next 30 days. DI can use both alongside the actual AWS workload context.
Does a KEV match automatically mean an incident?
No. A KEV match increases urgency, but DI should still confirm affected resources, exposure, compensating controls, identity paths, runtime evidence, and business impact before declaring the full incident story.
Does DI ingest every GuardDuty source log?
No by default. DI consumes findings and queries bounded evidence when needed. GuardDuty itself analyzes AWS data sources and generates findings; DI does not need to duplicate those raw sources simply to preserve the finding.
How can Aegisify AI help?
Ask about Aegisify or WordPress: errors, plugins, security, SEO, compatibility, troubleshooting, comparisons, or launch a free website scan.