Is the scenario supported?
Check the account, Region, protection plan, and relevant data sources against the chosen scenario. Record missing prerequisites before interpreting a test result.
INDEPENDENT LAB · PRE-MVP
Test your AWS detections.
Follow the evidence.
Did the detection fire?
Did the alert reach your team?
For security engineers responsible for AWS detection coverage. The lab is developing repeatable checks that connect a specific test to its telemetry, finding, and downstream alert.
DEFINED SCENARIOSTRACEABLE EVIDENCEHUMAN REVIEW
01 / THE PROBLEM
From service settings
to a working detection.
A service can be enabled while a specific threat scenario or alert route remains unverified. The first checks will address three practical questions.
Does the finding become an alert?
Trace a finding into the destination used by the team. Check filters and rule mappings: receiving an event and creating an actionable alert are separate outcomes.
Does it still work after a change?
Repeat a check after a protection setting, routing rule, or detection mapping changes. Compare the evidence with the previous run and identify what needs review.
What “coverage” means here
Evidence for a named scenario, configuration, and observation window. A successful test applies to those conditions; other threat variants and untested scenarios remain unverified. Missing evidence leaves the result inconclusive.
02 / EXAMPLE REPORT
A finding exists.
The alert is missing.
An illustrative routing check using a generated GuardDuty sample finding. All observations below are invented to demonstrate the proposed report format. This is not a completed lab run or a customer result.
ILLUSTRATIVE · SYNTHETIC EXAMPLE
GuardDuty finding → security alert queue
- E1Source finding recordedObserved
The generated sample finding has a recorded ID and timestamp.
- E2Destination event recordedObserved
The receiving system contains an event correlated to the same finding.
- E3Alert creation disabledGap
The configuration snapshot shows that the matching destination rule does not create an alert.
- E4No matching queue alertMissing
A recorded query covering the full observation window returns no matching alert.
CHECK RESULTS
Alert routing: Not detected
Threat detection: Not tested
INTERPRETATION & NEXT CHECK
E2 confirms event ingestion; E3 identifies an alert-generation gap consistent with E4. Review whether the rule should create an alert, change it if appropriate, then repeat the check. A successful retest is needed to confirm the fix.
A sample finding tests the handling of an injected event. Testing threat detection itself requires a separate behavior-based scenario and its own evidence. AWS documentation on sample findings
03 / READING THE RESULTS
Make uncertainty
part of the report.
Each check gets its own outcome. Detection and alert delivery are assessed separately, so a successful routing test cannot be mistaken for proof that a threat was detected.
- Detected
- The expected finding or alert was observed and correlated to the test within the defined window.
- Not detected
- The check completed with verified prerequisites and sufficient evidence, but the expected finding or alert was absent within the window.
- Inconclusive
- A failed test step, missing evidence, or an unverified prerequisite prevents a reliable conclusion.
- Not tested
- The check was not run or was outside the scope of this test.
Results are time-bounded observations. A delayed finding can change the assessment; an absent alert alone does not establish the cause.
04 / METHOD & DATA
Repeatable procedures.
Reviewable conclusions.
Each proposed report will include the scenario and procedure version, test conditions, timestamps, evidence references, outcome, and recommended follow-up.
How will tests be controlled?
The prototype will start with synthetic datasets and isolated AWS test accounts. Procedures will define the allowed actions, required permissions, observation window, and cleanup. Execution records will distinguish failed test steps from absent detections.
Versioned procedures make checks repeatable. Cloud processing and detection timing can still vary between runs.
What will the analysis layer do?
The planned prototype uses the Claude API to help interpret selected configuration and evidence inputs, suggest relevant MITRE ATT&CK mappings, and draft explanations. Each conclusion must reference evidence and receive practitioner review.
Model output will not serve as proof that a test ran or a detection fired. Mapping a scenario to an ATT&CK technique does not demonstrate coverage of the entire technique.
What data would I need to provide?
For feedback now, a description of your workflow is enough. This site has no account connection or evidence upload facility.
Initial model evaluation is planned with synthetic inputs. Customer-data handling, retention, and deployment options have not been finalized. Any future trial would need an agreed data scope and processing terms before evidence is shared with an external model provider.
05 / THE PROJECT
A small lab.
A focused first step.
1a2b Cloud Detection Lab is an independent project by Nikolai, a security engineer with a background in cloud security, DevSecOps, automation, and threat detection.
The direction draws on practical work reviewing cloud protection settings and mapping provider findings to downstream detection rules. The lab aims to turn those recurring questions into repeatable, evidence-backed checks.
The current work is defining the first AWS scenarios and report format. There is no publicly available product yet. The next milestone is an isolated prototype that records both detection and routing outcomes, followed by feedback from security practitioners.
- BUILT BY
- Solo founder
- STARTING WITH
- AWS
- LOOKING FOR
- Practitioner feedback
HELP CHOOSE THE FIRST CHECKS
How do you know
your detections work?
If you build or operate AWS detections, I’d like to understand how you verify them today and where the process breaks down.
Tell me about one scenario: the signal you expect, where the alert should arrive, and what is difficult to verify. A brief description is enough to start.
Share your validation workflow box@1a2b.org