Audit an AWS Security Group

Introduction

30 Second Summary

A single setting can look harmless until it opens a door to the whole internet. A useful investigation connects that risky change to a person and a moment in time.

In this project, you will investigate a public SSH rule inside an isolated Amazon Virtual Private Cloud (Amazon VPC) lab. You will use AWS CloudTrail to trace the change before documenting the remediation in a sanitized GitHub incident report.

What You'll Build

You can open your finished GitHub report to walk someone through the risky rule, the identity behind the change, and the clean final state.

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

• Show a safe network baseline with an isolated VPC and a custom security group that contains no inbound rules.
• Recognize unrestricted SSH access when TCP port 22 shows source 0.0.0.0/0. Use CloudTrail Event history to connect the change to its identity, time, source, and Region.
• Publish a sanitized incident report that explains the finding, evidence, remediation, verification, and cleanup decision without exposing account-specific data.
• Secret Mission: independently investigate and remediate an unrestricted RDP rule on TCP port 3389.

Are there any prerequisites?

You need a Windows computer with internet access plus AWS and GitHub accounts. Your AWS account must let you manage VPCs and security groups and view CloudTrail Event history.

Before We Start

Your investigation has more value when you know what you are building before you change any cloud controls. This checkpoint connects the isolated AWS lab to the security investigation skills you want to prove.

Confirm Safe Access and Audit Visibility

Your investigation depends on staying in one AWS Region. AWS CloudTrail Event history is scoped to the Region where each management event occurs.

Before you change a network control, you need reliable access to the AWS Management Console. You also need a clean GitHub session for the sanitized report you publish after remediation.

In this step, get ready to:

• Fix the project to one recorded AWS Region.
• Confirm the recent management-events table loads in CloudTrail without creating audit resources.
• Verify access to the GitHub new-repository page without creating a repository.

Establish AWS access

Every AWS management event belongs to the Region where it occurred. Recording one Region now keeps the later network change aligned with its audit evidence.

Your account credentials stay inside AWS's sign-in flow, so you do not copy them into project notes.

• Switch back to Microsoft Edge.
• Use the address bar to go to the AWS Management Console.

You'll see the AWS sign-in page or the console home page if your session is already active.

• Sign in with your AWS account if prompted.
• Complete any account verification prompt shown during sign-in.

You'll see the AWS Management Console home page when your session is ready.

• Select the current Region name in the console header.

You'll see the AWS Regions available to your account.

• Choose one AWS Region for the entire project.
• Record the displayed Region name here: your selected AWS Region.
• Confirm your selected AWS Region remains visible in the console header.

That Region is now your anchor for every network change and audit search in this lab.

Verify CloudTrail Event history

CloudTrail's built-in Event history gives you a recent management-event record without any setup. It provides the audit view this investigation needs.

• Use the AWS Management Console search bar to search for CloudTrail.
• Select CloudTrail from the search results.

You'll see the CloudTrail console for the currently selected Region.

• Confirm your selected AWS Region remains selected in the console header.
• Choose Event history in the CloudTrail navigation.
• Wait for the recent management-events table to finish loading.

You'll see the table headers with any recent management events available in this Region.

Why Is Event History Enough?

CloudTrail Event history includes the past 90 days of management events in the selected Region. Viewing or searching this history carries no charge.

This lab needs no trail, CloudTrail Lake event data store, or CloudWatch Logs integration.

Table Not Loading?

• Confirm your selected AWS Region is still selected in the console header.
• Refresh the browser page once.
• Confirm your AWS account has permission to view CloudTrail Event history.

Ask for help with an Event history page that will not load.

Confirm GitHub access

GitHub access is the final setup check. Repository creation waits until the risky rule is removed and the full incident story is ready.

GitHub handles its own sign-in flow, so your credentials stay out of the incident report.

• Open a second browser tab in Microsoft Edge.
• Use the address bar in the second tab to go to GitHub.

You'll see the GitHub sign-in page or your existing GitHub session.

• Sign in with your GitHub account if prompted.
• Complete any account verification prompt shown during sign-in.

You'll see your signed-in GitHub home page when the session is ready.

• Choose New repository in GitHub.
• Leave the repository form unchanged.

You'll see the repository setup form. No repository exists because you have not chosen Create repository.

• Pause to predict whether the CloudTrail Event history page remained available in the first browser tab.
• Switch back to the AWS browser tab.
• Confirm your selected AWS Region is still shown in the console header.
• Confirm the recent management-events table remains visible on Event history.

You'll see Event history in your selected AWS Region with the recent management-events table visible. CloudTrail still has no added trail, event data store, or CloudWatch Logs integration.

Your access checks are complete. Next, you'll create the isolated Amazon VPC with a custom security group that starts with no inbound rules.

Build a Safe Network Baseline

You have confirmed that AWS CloudTrail Event history is available in your chosen Region. The investigation now needs a controlled network boundary with no workload to expose.

In this step, you will create an isolated Amazon Virtual Private Cloud (Amazon VPC) with no workload. A custom security group with no inbound rules gives you a safe baseline that makes the later risky change easy to recognize.

In this step, get ready to:

• Create a VPC-only network with a private IPv4 address range.
• Create a custom security group with no inbound rules.
• Verify that the lab contains no workload or path to the internet.

Create the isolated VPC

A VPC provides the network boundary for this investigation. CIDR notation defines the private IPv4 address range available inside that boundary.

• Switch back to the CloudTrail tab from earlier.
• Use the AWS Management Console search bar to search for Amazon VPC.
• Ctrl-click the Amazon VPC result to open it in a new Microsoft Edge tab.

You should see the Amazon VPC console in the same selected AWS Region. Your CloudTrail Event history remains open in its original tab.

• Choose Create VPC.
• Select VPC only.

The form now focuses on the VPC itself. This choice avoids creating subnets or other network resources.

• Enter nw-cloud-audit-vpc in the Name tag field.
• Choose the manual IPv4 CIDR input option.

The form is now ready for the lab's private address range.

• Enter 10.0.0.0/24 in the IPv4 CIDR block field.
• Keep Tenancy set to default.

Your VPC configuration now has the required name and IPv4 range. Default tenancy keeps the lab on the standard shared AWS infrastructure.

• Leave the IPv6 CIDR setting unconfigured.
• Choose Create VPC.

Good progress. You should see nw-cloud-audit-vpc in the VPC list with the IPv4 CIDR 10.0.0.0/24.

VPC creation blocked?

• Confirm that the console header still shows the AWS Region you selected earlier.
• Check that the IPv4 CIDR contains 10.0.0.0/24 with no spaces.
• Ask your AWS administrator for permission to create VPCs if the console reports an authorization problem.

Help me diagnose why my VPC was not created. If the issue is account-specific, share the sanitized error text in the NextWork community.

Create the clean security group

A security group controls the traffic allowed to reach attached resources. A new security group starts with no inbound rules while retaining a default outbound rule.

Why use an unattached security group?

The VPC-only design creates no subnet or compute resource. The security group therefore remains unattached to any workload.

Later, you can study a risky rule without exposing a running service. This keeps the investigation focused on configuration and audit evidence.

• Choose Security groups in the Amazon VPC console navigation.
• Choose Create security group.

You should see the form for defining the new security group.

• Enter nw-cloud-audit-sg as the security group name.
• Enter Controlled cloud security investigation as the description.

The group now has a recognizable name and a description that states its purpose.

• Select nw-cloud-audit-vpc in the VPC field.
• Leave the Inbound rules section empty.

The group is now tied to your isolated VPC. Its inbound baseline allows no incoming traffic.

• Retain the default rule in the Outbound rules section.
• Choose Create security group.

That is the core baseline in place. You should see nw-cloud-audit-sg associated with nw-cloud-audit-vpc.

Security group missing?

• Confirm that you created the group in nw-cloud-audit-vpc.
• Clear any existing table filters that could hide the new group.
• Check your AWS permissions if the create action was rejected.

Help me find or create the security group safely. If the problem depends on your account permissions, share the sanitized error text in the NextWork community.

Verify the isolated baseline

The final check proves that the lab contains only a network boundary and its security group. The absence of workloads keeps the later risky rule controlled.

• Choose Your VPCs in the Amazon VPC console navigation.
• Select nw-cloud-audit-vpc.
• Record the displayed VPC ID here: your nw-cloud-audit-vpc ID.
• Choose the Resource map tab.
• Choose Show details.

You should see no subnet tiles for nw-cloud-audit-vpc. The network connections area should list no internet gateway.

• Use the AWS Management Console search bar to search for Amazon EC2.
• Ctrl-click the Amazon EC2 result to open it in a new Microsoft Edge tab.

The Amazon EC2 console opens in the same selected Region. Its resource lists let you confirm that the VPC has no workload.

• Choose Instances in the navigation pane.
• Apply the VPC ID filter with your nw-cloud-audit-vpc ID.

You should see no matching EC2 instances. This confirms that the lab contains no compute workload.

• Choose Network Interfaces in the navigation pane.
• Apply the VPC ID filter with your nw-cloud-audit-vpc ID.

You should see no matching network interfaces. With no interface or instance in this VPC, the lab has no assigned public IPv4 address.

What do these checks prove?

The resource map confirms that the VPC has no subnet or internet gateway. The Amazon EC2 resource lists confirm that it has no instance or network interface.

Your security group is therefore unattached to a workload. The later rule change alters the configuration without exposing a live server.

• Close the Amazon EC2 tab to return to the Amazon VPC console.
• Choose Security groups in the navigation.
• Select nw-cloud-audit-sg.
• Choose the Outbound rules tab.

You should see the default outbound rule retained. This confirms that only the inbound side is locked down for the baseline.

Before you inspect the inbound table, do you expect to see any rule that allows traffic into this security group?

• Choose the Inbound rules tab.

You should see no inbound entries. Your custom security group now matches the clean baseline required for the investigation.

See an inbound rule?

• Confirm that the selected group is nw-cloud-audit-sg.
• Confirm that the selected VPC is nw-cloud-audit-vpc.
• Remove any accidental inbound rule before continuing to the next step.

Help me restore the security group to a safe baseline. Share only sanitized details in the NextWork community if you need account-specific help.

Your isolated network baseline is ready. Next, you will add one controlled SSH rule and see how quickly a single entry changes the security posture.

Introduce and Assess a Risky SSH Rule

Your isolated Amazon VPC lab now gives you a clean baseline. Its custom security group has no inbound rules.

A safe baseline alone does not show how one rule creates unnecessary exposure. In this step, you will add public SSH access to the unattached group.

You will assess the rule against a published security control. Finally, you will test what the rule table can prove about the change.

In this step, get ready to:

• Add an unrestricted IPv4 SSH rule to the isolated security group.
• Assess the rule against AWS Security Hub control EC2.13.
• Test how much investigative context the security group page provides.

Add a public SSH rule

An inbound rule defines which incoming connections an attached resource could accept. This rule uses a public source to demonstrate a risky network control.

This controlled change affects only an unattached rule set. No running service becomes reachable in this lab.

• Return to the Amazon VPC console from earlier.
• Choose Security groups in the left navigation panel.
• Select nw-cloud-audit-sg.
• Choose Edit inbound rules.
• Choose Add rule.
• Select SSH for the Type.
• Select Anywhere-IPv4 for the Source.

• Enter Temporary public SSH test in the Description field.
• Choose Save rules.

You have the controlled SSH change in place. The Inbound rules tab now shows one rule with protocol TCP. Its port is 22. Its source is 0.0.0.0/0.

What does 0.0.0.0/0 mean?

The value 0.0.0.0/0 uses CIDR notation to cover every IPv4 address. The console represents this source as Anywhere-IPv4.

If this group protected a reachable workload, the rule could allow SSH connection attempts from anywhere on the public internet. AWS recommends limiting access to the specific address ranges that require it.

Rule missing after the save?

• Confirm that nw-cloud-audit-sg remains selected.
• Confirm that the AWS console still shows your selected Region.
• Choose Edit inbound rules to check whether the new row was saved.

Ask for help with the exact values you can see: help me find why my SSH inbound rule is missing after I saved it

Assess the unrestricted exposure

The published AWS Security Hub controls provide a precise benchmark for unrestricted remote administration. You can use the benchmark without enabling the service in your account.

• Open the AWS Security Hub EC2 controls reference in another Microsoft Edge tab.
• Find control EC2.13 on the page.
• Compare the rule's port 22 with the control's failure criteria.
• Compare the rule's source 0.0.0.0/0 with the control's failure criteria.

Your rule meets the failure condition in EC2.13. The control classifies unrestricted ingress to SSH port 22 as a High severity finding.

Why use a published control?

A published control gives your assessment a repeatable standard. It connects the visible rule to a documented security risk.

The documented remediation is to remove the unrestricted rule. You will complete that remediation after gathering the audit evidence.

Identify the missing audit context

The control explains why the current configuration is risky. Now test whether the security group page provides enough evidence to investigate how the rule appeared.

• Before you inspect the row again, predict whether it can identify who saved the change and when.

• Return to the Inbound rules tab for nw-cloud-audit-sg.
• Review every field displayed for the SSH rule.
• Check whether the row identifies the person or role that made the change.
• Check whether the row displays the source IP address behind the change.
• Check whether the row displays the exact time of the change.

The rule table shows the current network configuration. It does not show the identity behind the change, the actor's source IP address, or the exact change time.

That shortfall is intentional. Without attribution evidence, you cannot distinguish an approved test from an unauthorized change.

• Before the final check, predict whether the saved SSH rule still matches the values you selected.

• Select nw-cloud-audit-sg in the Security groups table.
• Choose the Inbound rules tab.

You should see exactly one inbound rule. It shows TCP port 22 from 0.0.0.0/0 with the description Temporary public SSH test.

You have exposed the investigation gap while keeping the lab isolated. Next, you will return to AWS CloudTrail to attribute the authorization action to its audit context.

Trace the SSH Change in CloudTrail

The unrestricted SSH rule is now visible in your security group. The rule table cannot attribute the change to an identity, a source address, or an exact time.

AWS CloudTrail records management events that provide this missing context. In this step, you will find the authorization event before capturing a sanitized evidence summary.

In this step, get ready to:

• Filter recent Event history for the SSH authorization action.
• Inspect the event record for attribution details.
• Capture a sanitized evidence summary without account-specific data.

Find the authorization event

Event history is scoped to one AWS Region. Filtering the recent window keeps your search focused on the authorization action you just performed.

• Switch back to the CloudTrail tab from earlier.
• Confirm the Region selector still shows the Region you selected earlier.

You should see the same Region that contains nw-cloud-audit-vpc and nw-cloud-audit-sg.

• Set the Relative range time filter to 1 hour.
• Choose Event name as the lookup attribute.

The filter bar now targets events from the last hour by event name.

Before you apply the lookup, do you expect the security group name or the API action name to identify this change?

• Enter AuthorizeSecurityGroupIngress as the full event-name value.

You should see a matching AuthorizeSecurityGroupIngress row near the time when you added the SSH rule.

Authorization Event Missing?

A short wait here is normal. AWS does not publish a guaranteed delay for new events to appear in Event history.

• Confirm CloudTrail still shows the same Region as the security group.
• Keep the time filter set to 1 hour.
• Refresh the Event history table.

You can ask for help finding the missing authorization event or share your sanitized symptoms in the NextWork community.

Inspect the event record

The matching event connects the current rule to the action that created it. Its record separates the time, identity context, request origin, Region, client context, and requested change into distinct fields.

• Open the matching event by selecting its event name.
• Find the Event record section in the event details.

You should see a structured event record containing named fields for the management action.

What Do These Fields Prove?

• The eventTime field establishes when the change occurred.
• The userIdentity field identifies the actor context.
• The eventName field identifies the API action.
• The awsRegion field identifies where AWS recorded the action.
• The sourceIPAddress field records the request origin.
• The userAgent field records the client context.
• The requestParameters field describes the requested ingress change.

• Inspect eventTime for the approximate time of the change.
• Inspect userIdentity for the identity type.
• Confirm eventName identifies AuthorizeSecurityGroupIngress.
• Check awsRegion against your selected Region.
• Inspect sourceIPAddress for the request origin.
• Inspect userAgent for the tool context.
• Inspect requestParameters for the inbound rule details.

The eventName field should show AuthorizeSecurityGroupIngress. The requestParameters field should describe the SSH ingress request for TCP port 22 from 0.0.0.0/0.

Rule Details Do Not Match?

• Return to the Event history table.
• Choose the authorization event closest to the time when you added the SSH rule.
• Check its requestParameters for TCP port 22 and source 0.0.0.0/0.

You can ask for help identifying the correct CloudTrail event or share a sanitized description in the NextWork community.

Record sanitized evidence

The checkpoint below is your private draft space. Your summary needs enough detail to prove the finding without copying account-specific data.

Protect Account-Specific Details

Include these investigation details in your summary:

• Event name: AuthorizeSecurityGroupIngress.
• Approximate time from eventTime.
• Identity type from userIdentity.
• Selected Region from awsRegion.
• Tool context from userAgent at a high level.
• Affected rule showing SSH TCP port 22 from 0.0.0.0/0.
• Risk created by unrestricted IPv4 access to SSH.

Exclude raw event JSON, AWS account IDs, full source IP addresses, credentials, and session identifiers.

• Compose your sanitized SSH authorization evidence in the checkpoint below.

Before your final check, which fields do you expect to prove the action, actor context, time, request origin, and Region?

• Switch back to the open Event record from earlier.
• Compare your sanitized summary against the seven fields you inspected.

You should see AuthorizeSecurityGroupIngress in eventName. The record should also show eventTime, userIdentity, sourceIPAddress, awsRegion, userAgent, and requestParameters for the SSH ingress request.

That closes the attribution gap. Your sanitized evidence now connects the risky SSH rule to its management event without exposing account-specific details.

Next, you will remove the risky rule. Then you will verify the revocation before publishing the sanitized incident report.

Remediate the Risk and Publish the Report

Your AWS CloudTrail investigation identified the management event behind the public SSH rule in the security group. The risky rule still exists in nw-cloud-audit-sg.

A complete investigation removes the exposure. It also proves the remediation through independent audit evidence.

You will publish the final evidence in a public GitHub repository. The report will show both events without exposing account-specific data.

In this step, get ready to:

• Remove the unrestricted SSH rule from nw-cloud-audit-sg.
• Verify the rule removal through its CloudTrail management event.
• Publish a sanitized incident report in a public GitHub repository.

Remove the public SSH rule

The inbound rule still permits SSH traffic from every IPv4 address. Removing it returns the unattached lab security group to its safe baseline.

• Switch back to the Amazon Virtual Private Cloud (Amazon VPC) console from earlier.
• Select Security groups in the left navigation pane.
• Select nw-cloud-audit-sg from the security group list.
• Choose Edit inbound rules.
• Choose Delete beside the TCP port 22 rule from 0.0.0.0/0.
• Choose Save rules.

Before you inspect the result, do you expect any inbound entries to remain?

• Open the Inbound rules tab for nw-cloud-audit-sg.

You should see no inbound entries. The default outbound rule remains unchanged.

That is the exposure closed. Your security group is back to its clean baseline.

Rule still visible?

• Return to Edit inbound rules for nw-cloud-audit-sg.
• Confirm the removed rule used TCP port 22 with source 0.0.0.0/0.
• Choose Save rules again.

Help me remove the public SSH rule from my unattached AWS security group.

Verify the remediation in CloudTrail

CloudTrail records the removal as a separate management action. That event provides independent evidence that the risky rule was revoked.

Before you filter the history, do you expect the removal to have its own event or only alter the original event?

• Switch back to the CloudTrail Event history from earlier.
• Confirm that the console header shows the same AWS Region used for the lab.
• Change the lookup attribute to Event name.
• Enter RevokeSecurityGroupIngress in the lookup value field.
• Refresh the Event history if the matching event is not visible.
• Open the matching RevokeSecurityGroupIngress event.
• Inspect the Event record for eventTime, userIdentity, awsRegion, sourceIPAddress, userAgent, and requestParameters.

You should see a RevokeSecurityGroupIngress event for the removed SSH TCP port 22 rule. This is the audit evidence for your remediation.

Remediation event missing?

• Confirm that CloudTrail shows the same AWS Region as nw-cloud-audit-vpc.
• Refresh the filtered Event history because new management events may take time to appear.

Help me find the CloudTrail event for my security group rule removal.

• Record a sanitized revocation summary with the approximate time, identity type, Region, tool used, affected rule, and remediation result.
• Exclude raw event JSON, account IDs, full source IP addresses, credentials, and session identifiers from the summary.

Publish the sanitized incident report

A public incident report should preserve the investigation method while removing sensitive account details. Your two sanitized summaries provide the evidence for that report.

• Switch back to the GitHub new-repository page from earlier.
• Select your GitHub account as the repository owner.
• Enter aws-security-group-incident-lab as the repository name.
• Set the repository visibility to public.
• Enable the option to add a README.
• Choose Create repository.

You should see the new aws-security-group-incident-lab repository with README.md listed.

Your investigation now has a public home. Next, you will turn the private evidence notes into a focused incident report.

Structure the incident report

Use the first five sections to establish what happened:

• Use Scenario to explain the controlled SSH test inside the isolated lab.
• Use Safe Baseline to describe the VPC-only environment with an empty inbound baseline.
• Use Finding to document TCP port 22 with source 0.0.0.0/0.
• Use Sanitized Evidence to summarize AuthorizeSecurityGroupIngress plus RevokeSecurityGroupIngress.
• Use Risk Assessment to explain the exposure identified by control EC2.13.

Use the final four sections to show how you closed the incident:

• Use Remediation to document removal of the public SSH rule.
• Use Verification to record the empty inbound-rule list.
• Use Cost Controls to explain how the lab avoided compute resources and metered network resources.
• Use Lessons Learned to explain how configuration evidence and audit evidence answer different investigation questions.

• Select README.md in the repository file list.
• Choose the file editing control above the README.
• Replace the starter content with your incident report using the section plan above.
• Choose Preview.

Your preview should show all nine report sections in a readable order. Each evidence section should use sanitized summaries instead of raw CloudTrail records.

• Confirm that the preview contains no raw CloudTrail JSON or account-specific identifiers.
• Choose Commit changes....
• Enter Document SSH security group incident as the commit message.
• Choose Commit changes.

Before your final review, do you expect the current security group state and both CloudTrail actions to tell one complete story?

• Return to the Amazon VPC console from earlier.
• Select nw-cloud-audit-sg.
• Open the Inbound rules tab.
• Confirm that the inbound-rule list has no entries.
• Return to the public aws-security-group-incident-lab repository.
• Confirm that README.md documents both management event names.
• Confirm that README.md records the clean final state.

You should see an empty inbound-rule list plus a public repository with the committed incident report. You have closed the risk, verified the remediation, and published the sanitized evidence.

Secret mission

Investigate a Public RDP Rule

Apply your audit method to an unrestricted RDP rule on TCP port 3389. Trace its authorization, remove the rule, verify the revocation, and add the sanitized evidence to your public incident report.

Clean Up Your Resources

Clean Up Your Resources

This lab has no ongoing costs. The isolated Amazon Virtual Private Cloud (Amazon VPC) plus its custom security group carry no additional charge.

Built-in AWS CloudTrail Event history is free for this project. Decide whether to keep the lab, pause safely, or delete the lab entirely.

Resources you used:

• VPC nw-cloud-audit-vpc with IPv4 CIDR 10.0.0.0/24 in your selected AWS Region.
• Custom security group nw-cloud-audit-sg with no inbound rules.

Your public GitHub repository aws-security-group-incident-lab stays outside this cleanup as sanitized evidence. Built-in CloudTrail Event history is audit history, so there is no trail or event data store to remove.

Keep everything running

No action is required. Choose this if you want to review the investigation lab again.

• Return to the Amazon VPC console from earlier.
• Choose Security groups.
• Select nw-cloud-audit-sg.
• Choose Inbound rules.

You'll see no inbound entries. This confirms that the retained lab has no public SSH or RDP access.

Pause - I'll come back to this later

No compute resource is running in this lab, so there is nothing to stop. Pausing means leaving the clean AWS resources in place for a later review.

• Return to the security group list in the Amazon VPC console from earlier.
• Select nw-cloud-audit-sg.
• Choose Inbound rules.

You'll see an empty inbound rule list. This proves the lab is in its clean state before you step away.

• Sign out of AWS.

The VPC remains ready for a later review. The clean security group remains unattached.

Delete - I don't want to use this again

Deleting the lab can feel final. It only removes the isolated AWS resources listed above.

• Return to the Amazon VPC console in your selected AWS Region.
• Choose Your VPCs.
• Select nw-cloud-audit-vpc.
• Choose Actions.
• Choose Delete VPC.
• Enter delete.
• Choose Delete.

You'll no longer see nw-cloud-audit-vpc in the VPC list. The console also removes its custom security group.

• Choose Security groups.
• Confirm nw-cloud-audit-sg is no longer listed.

That closes the AWS lab cleanly. Your public incident report remains available in GitHub.

Nice Work!

Nice Work!

You did it! You built an isolated AWS security investigation lab with a clean final state.

You've learned how to:

• Build an isolated network baseline inside Amazon VPC using an unattached custom security group. Recognize the exposure created by SSH TCP port 22 from 0.0.0.0/0.
• Use AWS CloudTrail Event history to attribute the AuthorizeSecurityGroupIngress action. Repeat the investigation for RevokeSecurityGroupIngress. Remove the risky rule to restore a clean inbound baseline.
• Publish a sanitized GitHub incident report covering the finding, evidence, risk assessment, remediation, verification, cost controls, and lessons learned. Keep account-specific identifiers out of the public record.
• Complete the Secret Mission by independently investigating an unrestricted RDP rule on TCP port 3389. Trace its authorization event. Trace its revocation event. Return nw-cloud-audit-sg to no inbound rules.

Ready to quiz yourself?