Links:

• “I Trust AWS IAM to Secure my Applications. I Don’t Trust the IAM Docs to Tell Me How”: https://ben11kehoe.medium.com/i-trust-aws-iam-to-secure-my-applications-i-dont-trust-the-iam-docs-to-tell-me-how-f0ec4c119e79
• “Introduction to Zero Trust on AWS ECS Fargate”: https://omerxx.com/identity-aware-proxy-ecs/
• Threat Stack Aquired by F5: https://techcrunch.com/2021/09/20/f5-acquires-cloud-security-startup-threat-stack-for-68-million/
• AWS removed from CVE-2021-38112: https://rhinosecuritylabs.com/aws/cve-2021-38112-aws-workspaces-rce/
• Ransomware that encrypts the contents of S3 buckets: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/

Transcript

Corey: This is the AWS Morning Brief: Security Edition. AWS is fond of saying security is job zero. That means it’s nobody in particular’s job, which means it falls to the rest of us. Just the news you need to know, none of the fluff.

Corey: This episode is sponsored in part by Thinkst Canary. This might take a little bit to explain, so bear with me. I linked against an early version of their tool, canarytokens.org, in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, or anything else like that that you can generate in various parts of your environment, wherever you want them to live. It gives you fake AWS API credentials, for example, and the only thing that these things do is alert you whenever someone attempts to use them. It’s an awesome approach to detecting breaches. I’ve used something similar for years myself before I found them. Check them out. But wait, there’s more because they also have an enterprise option that you should be very much aware of: canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files that it presents on a fake file store, you get instant alerts. It’s awesome. If you don’t do something like this, instead you’re likely to find out that you’ve gotten breached the very hard way. So, check it out. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I am so glad I found them. I love it.” Again, those URLs are canarytokens.org and canary.tools. And the first one is free because of course it is. The second one is enterprise-y. You’ll know which one of those you fall into. Take a look. I’m a big fan. More to come from Thinkst Canary weeks ahead.

Corey: This podcast seems to be going well. The Meanwhile in Security podcast has been fully rolled over and people are chiming in with kind things, which kind of makes me wonder, is this really a security podcast? Because normally people in that industry are mean.

Let’s dive into it. What happened last week in security? touching AWS, Ben Kehoe is on a security roll lately. His title of the article in full reads,  “I Trust AWS IAM to Secure My Applications. I Don’t Trust the IAM Docs to Tell Me How”, and I think he’s put his finger on the pulse of something that’s really bothered me for a long time. IAM feels arcane and confusing. The official doc just made that worse For me. My default is assuming that the problem is entirely with me, But that’s not true at all. I suspect I’m very far from the only person out there who feels this way.

An “Introduction to Zero Trust on AWS ECS Fargate” is well-timed. Originally when Fargate launched, the concern was zero trust of AWS ECS Fargate, But we’re fortunately past that now. The article is lengthy and isn’t super clear as to the outcome that it’s driving for and also forgets that SSO was for humans and not computers, But it’s well documented and it offers plenty of code to implement such a thing yourself. It’s time to move beyond static IAM roles for everything.

Threat Stack has been a staple of the Boston IT scene for years; they were apparently acquired by F5 for less money than they’d raised, which seems unfortunate. I’m eagerly awaiting to see how they find F5 for culture. I bet it’s refreshing.

and jealous of Azure as attention in the past few episodes of this podcast, VMware wishes to participate by including a critical severity flaw that enables ransomware in vCenter or vSphere. I can’t find anything that indicates whether or not VMware on AWS is affected, So those of you running that thing you should probably validate that everything’s patched. reach out to your account manager, which if you’re running something like that, you should be in close contact with anyway.

Corey: Now from AWS themselves, what do they have to say? not much last week on the security front, their blog was suspiciously silent. scuttlebutt on Twitter has it that they’re attempting to get themselves removed from an exploit, a CVE-2021-38112, which is a remote code execution vulnerability. If you have the Amazon workspaces client installed, update it because a malicious URL could cause code to be executed in the client’s machine. It’s been patched, but I think AWS likes not having public pointers to pass security lapses lurking around. I don’t blame them, I mean, who wants that? The reason I bring it up is Not to shame them for it, but to highlight that all systems have faults in them. AWS is not immune to security problems, nor is any provider. It’s important, to my mind, to laud companies for rapid remediation and disclosure and to try not to shame them for having bugs in the first place. I don’t always succeed at it, But I do try. But heaven help you if you try to blame an intern for a security failure.

And instead of talking about a tool, Let’s do a tip of the week. Ransomware is in the news a lot, But so far, all that I’ve seen with regard to ransomware that encrypts the contents of S3 buckets is theoretical proofs—or proves—of concept. That said, for the data you can’t afford to lose, you’ve got a few options that stack together neatly. The approach distills down to some combination of enabling MFA delete, enabling versioning on the bucket, and setting up replication rules to environments that are controlled by different credential sets entirely. This will of course become both maintenance-intensive and extremely expensive for some workload...