Show notes
Links:
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 Honeycomb. When production is running slow, it’s hard to know where problems originate. Is it your application code, users, or the underlying systems? I’ve got five bucks on DNS, personally. Why scroll through endless dashboards while dealing with alert floods, going from tool to tool to tool that you employ, guessing at which puzzle pieces matter. Context switching and tool sprawl are slowly killing both your team and your business. You should care more about one of those than the other; which one is up to you. Drop the separate pillars and enter a world of getting one unified understanding of the one thing driving your business: production. With Honeycomb, you guess less and know more. Try it for free at honeycomb.io/screaminginthecloud observability; it’s more than just hipster monitoring.
Corey: I must confess, I didn’t expect to see an unpatched AWS vulnerability being fodder for this podcast so early in the security lifespan here, but okay. Yes, yes, before I get letters, it’s not a vulnerability as AWS would define it, but it’s a pretty crappy default that charges customers money while giving them a false sense of security.
Past that, it’s going to be a short podcast this week, and that’s just fine by me because the point of it is, “The things you should know as someone who has to care about security.” On slow news weeks like last week that means I’m not here to give you pointless filler. Onward.
Now, AWS WAF is expensive and apparently, as configured by default, entirely optional for attackers. Only the first 8KB of a request are inspected by default. That means that any malicious payload that starts after the 8KB limit in a POST request will completely bypass AWS WAF unless you’ve explicitly added a rule to block any POST request greater than 8KB in size, which you almost assuredly have not done. Even their managed rule that addresses size limits only kicks in at 10KB. This is—as the kids say—less than ideal.
I had a tweet recently that talked about the horror of us-east-1 being globally unavailable for ages. Tim Bray took this and ran with the horrifying concept in a post he called, “Worst Case.” It’s really worth considering things like this when it comes to disaster and continuity planning. How resilient are our apps and infrastructure really when all is said and done? What dependencies do we take on third parties who in
turn rely on the same infrastructure that we’re trying to guard against failure from?
An unfortunate reality is that many cybersecurity researchers don’t have much in the way of legal protections; some folks are looking to change that through legislation. Here’s some good advice: if a security researcher reports a vulnerability to you or your company in good faith, perhaps not acting like a raging jackhole is an option that’s on the table. Bug bounties are hilariously small; they could make many times as much money by selling vulnerabilities to the highest bidder. Instead they’re reporting bugs to you in good faith. Word spreads. If you’re a hassle to deal with, other researchers won’t report things to you in the future. “Be a nice person,” is surprisingly undervalued when it comes to keeping yourself and your company out of trouble.
Now, only one interesting thing came out of the mouth of AWS horse last week in a security context, and it’s a Core Principles whitepaper: “Introducing Security at the Edge.” Setting aside entirely the fact that neither contributor to this has the job title of “EdgeLord,” I like it. Rather than focusing on specific services—although of course there’s some of that because vendors are going to vendor—it emphasizes how to think about the various considerations of edge locations that aren’t deep within hardened data centers. “How should I think about this problem,” is the kind of question that really deserves to be asked a lot more than it is.
and lastly, let’s end up with a tip of the week. If you have a multi-cloud anything, ensure that credentials are not shared between two cloud providers. I’m talking about passwords, keys, et cetera. This is a step beyond the standard password reuse warning of not using the same password for multiple accounts. Think it through; if one of your providers happens to be Azure, and they Azure up the security yet again, you really don’t want that to grant an attacker or other random Azure customers access to your AWS account as well, do you? I thought not.
Corey: This episode is sponsored in part by Liquibase. If you’re anything like me, you’ve screwed up the database part of a deployment so severely that you’ve been banned from ever touching anything that remotely sounds like SQL at least three different companies. We’ve mostly got code deployment solved for, but when it comes to databases, we basically rely on desperate hope, with a rollback plan of keeping our resumes up to date. It doesn’t have to be that way. Meet Liquibase. It’s both an open-source project and a commercial offering. Liquibase lets you track, modify, and automate database schema changes across almost any database, with guardrails that ensure you’ll still have a company left after you deploy the change. No matter where your database lives, Liquibase can help you solve your database deployment issues. Check them out today at liquibase.com. Offer does not apply to Route 53.
Corey: And that is what happened last week in AWS security. 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 with the latest in AWS security that actually matters. Pleas...
Our TOPPODCAST Picks 
Stay Connected
