AWS Morning Brief

AWS Morning Brief for the week of September 13, 2021 with Corey Quinn.

Links:Enumeration vulnerability in AWS: https://twitter.com/donkersgood/status/1433148548565151748Lacework Cloud Threat Report: https://info.Lacework.com/2021-cloud-threat-report.htmlHigh Availability WireGuard On AWS: https://www.procustodibus.com/blog/2021/02/ha-wireguard-on-aws/How to improve visibility into AWS WAF with anomaly detection: https://aws.amazon.com/blogs/security/how-to-improve-visibility-into-aws-waf-with-anomaly-detection/How US federal agencies can authenticate to AWS with multi-factor authentication: https://aws.amazon.com/blogs/security/how-us-federal-agencies-can-authenticate-to-aws-with-multi-factor-authentication/Ransomware mitigation: Top 5 protections and recovery preparation actions: https://aws.amazon.com/blogs/security/ransomware-mitigation-top-5-protections-and-recovery-preparation-actions/Top 10 security best practices for securing data in Amazon S3: https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-data-in-amazon-s3/TranscriptCorey: 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 wo...

Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/saas-cost-tools-suckNever miss an episodeJoin the Last Week in AWS newsletterSubscribe wherever you get your podcastsHelp the showLeave a reviewShare your feedbackSubscribe wherever you get your podcastsWhat's Corey up to?Follow Corey on Twitter (@quinnypig)See our recent work at the Duckbill GroupApply to work with Corey and the Duckbill Group to help lower your AWS bill

AWS Morning Brief for the week of September 6, 2021 with Corey Quinn.

Want to give your ears a break and read this as an article? You’re looking for this link https://www.lastweekinaws.com/blog/hey-aws-youre-missing-forrest-for-the-trees/Never miss an episodeJoin the Last Week in AWS newsletterSubscribe wherever you get your podcastsHelp the showLeave a reviewShare your feedbackSubscribe wherever you get your podcastsWhat's Corey up to?Follow Corey on Twitter (@quinnypig)See our recent work at the Duckbill GroupApply to work with Corey and the Duckbill Group to help lower your AWS bill

AWS Morning Brief for the week of August 30, 2021 with Corey Quinn.

Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/How-to-Effectively-Interview-for-Work-with-a-Portfolio-SiteNever miss an episodeJoin the Last Week in AWS newsletterSubscribe wherever you get your podcastsHelp the showLeave a reviewShare your feedbackSubscribe wherever you get your podcastsWhat's Corey up to?Follow Corey on Twitter (@quinnypig)See our recent work at the Duckbill GroupApply to work with Corey and the Duckbill Group to help lower your AWS bill

AWS Morning Brief for the week of August 23, 2021 with Corey Quinn.

TranscriptCorey: This episode is sponsored in part by our friends at ChaosSearch. You could run Elasticsearch or Elastic Cloud—or OpenSearch as they’re calling it now—or a self-hosted ELK stack. But why? ChaosSearch gives you the same API you’ve come to know and tolerate, along with unlimited data retention and no data movement. Just throw your data into S3 and proceed from there as you would expect. This is great for IT operations folks, for app performance monitoring, cybersecurity. If you’re using Elasticsearch, consider not running Elasticsearch. They’re also available now in the AWS marketplace if you’d prefer not to go direct and have half of whatever you pay them count towards your EDB commitment. Discover what companies like Klarna, Equifax, Armor Security, and Blackboard already have. To learn more, visit chaossearch.io and tell them I sent you just so you can see them facepalm, yet again.Corey: You know what really grinds my gears? Well, lots of things, but in this case, let’s talk about multi-cloud. Not my typical rant about multi-cloud not ever being a good best practice—because it’s not—but rather how companies talk about multi-cloud. HashiCorp just did a whole survey on how multi-cloud is the future, and at no point during that entire process did they define the term. So, you wind up with a whole bunch of people responding, each one talking about different things.Are we talking about multiple clouds and we have a workload that flows between them? Are we talking about, “Well, we have some workloads on one cloud provider and a different set of workloads on other cloud providers?” Did they break it down as far as SaaS companies go of, “Yeah, we have an application and we’d like to run it all on one cloud, but it’s data-heavy and we have to put it where our customers are, so of course we’re on multiple cloud providers.” And then you wind up with the stories that other companies talk about, where you have a bunch of folks where their sole contribution to the ecosystem is, “Ah, you get a single pane of glass between different cloud providers.”You know who wants that? No one. The only people who really care about those things are the folks who used to sell those items and realized that if this dries up and blows away, they have nothing left to sell you. There’s also a lot of cloud providers who are deep into the whole multi-cloud is the way and the light and the future because they know if you go all-in on a single cloud provider, it will certainly not be them. And then you have the folks who say, “Go in on one cloud provider and don’t worry about it. It’ll be fine. If you need to migrate down the road, you can do that.”And I believe that that’s generally the way that you should approach things, but it gets really annoying and condescending when AWS tells that story because from their perspective, yeah, just go all-in and use Dynamo as your data store for everything even though there’s really no equivalent on other cloud providers. Or, “Yeah, go ahead and just tie all of your data warehousing to some of the more intricate and non-replicable parts of S3.” And so on and so forth. And it just feels like they’re pushing a lock-in narrative in many respects. I like having the idea of a strategic Exodus, where if I have to move a thing down the road, I don’t have to reinvent the data model.And a classic example of what I would avoid in that case is something like Google Spanner—or Google Cloud Spanner, or whatever the one they sell us is—because yeah, it’s great, and it’s awesome. And you wind up with, effectively, what looks like an ACID-compliant SQL database that spans globally. But there’s nothing else quite like that, so if I have to migrate off, it’s not just a matter of changing APIs, I have to re-architect my entire application to be aware of the fact that I can’t really have that architecture anymore, just from a data flow perspective. And looking at this across the board, I find that this is also a bit esoteric because generally speaking, the people who are talking the most about multi-cloud and wanting to avoid lock-in, are treating the cloud like it’s fundamentally an extension of their own crappy data center where they run a bunch of VMs and that’s it.They say they want to be multi-cloud, but they’re only ever building for one cloud, and everything that they’re building on top of it is just reinventing baseline primitives. “Oh, we don’t trust their load balancers. We’re going to run our own with Nginx or HAProxy.” Great. While you’re doing that, your competitors are getting further ahead.You’re not even really in the cloud: you basically did the lift part of it, declined to shift, declared victory, and really the only problem you solve for is you suck at dealing with hard drive failure, so you used to deal with outages in your data center and now your cloud provider handles it for you at a premium that’s eye-wateringly high.Corey: I really love installing, upgrading, and fixing security agents in my cloud estate. Why do I say that? Because I sell things for a company that deploys an agent. There’s no other reason. Because let’s face it; agents can be a real headache. Well, Orca Security now gives you a single tool to detect basically every risk in your cloud environment that’s as easy to install and maintain as a smartphone app. It is agentless—or my intro would have gotten me in trouble here—but it can still see deep into your AWS workloads while guaranteeing 100% coverage. With Orca Security there are no overlooked assets, no DevOps headaches—and believe me, you will hear from those people if you cause them headaches—and no performance hits on live environment. Connect your first cloud account in minutes and see for yourself at orca dot security. That’s orca—as in whale—dot security as in that thing your company claims to care about but doesn’t until right after it really should have.Corey: Look, I don’t mean to be sitting here saying that this is how every company operates because it’s not. But we see a lot of multi-cloud narrative out there, and what’s most obnoxious about all of it is that it’s coming from companies that are strong enough to stand on their own. And by pushing this narrative, it’s increasingly getting to a point where if you’re not in a multi-cloud environment, you start to think, “Maybe I’m doing something wrong.” You’re not. There’s no value to this.Remember, you have a business that you’re trying to run, in theory. Or for those of us who are still learning things, yeah, we want to learn a cloud provider before we learn all the cloud providers, let’s not kid ourselves. Pick one, go all-in on for the time being, and don’t worry about what the rest of the industry is doing. We’re not trying to collect them all. There is no Gartner Magic Quadrant for Pokemons and I don’t think the cloud providers should be one of them.I know I’ve talked about this stuff before, but people keep making the same fundamental errors and it’s time for me to rant on it just a smidgen more than I have already.Thank you for listening, as always to Fridays From the Field on the AWS Morning Brief. And as always, I’m Chief Cloud Economist Corey Quinn, imploring you to continue to make good choices.Announcer: This has been a HumblePod production. Stay humble.

Want to give your ears a break and read this as an article? You’re looking for this link. https://www.lastweekinaws.com/blog/the-next-million-cloud-customersNever miss an episodeJoin the Last Week in AWS newsletterSubscribe wherever you get your podcastsHelp the showLeave a reviewShare your feedbackSubscribe wherever you get your podcastsWhat's Corey up to?Follow Corey on Twitter (@quinnypig)See our recent work at the Duckbill GroupApply to work with Corey and the Duckbill Group to help lower your AWS bill