HowTo Guides

Note: This post has been revised to include the new capabilities released by AWS prior to re:Invent 2024.
You can also check out the re:Invent presentation we did with Securosis: “Security invariants: From enterprise chaos to cloud order” slides - video

I’ve spoken a lot about Security Invariants, but all of them have been implemented using Organizational Policies. That’s great, but organizational policies don’t apply to the Organizational Management Account (aka “payer”). So how does one implement invariants in a payer account?

AWS would tell you that you shouldn’t be giving anyone access to the payer account, so the need for invariants should be minimal. However, that doesn’t reflect the reality that…

You are multi-cloud whether you like it or not.

Most organizations have a preferred cloud provider. This is the provider where they have the most engineering expertise, have negotiated the best discounts, and have built the paved road experience.

tl;dr - here is a link to the scripts

What Ransomware in AWS looks like

In a typical ransomware attack, a threat actor will attempt to encrypt files on critical machines belonging to the victim. In exchange for a cryptocurrency payment, the threat actor will provide the decryption key and software to the victim, who then has to go through the arduous process of restoring their machines. The encrypted data is typically lost forever if the victim refuses to pay the ransom.

This is a revised version of the original post Leveraging AWS SSO (aka Identity Center) with Google Workspaces based on the new announcement AWS IAM Identity Center now supports automated user provisioning from Google Workspace The original post is still valid, and in someways may be better, but this version has it’s own advantages.

Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an…

Setting up AWS IAM Identity Center (successor to AWS Single Sign-On), hereafter called AWS SSO (because I have to pay AWS for egress on this site), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.

Companies using Google Workspaces for email and collaboration can also leverage their Google accounts to access AWS via AWS…

Setting up AWS IAM Identity Center (successor to AWS Single Sign-On) henceforth called AWS SSO (because AWS charges for egress), is an excellent service to help you get rid of IAM users and enforce identity best practices around second-factor authentication, on and off-boarding employees, and assigning the right level of access depending on job function.

This past weekend I spoke at BSides Nashville on offensive operations in AWS: Get outta my host and into my cloud. While I was finishing the talk, Nick Jones published a blog post of his own: On AWS Penetration Testing.

At BSides Atlanta today I gave a talk on how to handle an incident in AWS. The talk and this post is intended to help those already familiar with the principles of Incident Response to understand what to do when the incident involves the AWS Control Plane. You can find the Slides here.