FIRCY for AWS Environments

Where FIRCY fits in an AWS security stack

An AWS security architecture normally combines preventative controls, audit logs, threat detection, posture management, identity analysis, workload protection, network controls, and incident response. These layers answer related but different questions.

FIRCY creates a deliberate early-warning signal when someone or something interacts with a controlled object that legitimate users, applications, and automation have no reason to touch.

Normal production events are often ambiguous: a failed sign-in may be a mistyped password, and a large S3 read may be a scheduled export. Use of a credential created only as a decoy, or access to a synthetic export object, has fewer benign explanations.

A FIRCY signal becomes more useful when a responder compares it with authoritative AWS telemetry and incident history.

AWS recommends a multi-account architecture with centralised security tooling and log-archive capabilities.¹ FIRCY can sit inside that model without becoming the AWS control plane:

• AWS services continue to record, assess, detect, and enforce according to the customer’s configuration.
• FIRCY creates the controlled deception signal and adds relevant context.
• Existing investigation workflows remain the system of action, while containment uses approved customer controls with auditability and rollback.

This is active defence in the defensive sense. With the FIRCY AWS WAF integration, the response can be automated: FIRCY feeds a detected source address into approved IP-set inputs, then the customer’s web ACL applies its configured block action. This blocks nominated threats through a control the customer owns and governs; it is not retaliation or access to an attacker’s infrastructure.

AWS attack paths worth instrumenting

Deception is most useful when it follows a realistic attack path rather than being scattered across an account. Start from an outcome that matters, work backwards through the identities and resources an intruder would need, then select one or two places where legitimate interaction should be close to zero.

MITRE ATT&CK documents cloud-account discovery, use of valid cloud accounts, and access through cloud-service dashboards as techniques used by adversaries.^{2 3 4} In AWS, those behaviours can lead through several connected surfaces.

Compromised IAM credentials and role references

An intruder may find a long-lived key, temporary session material, profile name, role ARN, CI/CD variable, or document that describes privileged access. The actor may validate it, enumerate the caller identity, inspect permissions, discover roles, or try to reach another account.

A controlled identity pattern can place a decoy credential or role reference in a location where credential discovery is plausible but normal automation will not use it. The decoy must not become a shortcut into production. Interaction should create a signal; it should not grant useful access.

For a detailed treatment of placement, telemetry, and response for this path, see Identity-led deception for cloud credential compromise.

S3 objects, sensitive data paths, and export workflows

S3 is often part of a larger data workflow: an application writes a report, a job stages an export, a partner retrieves it, or an analyst downloads it. An attacker or malicious insider who gains an identity may search bucket names, prefixes, application configuration, query results, notebooks, or runbooks for the same paths.

Useful deception can include a synthetic export prefix, a decoy object with a believable name, a monitored reference to a non-production location, or credentials that point towards a controlled data path. The content should be synthetic and clearly owned. It should not contain copied customer records, real secrets, or production trust simply to appear credible.

This path needs deliberate telemetry. CloudTrail management events can show control-plane activity such as bucket-configuration changes. Object-level actions such as GetObject, PutObject, and DeleteObject are data events. Trails and event data stores do not log data events by default; enabling them can add volume and cost.⁵ Scope collection to the resource and pilot question that matter.

Applications, APIs, and hidden administrative paths

Not every AWS attack remains in the AWS API. A compromised session may be used against an application, while an external actor may enumerate routes, parameters, GraphQL objects, API documentation, tenant identifiers, or administrative paths.

Controlled application deception can include a hidden route, synthetic record, fake integration reference, or administrative object that normal users cannot reach. Preserve enough application context to distinguish a security tool, test, developer action, or broken link from deliberate discovery.

The most useful correlation may be outside CloudTrail: application access logs, identity-provider events, session metadata, deployment records, AWS WAF logs, and the surrounding requests can explain how the object was reached.

EC2, container, network, and hybrid discovery

Once an actor reaches a workload, they may inspect environment variables, instance or task configuration, mounted files, internal DNS, service discovery, shares, secrets, hosts, or reachable ports. Hybrid environments add routes between AWS and data centres, branch networks, development platforms, and operational tooling.

Decoy service references, credentials, files, names, or network services can make this visible. Match the workload’s operating model: an EC2 administration path differs from an Amazon ECS or Kubernetes workflow. Avoid shared credentials that gain trust between environments.

Optional VPC Flow Logs can help answer network questions such as which interface communicated with a decoy service and whether related traffic reached other addresses. Flow records describe IP traffic; they do not replace workload, application, DNS, authentication, or packet-level evidence.⁶

Internet-facing services and AWS WAF response

Internet-facing applications are continuously scanned. A single request to a common path is rarely enough to justify a block. A controlled route, token, or application lure can add specificity by showing that a source followed a path with no normal business purpose.

FIRCY’s AWS WAF active-defence integration can automate the response. Where configured criteria are met, FIRCY feeds detected source addresses into approved IP-set inputs and the existing web ACL applies its block action. Policy, scope, logging, expiry, and reversal stay inside the customer’s AWS control boundary.

Five controlled deployment patterns

These patterns are architecture starting points. Exact components, permissions, and response steps depend on the selected use case and deployment design.

Pattern 1: decoy identity and credential material

Objective: detect credential discovery, validation, or use before a real privileged identity is abused.

Place a unique decoy credential, profile, role reference, or identity artefact in a controlled location an attacker could plausibly inspect. Suitable locations might be a synthetic runbook, a test repository, an isolated workload file, or a non-production administrative path. Do not place a decoy where an authorised secret scanner, deployment job, backup process, or developer tool will automatically exercise it unless that interaction is part of the test.

Design the identity so it cannot access production data or assume production roles. Apply least privilege, explicit trust boundaries, monitoring, ownership, expiry, and a tested revocation path. AWS IAM guidance recommends federation and temporary credentials for human users and workloads, least-privilege permissions, regular removal of unused access, and use of IAM Access Analyzer to refine permissions.⁷

When someone validates or uses the credential, preserve the placement, time, source, action, account, region, and available session information. Investigate where the material was discovered—not only the infrastructure from which it was used.

Pattern 2: decoy S3 data and export paths

Objective: detect suspicious discovery of sensitive-looking data, staging areas, or exfiltration workflows.

Create a synthetic object, prefix, manifest, report, or export reference that has no legitimate consumer. Give it a believable relationship to the protected workflow without copying real data. A unique placement identifier helps distinguish interaction with a document reference from direct bucket discovery.

Decide what counts as interaction before deployment. Depending on the design, it might be a list request around the prefix, an object read, use of a decoy reference, or an application request that resolves to the path. Then enable only the telemetry required to prove that event. For S3 object-level API activity, that normally means targeted CloudTrail data events rather than assuming the default trail already records it.⁵

Test validation, alert delivery, CloudTrail lookup, identity correlation, cleanup, and expiry. Review crawlers, data catalogues, scanners, replication, lifecycle rules, and backup jobs so the decoy is not treated as production data.

Pattern 3: decoy application and API objects

Objective: identify reconnaissance or misuse inside an application before a real administrative or data action occurs.

Add a controlled route, API reference, record, tenant, integration object, or administrative link that a normal user journey never reaches. The lure should be believable in its immediate context, but it should fail safely and avoid disclosing real architecture or credentials.

Collect the session, authenticated identity where available, request, source, user agent, correlation ID, and surrounding activity. Responders should check for approved scanners, penetration tests, quality-assurance jobs, monitoring systems, and indexers.

Application deception is especially useful when the same session can be traced into cloud activity. Correlating a lure interaction with role assumption, object access, deployment changes, or a GuardDuty finding gives the SOC a stronger investigation hypothesis than either signal alone.

Pattern 4: decoy workload, service, and hybrid references

Objective: expose post-compromise discovery and attempted movement between workloads or environments.

Place a decoy hostname, service entry, credential, file, share reference, or internal endpoint in the selected EC2, container, Kubernetes, or hybrid path. Keep it isolated from production trust and record enough detail to identify the interaction’s originating workload and identity.

Combine only the sources needed to answer: where was the lure found, which identity or process touched it, what else did that source access, and can it be contained safely?

For hybrid deployment, document which team owns the AWS side, network side, endpoint side, and incident bridge. A high-confidence alert loses value if every team assumes another group will investigate it.

Pattern 5: decoy web interaction with AWS WAF enforcement

Objective: turn meaningful interaction with an internet-facing lure into governed, automated threat blocking at the edge.

Place a controlled web or application lure behind a supported AWS WAF-protected resource. FIRCY can add context to suspicious interaction and supply approved IP-set inputs. The customer’s web ACL decides where and how that IP set is used—for example in count or block mode, for a particular application, path, or scope.

Treat the IP set as managed policy data, not as an irreversible threat list:

1. Approve: require analyst approval at first, or a tested confidence rule with a clear owner.
2. Read before writing: AWS WAF’s IP-set update operation replaces the mutable IP-set specification. A workflow should retrieve the current object, preserve existing approved entries, and use the required lock token before updating it. If another process changed the IP set first, the update fails with an optimistic-lock error; re-read the set and retry rather than overwriting it.⁸
3. Expect propagation: AWS notes that WAF changes can take from seconds to minutes to propagate and may be temporarily inconsistent across locations.⁸
4. Expire: record a reason, source event, owner, creation time, and expiry for every dynamic entry, and remove entries when they expire. AWS WAF IP sets store only address ranges in CIDR notation, not per-entry metadata, so keep this record in a separate, controlled store.⁸
5. Observe: use WAF logs and web ACL metrics to confirm matching requests and detect unintended effects. AWS WAF can send logs to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose.⁹
6. Roll back: retain the prior approved set or an equivalent versioned representation so an entry or update can be reversed quickly.

IP blocking has limits. Shared egress, carrier NAT, VPNs, proxies, cloud hosting, and address reassignment can affect unrelated users. Use the narrowest appropriate web ACL scope, start in count mode where practical, and do not treat an IP address as proof of identity.

Reference workflow: suspicious access to a decoy S3 export path

Consider an analytics environment that produces approved S3 exports for a small operations group. The team is concerned that a compromised identity could search notebooks, runbooks, application settings, or bucket prefixes to find export data.

The reference workflow is:

1. Map the real path. Document how an approved export is requested, which identity creates it, where it is written, who retrieves it, and which logs support an investigation.
2. Create a safe parallel signal. Place a synthetic export reference and decoy S3 object outside the production workflow. The object contains no customer or production data and has a named owner and expiry date.
3. Define the trigger. Select the interaction that matters—such as an object read or use of a unique reference—and enable the minimum telemetry required to confirm it. If S3 object access is in scope, configure targeted CloudTrail data-event logging and record the expected cost boundary.⁵
4. Generate the FIRCY signal. Suspicious interaction with the controlled path produces an early-warning event. The exact mechanism depends on the approved FIRCY deployment pattern; the event should identify the decoy, placement, source, time, and reason it matters.
5. Add AWS context. Query the relevant CloudTrail management and data events. Identify the principal, session, source, requested operation, bucket or object, account, region, and related actions. Check for nearby role assumptions, policy changes, console activity, or access to real export paths.
6. Compare native findings. Review GuardDuty for related findings, including findings associated with unusual IAM activity or potentially exposed instance credentials.¹⁰ A related finding raises confidence; the absence of one does not make the decoy interaction benign.
7. Route to the existing workflow. Send the evidence to the organisation’s SIEM, SOAR, ticketing, or case-management process. If the organisation has chosen a Security Hub CSPM pattern, an approved transformation can create a custom finding; this is a customer-controlled workflow, not a default FIRCY integration.¹¹
8. Investigate the discovery point. Determine how the actor found the reference. Review the endpoint, workload, repository, notebook, document, or application session that exposed it. Search for access to nearby real assets.
9. Contain through governed controls. Options may include revoking a session, rotating adjacent real credentials, restricting a role, isolating a workload, or changing access to a real export location. Use existing authority, approvals, and rollback procedures.
10. Learn and reset. Preserve evidence, rotate or replace the decoy, close the discovery path if it was unintended, and update the playbook. Do not leave an already-triggered lure in place without deciding whether reuse is still safe and useful.

FIRCY explains why the interaction is unusual; AWS and enterprise telemetry explains who performed it, what else happened, and which response is justified.

Telemetry and context to preserve

Start with the question each source must answer, confirm retention and access, and test retrieval before an incident.

CloudTrail event history shows only the last 90 days of management events, searched one account and one region at a time.¹² It is not a substitute for a deliberately configured organisation trail (or, for existing CloudTrail Lake customers, an organisation event data store). Management events and data events also answer different questions.¹³ Validate that multi-region and multi-account coverage, encryption, integrity validation, retention, and access paths match the incident-response plan.

GuardDuty is context, not a prerequisite for a FIRCY event. Its IAM-related findings can indicate anomalous API activity or credential use.^{14 10} A decoy signal can focus review of a broader finding, while a related GuardDuty finding can raise its priority.

AWS-native workflow options

FIRCY events should enter a workflow the security team already operates. The FIRCY integrations approach is to connect detections and context to existing security, automation, and response systems rather than create another isolated queue.

Customer-controlled patterns include:

• Send the FIRCY signal and relevant context directly to a SIEM, SOAR, case-management platform, ticketing system, or SOC notification channel.
• Transform an approved event into an AWS Security Finding Format (ASFF) record and import it as a Security Hub CSPM custom finding.
• Use Security Hub CSPM finding events in Amazon EventBridge to route an already-imported finding to a customer-owned Lambda function, Step Functions workflow, SNS topic, SQS queue, or other supported target.¹⁵
• Keep the FIRCY event in the enterprise workflow while linking to CloudTrail, GuardDuty, WAF, application, and endpoint evidence in AWS.

Security Hub CSPM accepts findings from custom products through its BatchImportFindings operation.¹¹ That makes a customer-built pattern possible; it does not establish a native FIRCY integration. The newer AWS Security Hub uses the Open Cybersecurity Schema Framework (OCSF) rather than ASFF, so confirm which service the organisation uses before designing the mapping.¹⁶ Define ownership, schema mapping, retries, deduplication, state, regional operation, permissions, and failure monitoring.

AWS documents EventBridge as a way to react to Security Hub CSPM findings and route them to supported targets.¹⁵ The customer remains responsible for the rule, permissions, error handling, and response safety.

Multi-account design and safety guardrails

AWS environments often span production, development, security, shared-services, data, and workload accounts. Central ownership improves consistency, but a universal decoy is not believable or safe everywhere.

Use these guardrails:

Separate deception from production trust

Use a dedicated deception or security account for shared management, isolated services, or central evidence where that matches the organisation’s AWS architecture. AWS’s Security Reference Architecture places delegated security services in a Security Tooling account and immutable or controlled log copies in a Log Archive account.¹ A FIRCY deployment can align with those boundaries without assuming it must own them.

Decoys should not inherit production access. Where a signal needs a workload-account resource, give it the smallest account, region, resource, action, and time scope that supports the objective.

Use synthetic data

A realistic filename does not require real personal, customer, financial, or proprietary data. Use synthetic records, classify the decoy, record its purpose, and tell data-governance teams how to handle it.

Prefer temporary and least-privilege access

AWS IAM recommends temporary credentials for human and workload access, MFA, least privilege, removal of unused permissions, and regular review.⁷ Apply the same discipline to deployment, enrichment, and response components. Avoid one central role with broad standing access simply because it is operationally convenient.

Isolate and protect evidence

Centralise the evidence needed for investigation, restrict who can alter it, and keep clocks, account identifiers, region, event IDs, and retention consistent. Separate an alerting failure from an evidence failure: if a notification is dropped, responders should still be able to find the underlying event.

Define lifecycle ownership

Every placement needs an owner, purpose, account, region, creation date, review date, expiry, expected telemetry, and removal method. Track application redesigns, role changes, bucket lifecycle policies, account closures, and team changes that can turn a safe decoy into noise or orphaned infrastructure.

Make automation reversible

Start with enrichment and notification. Test containment in a non-production or tightly scoped path. For WAF, identity, workload, or network actions, record the triggering event, prior state, approver or rule, expiry, and rollback result. Set a maximum scope so one malformed event cannot update every account or application.

Respect account and regional boundaries

Service availability, logging, aggregation, WAF scope, encryption, and data residency can vary by account and region. Document where signals originate, evidence is stored, and analysts act. Validate cross-account assumptions during the pilot.

A phased AWS pilot

A useful pilot proves an investigation and response path, not just that a decoy can create an alert.

Phase 1: one path, one account, one owner

Choose one bounded attack path: a decoy S3 export path, credential, application route, or workload reference.

Before deployment:

• Name the security objective and protected workflow.
• Confirm the decoy has no legitimate consumer and no production trust.
• Map scanners, crawlers, backup jobs, tests, and administrators that might touch it.
• Select the exact trigger and required AWS telemetry.
• Assign a SOC owner and a cloud or application owner.
• Write the first three investigation steps and one safe containment option.
• Set a review date, cost limit, and cleanup method.

Trigger the signal through an authorised test. Confirm the event reaches the right responder with enough information to identify the placement and start the investigation.

Phase 2: context and workflow

Add only the sources that improve a real triage question: targeted CloudTrail events, application or identity context, GuardDuty findings, WAF logs, endpoint data, or VPC Flow Logs. Route the result into the existing case workflow and test after-hours ownership, duplicate events, delayed events, missing context, and notification failure.

If containment is part of the pilot, begin with analyst approval and a reversible action. Measure how long propagation and rollback take in practice.

Phase 3: selected multi-account coverage

Expand to another account, region, application, or attack path only after the first placement has an owner and a stable runbook. Reassess believability and normal automation in each environment. Standardise metadata, evidence fields, expiry, and case routing, but allow the actual lure and investigation steps to match the local workload.

Use the Cyber deception readiness checklist before broadening coverage.

What to measure

The number of decoys deployed is an inventory metric, not a security outcome. Measure whether the design helps the team recognise and act on suspicious behaviour.

An uneventful pilot can still prove the detection chain and close a telemetry or response gap. Do not create risky production interaction to increase alert counts.

How FIRCY Sense fits operationally

FIRCY Sense is designed to create controlled early-warning signals from suspicious interaction, add analyst-ready context and threat intelligence, and connect the result to existing security workflows. In AWS, that can cover identities, data paths, applications, workloads, network discovery, and web controls without pretending every event has the same meaning.

The operating model should stay simple:

1. Place a controlled signal against a defined AWS risk.
2. Detect interaction that normal business activity should not create.
3. Enrich it with the AWS, identity, application, network, and threat context needed for triage.
4. Route it to the team’s existing investigation process.
5. Respond through approved customer controls.
6. Use what was learned to improve placement, detection, architecture, and playbooks.

See Use Cases for identity, cloud, application, network, and insider-risk scenarios; Threat Intelligence for the role of interaction evidence and context; and Integrations for the broader workflow approach.

Related FIRCY resources

• Identity-led deception for cloud credential compromise
• Cyber deception readiness checklist
• What is active defence in cyber security?
• FIRCY Sense platform
• FIRCY use cases
• FIRCY threat intelligence
• FIRCY integrations

Ready to test one AWS attack path? Apply for a FIRCY Sense trial and bring a defined identity, S3, application, workload, or edge-security use case.

Sources and further reading