How InfusionPoints Detects Threats Across Your AWS Environment
AWS-Native Security Operations Series | Part 2 of 6
A look inside the six AWS security services that power the Defend pillar of the InfusionPoints Continuous Trust Platform.
Defend is the fourth stage of the InfusionPoints Continuous Trust Platform engine: Build, Operate, Prove, Defend. It's where VNSOC360 lives. And it's where the data generated across all four stages comes to matter in real time.
Every effective SOC begins with visibility. You can't detect what you can't see, and most AWS environments have significant gaps in what they're actually collecting, monitoring, and correlating.
Before our analysts watch a single alert, we run a systematic coverage assessment to map what's enabled, what's configured, what's sending data, and where the gaps are. In most environments we enter, that assessment surfaces blind spots the customer didn't know existed: regions with GuardDuty disabled, S3 data events not captured in CloudTrail, SIEM alert thresholds tuned so conservatively that real activity doesn't fire.
Closing those gaps before going live on monitoring is the difference between a SOC that catches threats and a SOC that watches clean dashboards while an adversary moves through the environment undetected.
The detection layer of VNSOC360 is built on six AWS services that work together to provide layered coverage across threats, vulnerabilities, data exposure, and identity risk.
Amazon GuardDuty: the threat detection engine
GuardDuty is our primary threat detection service. It analyzes CloudTrail management and data events, VPC Flow Logs, and DNS logs using continuously updated threat intelligence, machine learning, and anomaly detection, without requiring us to manage the underlying infrastructure or maintain detection rules from scratch. GuardDuty is a fully managed threat detection service that continuously analyzes your environment.
In federal environments running in GovCloud, GuardDuty provides the baseline detection layer that operates continuously, even before an analyst reviews a console. It identifies reconnaissance activity, credential compromise, unusual API call patterns, communications with known malicious IPs, and behavioral anomalies that static rule sets miss.
The specific finding categories GuardDuty covers include: cryptocurrency mining, backdoor activity, trojan behavior, unauthorized access attempts, stealth techniques, and policy violations. In environments where adversaries operate slowly and deliberately to avoid detection, GuardDuty's machine learning models are often the first indicator that something is wrong.
AWS Security Hub: aggregation and normalization
Security Hub is our aggregation and normalization layer. It pulls findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and AWS Config into a single pane using the AWS Security Finding Format, a standardized structure that makes findings from different services comparable and actionable without manual translation.
That standardization matters when operating across dozens of customer accounts. Analysts work from consistent alert structures regardless of which underlying service generated the finding. Triage workflows apply the same logic whether the alert came from GuardDuty detecting lateral movement or Inspector surfacing a critical CVE.
Security Hub also runs automated security checks against CIS Benchmarks, PCI-DSS, and NIST 800-53 baselines. Those checks feed directly into ConMon reporting, giving our compliance team a continuous view of control status without running separate assessment tooling.
Amazon Inspector: continuous vulnerability assessment
Inspector provides continuous vulnerability assessment against EC2 instances, container images in Amazon ECR, and Lambda functions. Unlike traditional scanners that run on a schedule, Inspector is event-driven, it automatically rescans resources when new vulnerabilities are published or when resources change.
For ConMon customers, Inspector findings are a primary data source for the vulnerability management pipeline. Under FedRAMP's VDR requirements and the CR26 framework that took effect in 2026, continuous vulnerability detection isn't optional. Inspector gives us near-real-time coverage that a periodic scan cadence can't match.
Inspector findings flow into Security Hub and from there into Command Center, where they appear as vulnerability tickets with severity, affected resource, CVE detail, and remediation guidance. Nothing sits in a queue waiting for the next scheduled report.
Amazon Macie: sensitive data discovery
In environments handling federal data, Macie provides automated discovery and classification of sensitive data stored in S3. It uses machine learning to identify PII, credentials, financial data, and other sensitive content and alerts when that data is in buckets with unexpected access configurations.
The reason Macie matters for federal customers is simple: it tells us where sensitive data actually lives, not where the data classification policy says it should live. In almost every environment we assess, those two answers are different. Development buckets contain production data. Shared prefixes expose files that should be restricted. Legacy integrations write to locations nobody remembers authorizing.
For customers handling CUI under the new FAR CUI rule, Macie is often the first service that reveals the actual scope of their CUI problem. That's a harder conversation than most customers expect, and an essential one.
IAM Access Analyzer: identity and access risk
Identity is the perimeter in cloud environments. Traditional network perimeters don't apply when your infrastructure is API-driven and your users authenticate from anywhere. IAM Access Analyzer continuously evaluates resource-based policies to identify external access paths, resources shared with unintended principals, and access that violates least-privilege principles.
Combined with GuardDuty's identity threat detection, IAM Access Analyzer gives us two views of identity risk: the static posture view (what access is configured) and the dynamic behavioral view (what access is being used and how). Both matter. An attacker who compromises credentials that have excessive permissions is harder to detect through behavioral analysis alone if the behavior looks consistent with the permissions granted.
Access Analyzer findings feed into Security Hub and surface in our ConMon reporting as policy findings mapped to the applicable access control requirements in the customer's authorization baseline.
Amazon Detective: investigation and forensics
When an alert requires investigation, Detective provides graph-based analysis to trace activity across accounts, users, and resources over time. It automatically ingests and correlates data from GuardDuty, CloudTrail, and VPC Flow Logs to build a behavior graph that lets analysts answer questions like: what did this IP address do before it triggered the GuardDuty finding? What other resources did this compromised credential access? Is this the first time this behavior has appeared in this account?
Without Detective, answering those questions requires manually querying CloudTrail, correlating log data across time windows, and building the picture by hand. With Detective, the analysis is visual, interactive, and fast. In a time-sensitive incident, that acceleration changes outcomes.
Detective is the forensic layer that makes investigations defensible. When a customer asks what happened and when, Detective gives us the evidence to answer specifically.
Detection isn't a service. It's a coverage model. GuardDuty handles behavioral threats. Inspector handles vulnerabilities. Macie handles data exposure. IAM Access Analyzer handles identity risk. Detective handles investigation. Security Hub ties it together. Each layer catches what the others don't.
How these services work as a system, not a checklist
The value of this detection stack isn't in any individual service. It's in how they work together.
GuardDuty detects that a credential is behaving unusually. Security Hub normalizes the finding and correlates it with an IAM Access Analyzer finding showing that credential has broader permissions than its role requires. Detective traces the credential's activity over the prior 30 days and surfaces three other API calls that preceded the GuardDuty alert. Inspector shows that the EC2 instance the credential accessed has an unpatched vulnerability. The analyst sees all of that context in a single workflow.
That's not how most security operations work. Most teams have GuardDuty alerts in one console, Inspector findings in another, IAM data in a third, and no workflow connecting them. They're not running a detection system. They're managing a collection of detection tools.
The architecture we deploy, and the operational workflows we run on top of it, are what turns this service collection into an integrated detection system. That's the difference between tools and operations.
From Continuous Monitoring to Continuous Authorization
FedRAMP 20x and DoW cATO both point in the same direction: security has to move from periodic evidence collection to continuous, operational proof. The old model asks whether the environment was secure when the package was submitted. The new model asks whether the environment is secure right now, whether the organization can see material risk as it changes, and whether it can respond before that risk becomes mission impact.
That is why the detection architecture matters. GuardDuty, Inspector, Macie, IAM Access Analyzer, Detective, and Security Hub are not just AWS services in a diagram. They are the evidence engine for continuous authorization. They show what changed, what is vulnerable, what data is exposed, what access is risky, what activity looks abnormal, and what analysts did in response.
For FedRAMP 20x, this supports the shift toward automation, transparency, and measurable security outcomes. Instead of treating ConMon as a reporting exercise, VNSOC360 turns operational telemetry into live assurance: vulnerability findings become tickets, configuration drift becomes control evidence, identity exposure becomes risk data, and incident activity becomes auditable response history.
For DoW cATO, the connection is even more direct. The DoW cATO model depends on ongoing visibility inside the system boundary, active cyber defense, and DevSecOps practices that support rapid, secure change. This detection stack provides the visibility and active defense layer that authorizing officials need to make risk decisions based on current operating conditions, not stale assessment artifacts.
The mission value is simple: continuous authorization only works if continuous operations can prove what is happening. CTP and VNSOC360 give customers the operating model to build securely, operate with visibility, prove control effectiveness, and defend the mission in real time.
Next in the series: Part 3: The Log Pipeline That Makes It All Auditable
→ Learn How InfusionPoints Can Help
References
InfusionPoints resources
InfusionPoints, “FedRAMP 20x,” InfusionPoints Solutions, https://infusionpoints.com/solutions/fedramp-20x
InfusionPoints, “FedRAMP 20x Phase Two Pilot, FedRAMP Trust Centers, and Agency Struggles,” InfusionPoints Blog, October 28, 2025, https://infusionpoints.com/blogs/fedramp-20x-phase-two-pilot-fedramp-trust-centers-and-agency-struggles
InfusionPoints, “The Future of Continuous Assurance: Merging Zero Trust Validation with FedRAMP 20x,” InfusionPoints Blog, October 6, 2025, https://infusionpoints.com/blogs/future-continuous-assurance-merging-zero-trust-validation-fedramp-20x
InfusionPoints, “SWFT, cATO, 20x and the Rev. 4 Drag Still Inside DoW Cloud Authorization,” InfusionPoints Blog, April 28, 2026, https://infusionpoints.com/blogs/swft-cato-20x-and-rev-4-drag-still-inside-dow-cloud-authorization
InfusionPoints, “XBU40,” InfusionPoints Platform Page, https://infusionpoints.com/xbu40
External references
FedRAMP, “FedRAMP 20x,” https://www.fedramp.gov/20x/
GSA, “GSA announces FedRAMP 20x,” March 24, 2025, https://www.gsa.gov/about-gsa/newsroom/news-releases/gsa-announces-fedramp-20x-03242025
FedRAMP, “FedRAMP 20x - One Month In and Moving Fast,” April 24, 2025, https://www.fedramp.gov/2025-04-24-fedramp-20x-one-month-in-and-moving-fast/
U.S. Department of Defense CIO, “DevSecOps Continuous Authorization Implementation Guide,” March 2024, https://dodcio.defense.gov/Portals/0/Documents/Library/DoDCIO-ContinuousAuthorizationImplementationGuide.pdf
U.S. Department of Defense CIO, “Continuous Authorization to Operate (cATO) Evaluation Criteria,” May 29, 2024, https://dodcio.defense.gov/Portals/0/Documents/Library/cATO-EvaluationCriteria.pdf
U.S. Department of Defense, “Continuous Authorization To Operate (cATO),” February 2022, https://media.defense.gov/2022/Feb/03/2002932852/-1/-1/0/CONTINUOUS-AUTHORIZATION-TO-OPERATE.PDF?v=7.58
