IAM least-privilege lab
An over-permissioned IAM and S3 setup built deliberately, then remediated step by step to least privilege. The same exercise an assessment's first recommendations usually lead to.
Warsaw · AWS Security for Small Teams
Network security engineer with a firewall-review and SOC background, now focused on AWS security for small teams: companies running production in the cloud without anyone whose job is to secure it. I learn by building, and everything below runs, or ran, on accounts and hardware I administer myself.
I work in network security at a global payments company, reviewing and analysing firewall policies across a large enterprise network day to day: rule hygiene, policy violations, and change review across Palo Alto Panorama and Tufin. Before that, SOC analysis in the same organisation, and network engineering at Cisco.
My spare time goes into hands-on work rather than slideware. Right now that means AWS: a structured Solutions Architect Associate course, cloud labs on TryHackMe, and my own AWS account where I break things on purpose and write up how to fix them. Security Specialty is the longer-term target. Alongside that: virtual firewalls on Proxmox, a segmented Meraki network, and offensive practice on Hack The Box.
A firewall background turns out to be a surprisingly good map for cloud security. The questions are the same (who can reach what, who is allowed to do what, and would anyone notice) and they get asked of IAM policies, security groups and CloudTrail instead of rule bases.
Small companies on AWS tend to share the same handful of problems: broad IAM permissions, logging that was never switched on, resources exposed that nobody remembers creating, no guardrails across accounts. Scanners can list them. What's usually missing is someone to say which ones actually matter for this business, and in what order to fix them. That's the work I'm building toward.
A structured review of an AWS environment: identity and access, logging and detection, network exposure, data storage, and account-level guardrails. Automated checks for coverage, manual review for context.
Core focusA clear, prioritised report written for the people who run the company as well as the people who run the infrastructure: what was found, why it matters, and the fix, in plain language rather than a raw scanner export.
Core focusHands-on help closing the findings: least-privilege IAM, logging and alerting, guardrails, and a follow-up review to confirm the fixes hold.
PlannedAn over-permissioned IAM and S3 setup built deliberately, then remediated step by step to least privilege. The same exercise an assessment's first recommendations usually lead to.
An investigation of S3 data events in CloudTrail using jq: reconstructing who accessed what, when, and from where, from nothing but the logs.
A lab writeup on how over-broad iam:PassRole grants let a low-privileged principal hand a high-privileged role to a service it controls, and the policy patterns that prevent it.
The page you're reading. Private S3 origin behind CloudFront with Origin Access Control, ACM certificate with DNS validation, Route 53 alias records, HTTP/3. The bucket itself returns Access Denied, by design.
Palo Alto VM deployed on a Proxmox node inside a segmented Meraki network (separate lab, AD, and management VLANs). Used for policy testing, packet-level debugging, and mirroring what I review professionally, at home, with root.
Ongoing
A staged build from first principles: packet capture and Bash tooling first, Suricata next, custom C utilities later. The point is to earn each layer of the detection stack rather than install it.
In progress