Welcome to AMB: Security Edition

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 are empowered to 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. Take a look at this: what it does is it provides an enterprise approach to drive these things throughout your entire environment and manage them centrally. You can even 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 in the weeks ahead.

Corey: This is the inaugural episode of what is going to become a weekly feature, the AWS Morning Brief: Security Edition, where I do what I normally do: round up the news from Amazon’s cloud ecosystem, pick the things that I find interesting and make fun of them, only in the security world. This is going to be things that the rest of us need to care about, not the things that AWS feels a content need to put out there, but no one in the trenches tends to read. If you don’t work in security—by which I mean have the word security not in your job title—you’re in the right place. Neither do I, but I still have to care. So, what happened last week? Well, let’s dive in and we’ll see how this show shapes up.

We begin with the fact that there’s a contingent of anti-cloud folks out there who make the argument that [the cloud is somehow insecure, unsafe for your data, and not something you should be doing 00:08:26]. I generally have little patience for those folks, but when Azure’s Cosmos DB had a bug that allowed third parties unfettered and unlogged access to customer data, I’m hard-pressed to disagree with them. Events like this aren’t good for anyone. Companies don’t say things like, “Wow, as your security seems dicey, I’m going to use AWS or Google Cloud instead.” They say things instead, like, “Can’t trust the cloud. Hey, Dewey, fire up your Motel Six loyalty card because you’re about to spend the next nine months on the road building more company data centers for us.” Events like this weaken us all.

The second volume of the Lacework Cloud Threat Report has been released, and one of the things I really appreciate about it is that it talks about what’s actually going on in the wild, not invented theoretical threats that are designed to get you to shovel money into their product. I do not and will not condone the fear, uncertainty, and doubt—or FUD—marketing approach. There’s a reason that The Duckbill Group’s web pages are about how we help, not stuffed full of dire warnings about what might go wrong and blow the budget. If I can do it, so can the entire security industry. Nice job, Lacework, on that one.

There was a [great screed on Twitter 00:08:26] last week on the perils of using AWS read-only managed policies. The gist of the argument is that AWS is always updating these things, and permissions that aren’t included today may well be included tomorrow. Further, AWS does indeed have over-scoped permissions in managed policies. I gave a talk about one of them at re:Invent 2019. It’s a good thing to be aware of. While managed policies are definitely convenient, even AWS claims its security policies all squarely on the customer side of the shared responsibility model. Well, when they screw theirs up, they claim that anyway.

Luc van Donkersgoed recently found an enumeration vulnerability in AWS that allows users to determine valid account IDs and any IAM principles in it. AWS insists that this information is not sensitive and thus this doesn’t constitute a vulnerability. I can see that viewpoint, but if it’s true, why do AWS blog post screenshots always blur the account ID? Why isn’t there an API to explicitly get the account ID for a given resource?

The AWS documentation on account identifiers states that you shouldn’t provide credentials to third parties; it doesn’t say anything about account IDs. The messaging is, at a minimum, confusing. Until then, treat your AWS account ID as sensitive, I guess. There’s not a lot of reason for third parties to need it. I just wish AWS would stop being misunderstood for long periods of time on this particular point.

Announcer: Have you implemented industry best practices for securely accessing SSH servers, databases, or Kubernetes? It takes time and expertise to set up. Teleport makes it easy. It is an identity-aware access proxy that brings automatically expiring credentials for everything you need, including role-based access controls, access requests, and the audit log. It helps prevent data exfiltration and helps implement PCI and FedRAMP compliance. And best of all, Teleport is open-source and a pleasure to use. Download Teleport at goteleport.com. That’s goteleport.com.

Corey: [Imperva has a post 00:08:26] that, while it extolled the virtues of paying them money, it also alludes to the fact that a botnet attack that can hurl stupendous volumes of traffic is available for something like five bucks an hour. First, it turns out that revenge against things like the Managed NAT Gateway pricing page are way less money than I thought they were. Secondly, and more relevant to you folks than to me, is to have a plan [laugh] for what happens when some trash goblin decides that your company has displeased them and hurls a bunch of garbage traffic your way. Do a quick exploration of various options in this space—none of which I have recent enough experience with to endorse—and have a plan before you get a phone call from your boss, screaming that the website is down. Fix it, fix it, fix it, now.

If you work at Facebook, this entire section doesn’t apply to you since when your site is down, the internet is clearly better for it. There was a guide to High Availability WireGuard On AWS which was useful, and I’m not saying that from the perspective of explicitly running WireGuard per se, but more in terms of having single points of failure in things like the network that almost always stay up because the cloud is pretty good at things. Instead, this guide is primer, instead of focusing on WireGuard, how to think about your network risk exposure because I assure you there are security implications there.

Now, what did AWS have to say on their blog? This is that time of the podcast. How to improve visibility into AWS WAF with anomaly detection, and the honest answer is to pay a partner.

Look, I’m no happier about needing to drag third parties in to perform basic tasks on a potentially expensive AWS service than you are, but bolting together the monstrosity that AWS talks about in this post is not going to win you any friends. The biggest problem with a lot of these ‘build it from popsicle sticks’ solutions is that they’re complicated. Complexity is insecure just because you don’t understand the various nuances that go into all the different parts, and that leads to security lapses.

How US federal agencies can authenticate to AWS with multi-factor authentication. Because it’s federal, you undoubtedly have to use a government-grade MFA device. They no doubt weigh 50 pounds, cost $40,000 a pop, and take 20 minutes to boot up before they can be used.

Ransomware mitigation: Top 5 protections and recovery preparation actions. There’s good advice in this article. They are also cross-sells to other AWS services in this article. And this is my entire problem with the way these articles are structured. The actually good advice gets dismissed as a sales pitch.

And finally, Top 10 security best practices for securing data in Amazon S3. Some sales pitches, some good tips, and of course, encrypt your data in S3 without ever explaining why to do such a thing. Are people stealing discs out of AWS data centers? No? Okay, so that’s off the table is a threat model.

What precisely does encrypting data at rest buy you? That’s said, it’s not a hill worth dying on. Check the box, appease your auditor, and get on with doing the things that are important in your environment. And that’s the point of this podcast: because you’re not going to win those arguments, you’ll spend a lot of time on it. I’m here to make your job easier.

That is all the stuff that you need to be aware of that happened in AWS security last week. Well, that we know about. I’m sure something horrifying has happened that we will hear about in future weeks.

Corey: I have been your host, Corey Quinn, and if you remember nothing else, it’s that when you don’t get what you want, you get experience instead. Let my experience guide you with the things you need to know in the AWS security world, so you can get back to doing your actual job. Thank you for listening to the AWS Morning Brief: Security Edition.

Announcer: This has been a HumblePod production. Stay humble.