DEV Community: Gerardo Castro Arica

Mutable tags. 10,000 pipelines. One credential. — What the Trivy attack taught me about implicit trust

Gerardo Castro Arica — Fri, 27 Mar 2026 16:25:45 +0000

A few days ago I was designing a GitHub Actions pipeline with security scanning tools. Choosing what to integrate, how to structure it, what permissions to give it — especially for the context of the project I was building it for. The kind of work that feels productive — you're building something that will improve the team's security posture.

That's when I found out what had happened to Trivy.

On March 19, 2026, TeamPCP compromised the most widely used open-source vulnerability scanner in the cloud-native ecosystem. They didn't hack a business application. They didn't exploit a vulnerability in production code. They compromised the tool that thousands of organizations use to find vulnerabilities in their own applications. The security scanner became the weapon.

That made me stop. Not to throw the pipeline away — but to rethink from what principles I was building it.

This post is not a threat intelligence analysis. I'm a practitioner who is learning more and more about building security pipelines and who reflected on this case. What I found along the way changed how I think about trust in external dependencies.

What exactly happened?

The attack wasn't a single event — it was a multi-phase campaign that lasted several days and started earlier than most people think.

Three weeks before March 19, an automated bot called hackerbot-claw exploited a misconfigured workflow in the Trivy repository and stole a Personal Access Token. Aqua Security detected the incident and rotated credentials — but the rotation was incomplete. TeamPCP retained access to the credentials that survived. That's what made everything that followed possible. [Palo Alto Networks]

On March 19 at 17:43 UTC, using those retained credentials, TeamPCP compromised three components simultaneously:

The Trivy binary. A malicious version — v0.69.4 — was published across all official distribution channels: GitHub Releases, Docker Hub, GHCR, ECR Public, deb/rpm repositories, and get.trivy.dev. The scanning logic lives in this binary. The other two components are wrappers that invoke it. [Wiz Research]

trivy-action. The GitHub Action most teams use to integrate Trivy into their pipelines. TeamPCP force-pushed 76 of 77 version tags to point at malicious commits. Pipelines referencing these actions by tag began executing the attacker's code on their next run — with no visible change to the tag name or the releases page. [Microsoft Security Blog]

setup-trivy. The Action that installs the binary. All 7 existing tags were compromised in the same way.

The payload was an infostealer that harvested SSH keys, cloud tokens, Kubernetes credentials, and pipeline environment variables — all while Trivy ran normally and produced the expected output. To an engineer reviewing the logs, the step appeared successful. [SANS Institute]

Exposure windows ranged from 3 to 12 hours depending on the component. Three days later, on March 22, TeamPCP published additional malicious images on Docker Hub — v0.69.5 and v0.69.6 — using separately compromised Docker Hub credentials, extending exposure by another ~10 hours. [Legit Security]

According to SANS Institute, more than 10,000 CI/CD workflows are reported to have been affected.

They didn't exploit code — they exploited trust

When most teams think about an attack, they picture someone finding a buffer overflow, an SQL injection, an RCE. A technical vulnerability in the code that needs to be patched.

TeamPCP did none of that.

They didn't find a bug in Trivy. They didn't break any cryptographic algorithm. They exploited something much harder to patch: the implicit trust logic that organizations place in their dependencies. The premise that if a tool comes from the official vendor, through the official channel, with the official tag — it's safe.

That premise is what failed.

There's a brutal irony in how the impact was distributed. The most diligent teams — the ones who had integrated Trivy into every PR, every merge, every deploy — were the most exposed. The more disciplined the team was about running their security pipeline, the more times the infostealer ran. The good practice became the attack vector. [SANS Institute]

This is not an argument to stop scanning. It's an argument to understand that trusting an external tool without verifying its integrity is exactly the same as trusting a user without verifying their identity. In IAM, nobody accepts that. In dependencies, we accept it all the time.

The expansion of the attack confirms it. TeamPCP didn't stop at Trivy. On March 23 they compromised Checkmarx KICS — the infrastructure-as-code scanner. On March 24 they reached LiteLLM on PyPI, using credentials stolen from BerriAI's Trivy pipeline. According to SANS Institute, one stolen token propagated across five distinct ecosystems: CI/CD, npm, Docker, PyPI, and AI infrastructure. [Arctic Wolf]

TeamPCP isn't targeting business applications. It's targeting the security tooling ecosystem — exactly the tools that the most security-conscious teams have integrated into their pipelines.

Mutable tags: not the vector, but the multiplier

When the attack was reported, much of the media focus fell on mutable tags. That makes sense — it's the most striking technical detail. But it's worth understanding exactly what role they played, because they weren't the entry vector — they were what turned a single point of access into a massive problem.

To understand the difference, three concepts need to be separated.

The attack vector was the retained credential — the Personal Access Token that survived an incomplete rotation from a prior incident. That credential with write permissions over Aqua Security's repositories is what gave TeamPCP initial access. Without it, nothing that followed would have been possible. [Palo Alto Networks]

The attack surface was the CI/CD pipelines of thousands of organizations referencing Trivy and its GitHub Actions by tag. Every pipeline running uses: aquasecurity/trivy-action@v0.35.0 was an exposed surface — not because it had a vulnerability, but because its trust model depended on the immutability of a tag that wasn't immutable. According to SANS Institute, more than 10,000 CI/CD workflows were part of that surface.

Mutable tags were the multiplier. Once TeamPCP had access, tag mutability allowed them to silently redirect 76 of 77 tags in trivy-action and all 7 tags in setup-trivy to malicious commits — with no visible change in names, dates, or release pages. [Microsoft Security Blog]

Now, the fundamental difference between a tag and a digest.

A tag is a named pointer — v0.35.0, latest, v0.69.4. In Git and container registries, that name can be redirected to any commit or image without the name changing. No notification. No alert. No visible change on the releases page.

A digest is the SHA256 of the actual content — sha256:a3f8d2c1.... It's immutable by definition. If the content changes, the digest changes. It can't be forged, it can't be redirected. Referencing a dependency by digest anchors it to a specific verified piece of content.

Any pipeline referencing those actions by tag began executing malicious code on its next run. Without any visible change. Without any alert. If those same pipelines had referenced the actions by digest, the force-push would have had no effect. The digest would still point to the original commit. The blast radius would have been dramatically smaller. [Legit Security]

Supply chain security = least privilege applied to dependencies

There's a principle any engineer working with AWS knows by heart: least privilege. You don't give a role more permissions than it needs. You don't create access keys when you can use temporary roles. You don't leave a * in a Resource when you can specify the exact ARN.

It's the most repeated principle in cloud security. And yet, when it comes to external dependencies, we systematically ignore it.

When a pipeline runs uses: aquasecurity/trivy-action@v0.35.0, it's placing full trust in that tag — without verifying its integrity, without anchoring to specific content, without questioning whether the pointer still points to what it pointed to yesterday. It's the equivalent of giving AdministratorAccess to a role because "it's easier." It works. Until it doesn't.

Supply chain security isn't a separate domain from the security you already practice. It's the same least privilege principle applied to a different level: your dependencies. The question isn't "do I trust this tool?" — it's "what verification do I have that what I'm executing is exactly what I think it is?"

The expansion of the attack illustrates why this matters at scale. TeamPCP didn't need to compromise each organization individually. It compromised a central tool in the ecosystem and let implicit trust do the rest. LiteLLM was compromised because its pipeline used Trivy — the infostealer stole the PyPI publishing token, and from there TeamPCP published malicious versions with 3.6 million daily downloads. [SANS Institute]

One token. Five compromised ecosystems. That's the geometry of a well-executed supply chain attack.

What makes this case especially uncomfortable is that the victims weren't careless teams. They were teams that had invested in security, that scanned their pipelines, that used cloud-native tooling. Diligence didn't protect them — because the diligence was applied inside the trust perimeter, not at the perimeter itself.

The solution is not to stop using external tools

The wrong conclusion from this incident would be to stop using Trivy, to distrust all open-source tools, or to build everything in-house. That's neither viable nor the right lesson.

The lesson is that trust in external dependencies needs to be explicit and verifiable — not implicit and assumed.

Digest pinning

The most concrete and immediate change is to reference GitHub Actions by digest instead of by tag.

Instead of this:

- uses: aquasecurity/trivy-action@v0.35.0

This:

- uses: aquasecurity/trivy-action@sha256:57a97c7...

The digest anchors the pipeline to a specific verified piece of content. If someone force-pushes the tag, the pipeline keeps executing the original commit. Tag mutability stops being a problem because the pipeline doesn't depend on the tag. [Legit Security]

The obvious objection is that this makes updates harder — and it's valid. A fixed digest doesn't update itself. That's where the second part comes in.

Dependabot and Renovate

Dependabot and Renovate can manage GitHub Actions updates automatically, including digest pinning. When a new verified version is released, they open a PR with the updated digest. The team reviews, approves, and the pipeline updates in a controlled and auditable way.

The combination closes the loop: digest pinning eliminates exposure to mutable tags, and Dependabot/Renovate eliminates the friction of maintaining digests manually.

Confirmed safe versions

For those using Trivy at the time of the incident, confirmed safe versions are: Trivy binary v0.69.3 or earlier, trivy-action v0.35.0 at commit 57a97c7, setup-trivy v0.2.6 at commit 3fb12ec. Any reference to v0.70.0 in logs should be treated as suspicious — the attacker attempted to publish that version but was stopped before the tag was pushed. [Legit Security]

Secrets: less is more

One thing this incident makes clear is the problem of pipelines that inherit more secrets than they need. If a scanning job doesn't need production credentials, it shouldn't have them — regardless of whether they're temporary or static. Applying least privilege to what secrets get passed to each job reduces the blast radius when a tool is compromised.

Immediately rotate any credential that was exposed to a pipeline that ran compromised versions of Trivy between March 19 and March 22. That includes GitHub tokens, cloud credentials, registry tokens, SSH keys, and database passwords. [Legit Security]

Closing — what happened in LATAM

All of the above reflection could remain theoretical if it weren't for someone in our community who lived this in real time.

Alejandro Castañeda, AWS Community Builder and Cloud Engineer from Colombia, shared on LinkedIn what happened to his team. His pipeline was compromised. The infostealer ran on a self-hosted runner inside his EKS cluster and sent approximately 80KB to the attacker's server. To put that in perspective: 80KB is enough to carry away all the secrets from a complete pipeline.

And yet, they reviewed CloudTrail top to bottom and the result was zero lateral movement. No API calls from the attacker's IP. No IAM user creation, no policy changes, no resource access.

Why?

Because Alejandro's team had made an architecture decision ahead of time, when they were defining the foundations of their infrastructure: OIDC with IAM Roles instead of static access keys. Their pipelines assumed temporary roles that expired in minutes. By the time the attacker had the credentials in hand, they were already worthless. And the role's trust policy only allowed use from GitHub — so even if they hadn't expired, they couldn't be used from anywhere else.

If they had had static access keys stored as GitHub secrets, the story would be completely different. The attacker would have had access to ECR to inject malicious images into production containers, and to Secrets Manager to read database credentials and financial service tokens.

The difference between "our secrets were stolen and nothing happened" and a real disaster was an architecture decision that nobody made thinking about this specific attack. They made it because it was the right way to build.

That's what I take from this incident. Not the list of affected versions — that changes. Not the name of the threat actor — that changes too. What doesn't change is the principle: design so that when someone compromises a dependency, they don't find anything useful on the other side.

Security isn't about building a perfect wall. It's about making sure that when someone jumps it, there's nothing useful on the other side.

About the author

Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. Founder and Lead Organizer of the AWS Security Users Group LatAm. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.

🔗 GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro

I automated an AWS Security Maturity Model recommendation across 40 accounts — design decisions included

Gerardo Castro Arica — Wed, 25 Mar 2026 12:00:00 +0000

The AWS Security Maturity Model has a recommendation in Phase 1 — Quick Wins that seems trivial: assign a security contact in each account of your AWS Organization.

It's not glamorous. It doesn't have a complex architecture diagram. It doesn't require enabling any new service. It's literally filling out a form with a name, an email, and a phone number.

And yet, in most organizations I work with in LATAM, it isn't done.

Not because nobody knows about it — but because in environments with dozens of accounts, "filling out a form" becomes a manual process that depends on someone remembering, having access, and doing it correctly in each account. And when Control Tower provisions a new account, that process starts from scratch all over again.

The question that kicked off this project was simple: why am I doing this by hand?

The problem

An active AWS Organization isn't static. New projects arrive, development environments get created, teams join. With Control Tower, provisioning a new account takes minutes — and that's exactly what you want. The problem is what happens after provisioning.

Every new account is born without a security contact. AWS uses that contact to send critical alerts — abuse notifications, credential compromises, active vulnerabilities in your resources. If it isn't configured, those alerts go to the root account email, which in most cases nobody actively monitors.

In an organization with 10 accounts, you can manage it by hand. With 20, you start missing things. With 40, it's systematically inconsistent.

The maturity model is clear about this: it's not an advanced recommendation. It's in Phase 1. It's baseline. It's what you should have solved before anything else. And "solved" doesn't mean doing it once for the accounts that exist today — it means any account created tomorrow also has it, automatically, without anyone having to remember.

That requires automation. Not a runbook, not a checklist — real automation that reacts to the right event and doesn't depend on human intervention.

The architecture

The most important design decision in this project isn't the Lambda — it's where it lives and how it gets triggered.

The obvious temptation is simple: create an EventBridge rule in the Management account that invokes the Lambda directly. It works. But it creates coupling you'll regret later: the Management account knows a Lambda exists, knows where it is, and needs permissions to invoke it cross-account. Every new consumer of that event requires touching the Management account.

The right solution is a Custom Event Bus in the Security account.

Control Tower (Management)
  → EventBridge Rule
  → Custom Event Bus (Security)
  → EventBridge Rule
  → Lambda
  → account API (all accounts)
  → Slack notification

The flow is: Management publishes the event to the Bus. Security has its own rules that decide what to do with it. Management knows nothing about the Lambda — it only knows there's a Bus to send events to.

What you gain from this is real extensibility. The Custom Event Bus in Security becomes the central point for organization events. When tomorrow you want to react to the same event in a different way — send to a SIEM, trigger another automation, notify a different channel — you add a rule to the Bus. The Management account isn't touched. That's the kind of decision that seems like overhead at first and that you appreciate when the system grows.

CreateManagedAccount, not CreateAccount

When Control Tower provisions an account, AWS emits two distinct events at different moments in the process. Confusing them is one of the easiest mistakes to make — and one of the hardest to diagnose because both seem correct on paper.

CreateAccount is emitted when the creation process begins. At that point, the account exists in Organizations but Control Tower hasn't finished configuring it yet. If you trigger the Lambda with that event, you attempt to assign the security contact on an account that isn't fully accessible yet. The result is an error that looks like a permissions problem — and one that will have you spending time reviewing IAM policies that are perfectly fine.

CreateManagedAccount is emitted when Control Tower finishes provisioning. The account is ready, the roles are deployed, you can operate on it. This is the correct event.

But there's a second, subtler trap. The event's detail-type isn't AWS Control Tower via CloudTrail as you might assume — it's AWS Service Event via CloudTrail. This detail isn't well documented and there's only one way to discover it: opening CloudTrail, finding the actual event emitted when CT provisioned an account, and reading the full JSON.

The correct EventBridge rule looks like this:

{
  "source": ["aws.controltower"],
  "detail-type": ["AWS Service Event via CloudTrail"],
  "detail": {
    "eventName": ["CreateManagedAccount"]
  }
}

If you use CreateAccount or the wrong detail-type, the rule never fires — or fires at the wrong moment. In both cases, the security contact isn't assigned and there's no visible error telling you why.

The Lambda and idempotency

The most important behavior of this Lambda isn't what it does when it finds an account without a contact — it's what it does when it finds an account that already has the correct one.

It does nothing.

That seems obvious, but it has concrete design implications. The Lambda doesn't blindly call PutAlternateContact on every account. It first calls GetAlternateContact, reads the current value, compares it to the expected one, and only acts if there's a real difference. If the contact exists and is correct, the account is marked as "unchanged" and the process moves on.

current = get_contact(account_id, is_management)
if current == expected:
    results["unchanged"] += 1
    continue

set_contact(account_id, is_management)
results["assigned"] += 1

This makes the Lambda idempotent: you can run it a hundred times with the same result. There's no risk of overwriting a contact someone updated manually in a specific account — if the values match, it doesn't touch anything.

Idempotency also solves the problem of existing accounts. A reactive trigger that only responds to CreateManagedAccount covers new accounts, but not the 40 that already existed before deploying the tool. The solution is to run the Lambda once across the entire organization on the first deploy — same code, no additional logic, because idempotency guarantees it won't break anything that's already correctly configured.

The summary of each execution arrives via Slack:

✅ Security Contact Enforcer
Accounts processed: 40
Assigned: 3
Updated: 1
Unchanged: 36

That's the message you want to see. Thirty-six accounts that were already fine — and four that needed attention and no longer do.

The account API and its traps

The Lambda is simple. The AWS Account API is not.

There are three behaviors of the account API that aren't well documented, that don't generate descriptive errors when ignored, and that only appear when you deploy in a real environment.

The API is global — it only works in us-east-1

The AWS account service is a global API. That means it's not available in every region — only in us-east-1. If your Lambda lives in us-east-2 or sa-east-1 and you create the boto3 client without specifying a region, the call fails with AccessDeniedException.

The error is confusing because it looks like an IAM permissions problem. You can spend hours reviewing policies that are perfectly fine before realizing the issue is the region. The solution is explicit:

account_client = boto3.client('account', region_name='us-east-1')

One line. But one you only know you need after you've needed it.

The Management account doesn't accept AccountId

For member accounts, the API accepts an AccountId parameter that indicates which account to operate on. For the Management account, that parameter can't be passed — the call must be made without it, in standalone mode.

If you pass the Management account's AccountId, the API returns an error. If there's no logic to bifurcate behavior based on account type, the Lambda will silently fail on the Management account or skip it without warning.

The solution was adding an is_management parameter to the get_contact() and set_contact() functions:

def get_contact(account_id, is_management=False):
    if is_management:
        return client.get_alternate_contact(AlternateContactType='SECURITY')
    return client.get_alternate_contact(
        AccountId=account_id,
        AlternateContactType='SECURITY'
    )

Trusted Access must be enabled once

Before you can call account:GetAlternateContact or account:PutAlternateContact from an account other than Management, you need to enable Trusted Access between AWS Organizations and the Account Management service. Without this step, the API returns AccessDeniedException even if the role has all the correct permissions.

aws organizations enable-aws-service-access \
  --service-principal account.amazonaws.com \
  --profile YOUR-MANAGEMENT-PROFILE

It's a one-time step that isn't in the Terraform flow — it must be done manually before the first deploy. If it isn't documented, it's the kind of prerequisite that costs hours to whoever tries to reproduce the project from scratch.

The Makefile as the only path

Lambda with ZIP has a silent trap that's easy to ignore until it costs you real time.

When you update the Python code in src/security_contact_enforcer.py and build the ZIP manually, Lambda keeps running the old code. Without any error. Without any warning. It simply executes the previous version as if nothing changed.

What happens is that the code Lambda executes isn't the file you edited directly — it's what's inside src/package/, the directory that gets packaged into the ZIP. If you update the source but forget to copy it to package/ before repackaging, the "successful" Lambda deploy contains outdated code.

In a manual flow with multiple steps, that oversight is inevitable. The solution is to eliminate the manual flow.

The Makefile turns the update into a single command:

update:
    cp src/security_contact_enforcer.py src/package/
    rm -f function.zip
    cd src/package && zip -r ../../function.zip .
    aws lambda update-function-code \
        --function-name $(FUNCTION_NAME) \
        --zip-file fileb://function.zip \
        --profile $(SECURITY_PROFILE) \
        --region $(AWS_REGION)

make update

That's it. You edit src/security_contact_enforcer.py, run make update, and the full cycle — copy, package, deploy — happens in order without any steps that can be skipped.

The Makefile isn't an optimization — it's the only safe way to update the Lambda. When there's only one correct path, there's no room for human error.

How to validate it without creating an account

Validating that the system works end-to-end has two independent parts. Confusing them leads to incomplete tests or waiting for Control Tower to provision a real account every time you want to verify something.

Validate the Lambda logic

For this, you don't need to create any account. Manually delete the security contact from an existing account:

aws account delete-alternate-contact \
  --alternate-contact-type SECURITY \
  --account-id YOUR-ACCOUNT-ID \
  --profile YOUR-MANAGEMENT-PROFILE \
  --region us-east-1

Then invoke the Lambda directly:

aws lambda invoke \
  --function-name security-contact-enforcer \
  --payload '{}' \
  --cli-binary-format raw-in-base64-out \
  response.json \
  --profile YOUR-SECURITY-PROFILE \
  --region YOUR-REGION

cat response.json

If the result shows Assigned: 1, Unchanged: N-1 — the complete logic is validated. The Lambda traversed all accounts, detected the one without a contact, fixed it, and left the rest untouched. All without touching EventBridge or Control Tower.

Validate the EventBridge trigger

This validation is independent and requires the real event. The only way to do it is to create an account from Control Tower and verify in CloudWatch Logs that the Lambda fired automatically upon receiving the CreateManagedAccount event.

These are two distinct tests that validate different things. The first confirms the business logic works. The second confirms the trigger responds to the correct event. You need both — but you don't need to do them together or in that order.

The result

Running the Lambda for the first time against an organization with 40 active accounts produced this:

✅ Security Contact Enforcer
Accounts processed: 40
Assigned: 31
Updated: 4
Unchanged: 5

Thirty-one accounts without a security contact. Not because nobody cared about security — but because nobody had built the mechanism to guarantee it systematically. The 4 updated ones had a contact configured with outdated information, from an email that no longer existed or someone who had already left the team.

Only 5 accounts were correctly configured.

That number isn't unusual. It's what you find when you audit this control in organizations that have been on AWS for years without baseline automation. The problem isn't negligence — it's that without automation, consistency depends on someone remembering to do something manually at the right moment, every time a new account gets created.

Since the deploy, every account Control Tower provisions has a security contact assigned before the team that requested it finishes configuring their first resources. No tickets, no runbooks, no human intervention.

The operational cost of maintaining this control is now zero.

Closing

The AWS Security Maturity Model has dozens of controls. Some are complex, costly, and require weeks of planning. This one isn't.

Assigning a security contact is Phase 1 — Quick Wins. It's the first thing you should have solved. And yet, in practice, it's one of the most frequently omitted controls in multi-account organizations because nobody built the mechanism to guarantee it continuously.

What this project demonstrates isn't that automation is hard — it's exactly the opposite. A Lambda, a Custom Event Bus, Terraform and a Makefile are enough to turn a manual, error-prone process into a control that works on its own, forever, without anyone having to remember.

The traps that appeared along the way — the wrong Control Tower event, the global API that only lives in us-east-1, the special behavior of the Management account, the Lambda ZIP that silently deployed old code — aren't well documented anywhere. They appear when you deploy in production with real accounts. That's why they're documented here.

If you're building AWS security in LATAM with the resources you have, I hope this saves you the hours it cost to discover.

The repository is on GitHub with all the code, the IaC in Terraform, and the complete README.

🔗 GitHub: gerardokaztro/security-contact-enforcer

About the author

🔗 GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro

My manager asked if it could run itself. Here's how I automated iam-audit with Fargate, EventBridge and Terraform (Part 3)

Gerardo Castro Arica — Tue, 24 Mar 2026 12:00:00 +0000

A few weeks ago my manager asked me a question that seemed simple:

"Can it be scheduled to arrive on its own every week?"

The script was already scanning more than 20 AWS accounts. It was already detecting Access Keys from 2018 still active in production. It was already generating a dashboard that any CISO could read without opening a spreadsheet. Technically, the work was done.

But "the work was done" meant someone had to remember to run it. Someone had to have Docker installed, credentials configured, and free time on a Monday morning. On a security team with multiple open fronts, that "someone" is exactly the link that breaks.

Automation wasn't a cosmetic improvement. It was the step that turned a tool into a service.

The constraint that defines the architecture

The first decision wasn't technical — it was about constraints.

The report needs to run once a week. It takes minutes. When it's done, there's nothing to keep alive. Paying for infrastructure that sits idle 99.9% of the time isn't just a cost problem — it's a design problem.

With that clear, the options narrow themselves.

Lambda? The 15-minute execution limit is the problem. In an Organization with many accounts, the script can take longer — and a silent timeout halfway through an audit is worse than not running at all. Lambda is designed for millisecond-to-minute workloads, not for audit processes that traverse dozens of accounts in sequence.

ECS Service? A Service is designed for processes that run indefinitely — an API, a worker listening to a queue. Keeping a Service alive for a weekly job is exactly the antipattern we wanted to avoid. You pay for availability you'll never use.

EC2? More attack surface, more OS management, more base cost. Discarded.

The right answer is ECS Fargate Task — no Service, no persistent instances. A Task is ephemeral by design: it spins up, executes, and disappears. Nothing is running between executions. Nothing to patch, monitor, or pay for when not in use.

That's FinOps applied to security: the cheapest architecture isn't the one with fewer features — it's the one that doesn't spend on what it doesn't need.

The architecture

The complete flow has four steps and no unnecessary pieces.

EventBridge Scheduler fires an event every Monday at 9am Lima time (cron(0 14 ? * MON *) — UTC-5). No server waiting, no process sleeping. EventBridge simply remembers it has something to do, and does it.

That event spins up an ECS Fargate Task in the Security account. The task runs the iam-audit Docker image — the same one you were running locally with a single command in Part 2 — but now on AWS, with an assigned IAM role, no hardcoded credentials, no human intervention.

When the task finishes, it uploads the report to a dedicated S3 bucket. The bucket has a 90-day lifecycle policy — older reports are deleted automatically. No indefinite accumulation, no silently growing costs.

The last step is notification. The task generates a presigned URL valid for 48 hours and sends it via Slack. Whoever receives the message has two days to open the dashboard — after that the link expires. The report never leaves your AWS account; what travels through Slack is only the temporary access.

EventBridge Scheduler (Monday 9am Lima)
        │
        ▼
ECS Fargate Task
  └─ image: gerardokaztro/iam-audit
  └─ role: iam-audit-task-role
  └─ secret: Slack webhook URL (Secrets Manager)
        │
        ├──▶ S3 bucket (report + presigned URL 48h)
        │
        └──▶ Slack (presigned URL)

Everything lives in the Security account of the Organization. Not in the management account, not in an application account. The Security account is the right place for tools that touch the entire organization — isolated, with controlled access, audited separately.

If you want to deploy it in a different account, you can do so without touching anything structural. Just adjust the configuration values — bucket name, SSO profile, environment variables — and Terraform handles the rest the same way.

Terraform and the partial backend

The entire stack is defined in Terraform. But before writing a single resource, there's a language limitation that needs to be understood — and if you don't know it, it leads you straight to hardcoding things that shouldn't be in code.

The backend block in Terraform initializes before the variable system. That means this doesn't work:

terraform {
  backend "s3" {
    bucket  = var.state_bucket  # ❌ not valid
    region  = var.aws_region    # ❌ not valid
    profile = var.aws_profile   # ❌ not valid
  }
}

Terraform rejects it at init. The variables simply don't exist yet at that point in the lifecycle.

The obvious solution — and the wrong one — is to hardcode the values directly:

terraform {
  backend "s3" {
    bucket  = "my-state-bucket"  # ❌ now it's in the repo
    region  = "us-east-1"
    profile = "my-sso-profile"
  }
}

It works. But if the repo is public, you just exposed your state bucket name and SSO profile. And if the repo is private today, it might not be tomorrow.

The correct solution is the partial backend: leave the block empty in main.tf and pass the values in a separate file that goes in .gitignore.

main.tf:

terraform {
  backend "s3" {}
}

backend.hcl (in .gitignore, never in the repo):

bucket  = "your-state-bucket"
region  = "us-east-1"
profile = "your-sso-profile"

And the init looks like this:

terraform init -backend-config=backend.hcl

The repo includes a backend.hcl.example with the structure and example values. Whoever clones the project copies the file, fills in their values, and runs init. No friction, no exposed secrets.

This isn't a workaround — it's the pattern Terraform recommends exactly for this case. The language limitation, turned into a security best practice.

The Task Definition and secrets

When you define an ECS Task Definition in Terraform, you have two ways to pass values to the container: environment and secrets. They seem equivalent. They're not.

environment passes the value directly as an environment variable — visible in plain text in the ECS console, in the task logs, and in any describe-task-definition that someone with account access runs.

secrets does something different: it tells the task to fetch the value from AWS Secrets Manager at execution time, inject it as an environment variable in memory, and never write it anywhere. The value doesn't appear in the task definition. It doesn't appear in the logs. It doesn't appear in the console.

The Slack webhook URL is exactly the kind of value that shouldn't be in environment. Anyone with that URL can send messages to your Slack channel on behalf of the system — with no additional authentication, no traceability. It's a credential, not a configuration.

In the Task Definition it looks like this:

secrets = [
  {
    name      = "SLACK_WEBHOOK_URL"
    valueFrom = aws_secretsmanager_secret.slack_webhook.arn
  }
]

The value is created once in Secrets Manager and Terraform only references the ARN. The container receives the variable at runtime — the Python code reads it with os.environ["SLACK_WEBHOOK_URL"] like any environment variable, but it was never exposed in any definition.

The task's IAM role

The iam-audit-task-role is the role the container assumes at runtime. It's the equivalent of the AWS profile you were using locally in the first two posts — but now it's a role with permissions explicitly defined in Terraform, no long-lived credentials, no ~/.aws to mount.

What the task needs to function is exactly this and nothing more:

# List accounts in the Organization
statement {
  effect    = "Allow"
  actions   = ["organizations:ListAccounts"]
  resources = ["*"]
}

# Assume the audit role in each member account
statement {
  effect    = "Allow"
  actions   = ["sts:AssumeRole"]
  resources = ["arn:aws:iam::*:role/iam-audit-role"]
}

# Upload the report to the S3 bucket
statement {
  effect    = "Allow"
  actions   = ["s3:PutObject", "s3:GetObject"]
  resources = ["${aws_s3_bucket.reports.arn}/*"]
}

# Read the Slack secret
statement {
  effect    = "Allow"
  actions   = ["secretsmanager:GetSecretValue"]
  resources = [aws_secretsmanager_secret.slack_webhook.arn]
}

No * in resources where it isn't necessary. No AdministratorAccess because "it's easier." Each permission has a specific reason and a scoped target.

There's something worth noting: this is the role of the tool that audits least privilege across the entire organization. If that role had excessive permissions, we'd be auditing a principle we don't apply at home. Consistency isn't just aesthetic — it's what makes the project credible.

The result

Every Monday at 9am, without anyone doing anything, this arrives in Slack:

🔍 iam-audit | Weekly report
Organization: more than 20 accounts audited
📊 View dashboard → https://s3.amazonaws.com/...?X-Amz-Expires=172800
⏳ Link valid for 48 hours

Nothing to run. Nothing to remember. No engineer who had to remember on a Monday morning that this tool existed.

The Fargate Task spun up, audited, uploaded the report, generated the presigned URL, notified, and disappeared. The total cost of that execution is cents — literally. An ephemeral task that runs minutes per week doesn't generate a visible line in the monthly billing.

That's what it means to automate well: not just that it runs on its own, but that it runs on its own without leaving infrastructure or cost behind.

For a security team in LATAM operating on a tight budget with multiple open fronts, this isn't a minor detail. It's the difference between a tool that gets used and a tool that gets forgotten.

Closing

Three posts. Three versions of the same problem.

The first was a question: who has access, with what credentials, and since when? The answer was a Python script that traversed the entire Organization in minutes and surfaced what nobody was looking at.

The second was a tension: the data was there, but it didn't communicate to all audiences. The answer was a dashboard anyone could read, root account detection, and a Docker image that eliminated the friction of running it.

The third was an operational constraint: someone had to run it. The answer was turning the tool into a service — ephemeral, automated, secure, and with a cost that doesn't justify a line in the budget.

Visibility. Communication. Automation.

That's what we built. Not with commercial platforms, not with an enterprise budget, not with a team of ten people. With Python, Docker, Terraform, and the right design decisions.

If you're building AWS security in LATAM with the resources you have — not the ones you wish you had — I hope this series gave you something concrete to take with you. Not a framework to memorize. A tool you can run today.

The repository is on GitHub. The image is on Docker Hub. The IaC is in Terraform. All open, all documented, all yours.

🔗 GitHub: gerardokaztro/iam-audit
🐳 Docker Hub: gerardokaztro/iam-audit

About the author

🔗 GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro

OpenClaw on AWS Lightsail — Threat Model Alignment: OWASP, MITRE ATLAS, and the Gap No Framework Anticipated (Part 3)

Gerardo Castro Arica — Mon, 23 Mar 2026 06:22:14 +0000

Part 3 of the series: In Part 1 we audited the initial OpenClaw setup on AWS Lightsail — outdated kernel, the gateway + allow combination as a critical attack chain, and the Gateway Token exposed in plaintext. In Part 2 we went deep into the full dashboard — channels, agents, cron jobs, logs, and configuration panels. If you haven't read the previous parts, the full index is at the end of this post.

Note on findings: Vectors #7, #8, and #10 identified in Part 2 are pending live validation. The framework mapping in this post confirms that the vector exists and has documented precedent in similar systems — not that it was executed on this specific OpenClaw instance. Controlled environment validation is coming in Part 4.

References used in this post:

MITRE ATLAS — OpenClaw Official Threat Model
OWASP Top 10 for Agentic Applications 2026
AWS Agentic AI Security Scoping Matrix
AWS Generative AI Security Scoping Matrix
AWS Blog — Agentic AI Security Scoping Matrix
AWS Official Repo — sample-OpenClaw-on-AWS-with-Bedrock (contains the explicit acknowledgment of the open prompt injection gap)

The starting point

In the first two parts of this series we audited OpenClaw deployed on AWS Lightsail — not as a user, but as a Cloud Security Engineer with the goal of mapping the attack surface that deployment opens.

The result was a list of 13 findings distributed across three layers that don't always appear together in the same analysis:

IaaS Layer — what Lightsail brings by default and the operator inherits without necessarily knowing it:

#	Finding	Severity
1	Blueprint with outdated kernel and libraries	High
4	IPv6 enabled by default	Medium
5	Apache2 without documented hardening	Medium

Application Layer — what OpenClaw exposes as a system, regardless of where it runs:

#	Finding	Severity
3	Gateway Token in plaintext on the dashboard	High
6	No granular access control on channels	High
7	Indirect prompt injection via external channels	Critical
8	Memory poisoning via unvalidated context	High
9	53 skills active by default — opt-out model	High
10	No permission inheritance model in agent chains	High
13	Config and Debug exposed via Gateway Token	Medium

Intersection Layer — where operator configuration activates vectors that no application framework anticipates alone:

#	Finding	Severity
2	`exec_host_policy: gateway` + `shell_approval: allow` = no isolation	Critical
11	Cron Jobs as persistence and defense evasion vector	High
12	Local logs without external export	High

These three layers are not a design accident — they are the result of a deploy decision. Someone saw the OpenClaw blueprint on Lightsail, clicked, and inherited an attack surface that no application threat model fully contemplates, because none was designed to do so.

The question this post answers: what does each existing security framework cover, where do these 13 findings map, and what is left without a home?

MITRE ATLAS — OpenClaw's official threat model

MITRE ATLAS (Adversarial Threat Landscape for AI Systems) is the reference framework for modeling threats against artificial intelligence systems. It works with the same logic as MITRE ATT&CK — tactics, techniques, and procedures — but applied to the ML and AI ecosystem.

The OpenClaw team adopted it as the basis for their official threat model, available at trust.openclaw.ai/threatmodel. The result is a matrix of 37 threats distributed across 8 tactics, with 6 classified as critical.

Before mapping the findings, there is something important to understand about the scope of this threat model: it was designed to model threats against OpenClaw as a system — its skills, its gateway, its execution model, its channels. It was not designed to model what happens when someone deploys OpenClaw on a Lightsail VPS with an outdated kernel. That distinction is not a criticism — it is the correct scope for an application threat model.

With that in mind, the mapping:

What ATLAS anticipated — and matches the findings

Finding	ATLAS Threat	Tactic
#7 Indirect prompt injection	`T-EXEC-002` Indirect Prompt Injection	Execution
#8 Memory poisoning	`T-PERSIST-005` Prompt Injection Memory Poisoning	Persistence
#9 53 skills opt-out	`T-ACCESS-004` Malicious Skill as Entry Point	Initial Access
#11 Cron Jobs persistence	`T-EVADE-004` Staged Payload Delivery	Defense Evasion
#13 Config/Debug exposed	`T-DISC-002/003/004` Session/Prompt/Env Enumeration	Discovery
#3 Gateway Token	`T-ACCESS-003` Token Theft	Initial Access

These findings have a home in ATLAS. The framework anticipated them, assigned a technique, and placed them in an attack chain.

What ATLAS does not cover — and why

Finding	Why it falls outside
#1 Outdated kernel	Operator infrastructure — out of scope by design
#4 IPv6 enabled	Operator network configuration — out of scope by design
#5 Apache2 without hardening	Operator responsibility — out of scope by design
#2 exec_host_policy + allow	Intersection between operator configuration and application design
#6 No access control on channels	ATLAS documents `AllowFrom` as a trust boundary, but does not model the gap when that control is simply not configured
#10 Permission inheritance	No threat models privilege escalation between agents with different configurations
#12 Local logs	Completely absent from the threat model

The most interesting finding from the mapping: Finding #2 best illustrates the gap between application threat model and deploy reality. OpenClaw documents exec_host_policy as a configuration the operator controls. ATLAS models T-EXEC-004 Exec Approval Bypass as a threat. But neither explicitly models what happens when the operator activates the most permissive combination by default — which is exactly what the Lightsail blueprint does.

The threat model assumes the operator makes informed decisions. The blueprint assumes the operator wants simplicity. The intersection of those two assumptions is Finding #2.

OWASP Top 10 for Agentic Applications 2026

In December 2025, OWASP published the first security framework specific to agentic applications. It is not an extension of the Top 10 for LLMs — it is an independent list, built on the recognition that autonomous agents have a fundamentally different threat model than a chatbot.

The central difference: an LLM that fails produces an incorrect response. An agent that fails executes incorrect actions on real systems.

The 10 framework categories:

#	Category
AG01	Prompt Injection
AG02	Memory Poisoning
AG03	Tool Misuse
AG04	Privilege Escalation
AG05	Unsafe Agent Chaining
AG06	Resource Exhaustion
AG07	Data Exfiltration
AG08	Uncontrolled Agent Spawning
AG09	Over-Permissioned Agents
AG10	Excessive Trust of Agent Output

The mapping with the findings

Finding	OWASP Category	Observation
#7 Indirect prompt injection	AG01 Prompt Injection	Direct coverage — OWASP distinguishes direct and indirect prompt injection
#8 Memory poisoning	AG02 Memory Poisoning	Direct coverage — and in OpenClaw memory is plain Markdown files on disk, which amplifies the vector
#9 53 skills opt-out	AG03 Tool Misuse + AG09 Over-Permissioned Agents	Double mapping — the opt-out model inverts the principle of least privilege
#10 Permission inheritance	AG04 Privilege Escalation + AG05 Unsafe Agent Chaining	Double mapping — the absence of documentation on permission inheritance is exactly AG05
#11 Cron Jobs	AG08 Uncontrolled Agent Spawning	Partial — Cron Jobs don't spawn new agents, but create unsupervised autonomous executions with the same effect
#6 No access control on channels	AG09 Over-Permissioned Agents	A channel without access control is equivalent to an agent with excessive permissions over its input surface
#2 exec_host_policy + allow	AG03 Tool Misuse	Partial — OWASP models tool abuse, but not the deploy configuration that eliminates the sandbox

What OWASP does not cover

Finding	Why it falls outside
#1 Outdated kernel	Infrastructure — out of scope by design
#4 IPv6	Infrastructure — out of scope by design
#5 Apache2	Infrastructure — out of scope by design
#12 Local logs	OWASP has no observability category — the absence of external logging has no home
#13 Config/Debug exposed	OWASP touches it tangentially in AG07 (exfiltration) but does not model the exposure of internal panels via a shared token

The most revealing finding from the OWASP mapping:

Finding #9 maps simultaneously to AG03 and AG09 — Tool Misuse and Over-Permissioned Agents. That is not an editorial coincidence. It is the direct consequence of the opt-out model: when everything is enabled by default, each unnecessarily active skill is simultaneously an excessive permission and a potential abuse surface.

OWASP anticipated it conceptually. What it did not anticipate is that a real and popular system would implement it in reverse — not "enable what you need" but "disable what you don't want." The difference is philosophical but the consequences are operational.

AWS Agentic AI Security Scoping Matrix

AWS published two complementary frameworks that coexist and reference each other.

The first is the Generative AI Security Scoping Matrix — 5 scopes based on how much ownership the organization has over the model. OpenClaw on Lightsail falls in Scope 3: building a custom application using a pre-trained model via API. The model is not trained or fine-tuned — it is invoked. Security responsibilities in Scope 3 are divided between AWS (the model, Bedrock infrastructure) and the operator (the application, the integration, the data passed to it).

The second is the Agentic AI Security Scoping Matrix — published in November 2025, specifically designed for autonomous systems. It categorizes four scopes based on two dimensions: level of agency (what actions the system can take) and level of autonomy (how much human oversight exists).

This second matrix speaks most directly to the findings in this series.

What scope does OpenClaw operate in with the audited configuration?

The default configuration of the Lightsail blueprint — exec_host_policy: gateway + shell_approval: allow — places OpenClaw in Scope 4: Full Agency.

AWS's definition for Scope 4 is clear: systems that self-initiate, operate continuously with minimal human supervision, and can execute complex workflows autonomously. OpenClaw's Cron Jobs are exactly this — scheduled tasks that execute without operator intervention.

The problem is not that Scope 4 exists. The problem is that Scope 4 requires the most sophisticated controls in the framework — continuous behavioral monitoring, automatic circuit breakers, guaranteed rollback mechanisms, real-time anomaly detection. And the Lightsail blueprint does not configure any of them.

It is the same pattern identified with MITRE ATLAS: the system arrives configured to operate with maximum autonomy, but without the controls that autonomy requires.

The mapping with the 6 security dimensions

The Agentic AI Security Scoping Matrix organizes controls across six dimensions. This is where the findings find their most precise placement:

Identity Context — user, service, and agent identity management.

Finding	Observation
#3 Gateway Token in plaintext	The token is the gateway's only authentication mechanism — no rotation, no scope, no expiration
#6 No granular access on channels	The framework requires appropriate authentication per scope level. In Scope 4, any channel participant can instruct the agent

Data, Memory & State Protection — persistent memory security and memory poisoning prevention.

Finding	Observation
#8 Memory poisoning	AWS explicitly names memory poisoning as a critical vector in this dimension. In OpenClaw memory is Markdown files on disk — no integrity validation, no encryption

This is the finding with the most direct coverage in the entire matrix. AWS anticipated it, named it, and described exactly the risk. OpenClaw's implementation materializes it.

Audit & Logging — complete action traceability and reasoning chain capture.

Finding	Observation
#12 Local logs without export	The framework requires tamper-resistant logs, especially in Scope 4. Modifiable local logs are the opposite of what Scope 4 requires
#11 Cron Jobs as persistence	Without external logging, a malicious task can execute and erase its trail before anyone detects it

Agent & LLM Controls — guardrails, behavioral monitoring, sandboxing.

Finding	Observation
#2 exec_host_policy + allow	Eliminates the sandbox. The framework requires containerization and resource quotas in Scope 4 — the default configuration does exactly the opposite
#7 Indirect prompt injection	The framework mentions behavioral monitoring as a control. Without it, an indirect injection can execute undetected

Agency Perimeters & Policies — operational boundaries and dynamic constraint evaluation.

Finding	Observation
#9 53 skills opt-out	The framework is explicit: agents must operate within the limits of their designed purpose. 53 skills active by default is the opposite — maximum surface, minimum restriction
#10 Permission inheritance	The framework does not specify how permissions should propagate in agent chains — that gap is Finding #10

Orchestration — agent-to-system interaction management, tool access, execution flow control.

Finding	Observation
#10 Permission inheritance	The Orchestration dimension discusses inter-agent coordination protocols, but does not define the permission inheritance model in delegation
#11 Cron Jobs	The framework mentions transaction management and rollback mechanisms — Cron Jobs have neither

What the matrix does not cover

The Agentic AI Security Scoping Matrix implicitly assumes deployment is on AWS managed services — Bedrock, AgentCore, Lambda. It says nothing about what happens when the blueprint arrives with an outdated kernel, Apache without hardening, or IPv6 enabled by default.

That is not a criticism of the framework — it is the correct scope. AWS designed this matrix for the application and orchestration layer, not for the IaaS layer. The operator who chooses Lightsail inherits a layer of responsibilities that neither matrix contemplates.

That layer is unmapped territory.

The gap — what no framework anticipated

Three frameworks reviewed. One designed by the OpenClaw team itself, one by OWASP, one by AWS. All three do their job well. And all three leave the same territory uncovered.

Before naming it, it is worth seeing the pattern:

Finding	MITRE ATLAS	OWASP Agentic	AWS Scoping Matrix
#1 Outdated kernel	❌ out of scope	❌ out of scope	❌ out of scope
#2 exec_host_policy + allow	⚠️ partial	⚠️ partial	⚠️ partial
#3 Gateway Token	✅ T-ACCESS-003	⚠️ tangential	✅ Identity Context
#4 IPv6	❌ out of scope	❌ out of scope	❌ out of scope
#5 Apache2	❌ out of scope	❌ out of scope	❌ out of scope
#6 No channel access	⚠️ partial	✅ AG09	✅ Identity Context
#7 Prompt injection	✅ T-EXEC-002	✅ AG01	⚠️ mentioned, not resolved
#8 Memory poisoning	✅ T-PERSIST-005	✅ AG02	✅ Data & Memory
#9 53 skills opt-out	✅ T-ACCESS-004	✅ AG03+AG09	✅ Agency Perimeters
#10 Permission inheritance	❌ absent	✅ AG04+AG05	⚠️ partial
#11 Cron Jobs	⚠️ partial	⚠️ partial	⚠️ partial
#12 Local logs	❌ absent	❌ absent	✅ Audit & Logging
#13 Config/Debug	⚠️ partial	⚠️ tangential	⚠️ tangential

The pattern is clear. Findings from the application layer have a home in at least one of the three frameworks. Findings from the IaaS layer have no home in any of them. And findings from the intersection layer have partial coverage in all — no framework captures them completely because none was designed to see both layers at the same time.

The gap has a name

What is missing is not one more finding. It is a layer of analysis that existing frameworks do not contemplate by design: the attack surface opened by the decision to deploy on IaaS when the system being deployed is an autonomous agent.

An application threat model assumes that infrastructure is the operator's responsibility. An infrastructure framework assumes that the application running on top is the developer's responsibility. Neither models the intersection — the point where operator configuration activates vectors that the application threat model did not anticipate, and vice versa.

Finding #2 is the clearest example: exec_host_policy: gateway + shell_approval: allow is an operator configuration decision that eliminates the agent's only isolation mechanism. It is not an OpenClaw bug — it is a documented option. It is not an operator error — it is the blueprint's default value. Responsibility is distributed in a way that no framework captures in a single place.

The validation that was not expected

This is not just an independent observation. The official AWS repository — sample-OpenClaw-on-AWS-with-Bedrock — documents it explicitly in its README:

"Plan A is soft enforcement — the LLM can theoretically be bypassed via prompt injection. Plan E catches what Plan A misses. For hard enforcement via AgentCore Gateway MCP mode, see Roadmap."

AWS, in its own reference repository for deploying OpenClaw, acknowledges that prompt injection is not resolved and places it on the roadmap. This is not an inferred gap — it is a gap the AWS technical team documented while building the solution.

And prompt injection is Finding #7 — the critical vector identified in Part 2, which none of the three frameworks fully resolves in the context of an IaaS deployment.

What this means for anyone deploying OpenClaw today

Deploying OpenClaw on Lightsail following the official blueprint means operating an agent at Scope 4 of the AWS Agentic AI Security Scoping Matrix — maximum autonomy — without the controls Scope 4 requires, on infrastructure that no agentic security framework models, with a prompt injection vector that the AWS team itself acknowledges as pending work.

OpenClaw is not broken. Lightsail is not insecure. The combination of both on the default configuration opens an attack surface that requires an analysis that does not yet exist as a unified framework.

That is what comes next.

What's next

Three frameworks analyzed. Thirteen findings mapped. A gap identified with real evidence.

Something important about several findings mapped in this post: findings #7, #8, and #10 are marked as risk vectors identified but not executed live. The framework mapping confirms the vector exists and has documented precedent. Validation that it works in this specific implementation comes in Part 4.

And the demo may reveal something that static analysis did not show. That is not a warning — it is the method. An autonomous agent cannot be audited solely from the dashboard. At some point you have to see what it does when something goes wrong.

Part 4 closes the series with what frameworks cannot replace: live evidence. Prompt injection executed in a controlled environment, validation of pending findings, and the first elements of something that does not yet exist in LATAM: a unified framework for evaluating the security posture of an autonomous agent considering all three layers together.

Not a whitepaper. Not a checklist. Something built from real findings, on a real system, deployed on real infrastructure.

If you arrived here without reading Part 1 and Part 2, the full series index is here:

→ Part 1 — Secure setup and first infrastructure findings
→ Part 2 — Full dashboard: channels, agents, cron jobs, and logs
→ Part 3 — this post
→ Part 4 — coming soon

About the author

🔗 LinkedIn: gerardokaztro
🔗 Blog: roadtocloudsec.la

I Kept Auditing OpenClaw on AWS Lightsail: 53 Default Skills, No Channel Access Controls, Deletable Logs (Part 2)

Gerardo Castro Arica — Thu, 12 Mar 2026 14:55:00 +0000

Part 2 of a series: In Part 1 we audited the initial OpenClaw setup on AWS Lightsail — outdated kernel, the gateway + allow attack chain, and the Gateway Token exposed in plaintext. If you haven't read it, start there.

In Part 1 I closed with a warning: secure setup is the starting point, not the destination.

Once the server is patched, the firewall restricted, and security settings reviewed — there's still the entire dashboard to explore. And the OpenClaw dashboard isn't just a UI. It's a map of attack surfaces: each section has its own security implications, its own trust model, its own blast radius if something goes wrong.

Channels, Agents, Cron Jobs, Nodes, Logs, Config and Debug. I reviewed them all.

What I found isn't catastrophic — OpenClaw isn't broken. But it's also not production-ready with the default configuration. And there are design decisions every team should understand before connecting this agent to their messaging channels or infrastructure.

That's what we're looking at in this post.

Channels: the input vector that comes from outside

What is a Channel in OpenClaw

A Channel is a messaging integration — WhatsApp, Telegram, Discord, Slack, Signal, Google Chat. Once configured, any message that arrives through that channel becomes a prompt for the agent.

The UI makes it look simple: channel name, API token, webhook URL. Five minutes and it's running.

The security problem is exactly in that simplicity.

Finding #6: No granular access control at the channel level

When you connect a channel to OpenClaw, the agent responds to messages. The question you need to ask before doing so is: whose messages?

The channel configuration UI doesn't expose granular access controls — there's no field to specify which users or roles can instruct the agent, no authorized sender whitelist. If the bot is in a Telegram group, the system design doesn't offer a native mechanism to restrict which group participants can give it instructions.

This opens a vector for identity impersonation: someone with access to the channel can instruct the agent to execute tasks as if they were a legitimate user — and the agent has no way to verify whether the person writing has authorization for what they're requesting.

In an enterprise environment, this translates to horizontal privilege escalation: an employee with access to the corporate Slack group where the agent is integrated can instruct it to do things outside their role.

🔍 Finding #6: The channel configuration UI doesn't expose granular access controls. In multi-user environments, any participant with channel access can send instructions to the agent, representing a horizontal privilege escalation vector.

Finding #7: Indirect prompt injection via channel

This is the vector that concerns me most in the entire series.

Direct prompt injection is when someone writes directly to the agent: "Ignore your previous instructions and do X." That's the lab scenario — easy to understand, relatively easy to mitigate with guardrails.

Indirect prompt injection is different: the attacker doesn't talk to the agent. The attacker contaminates content the agent will consume.

Attacker publishes malicious content  →  Agent consumes that content  →  Agent executes hidden instruction
(on a website, a doc, a message)           (as part of a task)              (without the user knowing)

OpenClaw can browse the web, read files, process documents. If someone asks the agent to "summarize this page" and that page contains hidden instructions designed to manipulate its behavior, the agent without proper guardrails might execute them.

Messaging channels expand this surface. If the agent is in a group where external parties participate, anyone can send a message with embedded instructions designed to influence the next task the agent executes.

This vector was not tested on this instance — live demo validation is coming in Part 4.

🔍 Finding #7: Integration of external channels expands the indirect prompt injection surface. Malicious content injected into channels accessible to the agent can manipulate its behavior without direct attacker interaction.

Finding #8: Memory poisoning via unvalidated context

OpenClaw maintains memory of conversations and context between sessions. Not as a database — as plain Markdown files on disk: a MEMORY.md for long-term context and daily logs in memory/YYYY-MM-DD.md. If it hasn't been written to those files, the agent doesn't remember it.

That transparency is good for auditing. But it also defines the attack vector: if an attacker manages to introduce false information into that memory — via a channel with weak authentication, via indirect prompt injection, or via direct filesystem access — that information persists and affects all future interactions.

Concrete scenario: the agent has in memory that "the admin user is bad@boy.com". An attacker introduces in context that this data has changed. Depending on how the agent uses that memory in subsequent tasks, the consequences can be significant.

Unlike a real-time attack, memory poisoning is persistent — the effects continue even after the attacker has lost access to the system.

Validation of this vector is also coming in Part 4.

🔍 Finding #8: OpenClaw's memory consists of Markdown files on disk, with no integrity validation mechanisms. Malicious information introduced into the memory context can persistently affect agent behavior, even after the attacker loses access.

Agents: the default permissions problem

What are Agents in OpenClaw

OpenClaw allows configuring agents with different models, enabled skills, and system instructions. An agent can also delegate tasks to another agent.

From a productivity perspective, that's powerful. From a security perspective, it introduces questions that modern frameworks are still trying to resolve.

Finding #9: 53 skills active by default — opt-out model, not opt-in

OpenClaw installs 53 bundled skills as part of the system. The default behavior isn't "nothing until you enable it": it's everything active unless you explicitly disable it. Skills activate automatically if the corresponding CLI tool is available on the system.

When reviewing the main agent in the dashboard, I confirmed 50 skills enabled — the difference from 53 is explained by skills whose dependent binaries aren't installed on this Lightsail instance.

Among the capabilities available by default: code execution, filesystem access, web browsing, email sending, external API interaction, process management.

The problem isn't the number — it's the model. The principle of least privilege says a system should only have access to what it needs to fulfill its function. If your agent is configured to answer questions about internal documentation, it doesn't need the ability to send emails or full filesystem access.

Every unnecessarily active skill is additional attack surface — either because an attacker uses it after compromising the agent, or because the agent itself acts unexpectedly in response to an ambiguous instruction.

🔍 Finding #9: OpenClaw installs 53 bundled skills with an opt-out model: everything active by default, the operator must explicitly disable what they don't need. This inverts the principle of least privilege and maximizes blast radius under any compromise or unexpected behavior.

Finding #10: Privilege escalation in agent chains

When Agent A delegates a task to Agent B, what permissions does Agent B have to execute it?

OpenClaw's official documentation doesn't define a permission inheritance model between agents — it's not specified which restrictions from the origin agent propagate to the destination agent in a delegation chain. That means the operator has no visibility into how trust propagates through the system.

The risk derived from that gap: if Agent A has strict restrictions but Agent B has more permissive configurations, an attacker who manages to get Agent A to delegate to Agent B could bypass the first agent's controls. The pattern is analogous to privilege escalation in Unix systems — you don't compromise root directly, you compromise a process with sudo that can execute what you need.

This is an analysis vector, not a proven finding. Validation is coming in Part 4.

🔍 Finding #10: OpenClaw doesn't document a permission inheritance model between agents. The absence of specification on how trust propagates in delegation chains opens a privilege escalation vector between agents with different security configurations.

Cron Jobs: the automation nobody supervises

What are Cron Jobs in OpenClaw

If you've ever scheduled a task on Linux with cron, the idea is the same. In OpenClaw you can tell the agent: "run this task every day at 8am", and it does — without you being present.

The UI is simple and intuitive. That's part of the problem.

Finding #11: Cron Jobs as a persistence and defense evasion vector

An attacker who gains access to the OpenClaw dashboard — via a compromised Gateway Token, for example — can create a Cron Job that establishes persistence, evades detection, or gradually exfiltrates data.

The persistence vector is direct: a scheduled task that executes an outbound connection every hour maintains access to the system even if the original vector was closed. The defense evasion one too: tasks that periodically delete or modify logs make a compromise much harder to detect.

The most concerning aspect is that a malicious task is visually indistinguishable from legitimate use in the Cron Jobs dashboard list. There's no visible difference between "check system status every hour" and a persistence task.

OpenClaw has a Logs section in the dashboard, but we didn't validate whether it records Cron Job creation or with what level of detail — that's something we'll examine in the Part 4 demo.

🔍 Finding #11: Cron Jobs can be used as a post-compromise persistence and defense evasion mechanism. There's no visual distinction between legitimate and malicious tasks in the UI.

Nodes: distributing execution, distributing risk

What are Nodes in OpenClaw

Nodes allow distributing agent execution across multiple machines. Instead of everything running on a single instance, you can have independent nodes executing tasks in parallel.

Observation on Nodes

Each node has its own exec approvals configuration — independent from the global configuration. You can have a node with ask (the agent asks permission before executing) and another with allow (executes freely), running simultaneously in the same system.

This has an interesting security implication: blast radius from a compromise is contained to the affected node. If an attacker compromises one node, they don't necessarily have access to the others.

But it also works in reverse: if a node has more permissive configurations than the rest, that node becomes the weakest link in the chain — the path of least resistance for an attacker.

We didn't identify a concrete finding here because the behavior is by design. What is clear is that in a multi-node system, the security posture of the entire system is determined by the most permissive node, not the average.

Logs: the record that can disappear

What are Logs in OpenClaw

OpenClaw has a Logs section in the dashboard that shows agent activity and allows downloading them locally.

Finding #12: Local logs without external export

The problem isn't that logs exist — the problem is where they live.

OpenClaw's logs are stored locally on the server. That has two direct security implications.

First: if the agent has exec host policy set to gateway — the attack chain we saw in Part 1 — any process with filesystem access can modify or delete them. An attacker who compromises the server can clean up evidence of their activity before anyone detects it.

Second: if the instance fails, logs are lost with it. No historical visibility, no event correlation between sessions, no way to reconstruct what the agent did last week.

The obvious countermeasure is shipping logs to an external, immutable destination — CloudWatch Logs on AWS, for example — before they can be altered.

🔍 Finding #12: OpenClaw's logs are exclusively local. Combined with an agent with filesystem access, this facilitates post-compromise defense evasion and eliminates historical audit capability.

Config and Debug: internal information within token reach

What are these panels

The OpenClaw dashboard includes two panels that aren't for end users — they're for whoever administers the system.

Config shows the agent configuration: model, paths, timeouts, gateway parameters. Debug shows real-time internal diagnostics: component status, errors, internal system paths.

Finding #13: Internal information exposure via Gateway Token

Anyone who has the Gateway Token can access these panels.

The problem isn't new — we already saw it in Part 1: the token is visible in plaintext in the dashboard. But what we hadn't dimensioned is what information gets exposed if that token leaks.

With access to Config and Debug, an attacker has before executing any action: the complete map of how the agent is configured, the internal system paths, real-time status of each component, and error messages with internal architecture details.

That's not an execution vulnerability — it's free reconnaissance. And reconnaissance is the first step of any targeted attack.

🔍 Finding #13: Config and Debug panels expose internal system information to any Gateway Token holder. Combined with a token that's never been rotated, this is equivalent to permanent read access to the agent's internal state.

Findings summary

Combining findings from Part 1 and this Part 2, the complete map so far:

#	Finding	Surface	Severity
1	Blueprint with outdated kernel and libraries	Infrastructure	High
2	`exec host policy: gateway` + `shell approval: allow` = no isolation	Security Settings	Critical
3	Gateway Token in plaintext on dashboard	Authentication	High
4	IPv6 enabled by default	Network	Medium
5	Apache2 without documented hardening	Infrastructure	Medium
6	No granular access control on channels	Channels	High
7	Indirect prompt injection via external channels	Channels / Agent	Critical
8	Memory poisoning via unvalidated context	Agent	High
9	53 skills active by default — opt-out model	Agent	High
10	No permission inheritance model in agent chains	Agents	High
11	Cron Jobs as persistence and defense evasion vector	Cron Jobs	High
12	Local logs without external export	Observability	High
13	Config and Debug panels exposed via Gateway Token	Dashboard	Medium

What's next

Thirteen findings. Two critical, most of them high.

But a list of findings without structure is just noise. The next step is to give them a framework — understand where each one falls on the threat map of the agentic AI ecosystem, and how well existing frameworks anticipated them.

In Part 3 I'll map all these findings against three references:

OWASP Top 10 for Agentic Applications 2026 — the first framework specific to autonomous agents, published in December 2025.
AWS Agentic AI Security Scoping Matrix — AWS's framework for categorizing and prioritizing security controls in agentic AI systems.
OpenClaw's official threat model — based on MITRE ATLAS, with 37 threats documented by the team itself.

This won't be a framework walkthrough. I'll show where each finding lands on the map, what the frameworks anticipated, and — more interesting — what they didn't.

In Part 4 we get hands-on: a live demo putting findings to the test in a controlled environment. Real prompt injection, attack chain validation, and the first foundations of something that doesn't yet exist in LATAM: a security maturity model for agentic AI systems.

Did you find any of these surfaces in your own deploy? Leave a comment — I'd love to know how they look in different environments.

About the author

🔗 LinkedIn: gerardokaztro
🔗 Blog: roadtocloudsec.la

The script worked. The CISO needed something else. iam-audit v2: interactive dashboard, root account detection and Docker.

Gerardo Castro Arica — Tue, 10 Mar 2026 02:07:25 +0000

From raw CSVs to a visual dashboard anyone can run with a single Docker command — and how each feature came from a real need.

The hook

The first script worked. It iterated through 20+ AWS accounts, assumed roles with minimum privilege, and produced two CSVs with everything you needed to know about Access Keys and remediation events. Technically correct. Complete. Useful.

But when the time came to share the results with the team, I realized something uncomfortable: a CSV is an answer for someone who knows how to ask the right questions. For everyone else, it's noise.

The engineer opens the CSV and sees data. The CISO opens the CSV and sees rows. It's the same file — but it's not the same experience.

That led me to a question that changed the direction of the project: what if findings could be viewed, filtered, and understood without opening a single spreadsheet?

The context

When you work in security in enterprise environments, you quickly learn that technical findings have two distinct lives. The first is the technical life — raw data, fields, values, dates. The second is the executive life — risk, impact, urgency. The problem is that most tools only speak one of those two languages.

A CSV speaks the first. And that's fine — for the CloudSec Engineer who needs to triage, filter by account, sort by key age, and export for a ticket. But for the CISO who needs to understand the security posture of the organization in 30 seconds, a CSV is a barrier, not an answer.

This tension isn't new. Commercial security tools have been solving it for years — CSPMs like Wiz or Prisma Cloud have polished executive dashboards. But not every team has budget for those platforms, and even less so in LATAM where many organizations are still building their security baseline.

With that clear, the next step was obvious: the data was already there. What was missing was the presentation layer — no cost, no external dependencies, no friction.

Feature 1: The dashboard

From data to visibility: the HTML dashboard

The decision to use pure HTML was intentional. I could have used Grafana, QuickSight, or any visualization tool — but they all have the same problem: they require infrastructure, configuration, or an account on some service. An HTML file requires nothing. You open it in any browser, on any machine, without installing anything.

The mechanism is simple: the script generates the CSVs as usual, but before finishing it embeds them directly inside the HTML as strings. The dashboard parses them in the browser with JavaScript and converts them into interactive widgets. No backend, no database, no dependencies — a single self-contained file.

An important warning: the generated HTML contains real data from your organization. Treat it with the same sensitivity as a CSV with account and user information — don't share it through unsecured channels, don't upload it to public repositories, and make sure the output/ directory is in your .gitignore. The script already handles this, but it's worth keeping in mind.

The dashboard has four main views:

Executive summary — total accounts audited, total Access Keys, active vs inactive keys, users without MFA
Risk scoring per user — automatic prioritization based on key age, active status, and absence of MFA
Remediation trend — CloudTrail events chart over time, to see if the team is actually remediating
Findings table — filterable by account, status, and risk level

The filters are global — when you filter by account, all widgets update simultaneously. That's what makes it useful for a presentation: you can show the status of a specific account in seconds, without exporting anything or switching tools.

"Interactive dashboard generated by iam-audit v2"

Feature 2: Root account detection

The account everyone ignores: root account detection

There's a user in every AWS account that doesn't appear in any IAM Users listing. It doesn't have mandatory MFA by default. It generates no alerts if someone uses it. And it has unrestricted access to absolutely everything in the account. Unlike any other IAM user, its permissions cannot be reduced with identity policies — though certain actions can be restricted at the organizational level through SCPs. AWS Control Tower includes two specific preventive guardrails for this: one that prevents enabling Access Keys on the root account, and another that prevents executing actions as root. To detect whether MFA is enabled, there's also a detective guardrail — Detect Whether MFA for the Root User is Enabled — implemented via AWS Config Rule. However, none of these mechanisms give you consolidated visibility of root status across all your accounts in one place. That's exactly the gap this feature solves.

The AWS Security Maturity Model v2 is explicit about this. In its Phase 1 — Quick Wins, within the Identity and Access Management domain, one of the fundamental controls is Root Account Protection — ensuring the root account has active MFA, no active Access Keys, and that its usage is monitored. This isn't an advanced recommendation. It's baseline. It's the first thing you should have resolved before anything else.

Adding this control to the script was a logical decision: if you were already auditing IAM Users in each account, not auditing the root account meant leaving the most critical finding out of the report.

What the script audits per account:

MFA enabled — whether the root account has active MFA or not
Active Access Keys — whether any Access Key associated with root exists, which AWS explicitly recommends avoiding
Last login — cross-referenced with ConsoleLogin CloudTrail events filtered by root identity, to detect if anyone has used the root account recently

This last point is the most valuable for a CISO: it's not just knowing whether root has MFA — it's knowing whether someone used it in the last 90 days. That's what turns a technical finding into a real risk conversation.

"Root account detection widget — MFA, Access Keys and last login per account"

Feature 3: Docker

One command. No installation required. That's what was missing.

The script was already auditing. The dashboard was already visualizing. But there was a step that remained an invisible barrier: to run it, you needed Python installed, boto3 installed, and the repo cloned. For a CloudSec Engineer that's trivial. For someone who wants to evaluate the tool quickly, or for a team that doesn't want to manage Python dependencies on their machines, that's enough friction to not even try.

Docker eliminates that friction entirely.

The decision to dockerize wasn't about technology — it was about accessibility. If the goal was to build something any team in LATAM could use regardless of their local stack, the image had to be the unit of distribution. Not the repo, not the requirements.txt, not the installation instructions. The image.

The result is this command:

docker run --rm \
  -v ~/.aws:/root/.aws \
  -v $(pwd)/output:/app/output \
  -p 8000:8000 \
  gerardokaztro/iam-audit \
  --profile YOUR-AWS-PROFILE \
  --role YOUR-AUDIT-ROLE

That's it. Docker downloads the image from Docker Hub, mounts your local AWS credentials, runs the audit, generates the dashboard, and serves it at http://localhost:8000. When you're done, Ctrl+C and that's it — no residue, no dependencies installed on your machine.

Two design decisions worth mentioning:

The first is credential mounting. Instead of passing Access Keys as environment variables — which would be exactly the opposite of what the script audits — the container mounts the ~/.aws directory from your local machine. Your credentials are never hardcoded, never in the image, and expire if you use roles with aws sso login.

The second is the output volume. The output/ directory is mounted as an external volume, which means the generated files — CSVs and HTML dashboard — stay on your local machine even after the container is destroyed. Without a volume, you'd lose the reports when you hit Ctrl+C.

The image is published on Docker Hub at gerardokaztro/iam-audit and is built automatically from the Dockerfile in the repository.

"From a terminal command to a dashboard in the browser"

The findings

What the dashboard shows when you run it in production

Running iam-audit v2 against the same AWS Organization from the first post produced something qualitatively different from the original CSV. Not because the data was different — but because the presentation completely changed the conversation.

The executive summary of the dashboard showed the state of the organization at a glance:

Finding	Result
Accounts audited	20+ active accounts
Access Keys found	Dozens
Oldest key	Created in 2018 — active in production
Users without MFA + console access	Dozens
Root accounts without MFA	Several
Root accounts with active Access Keys	None
Total execution time	Minutes

The risk scoring widget was the most useful for prioritizing remediation. Seeing which users combined old key + no MFA + active console access — all in a single filterable view by account — is what turns a report into an action plan.

"Risk scoring per user — automatic findings prioritization"

The root account widget had the biggest impact for the executive conversation. Not because there were critical findings in every account — but because for the first time there was an immediate visual answer to the question: what's the root status across the entire organization? Before this feature, that question had no consolidated answer.

"Root account status per account — MFA, Access Keys and last login"

The most striking data point wasn't technical — it was process-related. The remediation trend in CloudTrail showed that DeleteAccessKey events increased significantly after sharing the first report. The script didn't just find the problem — it created the mechanism to measure whether it was being solved.

"Remediation trend via CloudTrail — DeleteAccessKey events increased after the first report"

The closing

What I learned building this

That tools evolve when you use them in production with real people. The script from the first post was technically correct — but the reality of the field kept pushing it toward something more complete. The dashboard was born because a CSV didn't communicate for all audiences. Root account detection was born because the ASMM required it and no one had it solved in a consolidated way. Docker was born because accessibility matters as much as functionality.

None of those decisions came from a planned roadmap. They came from using the tool, listening to what was missing, and building the next layer.

That's exactly what I want to document in Road to CloudSec LATAM — not the polished final result, but the real process of iterative construction. The design decisions, the mistakes, the adjustments. Because that's what actually teaches.

If you want to run iam-audit v2 in your own AWS Organization, everything you need is in the repository. No cost, no additional infrastructure, no dependencies beyond Docker and an audit role with minimum privilege.

docker run --rm \
  -v ~/.aws:/root/.aws \
  -v $(pwd)/output:/app/output \
  -p 8000:8000 \
  gerardokaztro/iam-audit \
  --profile YOUR-AWS-PROFILE \
  --role YOUR-AUDIT-ROLE

🔗 GitHub: github.com/gerardokaztro/iam-audit

If you run it, find something interesting, or have feedback — reach out. The CloudSec community in LATAM is built by sharing what works in real environments.

About the author

Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.

🔗 LinkedIn: linkedin.com/in/gerardokaztro
🔗 Blog: roadtocloudsec.la

A 2018 Access Key. Still Active in Production. Here's the Python Script That Found It Across an Entire AWS Organization.

Gerardo Castro Arica — Sat, 07 Mar 2026 10:00:00 +0000

A few weeks ago I sat down to review the IAM state of a multi-account AWS Organization. It wasn't a formal audit with weeks of planning. It was the simple question every Cloud Security Engineer should be able to answer at any time:

Who has access, with what credentials, and since when?

The answer surprised me. Not because it was hard to find — but because of how easy it was to automate, and what came to light when I did.

The Context

Organizations that have been running on AWS for years accumulate security debt without realizing it. They start with one account, then two, then a team requests its own environment, another project comes along, and suddenly you have an AWS Organization with dozens of accounts, each with its own IAM history.

The problem isn't scale — it's visibility. Or rather, the lack of it.

In multi-account environments, nobody has a consolidated view of who has what access. Infrastructure teams know what they deployed. Development teams know what they needed at the time. But the Access Keys created three years ago for an integration process that no longer exists, that were never rotated, that are still active — those don't show up in any dashboard. They don't generate alerts. They don't bother anyone. They just wait.

That's exactly what I found. An active AWS Organization, with multiple production accounts, and credentials that had gone years without being centrally audited. Not because the team was careless — but because nobody had built the mechanism to see them all at once.

I decided to automate that search.

The Risk

IAM Access Keys are long-lived credentials. Unlike IAM roles — which generate temporary credentials that expire automatically — an Access Key has no expiration date. If you create one today and never rotate it, it's still valid in 2030.

That makes them one of the most common attack vectors in AWS environments. Not because they're insecure by design, but because time works against them. A key that's been active for years silently accumulates risk:

It may have been exposed in a code repository without anyone noticing
It may be in the hands of an employee who no longer works at the organization
It may have permissions granted for a one-time project that were never reviewed
It may have been used by an attacker for months — and without rotation, nobody knows

The AWS Security Maturity Model v2 is precise about this. In its Phase 1 — Quick Wins, within the Identity and Access Management domain, one of the key controls is Multi-Factor Authentication — ensuring all users with console access have MFA enabled. In Phase 2 — Foundational, the model goes further with Use Temporary Credentials — the recommendation to migrate toward IAM roles and short-lived credentials, moving away from long-term Access Keys.

The script audits both controls in a single run: which users have active Access Keys, how long they've been active, and whether they have MFA configured. An active key from 2018 combined with a user without MFA isn't just technical debt — it's an attack surface that's been open for years.

The Solution

Design decisions before code

Before writing a single line, I made three decisions that define how the script works.

First decision: cross-account via STS, not IAM users.
The obvious temptation is to create an IAM user with audit permissions in each account. But that solves a visibility problem by creating exactly the problem we're trying to eliminate — more long-lived credentials. The right solution is sts:AssumeRole: the script assumes an existing role in each account, gets temporary credentials, audits, and the credentials expire on their own.

Second decision: start from AWS Organizations.
Instead of maintaining a manual list of accounts, the script queries the Organization directly and gets all active accounts in real time. If a new account is created tomorrow, the next run includes it automatically. No lists to maintain, no accounts slipping through the cracks.

Third decision: always paginate.
IAM APIs paginate. If you don't use get_paginator(), in an account with many users you'll only see the first results and never know it. It's the kind of silent bug that destroys the reliability of an audit.

With those three decisions clear, the code practically writes itself.

The main flow

def main():
    args = parse_args()
    session = boto3.Session(profile_name=args.profile)
    org_client = session.client('organizations')

    # Get all active accounts from the Organization
    accounts = get_accounts(org_client)

    all_findings = []
    for account in accounts:
        print(f"Auditing account: {account['name']} ({account['id']})")
        try:
            credentials = assume_role(
                session,
                account['id'],
                args.role,
                'SecurityAudit'
            )
            iam_client = boto3.client(
                'iam',
                aws_access_key_id=credentials['AccessKeyId'],
                aws_secret_access_key=credentials['SecretAccessKey'],
                aws_session_token=credentials['SessionToken']
            )
            findings = get_iam_users_with_keys(iam_client, account['id'], account['name'])
            all_findings.extend(findings)
        except Exception as e:
            print(f"Error in account {account['name']}: {e}")

    return all_findings

One account fails — the script continues. That's intentional: in a real Organization you'll find accounts where the role isn't deployed, or where permissions differ. The try/except ensures an error in one account doesn't stop the entire audit.

The heart of the script: what we audit per user

def get_iam_users_with_keys(iam_client, account_id, account_name):
    findings = []
    paginator = iam_client.get_paginator('list_users')

    for page in paginator.paginate():
        for user in page['Users']:
            # User's Access Keys
            keys_response = iam_client.list_access_keys(UserName=user['UserName'])

            # MFA status
            mfa_response = iam_client.list_mfa_devices(UserName=user['UserName'])
            mfa_devices = mfa_response['MFADevices']

            # Console access
            try:
                iam_client.get_login_profile(UserName=user['UserName'])
                password_status = 'Configured'
            except iam_client.exceptions.NoSuchEntityException:
                password_status = 'Not configured'

            for key in keys_response['AccessKeyMetadata']:
                last_used_response = iam_client.get_access_key_last_used(
                    AccessKeyId=key['AccessKeyId']
                )
                last_used = last_used_response['AccessKeyLastUsed']

                findings.append({
                    'account_id': account_id,
                    'account_name': account_name,
                    'username': user['UserName'],
                    'password_status': password_status,
                    'access_key_id': key['AccessKeyId'],
                    'status': key['Status'],
                    'created_date': str(key['CreateDate']),
                    'last_used_date': str(last_used.get('LastUsedDate', 'Never used')),
                    'service_name': last_used.get('ServiceName', 'N/A'),
                    'mfa_status': 'Virtual' if any('virtual' in d['SerialNumber'].lower()
                                   for d in mfa_devices) else 'Hardware' if mfa_devices else 'None'
                })
    return findings

For each user the script captures: all their Access Keys with status and creation date, when each key was last used and for what service, whether they have MFA active and of what type, and whether they have console access configured. All of that in a single pass per account.

How to run it

python iam_audit.py --profile your-mgmt-profile --role OrganizationAccountAccessRole

The script needs two things: an AWS profile with access to the Organization's management account, and a role deployed in each member account that allows assumption from the management account.

For the management account, the IAM policy is minimal by design — only the strictly necessary permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "organizations:ListAccounts",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::*:role/ROLE-NAME-IN-CHILD-ACCOUNTS"
    }
  ]
}

Nothing more. The role in the management account doesn't touch IAM directly — all auditing happens through the role it assumes in each child account. If you use AWS Control Tower, the AWSControlTowerExecution role already exists in all accounts and you can use it as a starting point, though in production I recommend creating a dedicated audit role with read-only permissions over IAM.

This isn't a minor detail — it's the least privilege principle applied to the tool that audits least privilege. The script's own attack surface is reduced to the minimum.

The script doesn't just audit the current state — it also reconstructs the timeline. Once you find the findings and start remediating, you need to be able to answer a second question: how are we progressing?

For that, the script queries CloudTrail in each account and extracts key IAM activity events: DeleteAccessKey, CreateAccessKey, DeleteUser. This lets you see over time whether the team is actually remediating — or whether the findings stayed in a report nobody acted on.

The final output is two CSV files: one with all IAM findings, and another with those CloudTrail events that build the remediation trend.

The Findings

I ran the script against an active AWS Organization in the region. Here's what I found:

Finding	Result
Accounts audited	More than 20 active accounts
Access Keys found	Dozens
Oldest key	Created in 2018 — active in production
Users without MFA + console access	Dozens
Total execution time	Minutes

Two accounts weren't audited — the audit role wasn't deployed in them. That in itself is a finding: if you can't audit an account, you can't know what's inside.

The most impactful data point isn't the volume — it's the age. An Access Key created in 2018 and still active in production means it survived everything. Not because someone protected it — but because nobody saw it.

The script saw it in minutes.

What Do You Do With This Now?

If you have an AWS Organization, you can run this script today. You don't need a SIEM, you don't need a dedicated security team, you don't need a special budget. You need Python, boto3, and an audit role with least privilege in your accounts.

What you do need is the willingness to see what's there.

The most uncomfortable result of an audit isn't the technical finding — it's realizing that the information was always there, waiting for someone to systematically look for it. Old Access Keys don't show up in any dashboard by default. They don't generate alerts. They don't bother anyone. They just wait.

Automating visibility is the first step of any serious security program. Not the most glamorous, but the most honest.

The script generates two CSVs. The natural next step is converting that data into a visual dashboard — risk widgets per account, remediation trend over time, consolidated MFA status. That's coming in the next post.

The repository with the complete code is on GitHub — link below. If you use it, find something interesting, or have feedback, reach out. The CloudSec community in LATAM is built by sharing what works in real environments.

About the Author

🔗 GitHub: gerardokaztro
🔗 LinkedIn: gerardokaztro
🔗 Original post (Spanish): roadtocloudsec.hashnode.dev

I Deployed OpenClaw on AWS and Here's What I Found as a Cloud Security Engineer (Part 1)

Gerardo Castro Arica — Thu, 05 Mar 2026 21:32:03 +0000

Part 1 of a series: Secure setup, real findings, and attack surface analysis of an autonomous AI agent on AWS Lightsail.

AWS just announced the general availability of OpenClaw on Amazon Lightsail — an open-source, self-hosted autonomous AI agent that connects to WhatsApp, Telegram, Discord, and executes tasks independently: running code, managing files, browsing the web.

The community is fired up testing it. So did I — but with a Cloud Security Engineer hat on.

This post isn't about how to use OpenClaw as an assistant. It's about what I found while setting it up from a security perspective, what decisions I made, and why.

What exactly is OpenClaw?

Before talking security, let's align on concepts.

An LLM (like Claude or GPT) receives a prompt and returns text. That's it.

An autonomous agent is different: it has access to tools (terminal, browser, APIs), decides the order in which to use them, interprets the results, and acts — without you directing each step. The LLM is the "brain," but the agent is the full system that operates in the real world.

OpenClaw is exactly that: an agent running on your server, using an LLM (in this case via Amazon Bedrock) as its reasoning engine, capable of executing tasks autonomously through messaging channels.

That autonomy is what makes it powerful. And also what makes it interesting from a security standpoint.

The Lightsail Setup

AWS packaged OpenClaw as a Lightsail blueprint — meaning you can have an instance running in minutes with no manual configuration.

What I saw in the wizard (and what caught my attention)

The SSH keypair:

Lightsail gives you two options: let AWS generate the keypair, or upload your own.

The security recommendation is clear: generate your own locally.

ssh-keygen -t ed25519 -C "openclaw-sandbox"

Why? When AWS generates the keypair, the private key is created on their servers and travels to you for download. That transmission moment is an avoidable risk. If you generate it yourself, the private key never leaves your machine.

The analogy: the public key is the padlock you put on the server. The private key is the key only you hold. Anyone can see the padlock, but no one else can open it.

💡 Remember: always run chmod 400 on your private key. If it has 644 permissions, other system users can read it — and the SSH client itself will warn you.

The firewall (Security Group):

By default, Lightsail opened ports 80, 443, and 22 to 0.0.0.0/0 — any IP in the world.

For a personal sandbox that's unnecessary. I changed all three rules to restrict them to my IP only:

curl ifconfig.me  # get your public IP

Less exposed attack surface = less blast radius if something goes wrong.

First Finding: Outdated OS

When I connected via SSH, the welcome message was straightforward:

44 updates can be applied immediately.
31 of these updates are standard security updates.

The AWS blueprint shipped with 31 unpatched security updates. Including a kernel patch and intel-microcode update.

Why does the kernel matter? Because it's the core of the OS — it controls memory, processes, and permissions. Known kernel vulnerabilities like Dirty Pipe or Spectre/Meltdown allow privilege escalation or reading memory from other processes.

On a server running Docker containers (like OpenClaw), an unpatched kernel can be exploited for a container escape — breaking out of the isolated container and taking full control of the host.

The fix is simple:

sudo apt update && sudo apt upgrade -y
sudo reboot

🔍 Finding #1: OpenClaw blueprint on Lightsail deployed with outdated kernel and system libraries. Any client using it in production without applying patches is exposed to known CVEs.

The Most Interesting Part: OpenClaw Security Settings

After setup, OpenClaw presents 5 security configurations. This is where things get interesting.

1. File & folder protection     → Status: ✓ Protected
2. Browser remote control       → Status: ✓ Disabled
3. Exec host policy             → Status: ~ Not set (defaults to sandbox)
4. Shell command approval       → Status: ~ Unrestricted
5. Access token                 → Status: ~ Never rotated

Setting 3: Exec host policy

This controls where the agent executes shell commands.

sandbox (default): commands run inside an isolated Docker container.
gateway: commands run directly on the server OS.

The blast radius difference is enormous. With gateway, if the agent is compromised, the attacker has direct access to the filesystem, environment variables, the IAM role — everything.

Setting 4: Shell command approval

This controls whether the agent asks for permission before executing a command.

deny: blocks all shell commands.
allow: executes them freely without asking.

The attack chain you can't ignore

Here's the most dangerous scenario, and it's completely possible if you don't configure things properly:

exec host policy: gateway  +  shell command approval: allow

Result: the agent can execute any command directly on the server, without isolation and without asking for permission.

Add a prompt injection attack on top of this — where someone inserts malicious instructions into content the agent consumes (an email, a file, a web page) — and the attacker can take control of the server without you noticing.

This chaining of weak configurations is called attack chaining, and it's exactly the type of analysis that needs to happen before putting an agent into production.

🔍 Finding #2: The combination of exec host policy: gateway + shell command approval: allow eliminates all agent isolation layers. In production, this represents a critical risk.

Setting 5: Gateway Token visible in the dashboard

The Gateway Token is the agent's "password" — whoever has it controls OpenClaw completely.

The problem: it's displayed in plaintext in the dashboard.

Any screenshot of the dashboard, any screen recording, anyone looking over your shoulder — compromises access to the agent.

AWS recommends rotating it frequently and not hardcoding it in configuration files. But the fact that it's visible by default in the UI is a design consideration worth noting.

🔍 Finding #3: The Gateway Token is displayed in plaintext in the dashboard. Combined with an internet-exposed dashboard, this represents direct credential exposure.

IPv6 Enabled by Default

A detail that flies under the radar: the blueprint comes with dual-stack (IPv4 + IPv6) enabled by default.

The security problem: many firewall rules are written with IPv4 in mind. IPv6 traffic can go unnoticed if you're not reviewing both protocol families in your controls.

If you're not using IPv6, disable it. Unnecessary attack surface.

What's Installed in This Blueprint?

Among the services restarted after apt upgrade, an interesting one appeared:

systemctl restart apache2.service

The OpenClaw dashboard runs on Apache2. That means Apache is another attack surface to consider — with its own CVEs and configurations to review.

An attacker familiar with Apache vulnerabilities could attempt to bypass gateway authentication without ever needing the token.

Findings Summary

#	Finding	Severity
1	Blueprint deployed with outdated kernel and system libraries (31 pending security updates)	High
2	`gateway` + `allow` combination eliminates isolation and command approval	Critical
3	Gateway Token displayed in plaintext in the dashboard	High
4	IPv6 enabled by default with no option to disable it in the wizard	Medium
5	Apache2 as web server with no documented hardening	Medium

Secure Configuration Recommendations

If you're deploying OpenClaw in a real environment:

Generate your keypair locally — never let the provider generate it for you.
Restrict the firewall to known IPs from the very beginning.
Apply patches immediately after deploy — don't trust that the blueprint is up to date.
Keep exec host policy on sandbox — Docker isolation is your first line of defense.
Set shell command approval to deny or require explicit approval — human in the loop for irreversible actions.
Rotate the Gateway Token regularly and never expose it in screenshots.
Disable IPv6 if you're not using it.
Don't expose the dashboard to the internet — if you need remote access, use a VPN or secure tunnel.

Why This Matters

Autonomous AI agents are arriving in production at companies across LATAM. OpenClaw is just the first of many.

Most teams deploying them aren't thinking about attack surface, blast radius from a misconfiguration, or how a prompt injection can chain with a misconfiguration to fully compromise a server.

That gap is exactly where Cloud Security Engineers need to be.

What's Next

In Part 2 I'll explore the surfaces we didn't touch today: Channels (WhatsApp/Telegram integrations), Agents, Cron Jobs, and how each one expands the system's attack surface.

I'll also run a full threat model using the OWASP Top 10 for Agentic Applications 2026 and the AWS Agentic AI Security Scoping Matrix.

This article is part of the Road to CloudSec LATAM series. Original version in Spanish on Hashnode.

Have questions or found something different in your deployment? Drop a comment — I'm building the complete threat model for Part 2.

About the Author

Gerardo Castro is an AWS Security Hero and Cloud Security Engineer focused on LATAM. He believes the best way to learn cloud security is by building real things — not memorizing frameworks. He writes about what he builds, what he finds, and what he learns along the way.

🔗 GitHub: https://github.com/gerardokaztro
🔗 LinkedIn: https://linkedin.com/in/gerardokaztro

Cómo visualizar los hallazgos de Amazon GuardDuty en MS Teams

Gerardo Castro Arica — Fri, 03 Mar 2023 19:27:11 +0000

En este blog post te mostraré como enviar los hallazgos de Amazon GuardDuty a un canal de mensajería como Microsoft Teams en un formato de tarjeta que contenga información relevante del hallazgo para que el equipo de seguridad pueda tomar acción inmediata.

Puede usar esta integración para comprender mejor los hallazgos de Amazon GuardDuty.

Enfoque para visualizar los resultados de Amazon GuardDuty

Como se muestra en la Figura 1, hay cuatro pasos de alto nivel para entender como funciona la solución.

1. Centralizar los hallazgos de Amazon GuardDuty

Puede centralizar los hallazgos de Amazon GuardDuty en una única cuenta como Security Audit para que desde aquí se pueda implementar el resto de componentes de la solución. De esa manera, puedes usar esta solución para recibir todos los hallazgos detectados en tus cargas de trabajo, sin importar en que cuenta o región se haya detectado.

2. Recopilar los hallazgos con Amazon EventBridge

Amazon EventBridge es un servicio muy útil al momento de recopilar eventos de algún otro servicio y redireccionarlos hacia un target especifico como una función Lambda, un tópico SNS, un servicio ETL como Kinesis Data Firehose, entre otros.

3. Ejecución del código de una función Lambda

Cada vez que la función lambda reciba un hallazgo de Amazon GuardDuty invocara el código que tiene configurado para hacer el envío de este hallazgo a un canal de mensajería como MS Teams.

4. Visualizar el hallazgo

En la Figura 2, podemos ver un ejemplo de como el equipo de segurida recibirán los hallazgos de Amazon GuardDuty en su canal.

Descripción general del diseño

Este diagrama de arquitectura representa a alto nivel los servicios a usar y la interacción entre ellos.

En el diagrama de la figura 3, vamos a explicar el paso a paso:

Dentro de un esquema de múltiples cuentas AWS, conviene empezar a delegar la administración de algunos servicios por sobre el resto de cuentas, como es el caso de Amazon GuardDuty. Hacer esto te permite centralizar todos los hallazgos de Amazon GuarDuty de todas las cuentas donde tengas habilitado este servicio. Y delegar una única cuenta, en este caso la Security Audit para gestionar Los hallazgos desde un único punto.
Cada hallazgo detectado por Amazon GuardDuty, es recopilado por una regla basada en eventos de Amazon EventBridge y redirigirá estos eventos (antes hallazgos) hacia una función lambda.
La función lambda va a desencadenar la invocación del código por cada evento que reciba de la regla configurada en EventBridge.
Recibirás una notificación en tu canal de MS Teams cada vez que se detecte un hallazgo, el cual se configura por medio de un incoming webhook.

Beneficios de la solución:

Al implementar esta solución, puede lograr los siguientes beneficios:

Ahorra tiempo al analizar un hallazgos de manera rápida y sencilla en lugar de hacerlo desde la misma consola de Amazon GuardDuty. En un esquema múltiples cuentas, no será efectivo hacer la búsqueda entre 1000 posibles.
Concentrarse en los hallazgos que generen mayor interés, por ejemplo, puedes solo recibir hallazgos de severidad HIGH, o de algún Treath Purpose como Cryptomining, o sobre algun recurso critico como una instancia EC2, un bucket S3, entre otros.
Obtener una vista rápida de los detalles del hallazgo, como saber cual es el indicador de compromiso del atacante o cual es el recursos afectado, incluso saber a que cuenta y región pertenece el hallazgo.

Pre-requisitos:

Instalar Git
Instalar Visual Studio Code, o algún otro de tu preferencia
Por si no lo tienes, instalar Zip
Instalar el cliente de MS Teams
Por ultimo, tener cuenta en Github y MS teams

Tutorial

Puedes hacer uso de esta solución tanto en un entorno de múltiples cuentas o una cuenta standalone. Es decir, si solamente tienes activado Amazon GuardDuty en una única cuenta, y quieres usar esta solución, puedes hacerlo, va a funcionar de todas maneras.

Lo primero que haremos, será crear o usar un canal de MS Teams para recibir los hallazgos, y configuraremos un incoming webhook.

Si vamos a crear un canal, estos son los pasos:

Elegir un nombre y descripción de tu preferencia.
La privacidad del canal, puede ser tanto pública o privada, va a depender de tus necesidades.
Dar clic en crear.

Una vez tengas el canal creado, ve a configuraciones del canal, y luego a conectores:

Acto seguido, donde dice "Webhook entrante" o "Incoming Webhook" dar clic en configurar:

Luego, en los detalles de la configuración del Webhook, coloca un nombre, agrega un icono y finalmente da clic en "Crear"

Inmediatamente el conector te va a brindar la url del webhook, cópiala en algún lugar, vamos a usar más tarde.

Lo segundo que haremos será crear una función lambda. Esta función debe ser creada en la misma cuenta donde residen los hallazgos de Amazon GuardDuty.

Elije un nombre, yo usare "alert-guardduty-teams"
Usa los mismos valores que muestro en la imagen.

Cambiemos los valores por defecto que usa lambda function a estos nuevos:

En la opción de Enviroment Variables (variables de entorno), agreguemos lo siguiente:

SEVERITY_THRESHOLD = coloca aquí el nivel de severidad de las amenazas que deben ser notificadas
TEAMS_WEBHOOK_URL = coloca aquí la url del incoming webhook que generaste en el primer paso.

Lo tercero que haremos será crear una regla en EventBridge, no te preocupes por el código ahora mismo, ya lo veremos.

Para crear una regla basada en eventos, ir a Amazon CloudWatch, y luego hacer clic en Rule:

Para crear y configurar una regla, consta de 3 pasos importantes:

Paso 1:

Elegir un nombre.
Agrega una descripción.
Todo lo demás por defecto, como en la imagen.

Paso 2:

Las opciones de "Event Source" y "Sample Event" las dejaremos por defecto.
En la opción de "Creation Method" elegir "Use pattern form".
En la opción de "Event pattern".

Paso 3:

Target type: AWS Services
Select a target: Lambda function
En Function, elegir la función lambda creada en el segundo paso.
Todo lo demás por defecto

Ahora si, vamos a por el código 💪

Deberás clonar en tu máquina local, este repositorio alojado en Github que contiene el código que usaremos.

No olvides dejar tu ⭐ al repositorio, también hazle fork 🔂 para que puedas customizarlo a tus necesidades y envíame un PR así contribuimos juntos a la comunidad Open Source.

gerardokaztro / guardduty-to-msteams

Cómo enviar los hallazgos de Amazon GuardDuty hacia MS Teams.

Cómo visualizar los hallazgos de Amazon GuardDuty en MS Teams

Puede usar esta integración para comprender mejor los hallazgos de Amazon GuardDuty.

Enfoque para visualizar los resultados de Amazon GuardDuty

Como se muestra en la Figura 1, hay cuatro pasos de alto nivel para entender como funciona la solución.

1. Centralizar los hallazgos de Amazon GuardDuty

View on GitHub

Una vez tengas el repositorio en tu local, busca el archivo alerts-guardduty-teams.zip y súbelo a tu función lambda.

Finalmente, modifica el lambda handler usando el nombre del archivo python comprimido

Si quieres hacer alguna modificación al código, te recomiendo hacerlo de manera local, luego comprimes el archivo python usando zip y lo subes a la función lambda.

Finalmente, empieza a recibir los hallazgos:

Te invito a compartir este blog, reaccionar y dejar un comentario acerca de que tan útil encuentras contenido como este. y te dejamos todas nuestras redes para que puedas seguirnos 🤝

🌎 CONTACTO:

🌐 Website: https://bit.ly/awssecuritylatam
🤝 Meetup: https://bit.ly/comunidad-awsseclatam
🔗 LinkedIn: https://bit.ly/linkedin-awsseclatam
🗣️ Slack: https://bit.ly/slack-awsseclatam

🔥 MÁS CONTENIDO:

📺 Youtube: https://bit.ly/youtube-awsseclatam
📺 Twitch: https://bit.ly/twitch-awsseclatam
🤳 https://bit.ly/instagram-awsseclatam
✍ https://bit.ly/blogs-awsseclatam
🚨 Si quieres estar enterado de todo nuestros contenidos, no olvides suscribirte, y ¡compartir!

⚠️ Si alguno de nuestros enlaces no funciona, no dudes en reportarlo.

Cómo lograr un gobierno de múltiples cuentas a escala con AWS Control Tower - Parte 2

Gerardo Castro Arica — Fri, 17 Feb 2023 05:07:15 +0000

En la primera parte de esta serie, entendimos cuales son los beneficios que se obtienen al hacer uso de una estrategia de múltiples cuentas AWS por sobre el uso de una cuenta única.

Descubrimos que haciendo uso de AWS Control Tower se obtiene el aprovisionamiento automatizado de cuentas AWS con una configuración básica consistente, simplificando el gobierno, y el cumplimiento de múltiples cuentas con modelos prescriptivos y prácticas recomendadas.

Como resumen, al llegar a este blog, ya hemos aprendido a activar AWS Control Tower y a configurarlo adecuadamente.

En esta segunda parte, nos enfocaremos a, ¿Cuál es la estrategia de gobierno que puedo lograr con AWS Control Tower de acuerdo a los intereses y lineamientos de mi organización?, por supuesto que, cada organización tiene intereses y objetivos diferentes, hay organizaciones que están interesadas en el cumplimiento de estándares como la ISO 270001 y PCI, otras en cambio a estándares como GDPR, NIST e incluso HIPAA. Todo depende del rubro de la organización, de la residencia de sus datos, del tipo de datos que almacenen y procesen sean propios o de clientes, entre otros factores.

Para profundizar en el tema de este blog, usaremos como escenario ser una organización del rubro de servicios financieros (Banca, Fintech, Neo Bank, Payment Processors, Corredora de seguros, etc) donde como lineamientos de la organización es el cumplimiento de estándares como PCI, ISO 27001 y NIST. Veremos a continuación como AWS Control Tower nos ayuda a cumplir con nuestros objetivos.

PASO 1: Cómo organizar mis cargas de trabajo mediante Unidades Organizativas

Cuando tenemos cargas de trabajo para diferentes propósitos y entornos, es una recomendación general organizarlas en OUs diferentes. A continuación te explico cuales son las OUs que deberías tener dentro de tu AWS Organization.

- OU Workloads:
Esta OU puede subdividirse en otras OUs para organizar mejor tus cargas de trabajo por entornos (Dev, QAS y PRD), por país operación (Perú, Argentina, Colombia, Chile, etc), por tipo de unidad de negocio (Banca, Seguro, Corredora), por tipo de carga de trabajo (Inteligencia de Negocios, Seguridad, Machine Learning, Serverless, etc).

- OU Sandbox:
Las cuentas dentro de esta OU deben estar aisladas del resto del ecosistema pues se requieren permisos menos restrictivos ya que su propósito es solo de experimentación, tal y como su nombre lo indica. Debemos asegurarnos que las cuentas dentro de esta OU se encuentren completamente aisladas de las otras OUs tanto a nivel de autenticación y red. Es muy útil que se apliquen los guardrails o service control policies (SCP) necesarios para evitar que “por simple aprendizaje” se termine levantando recursos de manera indiscriminada y que generen un alto costo.
Les recomiendo este blogpost donde encontrarán una forma automatizada con buenas prácticas incorporadas para operar dicha OU y tener un buen control sobre el presupuesto de la cuenta.

- OU Shared:
Aquí se pueden desplegar servicios compartidos por el resto de cuentas, por ejemplo, el uso de algún firewall IPS/IDS como AWS Network Firewall con un modelo de despliegue de salida hacia internet centralizada, el uso de VPNs como Site to Site o SSL. También puede centralizar la implementación de AWS Transit Gateway, RAM. Asi como casos donde se implementan y comparten servicios de directorio (AD), resolución de nombre de dominio (DNS) y cuentas de herramientas de desarrollo y ciclo de vida del software (SDLC) repositorio de código fuente, repositorio de artefactos, pipelines de CI/CD, servicios de infraestructura cómo código, etc.

- OU Security:
En esta OU, se despliegan las herramientas de seguridad que el equipo de seguridad usaría para monitorear el entorno y asegurarse de que no haya brechas de seguridad y que tengan las herramientas necesarias para remediar cualquiera de estas acciones.

- OU Suspended:
Si tienes cuentas que ya no son necesarias y quieres mantenerla en una OU un tanto especifica, puedes incluirla en esta OU. No está demás mencionar que es necesario que a esta OU se les asocie una SCP que deniegue cualquier tipo de acción.

- OU Policy Staging:
Recomiendo que antes de aplicar los guardrails o SCPs a una cuenta de producción, estos hayan sido probado antes en alguna cuenta para pruebas (no confundir con un ambiente sandbox).Tener una OU para ensayar políticas, puede resultar útil.

PASO 2: Identificar y habilitar los controles (guardrails)

Una vez separada tus cargas de trabajo mediante la segmentación de cuentas y unidades organizativas y como organización cuyo rubro es de servicios financieros, necesitamos controles que nos permitan cumplir o en su efecto estar alineados a los estándares que necesitamos.

AWS Control Tower Controls Library

Esta feature nos permite usar los diferentes tipos de controles que podemos encontrar agrupados por categoría.

Repasemos, ¿Qué es un control o guardrail en AWS Control Tower?
👉 Un control es una regla de alto nivel que nos permite aplicar una definición de gobierno sobre una unidad organizacional y posteriormente una cuenta o grupo de cuentas. Estos controles van a tener la misión de mejorar una postura de seguridad enfocada a objetivos de controles que pueden ser: logging monitoring, protección de datos entre otros, gestión de las vulnerabilidades, mínimo privilegio, entre otros.

Dentro de esta característica, vamos a conocer cuáles son, cómo funcionan y qué tipos existen, hasta aplicar una estrategia de controles en nuestro ambiente de múltiples cuentas AWS.

Control Behavior: ¿Cómo es que funcionan?

Repasemos nuevamente, existen 3 tipos de comportamientos para los controles:
1️⃣ Preventivos
2️⃣ Detectivos
3️⃣ Proactivos

Controles Preventivos

Previenen acciones dentro de nuestra infraestructura en AWS. Estos controles funcionan con SCP manejada por Control Tower, y deniegan acciones específicas relacionadas con el tipo de control que queremos aplicar.

Los controles preventivos, garantizan que la infraestructura esté en compliance con ese control o requerimiento específico, ya que no permite por medio de la SCP que se despliega recursos o que se haga alguna configuración inadecuada.

Otra característica de este tipo de controles es que su estado es “enforced” o “not enabled". Por lo que si queremos saber si estamos en cumplimiento con un control específico, solo basta con mirar el estado del control preventivo.

Ejemplo de un control preventivo

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "*",
            "Resource": "*",
            "Effect": "Deny",
            "Condition": {
                "StringLike": {
                    "aws:PrincipalArn": [
                        "arn:aws:iam::*:root"
                    ]
                }
            }
        }
    ]
}

Este guardrail (por detrás se aplica una SCP) es un control que previene que se realicen acciones en las cuentas AWS con el usuario root ya que se considera que el uso de este usuario privilegiado sobre la cuenta son para acciones de alto nivel y no para tareas del día a día, es decir, si tus acciones son de desplegar infra, cómo crear recursos en EC2, S3 entre otros, por favor, no uses la cuenta root. Y como parte del equipo de seguridad, si lo que requiero es prevenir este tipo de acciones y estar 100% en cumplimiento, pues este control preventivo de ejemplo es el ideal para responder.

Controles Detectivos

Nos permiten detectar cambios en la configuración actual de nuestra infraestructura e identifica si estos cambios se alinean o no con la postura de seguridad de la organización. Estos controles no garantizan qué todos nuestros recursos estén en compliance a diferencia de los controles preventivos.

Los controles detectivos funcionan con Config Rules, que nos permite conocer los cambios de configuración de los elementos en los recursos que estén desplegados y cuyos resultados son aprovechados por Control Tower.

En este tipo de controles, tenemos 3 estados que son “Clear”, “In Violation” y “not enabled”.

Ejemplo de un control detectivo

AWSTemplateFormatVersion: "2010-09-09"
Description: ""
Resources:
  ConfigRule:
    Type: "AWS::Config::ConfigRule"
    Properties:
      ConfigRuleName: "s3-bucket-public-read-prohibited"
      Scope:
        ComplianceResourceTypes:
          - "AWS::S3::Bucket"
      Description: "A Config rule that checks that your Amazon S3 buckets do not allow public read access. If an Amazon S3 bucket policy or bucket ACL allows public read access, the bucket is noncompliant."
      Source:
        Owner: "AWS"
        SourceIdentifier: "S3_BUCKET_PUBLIC_READ_PROHIBITED"
Parameters: {}
Metadata: {}
Conditions: {}

Este guardrail (por detrás se aplica una config rule) es un control que detecta cuando un bucket S3 cambia su estado de configuración, pasando de haber sido un recurso privado a uno público.

Controles Proactivos:

Nos ayudan a identificar la infraestructura que está a punto de desplegarse en la cuenta AWS, dando como resultado si los recursos a aprovisionarse serán compliance o no. Este análisis es realizado en la misma definición del código o template por el que se aprovisiona la infraestructura.

Cabe mencionar que funcionan utilizando cloudformation hooks, que precisamente es para identificar configuraciones específicas en recursos a desplegar. Un punto a considerar sobre este tipo de controles, es que solo es aplicable por recursos que son provisionados por AWS Cloudformation, aun no soporta recursos desplegados por Terraform, Pulumi, CDK, entre otros.

💡 TIP: Si usas StackSets (característica que permite desplegar infraestructura en múltiples cuentas) también podrás hacer uso de los controles proactivos.

Categorías de controles y Frameworks

Los controles en AWS Control Tower, se agrupan de la siguiente manera:

Agrupados por servicios de AWS:

Indican los servicios sobre los que se aplican los controles.

Agrupados por objetivos de control:

Indican en qué épica de seguridad nos ayudan a mejorar como: limitar el acceso a la red, administrar los secretos, impulsar el mínimo privilegio, administrar las vulnerabilidades, entre muchos otros.

Agrupados por Framework:

Nos muestran 3 categorías que nos ayudan a estar en cumplimiento respecto a las buenas prácticas que recomienda AWS con referencia a NIST, PCI y CIS AWS Benchmark.

PASO 3: Recomendaciones para habilitar controles

Revisa cada uno de los controles antes de activarlos en una OU (y por consecuente en las cuentas). Es necesario tener una clara comprensión sobre los controles que necesites habilitar y que este entendimiento sea compartido entre los equipos de seguridad, desarrollo y operaciones.

Si quieres conocer el detalle de un control en especifico, desplázate hacia a la pestaña “About” y encontraras información útil del control.

Es importante que se tenga definido que objetivos se quieren mejorar en la organización, es decir, cuales son esas políticas de seguridad a las que se necesita estar alineado. De esta forma, en Controls Library podrás los controles que te ayuden a mejorar la postura de esa política.

Por ejemplo, si están utilizando Amazon S3 y quieren averiguar todos los controles relacionados a este servicio y cumplir con el control objetivo de “protección de datos” pueden hacerlo de esta manera:

PASO 4: Conclusión

Identifica los controles que quieres habilitar
- Recuerda profundizar sobre el control: definición, tipo, comportamiento y referencia.
Despliega los controles aplicando buenas prácticas
- Recuerda tener una OU Policy Stagging con la finalidad de probar aquí los guardrails (controles) para luego ir pasando de a poco hacia OU productivas.
Monitorea el estado de los controles habilitados
- Importante monitorear los controles de tipo detectivo, ya que ellos te dirán que recursos se encuentran "In Violation", quiere decir, recursos non-compliance, identifica esos recursos y remédialos.

💡 TIP: Usa esta sintaxis en tu AWS CLI o AWS CloudShell para identificar los controles que tengas habilitados en alguna OU especifica.

aws controltower list-enabled-controls --target-identifier <OU Id>

ℹ️ Si quieres aprender mas sobre AWS Control Tower - Controls Library, te invito a ver este vídeo, recomendádselo

Te invito a compartir este blog, reaccionar y dejar un comentario de que te tan útil encuentras contenido como este. y te dejamos todas nuestras redes para que puedas seguirnos 🤝

🌎 CONTACTO:

🌐 Website: https://bit.ly/awssecuritylatam
🤝 Meetup: https://bit.ly/comunidad-awsseclatam
🔗 LinkedIn: https://bit.ly/linkedin-awsseclatam
🗣️ Slack: https://bit.ly/slack-awsseclatam

🔥 MÁS CONTENIDO:

⚠️ Si alguno de nuestros enlaces no funciona, no dudes en reportarlo.

Cómo lograr un gobierno de múltiples cuentas a escala con AWS Control Tower - Parte 1

Gerardo Castro Arica — Tue, 07 Feb 2023 19:43:31 +0000

Hoy en día, los clientes de las industrias reguladas enfrentan el desafío de definir y hacer cumplir los controles necesarios para cumplir con los requisitos de cumplimiento y seguridad, en la mayoría de casos, es posible que las organizaciones también deban cumplir con marcos y estándares como ISO 27001 y NIST 800-53.

Mantener la seguridad y la gobernabilidad en un modelo de múltiples cuentas podría ser un desafío para algunas organizaciones. Sin controles preventivos estructurados aplicados a escala (guardrails) y la aplicación de configuraciones básicas (Baseline), la solución de problemas y la mitigación de riesgos puede requerir un esfuerzo mayor al esperado.

¿Qué es una cuenta AWS?

Una cuenta AWS representa un límite de seguridad que aísla nuestros recursos y cargas de trabajo frente a las cargas de otros clientes de AWS, aunque hagamos uso de la misma región, la misma zona de disponibilidad e incluso el mismo centro de datos.

¿Qué estrategia me conviene usar: Cuenta única o Multi-Cuenta?

Si tu propósito es hacer uso de una cuenta con fines de aprendizaje, pruebas, sandbox, entonces te recomendaría solo tener una única cuenta AWS para que sea más sencilla de administrar.

Pero, si vas a utilizar la nube para tu empresa u organización, para alguna carga de trabajo productiva, se recomienda un esquema multi-cuentas, por las siguientes razones:

Para separar tu infraestructura en entornos como producción, testing y desarrollo.
Si desde un punto de vista temprano, sabes que vas a gestionar una infraestructura a escala, para separar las cargas de trabajo y que un despliegue de una unidad de negocio no afecte las cargas de otra unidad.
Para simplificar la separación de costos Unidades de negocio o proyecto, en cada cuenta.

Entonces, ¿Cómo podemos gestionar a escala consistentemente múltiples cuentas de AWS? Usando AWS Control Tower, el mismo que ya fué anunciado de manera global en 2019 para los clientes de AWS. Este servicio automatiza el aprovisionamiento de cuentas con una configuración básica consistente, simplifica la gobernanza, y el cumplimiento de múltiples cuentas con modelos prescriptivos y prácticas recomendadas.

Introducción

En este blog post, les mostraré cómo activar AWS Control Tower, asumiré que es la primera vez que usaras este servicio, iré paso a paso para que no te pierdas de nada. Si ya tienes el conocimiento básico o configuraste el servicio, te invito a ver la parte 2 de esta serie.

Descripción general del servicio:

AWS Control Tower configura tres cuentas de referencia (Management Account, Log Archive y Security Audit) que proporcionan entornos dedicados para funciones especializadas dentro de su organización.

Les dejo una breve descripción de cada cuenta de referencia:

Management Account contiene información de facturación para cada recurso en su landing zone.
Log Archive proporciona a su equipo el acceso a la información de registro (logs) de todas sus cuentas asociadas.
Security Audit proporciona a su equipo el acceso a la información de auditoría que AWS Control Tower pone a su disposición, principalmente por motivos de seguridad y cumplimiento.

Características adicionales:

Landing zone: Es el entorno general de las múltiples cuentas que AWS Control Tower configura por nosotros, a partir de una cuenta de AWS nueva.
Controls: Tambien conocido como guardrail, es una regla de alto nivel que proporciona un gobierno continuo para nuestro entorno general de AWS.
- Existen tres tipos de controles:
  - preventivo
  - detectivo
  - proactivo
- Se aplican tres categorías de orientación a los controles:
  - mandatorios
  - fuertemente recomendados
  - electivos.
Account Factory: es una plantilla de cuenta configurable que ayuda a estandarizar el aprovisionamiento de nuevas cuentas con configuraciones de cuenta preaprobadas.
Dashboard: ofrece una supervisión continua de su landing zone a su equipo de administradores de la nube central.

Cómo Activar AWS Control Tower:

Desde su cuenta root (o Management Account), ir al servicio de AWS Control Tower y dar clic en “Set Up Landing Zone”

AWS Control Tower verificará ciertos requisitos como el no tener activado Cloudtrail y Config a nivel Organizacional para determinar si tu cuenta root esta lista para ser configurada. De no cumplir con algunos de estos requisitos, te aparecerá un mensaje así:

Es importante corregir los requisitos fallidos para poder darle “Rechek”.

Paso 1: Revisión de precios y Selección de regiones

Home Region: Esta es la región predeterminada donde se aprovisionan los recursos de sus cuentas compartidas.
Deny Region Control: El control de denegación de región es único, porque se aplica a su landing zone como un todo, en lugar de a cualquier unidad organizativa específica. Si aún no tiene idea de que regiones denegar, puede dejar esta opción en “not enabled” ya que puede cambiarse después.
Additional AWS Region: Permite seleccionar las regiones que estarán bajo el gobierno de AWS Control Tower adicional al “Home Region” seleccionado. Aún podrá aprovisionar sus recursos en las regiones no seleccionadas, pero debe tener en cuenta que no estarán bajo el gobierno de AWS Control Tower. También puede configurar esta opción más tarde.

Paso 2: Configurar unidades organizativas (OU)

Las mejores prácticas de AWS para un entorno bien diseñado recomiendan que debe separar sus recursos y cargas de trabajo en varias cuentas de AWS y que se agrupan (a menudo) en unidades organizativas (OU) con fines de gobierno y control.

AWS Control Tower configura automáticamente algunas de estas unidades organizativas:

Foundational OU: que contiene 3 cuentas compartidas: Management Account, Log Archive y Security Audit (también conocida como Audit).

Additional OU: para ayudar a configurar una estrategia multi-cuentas, es recomendable crear una OU secundaria al configurar la landing Zone. Esta OU se puede utilizar para almacenar cualquier cuenta de producción o desarrollo.

Paso 3: Configurar cuentas compartidas

AWS Control Tower requiere dos direcciones de correo electrónico únicas que aún no estén asociadas con una cuenta de AWS. Cada una de estas dos direcciones de correo electrónico se convierte en una bandeja de entrada colaborativa, lo que significa que cada una se convierte en una cuenta de correo electrónico compartida, a la que pueden acceder usuarios específicos de su empresa que realizan trabajos relacionados con AWS Control Tower.

Paso 4: Configurar CloudTrail y encriptación

AWS CloudTrail es un servicio que registra continuamente las actividades de su cuenta de AWS y está habilitado de forma predeterminada para los trails (rastreo) de CloudTrail a nivel de organización.

Los trails a nivel de organización agrega registros para todas las cuentas en la organización de AWS, incluidas las cuentas que no están gobernadas por AWS Control Tower. Puede cambiar esta configuración más adelante para evitar cargos adicionales de CloudTrail en las cuentas que no estén bajo el gobierno de AWS Control Tower.

De manera opcional, en la sección de “Log configuration for Amazon S3” puede configurar el tiempo de retención del bucket de archivos de registro de Amazon S3 y el tiempo de retención de los registros para acceder al depósito.

Y en la sección de "KMS Encryption" puede seleccionar una llave KMS existente o crear una nueva que cifre los registros almacenados en el bucket que AWS Control Tower crea para almacenar los registros de Cloudtrail a nivel Organizacional. Tenga en cuenta que esta llave deberá tener permisos sobre CloudTrail. Esta opción está deshabilitada de manera predeterminada y puede configurarse más adelante.

Paso 5: Revisar y configurar la landing zone

Finalmente, después de toda la configuración de los pasos previos, deberás marcar la casilla de verificación y dar clic en “Set Up landing zone”

El proceso que toma esta configuración dura aproximadamente 1 hora (60 minutos).

Pantallas o secciones adicionales:

La consola ofrece algunas acciones recomendadas:

En este punto, se pueden ver y habilitar los controles obligatorios, opcionales y fuertemente recomendados:

Puedo ver las unidades organizativas (OU) y las cuentas, y el estado de cumplimiento de cada una (con respecto a las medidas de seguridad):

Hasta aquí, ya tenemos activado AWS Control Tower. En la parte 2 de este blog, te mostraré algunas tareas operacionales que puedes hacer para administrar de manera eficiente este servicio.

Te invito a compartir este blog, reaccionar y dejar un comentario de que te tan útil encuentras contenido como este. y te dejamos todas nuestras redes para que puedas seguirnos 🤝

🌎 CONTACTO:

🌐 Website: https://bit.ly/awssecuritylatam
🤝 Meetup: https://bit.ly/comunidad-awsseclatam
🔗 LinkedIn: https://bit.ly/linkedin-awsseclatam
🗣️ Slack: https://bit.ly/slack-awsseclatam

🔥 MÁS CONTENIDO:

📺 Youtube: https://bit.ly/youtube-awsseclatam
📺 Twitch: https://bit.ly/twitch-awsseclatam
🤳 https://bit.ly/instagram-awsseclatam
✍ https://bit.ly/blogs-awsseclatam

🚨 Si quieres estar enterado de todo nuestros contenidos, no olvides suscribirte, y ¡compartir!

⚠️ Si alguno de nuestros enlaces no funciona, no dudes en reportarlo.

AWS Re:Invent 2021 #Reaction Final Part

Gerardo Castro Arica — Sat, 04 Dec 2021 17:05:48 +0000

AWS re: Invent 2021 has come to an end. It has been a week of total ecstasy. A week has passed since I published this post at the pre-inaugural midnight madness moment:

AWS Re:Invent 2021 #Reaction

Gerardo Castro Arica for AWS Community Builders ・ Nov 29 '21

#aws #discuss #news

Now, let me tell you a summary of the brightest and most outstanding moments that happened for me during Werner's keynote.

Keynote with Dr. Werner Vogels
Besides having had one of the best intros I have ever seen, listening to Werner's keynote was like going back in time, the beginnings of many services such as EC2 among others were remembered, since 2006. If you see the intro in detail, We will see references to the past like that "box" and we see that Werner remembers when he announced Lambda for the first time. Why so much nod to the past?

After the nod to the past about EC2 instances, boom! nod to the future with EC2 M1 Mac Instances, what will come next? kind of InstancesVerse? we won't know yet.

Other of the best announcements of this keynote is the launch of 30 new AWS Local Zones, including 2 AWS Local Zones in LATAM. This after highlighting how AWS has been working to offer a better user experience with very low latencies thanks to the large number of regions, and not to mention the more than 216 Edge Locations that it now has.

Our much-loved Amplify Studio comes with a huge upgrade. Now it allows us to create applications in a matter of hour, with a nice UI.

What I liked the most about this new release is its integration with the very powerful design tool Figma. That is, you have the development of your application without the need to throw code, and with a single click, you export all that UI to Figma for prototyping. What more can you ask? Yes, I am a fan of Figma.

Following that line "Dev", because now SDK is compatible with runtime like Swift, Kotlin and Rust.

Sustainability pillar

Goodbye StackOverFlow, Welcome AWS re:Post

You asked for this. Basically, this is your fault.
By Werner Vogels.

If you want to see the complete Keynote, this is the video: