GuardDuty Analyst IAM Workflow

Test least-privilege IAM access and triage a GuardDuty sample finding.

Introduction

30 Second Summary

A security alert only helps when the person investigating it can reach the evidence. Too much access can also let that person change the very protection they rely on.

In this project, you will build a read-only Amazon GuardDuty analyst workflow secured by the principle of least privilege in AWS Identity and Access Management (IAM). You will prove its permission boundary in the IAM Policy Simulator before using a sample finding to write a triage note.

What You'll Build

Your finished demo pairs a visible GuardDuty sample finding with simulator evidence proving that an analyst can investigate threats without changing or deleting the detector.

By the end of this project, you'll have:

A risk simulation showing how an over-permissive analyst policy exposes GuardDuty administration actions.
A tested least-privilege policy that allows finding investigation while GuardDuty write actions remain denied.
A sample finding triage note recording the finding classification, affected resource, evidence, containment recommendation, and next investigation step.
A Secret Mission: Add explicit deny guardrails that protect critical detector operations even if broader permissions are granted later.

Are there any prerequisites?

You need basic AWS knowledge and an AWS account with console access. You also need help from your account administrator to prepare the Regional lab permissions and sample findings.

Before We Start

The protected analyst role needs read-only visibility into Amazon GuardDuty detectors, findings, trial status, and usage statistics. Administration stays outside this role, including creating sample findings, updating or deleting detectors, suspending GuardDuty, or making other configuration changes.

Set Up the Admin-Assisted Lab

Your protected analyst role needs pre-generated findings before you can test a realistic investigation in Amazon GuardDuty.

An account administrator keeps the write permissions. Your identity receives read-only GuardDuty access plus the two permissions required for AWS Identity and Access Management (IAM) Policy Simulator Custom mode.

In this step, get ready to:

Ask an account administrator to prepare GuardDuty sample findings in one supported Region.
Request read-only GuardDuty access plus the minimum Custom mode simulator permissions.
Verify that you can simulate a pasted policy and view a current sample finding.

Give the administrator the preparation checklist

GuardDuty configuration is Regional. The detector must use the same AWS Region where you later inspect the sample findings.

GuardDuty becomes pay as you go after an eligible 30-day trial. The administrator checks the remaining trial days before leaving the detector active, so the lab begins with a clear cost state.

Ask the administrator to choose one supported AWS Region for this lab.
Record the administrator's selected Region here: your administrator-selected AWS Region.
Ask the administrator to enable or reuse the GuardDuty detector in that Region.
Ask the administrator to choose Settings in the GuardDuty console.
Ask the administrator to find Sample findings.
Ask the administrator to choose Generate sample findings.
Ask the administrator to confirm any remaining GuardDuty free-trial days.

The administrator should confirm that the detector is active or reused in the agreed Region. They should also confirm that the sample findings have been generated there.

Administrator cannot generate samples?

Ask the administrator to confirm that GuardDuty is enabled in your administrator-selected AWS Region. Sample findings must be generated from the same Regional detector.

Ask them to check that their identity retains the GuardDuty write permission needed to generate samples.

Help me prepare questions for my administrator.

Request only the lab permissions

This lab uses two permission layers to preserve least privilege. The managed policy supports live read-only investigation while the custom policy grants only the permissions needed for simulation.

Ask the administrator to attach AmazonGuardDutyReadOnlyAccess to your existing identity or temporary lab role.
Give the administrator the simulator policy by sharing this exact draft:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCustomPolicySimulation",
      "Effect": "Allow",
      "Action": [
        "iam:GetContextKeysForCustomPolicy",
        "iam:SimulateCustomPolicy"
      ],
      "Resource": "*"
    }
  ]
}

What does this policy allow?

The "Version": "2012-10-17" element identifies the AWS policy language version.
The AllowCustomPolicySimulation statement gives this narrow permission group a readable name.
The iam:GetContextKeysForCustomPolicy permission supports the context required for a custom policy simulation.
The iam:SimulateCustomPolicy permission allows Custom mode to evaluate the pasted policy.
The Resource value applies these two simulator permissions to *.

Ask the administrator to attach the permissions from policy-simulator-access-policy.json to the same identity or temporary lab role.
Ask the administrator to confirm that both permission layers are attached.
Keep full GuardDuty access and account administrator access out of your request.

Permissions attached to the wrong identity?

Confirm that the administrator used the identity or temporary lab role you plan to use for the AWS console session. Both permission layers must apply to that same session.

Help me troubleshoot my lab permissions.

✔️ Awesome, I've got everything!

The administrator has the exact simulator policy and has confirmed both permission layers on your learner identity or temporary lab role.

ⓧ I'd like to double check the full code

This is the exact policy draft the administrator should receive.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCustomPolicySimulation",
      "Effect": "Allow",
      "Action": [
        "iam:GetContextKeysForCustomPolicy",
        "iam:SimulateCustomPolicy"
      ],
      "Resource": "*"
    }
  ]
}

Verify both access paths

Custom mode evaluates pasted policies without attaching them to an identity. It sends no real GuardDuty service request.

The GuardDuty console provides the separate live check. Together, these paths prove that simulation access and read-only finding access both work.

Sign in to the AWS Management Console using the prepared identity or temporary lab role.
Open the IAM console.
Choose Policy simulator.
Choose Custom mode.
Paste the contents of policy-simulator-access-policy.json into the custom policy editor.

You should see the complete policy remain available for simulation without a permission rejection. This confirms that Custom mode accepts your pasted policy.

Custom mode unavailable?

Ask the administrator to confirm that iam:GetContextKeysForCustomPolicy applies to your signed-in identity.

Ask them to confirm that iam:SimulateCustomPolicy applies to the same identity.

Help me restore Custom mode access.

Open Amazon GuardDuty from the AWS Management Console in a second browser tab.
Select your administrator-selected AWS Region in the console.
Choose Findings.
Select Current findings.

Before you check the titles, do you expect the administrator-generated entries to appear in this Region?

Scan the finding titles for an entry that begins with [SAMPLE].

You'll see at least one current finding whose title begins with [SAMPLE]. This proves that your read-only identity can inspect the safe findings prepared by the administrator.

No sample findings in the list?

Confirm that the console is using your administrator-selected AWS Region. GuardDuty findings stay within the Region where the administrator generated them.

If access is denied, ask the administrator to confirm that AmazonGuardDutyReadOnlyAccess applies to your current identity or temporary lab role.

Help me find the missing sample findings.

You have the safe lab boundary in place: live read-only findings plus a separate simulator. Next, you'll use Custom mode to expose why broad GuardDuty access is dangerous.

Expose the Over-Permissive Policy

The live sample findings prove that your analyst can investigate Amazon GuardDuty from the prepared role. A broad draft policy can still cross the analyst's job boundary.

The IAM Policy Simulator lets you test that boundary without sending a real service request. You will compare one read action with three detector administration actions inside the same simulation.

In this step, get ready to:

Load a simulation-only GuardDuty policy into Custom mode.
Simulate one read action plus three detector administration actions against all resources.
Classify each simulator decision against the analyst's job boundary.

Load the risky policy

Custom mode evaluates a pasted policy before attachment. The draft stays inside the simulator during this test.

Switch back to IAM Policy Simulator in Custom mode.
Click inside the policy editor.
Press Cmd+A (macOS) or Ctrl+A (Windows) to select the current policy.
Replace the selected text by pasting this simulation-only policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OverPermissiveGuardDutyAnalyst",
      "Effect": "Allow",
      "Action": [
        "guardduty:GetFindings",
        "guardduty:CreateSampleFindings",
        "guardduty:UpdateDetector",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*"
    }
  ]
}

What Does This Policy Contain?

The "Version": "2012-10-17" element selects the IAM policy language version.
The OverPermissiveGuardDutyAnalyst statement identifier names the permission set being tested.
The Action array places one finding-read action beside three detector administration actions.
The Resource value * applies the statement to all resources.

Confirm that the Custom mode editor displays one statement named OverPermissiveGuardDutyAnalyst.
Check that the statement contains four GuardDuty actions.

Policy Draft Not Accepted?

Compare every brace with the reference below. Check that each action remains inside the Action array.

Ask for help with the policy structure.

✔️ Awesome, I've got everything!

Your Custom mode editor now contains the complete simulation-only draft.

ⓧ I'd like to double check the full code

Compare the editor contents with this complete draft:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OverPermissiveGuardDutyAnalyst",
      "Effect": "Allow",
      "Action": [
        "guardduty:GetFindings",
        "guardduty:CreateSampleFindings",
        "guardduty:UpdateDetector",
        "guardduty:DeleteDetector"
      ],
      "Resource": "*"
    }
  ]
}

What Should Match?

Check that the policy contains one statement.
Check that the four actions appear in the same order.
Check that the statement uses the * resource wildcard.

Test read and write actions together

A useful permission test keeps every input consistent. This simulation uses the same draft plus the same resource for all four actions.

Add guardduty:GetFindings in the simulator's action selector.
Add guardduty:CreateSampleFindings in the simulator's action selector.
Add guardduty:UpdateDetector in the simulator's action selector.
Add guardduty:DeleteDetector in the simulator's action selector.
Set the simulation resource to *.

Before you run it, do you expect every action to receive the same decision? Hold your prediction in mind.

Start the test by running the simulation.

The results show an Allowed decision for all four actions. Your simulation worked and exposed the permission gap inside this draft.

The Shortfall Is Intentional

The read action received an Allowed decision. The three write actions received Allowed decisions too.

The same statement has placed finding investigation plus detector administration inside one permission boundary. The simulator made no GuardDuty service requests.

Seeing a Denied Decision?

Confirm that all four actions appear inside the policy's Action array.
Confirm that the simulation resource is *.
Confirm that the policy statement uses Allow as its effect.

Help me inspect my simulation inputs.

Capture the policy shortfall

A simulator decision becomes useful evidence when it is tied to the analyst's actual responsibilities. The final record needs to separate investigation access from detector administration.

How Should You Classify the Actions?

The guardduty:GetFindings action is a read action that supports finding inspection.
The guardduty:CreateSampleFindings action is a write action that generates samples.
The guardduty:UpdateDetector action is a write action that changes detector configuration.
The guardduty:DeleteDetector action is a write action that deletes the detector.

Keep the simulator results from the previous substep visible.
Take a screenshot that shows each action name with its Allowed decision.
Use the text checkpoint below to classify each action against the analyst's job boundary.

You now have concrete evidence that one broad policy grants investigation plus detector administration. Next up, you will tighten the boundary while keeping investigation available.

Enforce Least-Privilege Access

Your risky-policy simulation proved that the analyst could inspect findings. It also exposed three Amazon GuardDuty write actions that could administer the detector.

Now you will apply least privilege in the IAM Policy Simulator. The new draft preserves investigation access while removing GuardDuty write permissions.

In this step, get ready to:

Replace the broad GuardDuty permissions with focused read and list actions.
Repeat the original simulation with identical test inputs.
Record the new access boundary in your comparison evidence.

Replace broad access with analyst actions

The analyst needs a focused set of read and list actions for investigation. This draft removes every GuardDuty write action from the Allow statement.

Switch back to the Custom mode policy editor from earlier.
Select the entire risky policy draft in the policy editor.
Replace the selected text by pasting the following least-privilege-guardduty-analyst-policy.json policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadGuardDutyFindingsAndUsage",
      "Effect": "Allow",
      "Action": [
        "guardduty:ListDetectors",
        "guardduty:GetDetector",
        "guardduty:ListFindings",
        "guardduty:GetFindings",
        "guardduty:GetFindingsStatistics",
        "guardduty:GetRemainingFreeTrialDays",
        "guardduty:GetUsageStatistics"
      ],
      "Resource": "*"
    }
  ]
}

What does this policy do?

The ReadGuardDutyFindingsAndUsage statement gives the permission boundary a clear purpose.
The GuardDuty Get actions expose investigation details without changing the detector.
The GuardDuty List actions expose the available detectors and findings.
The Resource value remains * for this action set.

Confirm that every entry in the Action list starts with guardduty:Get or guardduty:List.
Confirm that the three write actions from the risky draft no longer appear.

You should now see seven GuardDuty investigation actions in the Allow statement. The policy editor should contain no sample creation, detector update, or detector deletion action.

Policy draft not accepted?

Check that the pasted policy begins with an opening brace and ends with a closing brace. Confirm that each action except the last one has a comma after it.

Compare the Version, Statement, Action, and Resource keys with the reference below.

Help me check my least-privilege policy draft.

✔️ Awesome, I've got everything!

Your Custom mode editor now contains the focused GuardDuty analyst policy. Keep this draft in the simulator for the identical action test.

ⓧ I'd like to double check the full code

Compare the complete policy in your Custom mode editor with this reference.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadGuardDutyFindingsAndUsage",
      "Effect": "Allow",
      "Action": [
        "guardduty:ListDetectors",
        "guardduty:GetDetector",
        "guardduty:ListFindings",
        "guardduty:GetFindings",
        "guardduty:GetFindingsStatistics",
        "guardduty:GetRemainingFreeTrialDays",
        "guardduty:GetUsageStatistics"
      ],
      "Resource": "*"
    }
  ]
}

What should match?

Your draft should contain one Allow statement named ReadGuardDutyFindingsAndUsage. Its action list should contain the same seven entries in the same order.

Repeat the identical test

A fair policy comparison keeps the action set and resource unchanged. Any decision change then comes from the new policy draft.

Before you run this, predict which action will remain allowed.

Keep guardduty:GetFindings, guardduty:CreateSampleFindings, guardduty:UpdateDetector, and guardduty:DeleteDetector selected for simulation.
Keep the simulated resource set to *.
Use the simulator's run control to evaluate the four actions.

You should see guardduty:GetFindings allowed. You should see the three GuardDuty write actions denied.

Why are the write actions denied?

The new policy has no Allow statement that matches the three write actions. IAM therefore applies an implicit deny to each one.

The simulator does not send these requests to GuardDuty. Your enabled detector remains unchanged.

Write actions still allowed?

Confirm that the policy editor contains ReadGuardDutyFindingsAndUsage instead of OverPermissiveGuardDutyAnalyst.

Check the Action list for any remaining GuardDuty write action. Remove any content left over from the risky draft by pasting the complete reference policy again.

Help me understand why my write actions remain allowed.

Explain the access boundary

The comparison record turns simulator output into evidence. It shows that investigation remains available while detector administration falls outside the analyst role.

Add the guardduty:GetFindings allowed decision to your comparison record.
Add the guardduty:CreateSampleFindings denied decision to your comparison record.
Add the guardduty:UpdateDetector denied decision to your comparison record.
Add the guardduty:DeleteDetector denied decision to your comparison record.
Label the three denied actions as outside the security analyst's job.

Keep the live policy separate

The administrator-provided AmazonGuardDutyReadOnlyAccess policy still supplies your live console access. The narrower Custom mode draft remains simulation-only.

Custom mode evaluates the draft without attaching it to your identity. Your original risky-policy evidence also remains available for comparison.

Before the final check, predict what the unchanged action set should prove about the new policy.

Switch back to the current simulator results.
Confirm that guardduty:GetFindings has an allowed decision.
Confirm that the three GuardDuty write actions have denied decisions.
Confirm that the simulated resource remains *.

That is the boundary working: the analyst can inspect findings without changing or deleting the detector. Your identical test now proves that the safer policy caused the decision change.

Your least-privilege policy now protects GuardDuty administration while preserving investigation access. Next, you will use that analyst access to triage a sample finding.

Triage a Sample Finding

Your IAM Policy Simulator comparison now proves that guardduty:GetFindings remains available. It also proves that three GuardDuty write actions are denied.

Least privilege must leave enough evidence for an analyst to make a useful security decision. A sample finding lets you test that workflow without responding to a real incident.

In this step, you'll inspect a safe Amazon GuardDuty sample. You'll turn its JSON evidence into a triage note.

In this step, get ready to:

Identify one sample finding in the agreed Region.
Confirm the finding's sample marker in its complete JSON.
Complete a sample triage note from the supplied evidence.

Select and identify a sample finding

A finding summary gives you the first facts needed for triage. You will capture each fact before opening the deeper evidence.

Switch back to the Amazon GuardDuty Findings page from earlier.
Confirm the page is using the agreed Region.
Select the Title of one finding prefixed with [SAMPLE].

You'll see the details for the selected sample finding. These details establish what GuardDuty detected before you inspect the supporting evidence.

Record the finding title or type here: finding title or type.
Record the displayed severity here: finding severity.
Record the displayed Region here: finding Region.
Record the Resource affected information here: affected resource.

Can't open a sample finding?

Check that the console is using the Region prepared by the administrator.
Ask the administrator to confirm that the sample findings remain available.

Help me find the sample finding.

Inspect the supporting evidence

The finding summary identifies the event at a glance. The complete JSON exposes the supplied activity details that support the finding.

Choose Actions in the finding details.
Choose View and export JSON.

Before you check the marker, where do you expect GuardDuty to identify this finding as sample data?

Locate additionalInfo in the complete JSON.
Check the sample flag inside additionalInfo.

You'll see "sample": true. This confirms that the finding contains safe sample data.

Record one concrete piece of supplied activity, actor, target, or network evidence here: supplied activity, actor, target, or network evidence.

Why the sample marker matters

GuardDuty-generated sample findings use fictitious placeholder values. They let you practise reading evidence without treating the event as a real incident.

Your triage note can recommend a response for an equivalent real event. It must clearly state that no real remediation was performed.

Write the analyst response

A triage note turns raw finding evidence into a decision another analyst can follow. Clear separation between observed facts and recommended actions keeps the response defensible.

What belongs in the triage note?

The identification section records the finding title or type.
The severity field records the displayed severity.
The Region field records where the finding exists.
The affected resource field records the resource named by GuardDuty.
The evidence field records the supplied activity, actor, target, or network detail.
The classification field identifies the finding as sample data.
The immediate containment recommendation field describes a hypothetical response for an equivalent real event.
The next investigation step field states what an analyst should verify next.

Return to the comparison record from earlier.
Add a section titled Sample finding triage note.
Add finding title or type as the finding title or type.
Add finding severity as the severity.
Add finding Region as the Region.
Add affected resource as the affected resource.
Add supplied activity, actor, target, or network evidence as the evidence.
Set the Classification field to Sample finding.

Turn evidence into a response

Your note now identifies the finding from evidence on the screen. The response section should show how those facts guide a hypothetical security decision.

Write an immediate containment recommendation for an equivalent real event.
Write the next investigation step that would test the finding further.
Add No real remediation performed because this is sample data at the end of the note.
Save the updated comparison record.

Before you review the note, would another analyst be able to separate the observed facts from your proposed response?

Check the note against the five response fields above.
Confirm the note includes every recorded finding detail.

You should see the finding title or type. The note should also show its severity, Region, affected resource, and supplied evidence.

Your response section should include classification, immediate containment, and a next investigation step. The final line should state that no real remediation was performed because the finding is sample data.

Does the note feel incomplete?

Compare each field with the finding summary and complete JSON. Keep observed evidence separate from hypothetical recommendations.

Help me review my sample triage note.

Strong finish. You have proved that read-only GuardDuty access still supports a complete sample triage workflow.

Secret mission

Add Explicit Deny Guardrails

A future broad policy could grant detector administration. Add an explicit Deny guardrail that keeps three write actions blocked while finding reads continue.

Clean Up Your Resources

Amazon GuardDuty can incur usage charges after an eligible 30-day trial. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Amazon GuardDuty is pay-as-you-go after an eligible 30-day trial. Charges depend on the volume of data analyzed in the agreed Region.

The Pause and Delete options below prevent additional GuardDuty usage charges. Both options require help from your account administrator.

Resources you used:

One Regional Amazon GuardDuty detector enabled or reused by your account administrator.
GuardDuty sample findings stored with the detector in the agreed Region.
The AmazonGuardDutyReadOnlyAccess policy attached to your existing identity or temporary lab role.
Custom mode permissions from policy-simulator-access-policy.json attached to your existing identity or temporary lab role.

What needs no cleanup?

Your Custom mode policy drafts need no deletion. The AWS Identity and Access Management (IAM) Policy Simulator did not save them or attach them to an identity.

Your completed sample triage note and simulation evidence remain available for future reference.

Keep everything running

No action needed. Choose this if you plan to continue investigating sample findings or testing policy decisions.

Ask your administrator to leave the GuardDuty detector enabled in the agreed Region.
Ask your administrator to monitor estimated monthly spend on the GuardDuty console usage page.
Ask your administrator to confirm the remaining trial days shown in the GuardDuty console.

Pause - I'll come back to this later

Suspend GuardDuty monitoring to stop new findings and usage charges. Existing findings and configuration remain available for your return.

Ask your administrator to switch to the agreed Region in the AWS Management Console.
Ask your administrator to choose Settings in Amazon GuardDuty.
Ask your administrator to use Suspend GuardDuty.

You should see that GuardDuty is suspended in the agreed Region. Existing findings and configuration remain available.

Monitoring stops while the detector is suspended. GuardDuty usage charges also stop.

Delete - I don't want to use this again

Remove the Regional GuardDuty lab and its temporary permissions. Disabling GuardDuty permanently removes the Region's findings and configuration.

This option is final, so your saved triage note and simulation evidence matter. Export any finding details you need before your administrator disables the detector.

Return to the GuardDuty Findings page in the agreed Region.
Select the Title of any finding you need to retain.
Choose Actions.
Choose View and export JSON.
Choose Download.
Ask your administrator to disable Amazon GuardDuty in the agreed Region.
Ask your administrator to detach AmazonGuardDutyReadOnlyAccess from your existing identity or temporary lab role.
Ask your administrator to detach the permissions defined in policy-simulator-access-policy.json from your existing identity or temporary lab role.

Your administrator should confirm that the detector and sample findings are removed from the agreed Region. They should also confirm that both temporary permission sets are detached.

Nice Work!

You did it! You built a read-only Amazon GuardDuty analyst workflow backed by evidence from the AWS Identity and Access Management (IAM) Policy Simulator that keeps finding investigation available while detector administration stays denied.

You've learned how to:

Simulate an over-permissive GuardDuty policy safely in Custom mode to reveal how broad access combines finding reads with detector administration.
Replace broad permissions with a least-privilege analyst policy that preserves finding investigation while GuardDuty write actions receive denied decisions.
Triage a safe sample finding by recording its classification, affected resource, evidence, containment recommendation, and next investigation step.
Secret Mission: Add explicit deny guardrails for critical GuardDuty write actions to prove that protected operations stay denied even when another identity-based policy grants broad access.

Ready to quiz yourself?