DEV Community: Javier Pulido

How I Built a Hardened Amazon Linux 2 AMI with EC2 Image Builder

Javier Pulido — Mon, 16 Jun 2025 07:52:26 +0000

Manually hardening EC2 instances is tedious, inconsistent, and easy to mess up.

So I automated the entire process — and built a hardened Amazon Linux 2 AMI using EC2 Image Builder. It includes:

✅ CIS benchmark controls
✅ IMDSv2-only access
✅ Auditd + CloudWatch logging
✅ Patch compliance automation
✅ Secure, reusable AMIs for production

Here's a quick preview of the image pipeline config:

aws imagebuilder create-image-pipeline --cli-input-json file://pipeline-config.json

And it tests compliance automatically with every build.

👉 Full guide in here:
🔗 https://thehiddenport.dev/posts/aws-ami-hardening

How to Enforce Least Privilege in AWS IAM (Access Analyzer + CloudTrail)

Javier Pulido — Mon, 09 Jun 2025 11:08:44 +0000

Most IAM roles are over-permissioned by default.

We know we should “enforce least privilege,” but how? AWS doesn’t make it easy — especially across dozens of roles, dev teams, and constantly shifting service usage.

This week, I broke down my real-world approach using tools already built into AWS:

✅ IAM Access Analyzer for external exposure
✅ Service Last Accessed data for stale permissions
✅ CloudTrail + the IAM Policy Simulator to trim roles down
✅ EventBridge + Lambda for real-time alerting and automation

Here’s a sample from the article — using generate-service-last-accessed-details to audit a role:

aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:role/MyAppRole

Then review which services haven’t been touched in 90+ days:

aws iam get-service-last-accessed-details \
  --job-id <job-id>

💡 Combine this with CloudTrail and Access Analyzer for a full-picture review.

👉 I published the full, step-by-step guide here:

🔗 https://thehiddenport.dev/posts/aws-enforcing-least-privilege/

Includes detection tips, audit workflows, and code examples you can apply right now.

Thanks for reading — let me know how you're enforcing least privilege in your AWS org, or what your biggest roadblock has been.

How to Harden EC2 Instances in AWS: A Technical Guide

Javier Pulido — Thu, 29 May 2025 08:58:38 +0000

Hardening an EC2 instance in AWS isn't just about patching the OS. It’s about building layered defense into the very foundation of your infrastructure — before any workloads even land on the box.

In this article, I walk through a practical and detailed approach to hardening Amazon EC2 instances, aligned with AWS best practices and enriched with technical implementation examples. We’ll cover:

🔐 Identity and access controls
🛡️ OS-level security and configuration
📦 Package and service minimization
📊 Monitoring and audit trails
🔄 Secure metadata access via IMDSv2
🔒 Disk encryption, traffic filtering, and more

Whether you're operating EC2 in a production-grade environment or just want to learn how to build secure-by-default systems, this guide is for you.

👇 Table of Contents

IAM roles and SSH access
OS hardening: users, packages, and kernel settings
Logging with CloudWatch and audit tools
Enforcing IMDSv2 and disabling instance metadata abuse
Network-layer protections (SGs, NACLs, VPC)
EBS and filesystem encryption
Long-term patching, automation, and compliance

🔐 Identity and Access Management

Before you even spin up your EC2 instance, control who can access it — both at the AWS level and the OS level.

Use IAM instance roles instead of embedding credentials. Lock down ec2:DescribeInstances, ssm:SendCommand, and similar privileges to only those who need them. Avoid using hardcoded SSH keys in favor of EC2 Instance Connect or Session Manager whenever possible.

Here's a deeper look at these IAM concerns in my article on IAM misconfigurations and how to fix them.

🛠️ Operating System Hardening

Once the instance is launched, start hardening from the inside out. Some key steps:

Remove unused packages and users
Disable root login and enforce key-based authentication
Apply CIS Benchmarks (or AWS Inspector rules) where applicable
Configure iptables or nftables for outbound controls
Ensure auditd is enabled and logs are shipped externally

It’s worth automating these steps with user-data scripts, EC2 Image Builder, or a configuration tool like Ansible.

📖 Read the Full Guide

👉 I’ve written the full deep-dive article, with detailed configuration examples, command-line snippets, and AWS-specific security pitfalls to watch for.

🔗 Read the full article on The Hidden Port:

https://thehiddenport.dev/posts/aws-ec2-hardening/

Thanks for reading — feel free to leave a comment or let me know how you approach EC2 hardening!

Templates, Automation, and Playbooks: My AWS IR Toolkit is Now Live

Javier Pulido — Tue, 20 May 2025 12:10:40 +0000

I’ve spent the last few weeks organizing and refining my own incident response process for AWS.

From handling Security Hub alerts to writing custom SES and Slack notifications, I needed more than just a checklist — I needed an actual toolkit.

So I built one.

What’s Included:

✅ A printable incident response checklist for triage
✅ An editable IR playbook aligned with ISO 27001 + AWS best practices
✅ Notification flows using EventBridge, SES, and Slack
✅ A cloud forensics tool matrix to guide acquisition and analysis
✅ Deployment-ready Terraform + Lambda code for alerting automation

Why I Built It

After publishing my free IR checklist on my blog, I realized many teams (and individuals) still struggle with:

Rebuilding IR processes from scratch
Responding to findings without a clear comms path
Automating triage across teams or accounts

I bundled everything I use — templates, scripts, docs — into one focused toolkit.

When I started planning IR action plans this would have helped me a lot.

🛠️ Get the Toolkit

You can explore the full breakdown + story behind it here:
👉 [Read the full article](https://thehiddenport.dev/posts/aws-ir-toolkit/

And if you’re ready to grab it:
👉 Download the AWS IR Toolkit on Gumroad (€9)

Includes all future updates, and a community where you can suggest changes.

💬 If you've built your own IR tools or want to share feedback — I'm all ears. This is version 1.0, and I plan to keep refining it.

Thanks for reading — and stay sharp out there.

– Javier

Securing Temporary Credentials in AWS: What You Should Be Doing But Probably Aren’t

Javier Pulido — Mon, 12 May 2025 09:03:48 +0000

🔐 Temporary credentials in AWS are powerful—but also widely misunderstood.

They allow developers and systems to access AWS resources without relying on long-lived access keys. But just because they expire doesn’t mean they’re safe by default.

In this post, I break down:

✅ When and why to use temporary credentials
🧱 Where things go wrong (over-permissive roles, lazy session durations…)
🔒 Best practices for keeping temp creds secure
🧠 Advanced use cases like federation and IAM Roles Anywhere

🚧 Where People Go Wrong

I’ve seen real-world setups where:

Temp credentials lasted 12 hours
Were used with AdministratorAccess
In CI/CD pipelines with no monitoring

That defeats the whole point of ephemeral access.

🛡️ What You Should Be Doing

🔸 Use least privilege roles

Scope your roles tightly and use IAM condition keys like aws:SourceIp.

🔸 Shorten session durations

15–30 minutes is more than enough for most automation tasks.

🔸 Log STS usage with CloudTrail

Every AssumeRole or GetSessionToken should be traceable and alertable.

🔸 Require MFA where appropriate

Especially for sensitive role assumptions—break-glass or prod access.

🔸 Automate responsibly

Don’t reuse temporary creds or store them insecurely in config files. Use the SDKs properly.

🧠 Bonus: IAM Roles Anywhere

For non-AWS workloads (like on-prem apps), IAM Roles Anywhere lets you issue short-lived AWS credentials using signed certificates. It's a powerful addition for hybrid setups, but comes with its own set of guardrails.

🔗 Want the full breakdown?

The original article goes deeper into:

Federation setups with Okta or AzureAD
Example real-world misuses (and fixes)
Credential rotation strategies

👉 Read the full guide here

Let me know:

How is your team managing AWS access today?

Still using long-term credentials… or have you moved fully to short-lived roles?

Incident Response in AWS + Free PDF Playbook

Javier Pulido — Thu, 08 May 2025 06:30:00 +0000

🛡️ Incident Response in AWS + Free PDF Playbook

TL;DR: I wrote a complete, experience-based guide on how to structure an Incident Response (IR) process inside AWS. It includes a free downloadable playbook template you can adapt for your own organization.
🔍 What's in the guide?

This article walks through how to:

Set up a dedicated AWS IR account (or region)

Isolate and import compromised resources

Collect and store forensic evidence in S3

Automate parts of your response workflow using AWS-native services

Ensure evidence integrity and avoid contamination

It’s not theory — this is based on how we’re actually handling IR processes in real environments.
🧰 Bonus: Free PDF Playbook Template

I’ve included a downloadable playbook you can adapt to your own AWS setup.
It’s simple, focused, and designed to be actionable.
🔗 Read the Full Post

👉 Incident Response in AWS + PDF Playbook

If you're building or refining your IR playbook, I hope this helps you build something practical and secure.

Would love to hear how others are handling IR in cloud-native environments.

How I Passed the AWS Certified Security – Specialty (SCS-C02) Exam

Javier Pulido — Wed, 30 Apr 2025 06:38:26 +0000

I recently passed the AWS Certified Security – Specialty (SCS-C02) exam, and I wanted to share my experience in case it helps anyone else on the same path.

📚 Study Journey

I first started studying with Zeal Vora's course on Udemy back in September 2024. It gave me a solid foundation, but work got hectic, and I had to pause.

Earlier this year, I got back into it with Stephane Maarek’s SCS-C02 course — it was a fantastic refresher and only 16 hours long. I also started working through Tutorial Dojo’s practice exams, which were incredibly useful for simulating the real exam format.

All in all, I spent around 80–100 hours studying and playing lightly in AWS.

🧠 What Helped the Most

Taking notes after each failed question
Reviewing explanations, not just answers
Practicing with an AWS account (light console usage helped a lot)
Focusing on IAM, STS, Organizations, and logging-related services

🔍 What the Exam Felt Like

The real exam had a strong focus on:

AWS Organizations
CloudFront
Fleet management and IAM structure

Some topics like CloudHSM didn’t appear at all. But honestly, almost everything I studied showed up in one form or another.

Time was manageable — I finished with around 10 minutes to spare.

🎓 Final Advice

Pick one course and finish it fully before jumping to exams
Practice exams are not optional — they are essential
Don’t just memorize — try to understand what the service does and why you’d use it that way

📫 I write about cloud security, automation, and best practices at The Hidden Port.

If this post helped you, feel free to visit or share!