Podcasts about aws security

The DNS resolution path by which the world's internet content consumers locate the world's internet content producers has been under continuous attack since the earliest days of Internet commercialization and privatization. Much work has recently and is currently being invested to protect this vital source of Personally Identifiable Information -- but by whom, and why, and how? Let's discuss. About the speaker: Paul Vixie serves AWS Security as Deputy CISO, VP & Distinguished Engineer after a 29-year career as the founder and CEO of five startup companies covering the fields of DNS, anti-spam, Internet exchange, Internet carriage and hosting, and Internet security. Vixie earned his Ph.D. in Computer Science from Keio University in 2011 and was inducted into the Internet Hall of Fame in 2014. He has authored or co-authored several Internet RFC documents and open source software projects including Cron and BIND. https://en.wikipedia.org/wiki/Paul_Vixie

Learn actionable strategies for handling AWS security breaches from detection through prevention. AWS security experts share real incident response experiences, containment tactics, and practical tips for securing your AWS infrastructure.

Podcast del programa Imagen Empresarial transmitido originalmente el 31 de octubre de 2024. Conduce Rodrigo Pacheco. Los entrevistados de hoy: Entrevista: Dilip Kumar, vicepresidente de Amazon Q Business Tema: Amazon Q e IA Entrevista: Mark Ryland, director de AWS Security. Tema: Seguridad e IA

Corey Quinn and Daniel Grzelak take you on a journey through the wild and wonderful world of Amazon S3 in this episode. They explore the fun quirks and hidden surprises of S3, like the mysterious "Schrodinger's Objects" from incomplete uploads and the head-scratching differences between S3 bucket commands and the S3 API. Daniel and Corey break down common misunderstandings about S3 encryption and IAM policies, sharing stories of misconfigurations and security pitfalls.Show Highlights: (00:00) - Introduction(03:49) - Schrodinger's Objects(05:23) - S3 Permissions and Security(06:44) - Incomplete Multipart Uploads Causing Unexpected Billing Issues(10:28) - Historical Oddities and Unexpected Behaviors of S3(12:00) - Encryption Misconceptions(15:17) - Durability and Reliability of S3(17:49) - AWS Security and Trust(21:01) - Practical Tips for S3 Users(26:10) - Compliance Locks and Data Management(29:13) - Closing ThoughtsAbout Daniel:Daniel Grzelak is a 20-year cybersecurity industry veteran, currently working as Chief Innovation Officer at Plerion. He is no longer the CISO at Linktree nor the Head of Security at Atlassian, but he tries to stay relevant by hacking AWS and Cloud in general.Links Referenced:Personal Website: https://dagrz.com/LinkedIn: https://www.linkedin.com/in/danielgrzelak/Things you wish you didn't need to know about S3: https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/S3 Bucket Encryption Doesn't Work The Way You Think It Works: https://blog.plerion.com/s3-bucket-encryption-doesnt-work-the-way-you-think-it-works/*SponsorPanoptica: https://www.panoptica.app/

In a recent episode of the Detection at Scale podcast recorded at the RSA conference, Jack chats with Corey Quinn, Chief Cloud Economist at The Duckbill Group, an AWS cost-management agency. They talked about the intersection of security and billing in the context of AWS environments, highlighting the significance of observability through billing data to enhance security measures.  Corey also discussed key offenders in AWS services for security and highlighted the challenges companies face in determining optimal investments in security services. Throughout our discussion, Corey offers valuable takeaways on navigating the evolving landscape of AWS security practices and optimizing billing strategies for enhanced cloud security. Topics discussed: The importance of observability via billing data to bolster AWS security measures and optimize investments in security services. How to identify key security offenders in AWS services to enhance cloud security practices and mitigate potential breaches. The challenges in determining optimal security investments within AWS environments. Detecting potential breaches through AWS billing insights and the significance of understanding billing intricacies for security enhancements. The impact of billing data on identifying security vulnerabilities and navigating the AWS security landscape with enhanced strategies. The role of services like Route 53 in bolstering security measures and considerations for AWS spending on security services.  Resources Mentioned:  Corey Quinn on LinkedIn The Duckbill Group website 

Hosts: Maura Carabello and Leah Murray Troy Rydman, Sr. Practice Manager for AWS Security, Risk, Compliance for Strategic Accounts, calls into the program to talk about the Federal Communication Commission’s recent decision to restore net neutrality. He clarifies what the changes will look like, and how they compare to the last time net neutrality was in place.

Hosts: Leah Murray and Maura Carabello Recapping the biggest moments from the weekend’s state conventions KSL at Night hosts Leah Murray and Maura Carabello kick off the week talking about the biggest political stories from the weekend – all centered around the political state conventions. Bridger Beal-Cvetko, KSL.com reporter, joins the program to recap the biggest races and challenges the convention faced. Controversy surrounds the behavior displayed at the conventions Besides the races, the biggest thing coming out of the GOP convention was decorum, or the lack thereof. Former Speaker of the Utah House, Greg Hughes, joins the show to defend conventions, while also admitting that there were several things that disappointed and concerned him with last weekend’s conventions. He explains his more nuanced stance. State political conventions – how do they adapt to the changing times? Continuing the conversation on conventions, we take a look at the opposing views. Holly Richardson, Editor of Utah Policy, discusses her concerns about future conventions due to “disgraceful” behavior by GOP delegates. The hosts discuss if the convention process is even applicable nowadays with the signature-gathering primary option. The FCC restores net neutrality – what does it mean? Troy Rydman, Sr. Practice Manager for AWS Security, Risk, Compliance for Strategic Accounts, calls into the program to talk about the Federal Communication Commission’s recent decision to restore net neutrality. He clarifies what the changes will look like, and how they compare to the last time net neutrality was in place. Democratic Lt. Gov. nominee Rebekah Cummings discuss her and Brian King’s campaign Just today, Democratic Gubernatorial candidate Brian King chose his running mate: Lieutenant Governor-hopeful Rebekah Cummings. She joins KSL at Night – in her first media interview – to explain her stances. She shares how book bans brought her to the political arena, and what she wants to do because of it. Historic deal gives Colorado River tribes access to water rights An historic deal gives water rights to six tribes in the Upper Colorado River Basin. Gene Shawcroft, Colorado River Commissioner for Utah, explains the recent developments that will impact how water will be used along the river. He also talks about how Lake Powell is looking, especially with this year’s snowpack. Salt Lake City revamps its transportation plans Regardless of where you live in Utah, you’re bound to visit Salt Lake City at some point. Whether for a sports game, General Conference, or the potential 2034 Olympics, the world comes to Salt Lake City pretty often. That results in traffic issues, so the city’s looking at revamping its transportation plans. Joe Taylor, Transportation Planner for SLC’s Transportation Division, joins the show. Retiring at 62: Why the trend for earlier retirement is growing in popularity More and more people try to retire earlier than 65, but is it actually feasible? If you didn’t get started on saving for retirement in your 20s, is it too late? Should you prioritize retirement or your kids’ college? Kristen Cooper, President of Axios Capital, breaks it down on KSL at Night, giving good resources for those who might not be the most financially-savvy.    

This year at AWS re:Invent we are going to interview conference attendees, AWS Heroes, and AWS employees. We're asking them what they are excited about at re:Invent and what they are working on! Chris Farris is a Cloud Security Consultant at Fooli Media. Join us to hear the answer to these questions from some of the top minds in the industry!!! Resources: https://www.linkedin.com/in/jcfarris/ https://twitter.com/jcfarris Intro music attribution: Artist - MaxKoMusic

Iranian hacktivists claim an attack on a Pennsylvania water utility. North Korea's increased attention to supply-chains. Rhysida's action against British and Chinese targets. Sandworm activity puts European power utilities on alert. Neanderthals and the Telekopye bot. Mirai-based botnet activity. Our guest is Chris Betz, the new CISO of AWS Security, with insights on the upcoming AWS re:Invent conference. And just how easy is it to track the comings and goings at Mar-a-Lago? CyberWire Guest Our guest today is Chris Betz, the new CISO of AWS Security giving us some insight into what to expect at the AWS re:Invent conference. You can connect with Chris on LinkedIn and find out more about AWS re:Invent on the event website. For links to all of today's stories check out our CyberWire daily news briefing: https://thecyberwire.com/newsletters/daily-briefing/12/224 Selected Reading Municipal Water Authority of Aliquippa hacked by Iranian-backed cyber group (KDKA News) Iranian-linked cyber army had partial control of Aliquippa water system (Beaver Countian) Cyber Av3ngers Claim Israeli MEKOROT National Water Company Hack (Cyberwarzone) A hack in hand is worth two in the bush (Securelist by Kaspersky) Diamond Sleet supply chain compromise distributes a modified CyberLink installer (Microsoft) UK and Republic of Korea issue warning about DPRK state-linked cyber actors attacking software supply chains (National Cyber Security Centre) Rhysida (SentinelOne) Rhysida, the new ransomware gang behind British Library cyber-attack (The Guardian) RHYSIDA RANSOMWARE GANG CLAIMED CHINA ENERGY HACK (Security Affairs) #StopRansomware: Rhysida Ransomware (CISA) Russia continuing cyberthreats against NATO countries (Defence Industry Europe) Europe's grid is under a cyberattack deluge, industry warns (Politico) Telekopye: Chamber of Neanderthals' secrets (ESET) InfectedSlurs Botnet Spreads Mirai via Zero-Days (Akamai) We Spied on Trump's ‘Southern White House' From Our Couches (Rolling Stone)

Toni de la Fuente is Founder of ProwlerPro, the cloud security platform built on top of Prowler, the open source security tool that helps companies implement security best practices including assessments, audits, and scanning. In this episode, we dig into the importance of good documentation, the industry events that helped Prowler gain momentum, shifting focus from AWS only to all major cloud platforms, the need for patience with open source & more!

If you enjoyed this content, your learning journey has just begun! Dive deeper into the fascinating world of technology with these hand-picked resources:

If you enjoyed this content, your learning journey has just begun! Dive deeper into the fascinating world of technology with these hand-picked resources:

If you enjoyed this video, your learning journey has just begun! Dive deeper into the fascinating world of technology with these hand-picked resources:

If you enjoyed this video, your learning journey has just begun! Dive deeper into the fascinating world of technology with these hand-picked resources:

In this episode, Kostas and I discuss how to get started with AWS security, what beginners and practitioners should focus on, and what's currently hot and in-demand job wise. Kostas is the co-author of our course on Cybr: Introduction to AWS Security.

In this conversation we are discussing security assessment for the AWScloud . I am joined by Artur Schneider, Senior Cloud Consultant at T-Systems

Welcome to the newest episode of The Cloud Pod podcast - where the forecast is always cloudy! Ryan, Jonathan, and Matt are your hosts this week as we discuss all things cloud, including updates to Terraform, pricing updates in GCP SCC, AWS Blueprint, DMS Serverless, and Snowball - as well as all the discussion on Microsoft quantum safe computing and ethical AI you could possibly want!  A big thanks to this week's sponsor: Foghorn Consulting, provides top-notch cloud and DevOps engineers to the world's most innovative companies. Initiatives stalled because you have trouble hiring?  Foghorn can be burning down your DevOps and Cloud backlogs as soon as next week.

Lex Neva, Staff Site Reliability Engineer at Honeycomb and Curator of SRE Weekly, joins Corey on Screaming in the Cloud to discuss reliability and the life of a newsletter curator. Lex shares some interesting insights on how he keeps his hobbies and side projects separate, as well as the intrusion that open-source projects can have on your time. Lex and Corey also discuss the phenomenon of newsletter curators being much more demanding of themselves than their audience typically is. Lex also shares his views on how far reliability has come, as well as how far we have to go, and the critical implications reliability has on our day-to-day lives. About LexLex Neva is interested in all things related to running large, massively multiuser online services.  He has years of SRE,  Systems Engineering, tinkering, and troubleshooting experience and perhaps loves incident response more than he ought to.  He's previously worked for Linden Lab, DeviantArt, Heroku, and Fastly, and currently works as an SRE at Honeycomb while also curating the SRE Weekly newsletter on the side.Lex lives in Massachusetts with his family including 3 adorable children, 3 ridiculous cats, and assorted other awesome humans and animals.  In his copious spare time he likes to garden, play tournament poker, tinker with machine embroidery, and mess around with Arduinos.Links Referenced: SRE Weekly: https://sreweekly.com/ Honeycomb: https://www.honeycomb.io/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Chronosphere. Tired of observability costs going up every year without getting additional value? Or being locked into a vendor due to proprietary data collection, querying, and visualization? Modern-day, containerized environments require a new kind of observability technology that accounts for the massive increase in scale and attendant cost of data. With Chronosphere, choose where and how your data is routed and stored, query it easily, and get better context and control. 100% open-source compatibility means that no matter what your setup is, they can help. Learn how Chronosphere provides complete and real-time insight into ECS, EKS, and your microservices, wherever they may be at snark.cloud/chronosphere that's snark.cloud/chronosphere.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Once upon a time, I decided to start writing an email newsletter, and well, many things happened afterwards, some of them quite quickly. But before that, I was reading a number of email newsletters in the space. One that I'd been reading for a year at the time, was called SRE Weekly. It still comes out. I still wind up reading it most weeks.And it's written by Lex Neva, who is not only my guest today but also a staff site reliability engineer at Honeycomb. Lex, it is so good to finally talk to you, other than reading emails that we send to the entire world that pass each other like ships in the night.Lex: Yeah. I feel like we should have had some kind of meeting before now. But yeah, it's really good to [laugh] finally meet you.Corey: It was one of the inspirations that I had. And to be clear, when I signed up for your newsletter originally—I was there for issue 15, which is many, many years ago—I was also running a small-scale SRE team at the time. It was, I found as useful as a part of doing my job and keeping abreast of what was going on in the ecosystem. And I found myself, once I went independent, wishing that your newsletter and a few others had a whole bunch more AWS content. Well, why doesn't it?And the answer is because you are, you know, a reasonable person who understands that mental health is important and boundaries exist for a reason. No one sensible is going to care that much about one cloud provider all the time [sigh]. If only we were all that wise.Lex: Right? Well, [laugh] well, first of all, I love your newsletter, and also the content that you write that—I mean, I would be nowhere without content to link to. And I'm glad you took on the AWS thing because, much like how I haven't written Security Weekly, I also didn't write any kind of AWS Weekly because there's just too much. So, thanks for falling on that sword.Corey: I fell on another one about two years ago and started the Thursdays, which are Last Week in AWS Security. But I took a different bent on it because there are a whole bunch of security newsletters that litter the landscape and most of them are very good—except for the ones that seem to be entirely too vendor-captured—but the problem is, is that they lacked both a significant cloud focus, as well as an understanding that there's a universe of people out here who care about security—or at least should—but don't have the word security baked into their job title. So, it was very insular, using acronyms they assume that everyone knows, or it's totally vendor-captured and it's trying to the whole fear, uncertainty, and doubt thing, “And that's why you should buy this widget.” “Will it solve problems?” “Well, it'll solve our revenue problems at our company that sells the widgets, but other than that, not really.” And it just became such an almost incestuous ecosystem. I wanted something different.Lex: Yeah. And the snark is also very useful [laugh] in order to show us that you're not in their pocket. So yeah, nice work.Corey: Well, I'll let you in on a secret, now that we are—what, I'm somewhat like 300 and change issues in, which means I've been doing this for far too long, the snark is a byproduct of what I needed to do to write it myself. Because let's face it, this stuff is incredibly boring. I needed to keep myself interested as I started down that path. And how can I continually keep it fresh and funny and interesting, but not go too far? That's a fun game, whereas copying and pasting some announcement was never fun.Lex: Yeah, that's not—I hear you on trying to make it interesting.Corey: One regret that I've had, and I'm curious if you've ever encountered this yourself because most people don't get to see any of this. They see the finished product that lands in their inbox every Monday, and—in my case, Monday; I forget the exact day that yours comes out. I collect them and read through them for them all at once—but I find that I have often had caused a look back and regret the implicit commitment in Last Week in AWS as a name because it would be nice to skip a week here and there, just because either I don't particularly feel like it, or wow, there was not a lot of news worth talking about that came out last week. But it feels like I've forced myself onto a very particular treadmill schedule.Lex: Yeah. Yeah, it comes with, like, calling it SRE Weekly. I just followed suit for some of the other weeklies. But yeah, that can be hard. And I do give myself permission to take a week off here and there, but you know, I'll let you in on a secret.What I do is I try to target eight to ten articles a week. And if I have more than that, I save some of them. And then when it comes time to put out an issue, I'll go look at what's in that ready queue and swap some of those in and swap some of the current ones out just so I keep things fresh. And then if I need a week off, I'll just fill it from that queue, you know, if it's got enough in it. So, that lets me take vacations and whatnot. Without that, I think I would have had a lot harder of a time sticking with this, or there just would have been more gaps. So yeah.Corey: You're fortunate in that you have what appears to be a single category of content when you construct your newsletter, whereas I have three that are distinct: AWS releases and announcements and news and things to make fun of for the past week; the things from the larger community folks who do not work there, but are talking about interesting approaches or news that is germane; and then ideally a tip or a tool of the week. And I found, at least lately, that I've been able to build out the tools portion of it significantly far in advance. Because a tool that makes working with AWS easier this week is probably still going to be fairly helpful a month from now.Lex: Yeah, that's fair. Definitely.Corey: But putting some of the news out late has been something of a challenge. I've also learned—by getting it wrong—that I'm holding myself to a tighter expectation of turnaround time than any part of the audience is. The Thursday news is all written the week before, almost a full week beforehand and no one complains about that. I have put out the newsletter a couple of times an hour or two after its usual 7:30 pacific time slot that it goes out in; not a single person has complained. In one case, I moved it by a day to accommodate an announcement but didn't explain why; not a single person emailed in. So, okay. That's good to know.Lex: Yeah, I've definitely gotten to, like, Monday morning, like, a couple of times. Not much, not many times, but a couple of times, I've gotten a Monday morning be like, “Oh, hey. I didn't do that thing yesterday.” And then I just release it in the morning. And I've never had a complaint.I've cancelled last minute because life interfered. The most I've ever had was somebody emailing me and be like, you know, “Hope you feel better soon,” like when I had Covid, and stuff like that. So, [laugh] yeah, sometimes maybe we do hold ourselves to a little bit of a higher standard than is necessary. I mean, there was a point where I got—I had major eye surgery and I had to take a month off of everything and took a month off the newsletter. And yeah, I didn't lose any subscribers. I didn't have any complaints. So people, I think, appreciate it when it's there. And, you know, if it's not there, just wait till it comes out.Corey: I think that there is an additional challenge that I started feeling as soon as I started picking up sponsors for it because it's well, but at this point, I have a contractual obligation to put things out. And again, life happens, but you also don't want to have to reach out on apology tours every third week or whatnot. And I think that's in part due to the fact that I have multiple sponsors per issue and that becomes a bit of a juggling dance logistically on this end.Lex: Yeah. When I started, I really didn't think I necessarily wanted to have sponsors because, you know, it's like, I have a job. This is just for fun. It got to the point where it's like, you know, I'll probably stop this if there's not some kind of monetary advantage [laugh]. And having a sponsor has been really helpful.But I have been really careful. Like, I have always had only a single sponsor because I don't want that many people to apologize to. And that meant I took in maybe less money than I then I could have, but that's okay. And I also was very clear, you know, even from the start having a contract that I may miss a week without notice. And yes, they're paying in advance, but it's not for a specific range of time, it's for a specific number of issues, whenever those come out. That definitely helped to reduce the stress a little bit. And I think without that, you know, having that much over my head would make it hard to do this, you know? It has to stay fun, right?Corey: That's part of the things that kept me from, honestly, getting into tech for the first part of my 20s. It was the fear that I would be taking a hobby, something that I love, and turning it into something that I hated.Lex: Yeah, there is that.Corey: It's almost 20 years now and I'm still wondering whether I actually succeeded or not in avoiding hating this.Lex: Well, okay. But I mean, are you, you know, are you depressed [unintelligible 00:09:16] so there's this other thing, there's this thing that people like to say, which is like, “You should only do a job that you really love.” And I used to think that. And I don't actually think that anymore. I think that it is important to have a job that you can do and not hate day-to-day, but there's no shame in not being passionate about your work and I don't think that we should require passion from anyone when we're hiring. And I think to do so is even, like, privilege. So, you know, I think that it's totally fine to just do something because it pays the bills.Corey: Oh, absolutely. I find it annoying as hell when I'm talking to folks who are looking to hire for roles and, “Well, include a link to your GitHub profile,” is a mandatory field. It's, well, great. What about people who work in places where they're not working on open-source projects as a result, and they can't really disclose what they're doing? And the expectation that oh, well outside of work, you should be doing public stuff, too.It's, I used to do a lot of public open-source style work on GitHub, but I got yelled at all the time for random, unrelated reasons and it's, I don't want to put something out there that I have to support and people start to ask me questions about. It feels like impromptu unasked-for code review. No, thanks. So, my GitHub profile looks fairly barren.Lex: You mean like yelling at you, like, “Oh, you're not contributing enough.” Or, you know, “We need this free thing you're doing, like, immediately,” or that kind of thing?Corey: Worse than that. The worst example I've ever had for this was when I was giving a talk called “Terrible Ideas in Git,” and because I wanted to give some hilariously contrived demos that took a fair bit of work to set up, I got them ready to go inside of a Docker container because I didn't trust that my laptop would always work, I'm might have to borrow someone else's, I pushed that image called “Terrible Ideas” up to Docker Hub. And I wound up with people asking questions about it. Like, “Is this vulnerable to ShellCheck.” And it's, “You do realize that this is intentionally designed to be awful? It is only for giving a very specific version of a very specific talk. It's in public, just because I didn't bother to make it private. What are you doing? Please tell me you're not running this in production at a bank?” “No comment.” Right. I don't want that responsibility of people yelling at me for things I didn't do on purpose. I want to get yelled at for the things I did intentionally.Lex: Exactly. It's funny that sometimes people expect more out of you when you're giving them something free versus when they're paying you for it. It's an interesting quirk of psychology that I'm sure that professionals could tell me all about. Maybe there's been research on it, I don't know. But yeah, that can be difficult.Corey: Oh, absolutely. I used to work at a web hosting company and the customer spending thousands a month with us were uniformly great. But there was always the lowest tier customer of the cheapest thing that we offered that seemed to expect that that entitle them to 80 hours a month of support from engineering problems and whatnot. And it was not profitable to service some of those folks. I've also found that there's a real transitive barrier that begins as soon as you find a way to charge someone a dollar for something.There's a bit of a litmus test of can you transfer a dollar from your bank account to mine? And suddenly, the entire tenor of the conversations with people who have crossed that boundary change. I have toyed, on some level, with the idea of launching a version of this newsletter—or wondering if I retcon the whole thing—do I charge people to subscribe to this? And the answer I keep coming away with is not at all because it started in many respects is marketing for AWS bill consulting and I want the audience as fast as possible. Artificially limiting its distribution via a pay-for model just seemed a little on the strange side.Lex: Yeah. And then you're beholden to a very many people and there's that disproportionality. So, years ago, before I even started in my career in I guess, you know, things that were SRE before SRE was cool, I worked for a living in Second Life. Are you familiar with Second Life?Corey: Oh, yes. I'm very familiar with that. Linden Labs.Lex: Yep. So, I worked for Linden Lab years later, but before I worked for them, I sort of spent a lot of my time living in Second Life. And I had a product that I sold for two or three dollars. And actually, it's still in there; you could still buy it. It's interesting. I don't know if it's because the purchase price was 800 Linden dollars, which equates to, like, $2.16, or something like that, but—Corey: The original cryptocurrency.Lex: Right, exactly. Except there's no crypto involved.Corey: [laugh].Lex: But people seem to have a disproportionate amount of, like, how much of my time they expected for support. You know, I'm going to support them a little bit. You have to recognize at some point, I actually can't come give you a tutorial on using this product because you're one of 500 customers for this month. And you give me two dollars and I don't have ten hours to give you. You know, like, sorry [laugh]. Yeah, so that can be really tough.Corey: And on some level, you need to find a way to either charge more or charge for support on top of it, or ideally—it I wish more open-source projects would take this approach—“Huh. We've had 500 people asking us the exact same question. Should we improve our docs? No, of course not. They're the ones who are wrong. It's the children who are getting it wrong.”I don't find that approach [laugh] to be particularly useful, but it bothers me to no end when I keep running into the same problem onboarding with something new and I ask about it, and, “Oh, yeah, everyone runs into that problem. Here's how you get around it.” This would have been useful to mention in the documentation. I try not to ask questions without reading the manual first.Lex: Well, so there's a couple different directions. I could go with this. First of all, there's a really interesting thing that happened with the core-js project that I recommend people check out. Another thing that I think the direction I'll go at the moment—we can bookmark that other one, but I have an open-source project on the side that I kind of did for my own fun, which is a program for creating designs that can be processed by computer-controlled embroidery machines. So, this is sewing machines that can plot stitches in the x-y plane based on a program that you give it.And there really wasn't much in the way of open-source software available that could help you create these designs and so I just sort of hack something together and started hacking with Python for my own fun, and then put it out there and open-sourced. And it's kind of taken off, kind of like gotten a life of its own. But of course, I've got a newsletter, I've got three kids, I've got a family, and a day job, and I definitely hear you on the, like, you know, yeah, we should put this FAQ in the docs, but there can be so little time to even do that. And I'm finding that there's, like—you know, people talk about work-life balance, there's, like, work slash life slash open-source balance that you really—you know, you have to, like, balance all three of them.And a lot of weeks, I don't have any time to spend on the project. But you know what, it's still kicks along and people just kind of, they use my terrible little project [laugh] as best they can, even though it has a ton of rough edges. I'm sorry, everyone, I'm so sorry. I know it has a t—the UI is terrible. But yeah, it's interesting how these things sometimes take on a life of their own and you can feel dragged along by your own open-source work, you know?Corey: It always bothers me—I think this might tie back to the core-js issue you talked about a second ago—where there are people who are building and supporting open-source tools or libraries that they originally constructed to scratch an itch and now they are core dependencies of basically half the internet. And these people are still wondering on some level, how do I put food on the table this month? It's wild to me. If there were justice in the world, you'd start to think these people would wind up in never-have-to-work-again-if-they-don't-want-to positions. But in many cases, it's exactly the opposite.Lex: Well, that's the really interesting thing. So, first of all, I'm hugely privileged to have any time to get to work on open-source. There's plenty of people that don't, and yeah, so requiring people to have a GitHub link to show their open-source contributions is inherently unfair and biased and discriminatory. That aside, people have asked all along, like, “Lex, this is decent software, you could sell this. You could charge money for this thing and you could probably make a, you know, a decent living at this.”And I categorically refuse to accept money for that project because I don't want to have to support it on a commercial level like that. If I take your money, then you have an expectation that—especially if I charge what one would expect—so this software, part of the reason I decided to write my own is because it starts at two-hundred-some-off dollars for the competitors that are commercial and goes up into the five, ten-thousand dollars. For a software package. Mine is free. If I started charging money, then yeah, I'm going to have to build a support department and we're going to have a knowledge base, I'm going to have to incorporate. I don't want to do that for something I'm doing for fun, you know? So yeah, I'm going to keep it free and terrible [laugh].Corey: It becomes something you love, turns into something you hate without even noticing that it happens. Or at least something that you start to resent.Lex: Yeah. I don't think I would necessarily hate machine embroidery because I love it. It's an amazingly fun little quirky hobby, but I think it would definitely take away some of the magic for me. Where there's no stress at all, I can spend months noodling on an algorithm getting it right, whereas it'd be, you know, if I start having to have deliverables, it changes it entirely. Yeah.Corey: It's odd, it seems, on some level too, that the open-source world that I got started with has evolved in a whole bunch of different ways. Whereas it used to be write a quick fix for something and it would get merged, in many cases by the time you got back from lunch. And these days, it seems like it takes multiple weeks, especially with a corporate-controlled open-source project, and there's so much back and forth. And even getting the boilerplate, like the CLI—the Contributor License Agreement—aside and winding up getting other people to sign off on it, then there's back and forth, in some cases for weeks about, well, the right kind of test coverage and how to look at this and the right holistic framework. And I appreciate that there is validity and value to these things, but is that the bulk of the effort should be going when there's a pull request ready to go that solves a breaking customer problem?But the test coverage isn't right so we're going to delay it for two or three releases. It's what are you doing there? Someone lost the plot somewhere. And I'm sure there are reasons that makes sense, given the framework people are operating within. I just find it maddening from the side of having to [laugh] deal with this as a human.Lex: Yeah, I hear you. And it sometimes can go even beyond test coverage to something like code style, you know? It's like, “Oh, that's not really in the style of this project,” or, “You know, I would have written it this way.” And one thing I've had to really work on, on this project is to make it as inviting to developers as possible. I have to sometimes look at things and be like, yeah, I might do that a different way. But does that actually matter? Like, do I have a reason for that that really matters or is it just my style? And maybe because it's a group project I should just be like, no, that's good as it is.[midroll 00:20:23]Corey: So, you've had an interesting career. And clearly you have opinions about SRE as a result. When I started seeing that you were the author of SRE Weekly, years ago, I just assumed something that I don't believe is true. Is it possible that you have been contributing to the community around SRE, but somehow have never worked at Google?Lex: I have never worked at Google. I have never worked at Netflix. I've never worked at any of those big companies. The biggest company I've worked for is Salesforce. Although I worked for Heroku who had been bought by Salesforce a couple of years prior, and so it was kind of like working for a startup inside a big company. And here's the other thing. I created that newsletter two months after starting my first job where I had a—like, the first job in which I was titled ‘SRE.' So, that's possibly contentious right there.Corey: You know, I hadn't thought of it this way, but you're right. I did almost the exact same thing. I was no expert in AWS when I started these things. It came out of an effort that I needed to do of keeping touch with everything that came out that had potential economic impact, which it turns out are most things when you understand architecture and cost are the same thing when it comes to cloud. But I was more or less gathering what smart people were saying.And somehow there's been this osmotic effect, where people start to view me as the wise old sage of the mountain when it comes to AWS. And no, no, no, I'm just old and grumpy. That looks alike. Don't mistake it for wisdom. But people will now seek me out to get my opinion on things and I have no idea what the answer looks like for most of the stuff.But that's the old SRE model—or sysadmin model that I've followed, which is when you don't know the answer, well, how do you get to a place where you can find the answer? How do you troubleshoot this? Click the button. It doesn't work? Well, time to start taking the button apart to figure out why.Lex: Yeah, definitely. I hear you on people. So, first of all, thanks to everyone who writes the articles that I include. I would be nothing without—I mean—literally, that I could not have a newsletter without content creators. I also kind of started the newsletter as an exploration of this new career title.I mean, I've been doing things that basically fit along with SRE for a long time, but also, I think my view of SRE might be not really the same as a lot of folks, or, like, that Google passed down from the [Google Book Model 00:22:46]. I don't—I'm going to be a little heretical here—I don't necessarily a hundred percent believe in the SLI SLO SLA error budget model. I don't think that that necessarily fits everyone, I'm not sure even suits the bigger companies as well as they think it does. I think that there's a certain point to which you can't actually predict failure and just slowing down on your deploys. And it likes to cause there to be fewer incidents so that you can get—your you know, you can go back to passing in your error budget, to passing your SLO, I'm not sure that actually makes sense or is realistic and works in the real world.Corey: I've been left with the distinct impression that it's something of a framework for how to think about a lot of those things. And it's for folks on a certain point of their development along whatever maturity model or maturity curve you want to talk about, it becomes extraordinarily useful. And at some point, it feels like the path that a given company is on will deviate from that. And, on some level, if you don't wind up addressing it, it turns into what it seems like Agile did, where you wind up with the Cult of Agile around it and the entire purpose of it is to perpetuate the Cult of Agile.And I don't know that I'm necessarily willing to go so far as to say that's where SLOs are headed right now, but I'm starting to get the same sort of feeling around the early days of the formalization of frameworks like that, and the ex cathedra proclamation that this is right for everyone. So, I'm starting to wonder whether there's a reckoning, in that sense, coming down the road. I'm fortunate that I don't run anything that's production-facing, so for me, it's, I don't have to care about these things. Mostly.Lex: Yeah. I mean, we are in… we're in 2023. Things have come so much further than when I was a kid. I have a little computer in my pocket. Yeah, you know, “Hey, math teacher, turns out yeah, we do carry calculators around with us wherever we go.” We've built all these huge, complicated systems online and built our entire society around them.We're still in our infancy. We still don't know what we're doing. We're still feeling out what SRE even is, if it even makes sense, and I think there's—yeah, there's going to be more evolution. I mean, there's been the, like, what is DevOps and people coining the term DevOps and then getting, you know, almost immediately subsumed or turned into whatever other people want. Same thing for observability.I think same thing for SRE. So honestly, I'm feeling it out as I go and I think we all are. And I don't think anyone really knows what we're doing. And I think that the moment we feel like we do is probably where we're in trouble. Because this is all just so new. Look where we were even 40 years, 30, even 20 years ago. We've come really far.Corey: For me, one of the things that concerns slash scares me has been that once someone learns something and it becomes rote, it sort of crystallizes in amber within their worldview, and they don't go back and figure out, “Okay, is this still the right approach?” Or, “Has the thing that I know changed?” And I see this on a constant basis just because I'm working with AWS so often. And there are restrictions and things you cannot do and constraints that the cloud provider imposes on you. Until one day, that thing that was impossible is now possible and supported.But people don't keep up with that so they still operate under the model of what used to be. I still remember a year or so after they raised the global per-resource tag limit to 50, I was seeing references to only ten tags being allowed per resource in the AWS console because not even internal service teams are allowed to talk to each other over there, apparently. And if they can't keep it straight internally, what hope to the rest of us have? It's the same problem of once you get this knowledge solidified, it's hard to keep current and adapt to things that are progressing. Especially in tech where things are advancing so rapidly and so quickly.Lex: Yeah, I gather things are a little feudalistic over inside AWS, although I've never worked there, so I don't know. But it's also just so big. I mean, there's just—like, do you even know all of the—like, I challenge you to go through the list of services. I bet you're going to find when you don't know about. You know, the AWS services. Maybe that's a challenge I would lose, but it's so hard to keep track of all this stuff with how fast it's changing that I don't blame people for not getting that.Corey: I would agree. We've long since passed the point where I can talk incredibly convincingly about AWS services that do not exist and not get called out on it by AWS employees. Because who would just go and make something up like that? That would be psychotic. No one in the right mind would do it.“Hi, I'm Corey, we haven't met yet. But you're going to remember this, whether I want you to or not because I make an impression on people. Oops.”Lex: Yeah. Mr. AWS Snark. You're exactly who I would expect to do that. And then there was Hunter, what's his name? The guy who made the—[singing] these are the many services of AWS—song. That was pretty great, too.Corey: Oh, yeah. Forrest Brazeal. He was great. I loved having him in the AWS community. And then he took a job, head of content over at Google Cloud. It's, well, suddenly, you can't very well make fun of AWS anymore, not without it taking a very different tone. So, I feel like that's our collective loss.Lex: Yeah, definitely. But yeah, I feel like we've done amazing things as a society, but the problem is that we're still, like, at the level of, we don't know how to program the VCR as far as, like, trying to run reliable services. It's really hard to build a complex system that, by its nature of being useful for customers, it must increase in complexity. Trying to run that reliably is hugely difficult and trying to do so profitably is almost impossible.And then I look at how hard that is and then I look at people trying to make self-driving cars. And I think that I will never set foot in one of those things until I see us getting good at running reliable services. Because if we can't do this with all of these people involved, how do I expect that a little car is going to be—that they're going to be able to produce a car that can drive and understand the complexities of navigating around and all the hazards that are involved to keep me safe.Corey: It's wild to me. The more I learned about the internet, the more surprised I am that any of it works at all. It's like, “Well, at least you're only using it for ridiculous things like cat pictures, right?” “Oh, no, no, no. We do emergency services and banking and insurance on top of that, too.” “Oh, good. I'm sure that won't end horribly one day.”Lex: Right? Yeah. I mean, you look at, like—you look at how much of a concerted effort towards safety they've had to put in, in the aviation industry to go from where they were in the '70s and '80s to where we are now where it's so incredibly safe. We haven't made that kind of full industry push toward reliability and safety. And it's going to have to happen soon as more and more of the services we're building are, exactly as you say, life-critical.Corey: Yeah, the idea of having this stuff be life-critical means you have to take a very different approach to it than you do when you're running, I don't know, Twitter for Pets. Though, I probably need a new fake reference startup now that Twitter for reality is becoming more bizarre than anything I can make up. But the idea that, “Well, our ad network needs to have the same rigor and discipline applied to it as the life support system,” maybe that's the wrong framing.Lex: Or maybe it's not. I keep finding instances of situations—maybe not necessarily ad networks, although I wouldn't put it past them—but situations where a system that we're dealing with becomes life-critical when we had no idea that it could possibly do. So, for example, a couple companies back, there was this billing situation where a vendor of ours accidentally nilled our customers incorrectly and wiped bank accounts, and real people were unable to make their mortgage payments and unable to, like, their bank accounts were empty, so they couldn't buy food. Like, that's starting to become life-critical and it all came down to a single, like, this could have been any outage at any company. And that's going to happen more and more, I think.Corey: I really want to thank you for taking time to speak with me. If people want to learn more, where's the best place for them to find you?Lex: sreweekly.com. You can subscribe there. Thank you so much for having me on. It has been a real treat.Corey: It really has. You'll have to come back and we'll find other topics to talk about, I'm sure, in the very near future. Thank you so much for your time. I appreciate it.Lex: Thanks.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.

If you enjoyed this video, here are additional resources to look at: MLOps Platforms: AWS SageMaker and Azure ML: https://www.coursera.org/learn/mlops-aws-azure-duke Open Source Platforms for MLOps: https://www.coursera.org/learn/open-source-mlops-platforms-dukePython Essentials for MLOps: https://www.coursera.org/learn/python-essentials-mlops-duke Coursera + Duke Specialization: Building Cloud Computing Solutions at Scale Specialization: https://www.coursera.org/specializations/building-cloud-computing-solutions-at-scale Python, Bash, and SQL Essentials for Data Engineering Specialization: https://www.coursera.org/specializations/python-bash-sql-data-engineering-duke AWS Certified Solutions Architect - Professional (SAP-C01) Cert Prep: 1 Design for Organizational Complexity: https://www.linkedin.com/learning/aws-certified-solutions-architect-professional-sap-c01-cert-prep-1-design-for-organizational-complexity/design-for-organizational-complexity?autoplay=true Essentials of MLOps with Azure and Databricks: https://www.linkedin.com/learning/essentials-of-mlops-with-azure-1-introduction/essentials-of-mlops-with-azure O'Reilly Book:  Implementing MLOps in the Enterprise O'Reilly Book: Practical MLOps: https://www.amazon.com/Practical-MLOps-Operationalizing-Machine-Learning/dp/1098103017 O'Reilly Book: Python for DevOps: https://www.amazon.com/gp/product/B082P97LDW/ O'Reilly Book: Developing on AWS with C#: A Comprehensive Guide on Using C# to Build Solutions on the AWS Platformhttps://www.amazon.com/Developing-AWS-Comprehensive-Solutions-Platform/dp/1492095877 Pragmatic AI: An Introduction to Cloud-based Machine Learning: https://www.amazon.com/gp/product/B07FB8F8QP/ Pragmatic AI Labs Book: Python Command-Line Tools: https://www.amazon.com/gp/product/B0855FSFYZ Pragmatic AI Labs Book: Cloud Computing for Data Analysis: https://www.amazon.com/gp/product/B0992BN7W8 Pragmatic AI Book: Minimal Python: https://www.amazon.com/gp/product/B0855NSRR7 Pragmatic AI Book: Testing in Python: https://www.amazon.com/gp/product/B0855NSRR7 Subscribe to Pragmatic AI Labs YouTube Channel: https://www.youtube.com/channel/UCNDfiL0D1LUeKWAkRE1xO5Q Subscribe to 52 Weeks of AWS Podcast:  https://52-weeks-of-cloud.simplecast.com View content on noahgift.com: https://noahgift.com/ View content on Pragmatic AI Labs Website: https://paiml.com/

Cloud Security Podcast - This month we are talking about "Building on the AWS Cloud" and next up on this series, we spoke to Chad Lorenc (Chad's Linkedin) about AWS Security Reference Architecture, Cloud Adoption Framework & Security Maturity Model are 3 ways to level up the maturity you have in Cloud . In this episode Chad Lorenc, from AWS shared lessons and talk about How AWS Customers can prepare to use 3 models to Crawl, Walk & Run their security practice. Episode ShowNotes, Links and Transcript on Cloud Security Podcast: www.cloudsecuritypodcast.tv Host Twitter: Ashish Rajan (@hashishrajan) Guest Twitter: Chad Lorenc (Chad's Linkedin) Podcast Twitter - @CloudSecPod @CloudSecureNews If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security News - Cloud Security BootCamp Spotify TimeStamp for Interview Questions (00:00) Introduction (03:35) A word from our sponsors - check them out at snyk.io/csp (03:51) A bit about Chad (05:38) How things are different in the Cloud (07:59) The Maturity framework of AWS (11:20) How maturity scales in AWS (13:17) Anti-Patterns when building maturity in Cloud (15:35) Framework examples on how to build maturity models (19:27) Mapping maturity models to business objectives (20:19) The role of cloud native tools (26:23) Patterns in AWS to watch out for (28:38) Challenges for security leaders trying to get into cloud (35:07) Foundational pieces for building maturity in AWS (37:50) How to implement AWS Control tower? (43:09) Give developers more freedom in cloud (47:34) Benchmark scales for security maturity (51:27) Resources to help you build your own maturity roadmap See you at the next episode!

If you enjoyed this video, here are additional resources to look at: Open Source Platforms for MLOps: https://www.coursera.org/learn/open-source-mlops-platforms-dukePython Essentials for MLOps: https://www.coursera.org/learn/python-essentials-mlops-duke Coursera + Duke Specialization: Building Cloud Computing Solutions at Scale Specialization: https://www.coursera.org/specializations/building-cloud-computing-solutions-at-scale Python, Bash, and SQL Essentials for Data Engineering Specialization: https://www.coursera.org/specializations/python-bash-sql-data-engineering-duke AWS Certified Solutions Architect - Professional (SAP-C01) Cert Prep: 1 Design for Organizational Complexity: https://www.linkedin.com/learning/aws-certified-solutions-architect-professional-sap-c01-cert-prep-1-design-for-organizational-complexity/design-for-organizational-complexity?autoplay=true Essentials of MLOps with Azure and Databricks: https://www.linkedin.com/learning/essentials-of-mlops-with-azure-1-introduction/essentials-of-mlops-with-azure O'Reilly Book:  Implementing MLOps in the Enterprise O'Reilly Book: Practical MLOps: https://www.amazon.com/Practical-MLOps-Operationalizing-Machine-Learning/dp/1098103017 O'Reilly Book: Python for DevOps: https://www.amazon.com/gp/product/B082P97LDW/ O'Reilly Book: Developing on AWS with C#: A Comprehensive Guide on Using C# to Build Solutions on the AWS Platformhttps://www.amazon.com/Developing-AWS-Comprehensive-Solutions-Platform/dp/1492095877 Pragmatic AI: An Introduction to Cloud-based Machine Learning: https://www.amazon.com/gp/product/B07FB8F8QP/ Pragmatic AI Labs Book: Python Command-Line Tools: https://www.amazon.com/gp/product/B0855FSFYZ Pragmatic AI Labs Book: Cloud Computing for Data Analysis: https://www.amazon.com/gp/product/B0992BN7W8 Pragmatic AI Book: Minimal Python: https://www.amazon.com/gp/product/B0855NSRR7 Pragmatic AI Book: Testing in Python: https://www.amazon.com/gp/product/B0855NSRR7 Subscribe to Pragmatic AI Labs YouTube Channel: https://www.youtube.com/channel/UCNDfiL0D1LUeKWAkRE1xO5Q Subscribe to 52 Weeks of AWS Podcast:  https://52-weeks-of-cloud.simplecast.com View content on noahgift.com: https://noahgift.com/ View content on Pragmatic AI Labs Website: https://paiml.com/

Over 90% of security breaches in the public cloud stem from user error, and not the cloud service provider. Today, your host John Verry sat down with one of Amazon Web Services (AWS) own Temi Adebambo, to understand what is going wrong with public cloud security, and how you can eliminate your biggest risks. This episode features Temi Adebambo, Head of Security Solutions Architecture at Amazon Web Services (AWS), to explain exactly what's going wrong with public cloud security, how users can eliminate their biggest risks, and much more. Join us as we discuss: • The 2 mistakes public cloud users make that cause the most security breaches • How using “higher-level” services can reduce your security burden • Ideas for baking security into your DevOps pipeline • The critical importance of “guardrails” for your team and how to implement them • The top AWS security tools all users should leverage To hear this episode, and many more like it, we would encourage you to subscribe to The Virtual CISO Podcast here. You can find all our full length and short form episodes here. Listening on a desktop & can't see the links? Just search for The Virtual CISO Podcast in your favorite podcast playerhttps://www.pivotpointsecurity.com/

InfosecTrain hosts a live event entitled “AWS Security Speciality Masterclass” with certified expert ‘Ayush'. AWS is a leading Cloud platform in the market and many organizations use it for their cloud services. AWS security professionals are in great demand to implement and test security strategies on cloud. #AWSSecuritySpeciality #awscertificationtraining #awstraining #AWSSecurity #aws #AWScloudSecurity Agenda for the Webinar ➡️ Day 1 • Introduction to AWS cloud • Shared responsibility model • AWS Well-Architected Framework • cloud QA Session Subscribe to our channel to get video updates. Hit the subscribe button above. Facebook: https://www.facebook.com/Infosectrain/ Twitter: https://twitter.com/Infosec_Train LinkedIn: https://www.linkedin.com/company/infosec-train/ Instagram: https://www.instagram.com/infosectrain/ Telegram: https://t.me/infosectrains

InfosecTrain hosts a live event entitled “AWS Security Speciality Masterclass” with certified expert ‘Ayush'. AWS is a leading Cloud platform in the market and many organizations use it for their cloud services. AWS security professionals are in great demand to implement and test security strategies on cloud. Day 1-AWS Security Speciality: https://www.youtube.com/watch?v=eIwGSews30s Day 2-AWS Security Speciality: https://www.youtube.com/watch?v=j7a6aysp5bE&t=6s #AWSSecuritySpeciality #awscertificationtraining #awstraining #AWSSecurity #aws #AWScloudSecurity Agenda for the Webinar ➡️ Day 2:

Jenny Brinkley, Director of AWS Security at Amazon Web Services (AWS), sits down to share her empowering story working through the ranks, and even co-founding her own company. While she did not have a typical upbringing in the industry, she credits her parents for ending up where she is now, as they told her that she could do anything and she decided as she was growing up that she could. She had the opportunity to co-found a small startup before selling it to AWS. She says that working in her position is like a rollercoaster, as no one thing is like the other, saying her highs are high and her lows are low. Being a woman in cybersecurity, she is working to empower more women in the field, Jenny says, "I think that we're living in such an interesting time where empathy, kindness, compassion, honesty, partnership in the security space, I mean, heck for any industry, but really for security and cyber security roles today, it's, it's the life blood and to be underestimated, especially as a female or because, you know, my background doesn't follow a cookie cutter pattern of what individuals think of when they think of individuals in security roles." We thank Jenny for sharing her story.

Jenny Brinkley, Director of AWS Security at Amazon Web Services (AWS), sits down to share her empowering story working through the ranks, and even co-founding her own company. While she did not have a typical upbringing in the industry, she credits her parents for ending up where she is now, as they told her that she could do anything and she decided as she was growing up that she could. She had the opportunity to co-found a small startup before selling it to AWS. She says that working in her position is like a rollercoaster, as no one thing is like the other, saying her highs are high and her lows are low. Being a woman in cybersecurity, she is working to empower more women in the field, Jenny says, "I think that we're living in such an interesting time where empathy, kindness, compassion, honesty, partnership in the security space, I mean, heck for any industry, but really for security and cyber security roles today, it's, it's the life blood and to be underestimated, especially as a female or because, you know, my background doesn't follow a cookie cutter pattern of what individuals think of when they think of individuals in security roles." We thank Jenny for sharing her story.

Gafnit Amiga, Director of Security Research from Lightspin joins Dave to discuss her team's research "AWS RDS Vulnerability Leads to AWS Internal Service Credentials." The research describes how the vulnerability was caught and right after it was reported the AWS Security team applied an initial patch limited only to the recent Amazon Relational Database Service (RDS) and Aurora PostgreSQL engines, excluding older versions. They followed by personally reaching out to the customers affected by the vulnerability and helped them through the update process. The research states "Lightspin's Research Team obtained credentials to an internal AWS service by exploiting a local file read vulnerability on the RDS EC2 instance using the log_fdw extension." The research can be found here: AWS RDS Vulnerability Leads to AWS Internal Service Credentials

Gafnit Amiga, Director of Security Research from Lightspin, joins Dave to discuss her team's research "AWS RDS Vulnerability Leads to AWS Internal Service Credentials." The research describes how the vulnerability was caught and right after it was reported, the AWS Security team applied an initial patch limited only to the recent Amazon Relational Database Service (RDS) and Aurora PostgreSQL engines, excluding older versions. They followed by personally reaching out to the customers affected by the vulnerability and helped them through the update process. The research states "Lightspin's Research Team obtained credentials to an internal AWS service by exploiting a local file read vulnerability on the RDS EC2 instance using the log_fdw extension." The research can be found here: AWS RDS Vulnerability Leads to AWS Internal Service Credentials

Hear from Chad Woolf, VP of AWS Security, on how AWS is constantly reinventing its security and compliance teams and processes to meet the demands of such a fast-growing and ever-changing world.

In this episode of the Virtual Coffee with Ashish edition, we spoke with Kinnaird McQuade (Kinnaird's Twitter) Episode ShowNotes, Links and Transcript on Cloud Security Podcast: www.cloudsecuritypodcast.tv Host Twitter: Ashish Rajan (@hashishrajan) Guest Twitter: Kinnaird McQuade (Kinnaird's Twitter) Podcast Twitter - @CloudSecPod @CloudSecureNews If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security News - Cloud Security Academy

About AlyssaAlyssa Miller, Business Information Security Officer (BISO) for S&P Global, is the global executive leader for cyber security across the Ratings division, connecting corporate security objectives to business initiatives. She blends a unique mix of technical expertise and executive presence to bridge the gap that can often form between security practitioners and business leaders. Her goal is to change how security professionals of all levels work with our non-security partners throughout the business.A life-long hacker, Alyssa has a passion for technology and security. She bought her first computer herself at age 12 and quickly learned techniques for hacking modem communications and software. Her serendipitous career journey began as a software developer which enabled her to pivot into security roles. Beginning as a penetration tester, her last 16 years have seen her grow as a security leader with experience across a variety of organizations. She regularly advocates for improved security practices and shares her research with business leaders and industry audiences through her international public speaking engagements, online content, and other media appearances.Links Referenced: Cybersecurity Career Guide: https://alyssa.link/book A-L-Y-S-S-A dot link—L-I-N-K slash book: https://alyssa.link/book Twitter: https://twitter.com/AlyssaM_InfoSec alyssasec.com: https://alyssasec.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. Screaming in the Cloud listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.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: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the problems that many folks experience in the course of their career, regardless of what direction they're in, is the curse of high expectations. And there's no escaping for that. Think about CISOs for example, the C-I-S-O, the Chief Information Security Officer.It's generally a C-level role. Well, what's better than a C in the academic world? That's right, a B. My guest today is breaking that mold. Alyssa Miller is the BISO—B-I-S-O—at S&P Global. Alyssa, thank you for joining me to suffer my slings and arrows—Alyssa: [laugh].Corey: —as we go through a conversation that is certain to be no less ridiculous than it has begun to be already.Alyssa: I mean, I'm good with ridiculous, but thanks for having me on. This is awesome. I'm really excited to be here.Corey: Great. What the heck's BISO?Alyssa: [laugh]. I never get that question. So, this is—Corey: “No one's ever asked me that before.” [crosstalk 00:03:38]—Alyssa: Right?Corey: —the same thing as, “Do you know you're really tall?” “No, you're kidding.” Same type of story. But I wasn't clear. That means I'm really the only person left wondering.Alyssa: Exactly. I mean, I wrote a whole blog on it the day I got the job, right? So, Business Information Security Officer, Basically what it means is I am like the CISO but for my division, the Ratings Division at S&P Global. So, I lead our cyber security efforts within that division, work closely with our information security teams, our corporate IT teams, whatever, but I don't report to them; I report into the business line.I'm in the divisional CTO's org structure. And so, I'm the one bridging that gap between that business side where hey, we make all the money and that corporate InfoSec side where hey, we're trying to protect all the things, and there's usually that little bit of a gap where they don't always connect. That's me building the bridge across that.Corey: Someone who speaks both security and business is honestly in a bit of rare supply these days. I mean, when I started my Thursday newsletter podcast nonsense Last Week in AWS: Security, the problem I kept smacking into was everything I saw was on one side of that divide or the other. There was the folks who have the word security in their job title, and there tends to be this hidden language of corporate speak. It's a dialect I don't fully understand. And then you have the community side of actual security practitioners who are doing amazing work, but also have a cultural problem that more or less distills down to being an awful lot of shitheads in them there waters.And I wanted something that was neither of those and also wasn't vendor captured, which is why I decided to start storytelling in that space. But increasingly, I'm seeing that there's a significant problem with people who are able to contextualize security in the context of business. Because if you're secure enough, you can stop all work from ever happening, whereas if you're pure business side and only care about feature velocity and the rest, like, “Well, what happens if we get breached?” It's, “Oh, don't worry, I have my resume up to date.” Not the most reassuring answer to give people. You have to be able to figure out where that line lies. And it seems like that figuring out where that line is, is more or less your entire stock-in-trade.Alyssa: Oh absolutely, yeah. I mean, I can remember my earliest days as a developer, my cynical attitude towards security myself was, you know, their Utopia would be an impenetrable room full of servers that have no connections to anything, right? Like that would be wildly secure, yet completely useless. And so yeah, then I got into security and now I was one of them. And, you know, it's one of those things, you sit in, say a board meeting sometime and you listen to a CISO, a typical CISO talk to the board, and they just don't get it.Like, there's so much, “Hey, we're implementing this technology and we're doing this thing, and here's our vulnerability counts, and here's how many are overdue.” And none of that means anything. I mean, I actually had a board member ask me once, “What is a CISO?” I kid you not. Like, that's where they're at.Like, so don't tell them what you're doing, but tell them why connected back to, like, “Hey, the business needs this and this, and in order to do it, we've got to make sure it's secure, so we're going to implement these couple of things. And here's the roadmap of how we get from where we are right now to where we need to be so they can launch that new service or product,” or whatever the hell it is that they're going to do.Corey: It feels like security is right up there with accounting, in the sense of fields of endeavor where you don't want someone with too much personality involved. Because if the CISO's sitting there talking to the board, it's like, “So, what do you do here, exactly?” And the answer is the honest, “Hey, remember last month how we were in The New York Times for that giant data breach?” And they do a split take, “No, no, I don't.” “Exactly. You're welcome.” On some level, it is kind of honest, but it also does not instill confidence when you're that cavalier with the description of what it is you do here.Alyssa: Oh there's—Corey: At least there's some corners. I prefer—Alyssa: —there's so much—Corey: —places where that goes over well, but that's me.Alyssa: Yeah. But there's so much of that too, right? Like, here's the one I love. “Well, you know, it's not if you get breached, it's when. Oh, by the way, give me millions and millions of dollars, so I can make sure we don't get breached.”But wait, you just told me we're going to get breached no matter what we do. [laugh]. We do that in security. Like, and then you wonder why they don't give you funding for the initiative. Like, “Hello?” You know?And that's the thing that gets me it's like, can we just sit back and understand, like, how do you message to these people? Yeah I mean, you bring up the accounting thing; the funny thing is, at least all of them understand some level of accounting because most of them have MBAs and business degrees where they had to do some accounting. They didn't go through cyber security in their MBA program.So, one of my favorite questions on Twitter once was somebody asked me, you know, if I want to get into cyber security leadership, what is the one thing that I should focus on or what skills should I study? I said, “Go study MBA concepts.” Like, forget all the cyber security stuff. You probably have plenty of that technolog—go understand what they learn in MBA programs. And if you can start to speak that language, that's going to pay dividends for bridging that gap.Corey: So, you don't look like the traditional slovenly computer geek showing up at those meetings who does not know how to sound as if they belong in the room. Like, it's unfair, on some level, and I used to have bitter angst about that. Like, “Why should how I dress matter how people perceive me?” Yeah, in an absolute sense you're absolutely right, however, I can talk about the way the world is or the way I wish it were and there has to be a bit of a divide there.Alyssa: Oh, for sure. Yeah. I mean, you can't deny that you have to be prepared for the audience you're walking into. Now, I work in big conservative financial services on Wall Street. You know, and I had this conversation with a prominent member of our community when I started the job.I'm like, “Boy, I guess I can't really put stickers on my laptop. I'm going to have to get, you know, a protector or something to put stickers on.” Because the last thing I want to do is go into a boardroom with my laptop and whip out a bunch of hacker stickers on the backside of my laptop. Like, in a lot of spaces that will work, but you can't really do that when you're, you know, at, you know, the executive level and you're in a conservative, financial [unintelligible 00:10:16]. It just, I would love to say they should deal with that, I should be able to have pink hair, and you know, face tattoos and everything else, but the reality is, yeah, I can do all that, but these are still human beings who are going to react to that.And it's the same when talking about cyber security, then. Like, I have to understand as a security practitioner that all they know about cyber security is it's big and scary. It's the thing that keeps them up at night. I've had board members tell me exactly that. And so, how do I make it a little less scary, or at least get them to have some confidence in me that I'll, like, carry the shield in front of them and protect them. Like, that's my job. That's why I'm there.Corey: When I was starting my consultancy five years ago, I was trying to make a choice between something in the security cloud direction or the cost cloud direction. And one of the things that absolutely tipped the balance for me was the fact that the AWS bill is very much a business-hours-only problem. No one calls me at two in the morning screaming their head off. Usually. But there's a lot of alignment between those two directions in that you can spend all your time and energy fixing security issues and/or reducing the bill, but past a certain point, knock it off and go do the thing that your company is actually there to do.And you want to be responsible to a point on those things, but you don't want it to be the end-all-be-all because the logical outcome of all of that, if you keep going, is your company runs out of money and dies because you're not going to either cost optimize or security optimize your business to its next milestone. And weighing those things is challenging. Now, too many people hear that and think, “See, I don't have to worry about those things at all.” It's, “Oh, you will sooner or later. I promise.”Alyssa: So, here's the fallacy in that. There is this assumption that everything we do in security is going to hamper the business in some way and so we have to temper that, right? Like, you're not wrong. And we talked about before, right? You know, security in a traditional sense, like, we could do all of the puristic things and end up just, like, screeching the world to a halt.But the reality is, we can do security in a way that actually grows the business, that actually creates revenue, or I should say enables the creation of revenue in that, you know, we can empower the business to do more things and to be more innovative by how we approach security in the organization. And that's the big thing that we miss in security is, like, look, yes, we will always be a quote-unquote, “Cost center,” right? I mean, we in security don't—unless you work for a security organization—we're not getting revenue attributed to us, we're not creating revenue. But we are enabling those people who can if we approach it right.Corey: Well, the Red Team might if they go a little off-script, but that's neither here nor there.Alyssa: I—yeah, I mean, I've had that question. “Like, couldn't we just sell resell our Red Team services?” No. No. That's not our core [crosstalk 00:13:14]Corey: Oh, I was going the other direction. Like, oh, we're just going to start extorting other businesses because we got bored this week. I'm kidding. I'm kidding. Please don't do an investigation, any law enforcement—Alyssa: I was going to say, I think my [crosstalk 00:13:22]—Corey: —folks that happen to be listening to this.Alyssa: [crosstalk 00:13:24] is calling me right now. They're want to know what I'm [laugh] talking about. But no—Corey: They have some inquiries they would like you to assist them with and they're not really asking.Alyssa: Yeah, yeah, they're good at that. No, I love them, though. They're great. [laugh]. But no, seriously, like, I mean, we always think about it that way because—and then we wonder why do we have the reputation of, you know, the Department of No.Well, because we kind of look at it that way ourselves; we don't really look at, like how can we be a part of the answer? Like, when we look at, like, DevSecOps, for instance. Okay, I want to bring security into my pipeline. So, what do we say? “Oh, shared responsibility. That's a DevOps thing.” So, that means security is everybody's responsibility. Full stop.Corey: Right. It's a—Alyssa: Well—Corey: And there, I agree with you wholeheartedly. Cost is—Alyssa: But—Corey: —aligned with this. It has to be easier to do it the right way than to just go off half-baked and do it yourself off the blessed path. And that—Alyssa: So there—Corey: —means there's that you cannot make it harder to do the right thing; you have to make it easier because you will not win against human psychology. Depending on someone when they're done with an experiment to manually go in and turn things off. It will not happen. And my argument has been that security and cost are aligned constantly because the best way to secure something and save money on at the same time is to turn that shit off. You wouldn't think it would be that simple, but yet here we are.Alyssa: But see, here's the thing. This is what kills me. It's so arrogant of security people to look at it and say that right? Because shared responsibility means shared. Okay, that means we have responsibilities we're going to share. Everybody is responsible for security, yes.Our developers have responsibilities now that we have to take a share in as well, which is get that shit to production fast. Period. That is their goal. How fast can I pop user stories off the backlog and get them to deployment? My SRE is on the ops side. They're, like, “We just got to keep that stuff running. That's all we that's our primary focus.”So, the whole point of DevOps and DevSecOps was everybody's responsible for every part of that, so if I'm bringing security into that message, I, as security, have to be responsible for site's stability; I, in security, have to be responsible for efficient deployment and the speed of that pipeline. And that's the part that we miss.Corey: This episode is sponsored in parts by our friend EnterpriseDB. EnterpriseDB has been powering enterprise applications with PostgreSQL for 15 years. And now EnterpriseDB has you covered wherever you deploy PostgreSQL on-premises, private cloud, and they just announced a fully-managed service on AWS and Azure called BigAnimal, all one word. Don't leave managing your database to your cloud vendor because they're too busy launching another half-dozen managed databases to focus on any one of them that they didn't build themselves. Instead, work with the experts over at EnterpriseDB. They can save you time and money, they can even help you migrate legacy applications—including Oracle—to the cloud. To learn more, try BigAnimal for free. Go to biganimal.com/snark, and tell them Corey sent you.Corey: I think you might be the first person I've ever spoken to that has that particular take on the shared responsibility model. Normally, when I hear it, it's on stage from an AWS employee doing a 45-minute song-and-dance about what the secured responsibility model is, and generally, that is interpreted as, “If you get breached, it's your fault, not ours.”Alyssa: [laugh].Corey: Now, you can't necessarily say it that directly to someone who has just suffered a security incident, which is why it takes 45 minutes and slides and diagrams and excel sheets and the rest. But that is what it fundamentally distills down to, and then you wind up pointing out security things that they've had that [unintelligible 00:17:11] security researchers have pointed out and they are very tight-lipped about those things. And it's, “Oh, it's not that you're otherworldly good at security; it's that you're great at getting people to shut up.” You know, not me, for whatever reason because I'm noisy and obnoxious, but most people who actually care about not getting fired from their jobs, generally don't want to go out there making big cloud companies look bad. Meanwhile, that's kind of my entire brand.Alyssa: I mean, it's all about lines of liability, right?Corey: Oh yeah.Alyssa: I mean, where am I liable, where am I not? And yeah, well, if I tell you you're responsible for security on all these things, and I can point to any part of that was part of the breach, well, hey, then it's out of my hands. I'm not liable. I did what I said I would; you didn't secure your stuff. Yeah, it's—and I mean, and some of that is to be fair.Like, I mean, okay, I'm going to host my stuff on your computer—the whole cloud is just somebody else's computer model is still ultimately true—but, yeah, I mean, I'm expecting you to provide me a stable and secure environment and then I'm going to deploy stuff on it, and you are expecting me to deploy things that are stable and secure as well. And so, when they say shared model or shared responsibility model, but it—really if you listen to that message, it's the exact opposite. They're telling you why it's a separate responsibility model. Here's our responsibilities; here's yours. Boom. It's not about shared; it's about separated.Corey: One of the most formative, I guess, contributors to my worldview was 13 years ago, I went on a date and met someone lovely. We got married. We've been together ever since, and she's an attorney. And it is been life-changing to understand a lot of that perspective, where it turns out when you're dealing with legal, they are not—and everyone says, “Oh, and the lawyers insisted on these things.”No, they didn't. A lawyer's entire role in a company is to identify risk, and then it is up to the business to make a decision around what is acceptable and what is not. If your lawyers ever insist on something, what that actually means in my experience is, you have said something profoundly ignorant that is one of those, like—that is—they're doing the legal equivalent of slapping the gun out of the toddler's hand of, “No, you cannot go and tweet that because you'll go to prison,” level of ridiculous nonsense where it is, “That will violate the law.” Everything else is different shades of the same answer: it depends. Here's what to consider.Alyssa: Yes.Corey: And then you choose—and the business chooses its own direction. So, when you have companies doing what appeared to be ridiculous things, like Oracle, for example, loves to begin every keynote with a disclaimer about how nothing they're about to say is true, the lawyers didn't insist on that—though they are the world's largest law firm, Kirkland Ellison. But instead, it's this entire story of given the risk and everything that we know about how we say things onstage and people gunning for us, yeah, we are going to [unintelligible 00:20:16] this disclaimer first. Most other tech companies do not do that exact thing, which I've got to say when you're sitting in the audience ready to see the new hotness that's about to get rolled out and it starts with a disclaimer, that is more or less corporate-speak for, “You are about to hear some bullshit,” in my experience.Alyssa: [laugh]. Yes. I mean and that's the thing, like, [clear throat], you know, we do deride legal teams a lot. And you know, I can find you plenty of security people who hate the fact that when you're breached, who's the first call you make? Well, it's your legal team.Why? Because they're the ones who are going to do everything in their power to limit the amount that you can get sued on the back-end for anything that got exposed, that you know, didn't meet service levels, whatever the heck else. And that all starts with legal privilege.Corey: They're reporting responsibilities. Guess who keeps up on what those regulatory requirements are? Spoiler, it's probably not you, whoever's listening to this, unless you're an attorney because that is their entire job.Alyssa: Yes, exactly. And, you know, work in a highly regulated environment—like mine—and you realize just how critical that is. Like, how do I know—I mean, there are times there's this whole discussion of how do you determine if something is a material impact or not? I don't want to be the one making that, and I'm glad I don't have to make that decision. Like, I'll tell you all the information, but yes, you lawyers, you compliance people, I want you to make the decision of if it's a material impact or not because as much as I understand about the business, y'all know way more about that stuff than I do.I can't say. I can only say, “Look, this is what it impacted. This is the data that was impacted. These are the potential exposures that occurred here. Please take that information now and figure out what that means, and is there any materiality to that that now we have to report that to the street.”Corey: Right, right. You can take my guesses on this or you can get it take an attorney's. I am a loud, confident-sounding white guy. Attorneys are regulated professionals who carry malpractice insurance. If they give wrong advice that is wrong enough in these scenarios, they can be sanctioned for it; they can lose their license to practice law.And there are challenges with the legal profession and how much of a gatekeeper the Bar Association is and the rest, but this is what it is [done 00:22:49] for itself. That is a regulated industry where they have continuing education requirements they need to certify in a test that certain things are true when they say it, whereas it turns out that I don't usually get people even following up on a tweet that didn't come true very often. There's a different level of scrutiny, there's a different level of professional bar it raises to, and it turns out that if you're going to be legally held to account for things you say, yeah, turns out a lot of your answers to are going to be flavors of, “It depends.”Alyssa: [laugh].Corey: Imagine that.Alyssa: Don't we do that all the time? I mean, “How critical is this?” “Well, you know, it depends on what kind of data, it depends on who the attacker is. It depends.” Yeah, I mean, that's our favorite word because no one wants to commit to an absolute, and nor should we, I mean, if we're speaking in hyperbole and absolutes, boy, we're doing all the things wrong in cyber.We got to understand, like, hey, there is nuance here. That's how you run—no business runs on absolutes and hyperbole. Well, maybe marketing sometimes, but that's a whole other story.Corey: Depends on if it's done well or terribly.Alyssa: [laugh]. Right. Exactly. “Hey, you can be unhackable. You can be breached-proof.” Oh, God.Corey: Like, what's your market strategy? We're going to paint a big freaking target in the front of the building. Like, I still don't know how Target the company was ever surprised by a data breach that they had when they have a frickin' bullseye as their logo.Alyssa: “Come get us.”Corey: It's, like, talk about poking the bear. But there we are.Alyssa: [unintelligible 00:24:21] no. I mean, hey, [unintelligible 00:24:23] like that was so long ago.Corey: It still casts a shadow.Alyssa: I know.Corey: People point to that as a great example of, like, “Well, what's going to happen if we get breached?” It's like, well look at Target because they wound up—like, their stock price a year later was above where it had been before and it seemed to have no lasting impact. Yeah, but they effectively replaced all of the execs, so you know, let's have some self-interest going on here by named officers of the company. It's, “Yeah, the company will be fine. Would you like to still be here what it is?”Alyssa: And how many lawsuits do you think happened that you never heard about because they got settled before they were filed?Corey: Oh, yes. There's a whole world of that.Alyssa: That's what's really interesting when people talk about, like, the cost of breach and stuff, it's like, we don't even know. We can't know because there is so much of that. I mean, think about it, any organization that gets breached, the first thing they're trying to do is keep as much of it out of the news as they can, and that includes the lawsuits. And so, you know, it's like, all right, well, “Hey, let's settle this before you ever file.”Okay, good. No one will ever know about that. That will never show up anywhere. It is going to show up on a balance sheet anywhere, right? I mean, it's there, but it's buried in big categories of lots of other things, and how are you ever going to track that back without, you know, like, a full-on audit of all of their accounting for that year? Yeah, it's—so I always kind of laugh when people start talking about that and they want to know, what's the average cost of a breach. I'm like, “There's no way to measure that. There is none.”Corey: It's not cheap, and the reputational damage gets annoying. I still give companies grief for these things all the time because it's—again, the breach is often about information of mine that I did not consciously choose to give to you and the, “Oh, I'm going to blame a third-party process.” No, no, you can outsource work, but not responsibility. You can't share that one.Alyssa: Ah, third-party diligence, uh, that seems to be a thing. You know, I think we're supposed to make sure our third parties are trustworthy and doing the right things too, right? I mean, it's—Corey: Best example I ever saw that was an article in the Wall Street Journal about the Pokemon company where they didn't name the vendor, but they said they declined to do business with them in part based upon their lax security policy around S3 buckets. That is the first and so far only time I have had an S3 Bucket Responsibility Award engraved and sent to their security director. Usually, it's the ignoble prize of the S3 Bucket Negligence Award, and there are oh so many of those.Alyssa: Oh, and it's hard, right? Because you're standing—I mean, I'm in that position a lot, right? You know, you're looking at a vendor and you've got the business saying, “God, we want to use this vendor. All their product is great.” And I'm sitting there saying, but, “Oh, my God, look at what they're doing. It's a mess. It's horrible. How do I how do we get around this?”And that's where, you know, you just have to kind of—I wish I could say no more, but at the end of the day, I know what that does. That just—okay, well, we'll go file an exception and we'll use it anyway. So, maybe instead, we sit and work on how to do this, or maybe there is an alternative vendor, but let's sort it out together. So yeah, I mean, I do applaud them. Like that's great to, like, be able to look at a vendor and say, “No, we ain't touching you because what you're doing over there is nuts.” And I think we're learning more and more how important that is, with a lot of the supply chain attacks.Corey: Actually, I'm worried about having emailed you, you're going to leak my email address when your inbox inevitably gets popped. Come on. It's awful stuff.Alyssa: Yeah, exactly. So, I mean, it's we there's—but like everything, it's a balance again, right? Like, how can we keep that business going and also make sure that their vendors—so that's where it just comes down to, like, okay, let's talk contracts now. So, now we're back to legal.Corey: We are. And if you talk to a lawyer and say, “I'm thinking about going to law school,” the answer is always the same. “No… don't do it.” Making it clear that is apparently a terrible life and professional decision, which of course, brings us to your most recent terrible life and professional decision. As we record this, we are reportedly weeks away from you having a physical copy in your hands of a book.And the segue there is because no one wants to write a book. Everyone wants to have written a book, but apparently—unless you start doing dodgy things and ghost-writing and exploiting people in the rest—one is a necessary prerequisite for the other. So, you've written a book. Tell me about it.Alyssa: Oof, well, first of all, spot on. I mean, I think there are people who really do, like, enjoy the act of writing a book—Corey: Oh, I don't have the attention span to write a tweet. People say, “Oh, you should write a book, Corey,” which I think is code for them saying, “You should shut up and go away for 18 months.” Like, yeah, I wish.Alyssa: Writing a book has been the most eye-opening experience of my life. And yeah, I'm not a hundred percent sure it's one I'll ever—I've joked with people already, like, I'll probably—if I ever want another book, I'll probably hire a ghostwriter. But no, I do have a book coming out: Cybersecurity Career Guide. You know, I looked at this cyber skills gap, blah, blah, blah, blah, blah, we hear about it, 4 million jobs are going to be left open.Whatever, great. Well, then how come none of these college grads can get hired? Why is there this glut of people who are trying to start careers in cyber security and we can't get them in?Corey: We don't have six months to train you, so we're going to spend nine months trying to fill the role with someone experienced?Alyssa: Exactly. So, 2020 I did a bunch of research into that because I'm like, I got to figure this out. Like, this is bizarre. How is this disconnect happening? I did some surveys. I did some interviews. I did some open-source research. Ended up doing a TED Talk based off of that—or TEDx Talk based off of that—and ultimately that led into this book. And so yeah, I mean, I just heard from the publisher yesterday, in fact that we're, like, in that last stage before they kick it out to the printers, and then it's like three weeks and I should have physical copies in my hands.Corey: I will be getting one when it finally comes out. I have an almost, I believe, perfect track record of having bought every book that a guest on this show has written.Alyssa: Well, I appreciate that.Corey: Although, God help me if I ever have someone, like, “So, what have you done?” “I've written 80 books.” Like, “Well, thank you, Stephen King. I'm about to go to have a big—you're going to see this number of the company revenue from orbit at this point with that many.” But yeah, it's impressive having written a book. It's—Alyssa: I mean, for me, it's the reward is already because there are a lot of people have—so my publisher does really cool thing they call it early acc—or electronic access program, and where there are people who bought the book almost a year ago now—which is kind of, I feel bad about that, but that's as much my publisher as it is me—but where they bought it a year ago and they've been able to read the draft copy of the book as I've been finishing the book. And I'm already hearing from them, like, you know, I'm hearing from people who really found some value from it and who, you know, have been recommending it other people who are trying to start careers and whatever. And it's like, that's where the reward is, right?Like, it was, it's hell writing a book. It was ten times worse during Covid. You know, my publisher even confirmed that for me that, like, look, yeah, you know, authors around the globe are having problems right now because this is not a good environment conducive to writing. But, yeah, I mean, it's rewarding to know that, like, all right, there's going to be this thing out there, that, you know, these pages that I wrote that are helping people get started in their careers, that are helping bring to light some of the real challenges of how we hire in cyber security and in tech in general. And so, that's the thing that's going to make it worthwhile. And so yeah, I'm super excited that it's looking like we're mere weeks now from this thing being shipped to people who have bought it.Corey: So, now it's racing, whether this gets published before the book does. So, we'll see. There is a bit of a production lag here because, you know, we have to make me look pretty and that takes a tremendous amount of effort.Alyssa: Oh, stop. Come on now. But it will be interesting to see. Like, that would actually be really cool if they came out at about the same time. Like, you know, I'm just saying.Corey: Yeah. We'll see how it goes. Where's the best place for people to find you if they want to learn more?Alyssa: About the book or in general?Corey: Both.Alyssa: So—Corey: Links will of course be in the [show notes 00:32:49]. Let's not kid ourselves here.Alyssa: The book is real easy. Go to Alyssa—A-L-Y-S-S-A, back here behind me for those of you seeing the video. Um—I can't point the right direction. There we go. That one. A-L-Y-S-S-A dot link—L-I-N-K slash book. It's that simple. It'll take you right to Manning's site, you can get in.Still in that early access program, so if you bought it today, you would still be able to start reading the draft versions of it. If you want to know more about me, honestly, the easiest way is to find me on Twitter. You can hear all the ridiculousness of flight school and barbecue and some security topics, too, once in a while. But at @alyssam_infosec. Or if you want to check out the website where I blog, every rare occasion, it's alyssasec.com.Corey: And all of that will be in the [show notes 00:33:41]. Thank you—Alyssa: There's a lot. [laugh].Corey: I'm looking forward to seeing it, too. Thank you so much for taking the time to deal with my nonsense today. I really appreciate it.Alyssa: Oh, that was nonsense? Are you kidding me? This was a great discussion. I really appreciate it.Corey: As have I. Thanks again for your time. It is always great to talk to people smarter than I am—which is, let's be clear, most people—Alyssa Miller, BISO at S&P Global. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice—or smash the like and subscribe button if this is on the YouTubes—whereas if you've hated the podcast, same thing, five-star review, platform of choice, smash both of the buttons, but also leave an angry comment, either on the YouTube video or on the podcast platform, saying that this was a waste of your time and what you didn't like about it because you don't need to read Alyssa's book; you're going to get a job the tried and true way, by printing out a copy of your resume and leaving it on the hiring manager's pillow in their home.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

AWS has LOTS to offer when it comes to cloud security. In this episode, Jim talks to Ranjit Kalidasan, a Senior Solutions Architect, who will discuss the Shared Responsibility Model for Cloud security and then review the key tools and  observability use cases you need to know about to ensure your AWS cloud solution is protected.

Roger White (https://twitter.com/rogerkwhite1) shares his experience with the AWS security black belt program, what is it, and why it's good to become involved! Resources: https://awssecworkshops.com/workshops/ https://aws.amazon.com/partners/programs/

About ScottCloud security historian.Developed flaws.cloud, CloudMapper, and Parliament.Founding team for fwd:cloudsecLinks: Block: https://block.xyz/ Twitter: https://twitter.com/0xdabbad00 TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning fast processing power, courtesy of third gen AMD EPYC processors without the IO, or hardware limitations, of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices, and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. "Screaming in the Cloud" listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G E T V U L T R.com/screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I am joined by a returning guest with a bit of a different job. Scott Piper was formerly an independent security researcher—basically the independent security researcher in the AWS space—but now he's a Principal Engineer over at Block. Scott, welcome back.Scott: Thanks for having me, again, Corey.Corey: So, you've taken a corporate job, and when that happened, I have to confess, I was slightly discouraged because oh, now it's going to be like one of those stories of when someone you know goes to work at Apple because no one knows anyone at Apple; we just used to know people who went there and then we kind of lost touch because it's a very insular thing. Not the Block slash Square slash whatever they're calling themselves this week has that reputation. But InfoSec is always a very nuanced space and companies that have large footprints and, you know, handle financial transaction processing generally don't encourage loud voices that attract attention around anything that isn't directly aligned with the core mission of the company. But you're still as public and prolific as ever. Was that a difficult balance for you to strike?Scott: So, when I was considering employment options, that was something that I made clear to any companies that I was talking to, that this is something that probably will and should continue because a lot of my value to these companies is because I'm able to have discussions, able to impact change because of that public persona. So yeah, so I think that it was something that they were aware of, and a risk that they took. [laugh]. But yeah, it's been useful.Corey: This is the sort of conversation I would have expected to have with, “Yeah, things seem to be continuing the same, and I haven't rocked any boats, yet and they haven't fired me, knock on wood.” Except that recently you've launched yet something else that I am personally a fan of. Now, before we get into the specifics of what it is you're up to these days, I should call out that since your last appearance on this show, I have really leaned into the Thursday newsletter podcast duo of Last Week in AWS: Security Edition. Rounding up what happened the previous week—yes, it was the previous week, and it comes out on Thursdays—because, you know, timing and publication, things are hard, computers, you know how it is—aimed at a target audience that is very much not you: People who have to care about security, but are not immersed in the space. It's a, “All right, what now? What do I have to pay attention to?”Because there's a lot of noise in this space, there's a lot of vendor-captured stuff out there. There's very little that is for people who work in security but don't have the word security anywhere near their job title. And I have to confess that one of my easy shortcuts is, “Oh, it's a pretty thin issue this week,” which is not inherently a bad thing, let's be clear, it's not yay, the three things you need to care about in security then eight more of filler; that's not what we're about. But I always want to make sure I didn't miss something meaningful, and one of my default publication steps is, “What's Scott been tweeting about this week?” Just to make sure that I didn't miss something that I really should be talking about.And every single time I pull up your Twitter feed, I find myself learning something, whether it's a new concept, or whether it is a nuance on an existing thing I was already aware of. So first, thank you for all the work that you do as a member of the community, despite having a, “Regular corporate job,” quote-unquote, you're still very present. It's appreciated.Scott: Thank you. Yeah. And I mean, that newsletter is great for people that don't want to be spending multiple hours per day trolling through Twitter and reading that. So, it provides, also, something great for the community to not have to spend all that time on Twitter like I do [laugh], unfortunately.Corey: It also strives—sort of—to be something approaching an upbeat position of not quite as cynical and sarcastic as the Monday issue. I try to be not just this is the thing that happened, but go a little bit into and this is why it matters. This is how to think about it. This thing that Amazon put out is nonsense, however, here's the kernel hidden within it that might lead to something, such as thinking about how you do sign-on, or how to think about protecting MFA devices, or stuff like that you normally care about a lot right after you really should have cared about it but didn't at all. So, it's just the idea of aiming in a slightly different audience.Scott: Yeah definitely. And it provides value that it does, it takes some delay so that you can read what everybody has written, how they've responded to the different news outtakes, you're not just including the hot takes. For example, as of this morning, there's a certain incident with an authentication provider, and it's not really clear if there was actually a breach or not. And so it's valuable to take a moment to understand what happened, get all the voices to have expressed their points, so you can summarize those issues.Corey: An internal term that we've used to describe the position here is that I am prolific but I also have things to do as a part of my job that do not involve sitting there hitting refresh on Twitter like mad all the time. The idea is to have the best take not the first take—Scott: Exactly.Corey: And if that means that I lose a bunch of eyeballs and early ad impressions in the middle of the night and whatnot, well, great. I don't sell ad impressions anyway, so what does it matter? It winds up lending itself to a more thoughtful analysis of figuring out, in the sober light of day, is this a nothing-burger or is this enormous? With that SSO issue that you're alluding to—[cough] Okta—sorry, something caught in my throat there—very clearly, something is going on, but if I had written next week's newsletter last night while it was still very unclear, it would have been a very different tone than the one that I would have written this morning after their public statement, and even still a certainly different tone that it would take a couple of days once more information is almost certain to come to light. And that is something that is, I think, underappreciated in certainly on Twitter, where an old tweet—there's nothing worse than an old tweet unless you're using it to drag someone for something—that, “Well, we have different perspectives on that nowadays. It's not 2018 anymore.” Right. Okay, cool.Scott: Yep. [laugh].Corey: But something that you've done has been a bit of a pivot lately. Historically, you have been right there in my sweet spot of needling cloud providers for their transgressions in various ways. Cool, right there with you. We could co-author a book on the subject. But lately, you've started a community list of [IMSDv2 00:07:04] abuses.Now, first, we should talk about what IMSDv2 is. It's the name that it clearly came from Amazon because that's a name only a cloud provider bad at naming things could possibly love. What is it?Scott: So, it's the Instance Metadata Service, Version Two. If there's a version two, you can imagine there was a version one at some point. And the version two—Corey: And there's a version two because Amazon prod—the first one was terrible, but they don't turn anything off, ever, so this is the way and the light and the future; we're going to leave that old thing around until your great-grandchild dies of old age.Scott: Exactly, yeah. So, when EC2s first came out, and IAM roles first came out, you wanted to give your EC2s the ability to use AWS privileges, so this is how those EC2s are getting access to their credentials that they can use. And the way in which this was originally done was there's this magic IP address, this 169.254.169.254 IP address, which is very important for security on AWS because if anything can access that magic IP address from an EC2 instance, you can steal their credentials of that EC2, and therefore basically become that EC2 instance, in terms of what it can do in the AWS environment.And so in 2019, there was a large breach of Capital One that was related to this. And so as a result of that—I think that AWS probably had this new version, probably, in the works for a while, but I think that motivated their faster release of this new version, and so IMDSv2 changed how you would obtain these credentials. So, you basically—instead of making a single GET request to this IP address, now you had to make multiple requests, they were now PUT request instead of a GET request, there was a challenge and response, there's the hop limit. So, there's all these various things that are going to make it harder and basically mitigate a lot of the different types of vulnerabilities that previously would be used in order to obtain these credentials. The problem, though, is that IMDSv1 still exists on EC2s, unless you as a customer are enforcing IMDSv2.And so, in order to do this in a large environment, it's difficult—theoretically, it's a simple thing; all you should have to do is update your SDK and now you're able to make use of the latest version. And if you're using any version of the SDK that was released in the past over two years, you already should be using IMDSv2 there, but you have to enforce it. And so that's where the problem is. And what was most problematic to me is now that I work for a company, we have run into the problem that there are some vendor solutions that we use that weren't allowing us to enforce IMDSv2 across all of our different accounts. And this is something I've heard from a number of other customers as well.And so I decided to create this list with vendors that I've had to deal with, vendors that other customers have had to deal with, in order to basically try and solve this problem once and for all. It's been multiple years now and a lot of these vendors, unfortunately, were also security vendors. And so that makes the conversation a little bit easier, to basically put them on this wall-of-shame and say, “You're a security vendor and you're not allowing your customers to enforce best practices of security.”Corey: I want to call on a couple of things around that. Originally the metadata service was used for a number of other things—still is—beyond credentials. It is not the credential service as envisioned by a lot of folks. The way that—also we'll find those credentials empty until there's an EC2 instance role, and those credentials will both be scoped what that instance does and automatically rotated in the fullness of time so they're not long-lived credentials that once you have them, they will last forever. This is, of course, a best practice and something you should be leveraging, but scope those credentials down, or you wind up with one of the ways that was chained together in the Capital One breach a few years ago.It's also worth noting that service would have been more useful earlier in time with a few functions. For example, you can use the metadata service to retrieve the instance tags about the EC2 instance. When I requested it in 2015, it was not possible. But they had released it in January of this year, 2022, long after we have all come up with workarounds for this, where we could have used that to set the hostname internally on the system, if you're looking for something basic and easy. It would have been something then you could have used to automatically self-register with DNS without having to jump through a whole bunch of hoops to do it manually.And you look at this, and it's wow, that's a whole lot of crappy tooling I can just throw into the trash heap of history you don't need anymore. But the IMSDv2, you're right, makes it a lot harder, there has to be a conversation, not just something you can sort of bankshot something off of to get access to it. And it's a terrific mitigation. What I've liked about your list of more or less shaming companies for doing this is, on the one hand, you have companies who take themselves off of the list as soon as it's up there. It's, “Oh, we love when people talk about us. Wait, what's that? They're saying something unkind? On the internet?” And they'll fix it, which honestly is better than I expected.And then every once in a while you'll see something that's horrifying of, “Oh, yeah, we're not vulnerable to that at all because we tell you to create permanent long-lived credentials, store them on disk and we'll use those instead.” And it's… that is, like, guaranteeing that no one is going to break down your door by making your walls out of tissue paper. Don't do that. Like, that has gone so far around the band that has come back around again. So, hopefully that got fixed.Scott: And I think you pointed out a couple of things I want to talk about with this is that, one, it has actually been very successful in terms of getting large vendors to make changes. Currently, of the seven vendors that have ever been listed there, are three of them have already made fixes and have been removed from the list. And the list has only been up for about a month. And so, in terms of getting enterprise solution vendors to make changes within, like, just a few weeks is very surprising to me. And these are things that people have been asking for for years now, and so it had motivated them a lot there.And the other thing that I want to point out is people have looked at the success that it's had and considered maybe we should make wall-of-shame lists, for all the things that we want. And I want to point out that there are some things about this problem, the IMDSv2 specifically, that make it work for having this wall-of-shame list like this. One of them is that not supporting or not allowing customers to enforce IMDSv2 is basically always bad. There is not a use case where you can make a claim—Corey: There is no nuance where that, in this case, is the thing to do, like having an open S3 bucket: There are use cases where that is very much something you want to do, but it's the uncommon case.Scott: Exactly. That I think is an important thing. Another thing is it's not just putting up a list, you know, like that is what people are seeing publicly, but behind the scenes, there's a lot of other things that are happening. One, I am communicating with various customers, customers that are reporting this issue to me, in order to try to better understand what's happening there, so that I can then relay that information to the company. So, I'm not just putting up the list; I'm also, behind the scenes, having conversations with these different companies to try to get timelines from them, to try to make sure that they are aware of the problem, they are aware that they're on this list, how to get off the list. So, there's that conversation happening.There's also the conversation that I'm happening with AWS in order to make various requests that AWS improve this for customers, to make this easier. And this is something that is public on that repo. I have my list of requests to AWS so that people can relay that to their own TAMs at AWS to basically say these are things we want as well. And so this includes things like, “I want an AWS account to have the ability to default to always be enforcing IMDSv2.” You know, so as an example, when you create an EC2 through the web console—which people can say, oh, you should always be using Infrastructure as Code; the reality is many folks are using the web console to create EC2s to do other changes.And when you create an EC2 in the web console, by default, it's going to allow IMDSv1 still. And so my request to AWS is, you should allow me to just default enforce IMDSv2. Also, the web console does not give you visibility into which EC2s are enforcing it and which ones are not. And also, you do not have the ability in the web console to enforce it. You cannot click on an EC2 and say, “Please enforce it now.”So, it's all these various, like, minor changes that I'm requesting AWS to do.Corey: It has to be done at instance creation time.Scott: Exactly. And so there is an API that you can make in order to change it afterwards, but that's only an API so you have to use the CLI or some other mechanism; you can't do it in the web console. But the other thing that I'm requesting AWS do is if security is a priority for AWS and they have all these other partners that are security companies, that they should be requiring their partners to also be enforcing this in their various products. So, if a partner is basically not allowing your AWS customers to enforce security best practices, then perhaps that partnership should be revoked in some way. And so that's a more aggressive thing that I'm asking AWS to do, but I think is reasonable.Corey: I'd also like them to get all of their own first-party services to support this, too.Scott: That's true as well. So, AWS is currently on the list. And so, they have one service, Data Pipelines, which if you are an AWS customer and you are using that service, you are not going to be able to enforce IMDSv2 in your environment. So, AWS themselves, unfortunately, is not allowing customers to enforce this. And then AWS themselves in their own production servers, we have seen indications that they do not enforce IMDSv2 on their own production servers.So, the best practice that they are telling customers to follow, they unfortunately are not following it themselves. And so the way in which we saw this was Orca is a security company that ended up finding this issue with AWS—and there's a lot of questions in terms of what all exactly they found—but they had this post that they called “Breaking Formation” in which they were somehow able to find—basically exploit to some degree—and again, it's unclear exactly what they were able to exploit here—but they were able to exploit AWS production servers that are responsible for the CloudFormation service. And in their blog post, they had a screenshot which showed that those production servers are not enforcing IMDSv2. And so AWS themselves is struggling with this as well, as are many customers. So, it's something that, you know, I put together this list of requests in hopes that AWS can make it easier for not only customers but also themselves to be able to enforce it.Corey: There are a lot of different things that we wish companies did differently, particularly if that company is AWS. Why is this the particular windmill that you've decided to tilt at given—let's say—it's not exactly slim pickins out there as far as changes that we wish companies would make? Obviously, you mentioned at one point, there is no drawback to enabling this, but a lot could be said for other aspects as well. Why is this one so important?Scott: So, in part, I personally have some, I guess, history with this [laugh], basically, IMDSv2, and so we can discuss this. This is back when Capital One had their breach in 2019, there was this Senator, Senator Ron Wyden, who sent this email over to AWS, to Steve Schmidt, who was the CISO at the time there and still is the CISO, and he basically—Corey: Now, he's head of security for all of Amazon.Scott: Yeah, yeah.Corey: CJ is now the AWS CISO. And he has the good sense to hide.Scott: Yeah. [laugh]. So, at the time, this Senator Ron Wyden had send over this email—and obviously it's not Senator Ron Wyden himself, you know, it's one of his, like, technical people on staff that is able to give him this information—and he sends this email to AWS saying, “Hey, this metadata service played a role in this very significant breach. Why hasn't this been fixed?” And Steve Schmidt responded, and because it's communications between a senator, I guess it has to become public.So, Steve Schmidt responds, saying that, “Hey, we never knew that this was an issue before,” is essentially what he responds with. And that irked me because I had reported this to AWS previously, as had many other people. So, there was a conference presentation by this guy Andrés Riancho at BlackHat, I believe in 2014, and he had presented previously in 2013, so it was a known issue; it had been around for a while. But I took the time to actually report it to AWS Security. So, I went through the correct channel of making sure that AWS was aware of a security concern, as a security researcher—so reporting it through that correct channel there—and provided Senator Ron Wyden with all this information.And so, then he then requested that the FTC begin a federal investigation into AWS, related to basically not following the best practices that security researchers have recommended. So, that was, kind of like, my early, I guess, involvement with this issue. So, it's something that I've been interested in for a while to make sure that this is resolved completely at some point.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of “Hello, World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free? This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: It's always fun watching where people come from, as far as the security problems that they call out. There was, I believe in the cloud security forum Slack, a thread of recently about what security issues are top-of-mind and that should be fixed as a baseline expectation. In fact, let me dig it out because that is one of those things that I think is well worth having the conversation properly on this.Good examples of risky, insecure defaults in AWS. And people are talking about IMDSv1, and they're talking about all kinds of other in-depth things, and my contribution to it was, “If I go and I spin up an AWS account, until I go out of my way, I'm operating as root in that account. That seems bad.” And a few responses to that were oh, the basically facepalming, “Oh, of course.” I wish that there were an easy way to get AWS SSO as the default because it is the right answer for so many different things. It solves so many painful problems that otherwise you're going to wind up stuck with.And this stuff is hard and confusing; when people are starting out with this for the first time, they're not approaching this from, “All right, how do I be extremely secure?” They want to get some work done. For fun a year ago, I spun up a test account—unattached to any organization—and because account aliases are globally unique, I somehow came up with the account ‘shitposting' because that's pretty much what I use it for. The actual reason I wanted that was I wanted something completely unattached from any other account that I could easily take screenshots from at any point, and the worst case scenario is okay, I've exposed some credential of my own in an account that has no privileged access to anything; I just have to apologize for all the Bitcoin mining now. And honestly, I think AWS would love that marketing campaign; they'd see my face on a billboard looking horrified. It'll be great.But I turned on every security service as I went because, of course, security is the most important thing. And there were so many to turn on, and the bill was approaching 50 bucks a month for an empty account. And it's. It starts to feel a little weird and more than a little wrong.Scott: [laugh]. Yeah, my personal concern in terms of default security features is really that problem of the cost controls, I think that that still is a big issue that AWS does not have cost controls such that when a student wants to try and use AWS for the very first time and somehow they spin up large EC2 instance, or they just you know, end up creating an access key and that access key gets leaked and somehow their account gets compromised and used for Bitcoin mining, now they're stuck with that large AWS bill. For a student who has no budget, is in debt, and now is suddenly being, you know, hit with multiple thousands of dollars on their bill, that I think is very problematic, and that is something that I wish AWS would change as a default is basically, if you are creating AWS account for the very first time, have some type of—I don't know how this would look, but maybe just be able to say, like, I don't ever want this AWS account to spend more than $100 per month, and I'm okay if you end up destroying all my data in the account because I have no money and money is more important to me than whatever data I may store in here.Corey: Make an answer to that question mandatory, just as putting a credit card in is mandatory. Because there are two extremes here. It's more or less the same problem of AWS not knowing who its customers are beyond an AWS account, but there's a spectrum somewhere between I'm a student who wants to learn how the cloud works, and my approach to security is very much the same. Don't let randos spin up resources in my account, and I don't ever want to be charged. If that means you turn off my “Hello World” blog post, okay, great.On the other end, it's this is Netflix. And this is our, you know, eight-millionth account that we're spending up to do a thing and what do you mean you're applying service quotas to it? I thought we had an understanding?—everything is a service quota, let's be clear—Scott: Yep.Corey: —or a company that's about to run a Superbowl ad. Yeah, there's going to be a lot of traffic there. Don't touch it. Just make it work. We don't care what it costs.Understanding where you fall on the cost perspective—as well as a security point of view of, “We're a bank, which means forget security best practices, we have compliance obligations that cannot be altered in this account and here's what they are.” There has to be a way that is easy and approachable for people to wind up moving that slider to whatever position best represents them. Because there are accounts where I never want to be charged a thing. And that's an important thing because—and I've been talking about this for a while because I'm convinced it's a matter of time—that poor kid who wound up trading on margin at Robinhood, woke up saw that he was seven-hundred-and-some-odd grand in debt and killed himself. When it all settled out, I think he turned something like a $30,000 profit when all was said and done, which just serves to make it worse.I can see a scenario in which that happens, and part of the contributors to it are that we used to see that the surprise bill for compromised accounts was 10, 15, 20 grand. Now, they're 70 to 90 because there are more regions, more services to run containers—because of course there are—and the payoff is such that the people exploiting this have gotten very practiced and very operationalized at spinning up those resources quickly, and they cost a lot very quickly. I mean, the third use case that they're not aiming at yet is people like me, where it's, oh, you have a free account that sandboxed; I want to get the high score on the free tier because all their fraud is attuned to you making money. With me, it's nope, just going to run up the store to embarrass Amazon. That's not a common exploit vector, but I'm very much here.Scott: [laugh]. Yep. And that also is the thing though: The Denial of Wallet attack is also a concern on AWS, as well, where you've written a blog post about this, how if you are able to make use of data transfer in different ways, you can run up very high multi-million dollar bills in people's AWS accounts and even AWS's own protections and defenses against trying to look for cost spikes and things like that is delayed by multiple hours. And so you can still end up spending a lot of money in people's accounts, or one thing that's wild is an S3 object locking; that feature, the whole purpose behind it is to ensure data can never be deleted. It exists for various compliance reasons, so even AWS themselves cannot delete certain data.So, if an attacker is able to abuse that functionality in somebody's account, they can end up locking data such that for the next 100 years, it can never be deleted and you're going to have to pay for that for the next 100 years inside your account. The only way of not paying for that anymore is to move everything that you have in an AWS account to a new account, and then ask AWS to delete that account, which is not going to be reasonable under most circumstances.Corey: Yeah, alternatively, it's one of those scenarios where well, the only other option is to start physically ripping hard drives out of racks in a bunch of different data centers. It's wild to me. It's such an attack surface that honestly I believe for the longest time that AWS Security is otherworldly good. And as we start seeing from these breaches, no, what really is otherworldly good is their ability to apply pressure to people not to go public with things they discover that they then wind up keeping quiet because once this whole Orca stuff came out, we started digging, and Aidan Steele found some stuff where you could just get unfiltered, raw outputs of CloudTrail events by setting up a couple of rules in weird ways.And that was a giant problem, and it was never disclosed publicly. I don't know if any of my events were impacted; I can't trust that they would have told me if they were. And for the first time, I'm looking at things like confidential computing, which are designed around well, what if you don't trust your cloud provider? Historically, I guess I was naive because my approach was, “Well, then you shouldn't be using the cloud.” Now it's, “Well, that's actually kind of a good point.”Because it's not that I don't trust my cloud provider to necessarily do what they're telling me. I just don't trust them to tell me what they're doing. And that's part of it. The, “Well, we found an issue, but you can't prove we had an issue, so we're going to say nothing.” And when it comes to light—because it always does—it erodes trust in a big way. And trust is everything in cloud.Scott: Yeah. And so with some of the breaches that have come out, I created another GitHub repo to start tracking all the different security incidents that I could find for the three cloud providers, Azure, GCP, and AWS. And so on there, I started listing not only some of the blog posts from security companies that had been able to exploit vulnerabilities in the cloud providers, but also just anything else that I felt was a security mistake in some way. And so there's a number of things I tried to avoid on there. Like, I tried to avoid listing something that's kind of like a business decision, for example, services that get released that don't have CloudTrail support. That's a security concern to me, but that's kind of a business decision that they decided to release a service before it supported all that functionality.So, I tried to start listing off all those different things in order to also keep track of you know, is there a security provider that's worse than the others? Are there any type of common patterns that I can see? And so I tried to look through some of those different things. And that's been interesting because also I really only focus on AWS, and so I haven't really known what all has been happening with GCP and Azure. And that was interesting because there's been two issues that have happened on AWS where the exact same issue happened on the other cloud providers. And so that tells me, that's concerning to me because that tells me tht—Corey: Because those are not discovered at the same time let's be clear.Scott: Yeah. These were, like, over a year apart. And so basically, somebody had found something on GCP, and then a year-plus later, somebody else found the exact same issue on AWS. And then similarly, there was an issue with Azure and then a year-plus later, same issue on AWS. And that's concerning because that tells me that AWS may not be monitoring what are the security issues that are impacting other cloud providers, and therefore checking whether or not they happen to themselves?That's something that you would expect a mature security team to be doing is to be monitoring what are public incidents that are happening to my competitors, and am I impacted similarly? Or what can I do to try and identify those issues, fix them, make sure they never happen? All those types of steps in terms of security maturity. And that's something that then I'm a little concerned of that we've seen those issues happen before. There's also, on AWS specifically, they have had a number of issues related to their IAM-managed policies that keep cropping up.And so they have had a number of incidents where they were releasing policies that shouldn't have been released in some way. And that's concerning that showed that they don't really have a change management process that you would expect. Usually, you would expect a company to be having GitHub PRs and approval processes and things like that, in order to make sure that there's a second set of eyes on something before it gets released.Corey: Particularly things of this level of sensitivity. This is not—like, I was making fun of them a day or two ago for having broken the copyright footer and not updating them since 2020 because instead of the ‘copyright' symbol, they used an ‘at' symbol. Minor stuff, but like that's fun to needle people about, but it doesn't actually matter for anything.Scott: Yeah.Corey: Security matters and mistakes show.Scott: Yeah. And so there had been some examples where they released a policy that was called, like, ‘cheese puffs something' and it's like, okay, that's clearly, like, an internal service of some sort. But I'd called them out and, like, I'd sent an email to AWS Security being like, “Hey, you need to make sure that you have change management processes on your IAM policies because one day you're going to do something that is bad.” And one day they did. They made a change to the read-only access policy, and that basically—they removed every single privilege, somebody had ended up, you know, internally, removed every single privileges to the read-only access policy and replaced it with a whole bunch of write privileges for, I think, the Cassandra service.And so, that was like, clearly they've made a mistake that they should have made sure they were correcting because you know, they had these previous incidents. Another kind of similar one was in December, there was a support policy where they had added S3 GetObject to that policy, and that was concerning in terms of have they just given all of their support employees access to everybody's content in their S3 buckets? And so AWS made some statements saying that there were other controls in place there so it wouldn't have been possible. But it's those types of things that [crosstalk 00:33:17]—Corey: Originally, those statements were made on Twitter, let's be clear here.Scott: Yes. Yeah. [laugh].Corey: And I feel like there's a—while I deeply appreciate how accessible a lot of their senior people are, I cannot point the executive leadership team at a client to some tweets that someone made. That is not a public statement of record that works on this.Scott: Exactly.Corey: They're learning. We'll get there sooner or later, I presume. I want to thank you for taking the time to speak with me, as always, I'll throw links to these repos into the [show notes 00:33:46], but if they want to know more what you have to say, where's the best place to find you?Scott: So, my Twitter, which, unfortunately, is a handle written in hex, but it's—‘dabbadoo' is how you would pronounce it, but it's probably easiest to see a link for it. So, that's probably the main place to look for me.Corey: That's why my old Twitter handle was my amateur radio callsign. I don't use that one anymore. It's just easier. And I think that's the right answer. Besides, given what you do, it's easy enough if people want your attention. They screw up badly enough, you'll come to them.Scott: Yep. [laugh].Corey: Scott, I really appreciate your time. Thanks again.Scott: Thank you.Corey: Scott Piper, Principal Engineer at Block and, more or less, roving security troubadour for lack of a better term. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice or a comment on the YouTubes saying that this episode is completely invalid because you wind up using the old version of the metadata service and you've never had a problem. That you know of.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.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/ubiquiti-teaches-aws-security-and-crisis-comms-via-counterexampleNever miss an episode Join the Last Week in AWS newsletter Subscribe wherever you get your podcasts Help the show Leave a review Share your feedback Subscribe wherever you get your podcasts What's Corey up to? Follow Corey on Twitter (@quinnypig) See our recent work at the Duckbill Group Apply to work with Corey and the Duckbill Group to help lower your AWS bill

Links: Links Referenced: Couchbase Capella: https://couchbase.com/screaminginthecloud couchbase.com/screaminginthecloud: https://couchbase.com/screaminginthecloud blog post: https://awsteele.com/blog/2022/02/03/aws-vpc-data-exfiltration-using-codebuild.html AutoWarp: https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/ “Google Announces Intent to Acquire Mandiant”: https://www.googlecloudpresscorner.com/2022-03-08-mgc password table: https://www.hivesystems.io/blog/are-your-passwords-in-the-green New Relic: http://newrelic.com newrelic.com/morningbrief: http://newrelic.com/morningbrief newrelic.com/morningbrief: http://newrelic.com/morningbrief DirtyPipe: https://www.theregister.com/2022/03/08/in_brief_security/ “Manage AWS resources in your Slack channels with AWS Chatbot”: https://aws.amazon.com/blogs/mt/manage-aws-resources-in-your-slack-channels-with-aws-chatbot/ “How to set up federated single-sign-on to AWS using Google Workspace”: https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-workspace/ Cloudsaga: https://github.com/awslabs/aws-cloudsaga lastweekinaws.com: https://lastweekinaws.com 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: Couchbase Capella Database-as-a-Service is flexible, full-featured, and fully managed with built-in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: Make your data sing.Hello and welcome to Last Week in AWS Security. A lot has happened; let's tear into it.So, there was a “Sort of yes, sort of no” security issue with CodeBuild that I've talked about previously. The blog post I referenced has, in fact, been updated. AWS has stated that, “We have updated the CodeBuild service to block all outbound network access for newly created CodeBuild projects which contain a customer-defined VPC configuration,” which indeed closes the gap. I love happy endings.On the other side, oof. Orca Security found a particularly nasty Azure breach called AutoWarp. You effectively could get credentials for other tenants by simply asking a high port on localhost for them via curl or netcat. This is bad enough; I'm dreading the AWS equivalent breach in another four months of them stonewalling a security researcher if the previous round of their nonsense silence about security patterns is any indicator.“Google Announces Intent to Acquire Mandiant”. This is a big deal. Mandiant has been a notable center of excellent cybersecurity talent for a long time. Congratulations or condolences to any Mandoogles in the audience. Please let me know how the transition goes for you.Hive Systems has updated its password table for 2022, which is just a graphic that shows how long passwords of various levels of length and complexity would take to break on modern systems. The takeaway here is to use long passwords and use a password manager.Corey: You know the drill: You're just barely falling asleep and you're jolted awake by an emergency page. That's right, it's your night on call, and this is the bad kind of Call of Duty. The good news is, is that you've got New Relic, so you can quickly run down the incident checklist and find the problem. You have an errors inbox that tells you that Lambdas are good, RUM is good, but something's up in APM. So, you click the error and find the deployment marker where it all began. Dig deeper, there's another set of errors. What is it? Of course, it's Kubernetes, starting after an update. You ask that team to roll back and bam, problem solved. That's the value of combining 16 different monitoring products into a single platform: You can pinpoint issues down to the line of code quickly. That's why the Dev and Ops teams at DoorDash, GitHub, Epic Games, and more than 14,000 other companies use New Relic. The next late-night call is just waiting to happen, so get New Relic before it starts. And you can get access to the whole New Relic platform at 100 gigabytes of data free, forever, with no credit card. Visit newrelic.com/morningbrief that's newrelic.com/morningbrief.And of course, another week, another terrifying security concern. This one is called DirtyPipe. It's in the Linux kernel, and the name is evocative of something you'd expect to see demoed onstage at re:Invent.Now, what did AWS have to say? Two things. The first is “Manage AWS resources in your Slack channels with AWS Chatbot”. A helpful reminder that it's important to restrict access to your AWS production environment down to just the folks at your company who need access to it. Oh, and to whomever can access your Slack workspace who works over at Slack, apparently. We don't talk about that one very much, now do we?And the second was, “How to set up federated single-sign-on to AWS using Google Workspace”. This is super-aligned with what I want to do, but something about the way that it's described makes it sounds mind-numbingly complicated. This isn't a problem that's specific to this post or even to AWS; it's industry-wide when it comes to SSO. I'm starting to think that maybe I'm the problem here.And lastly, AWS has open-sourced a tool called Cloudsaga, designed to simulate security events in AWS. This may be better known as, “Testing out your security software,” and with sufficiently poor communication, “Giving your CISO a heart attack.”And that's what happened last week in AWS security. If you've enjoyed it, please tell your friends about this place. I'll talk to you next week.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links: “Developer Experience is Security”: https://redmonk.com/rstephens/2022/02/17/devex-is-security/ Cleansing their network of ransomware: https://www.espn.com/nfl/story/_/id/33283115/san-francisco-49ers-network-hit-gang-ransomware-attack-team-notifies-law-enforcement “Control access to Amazon Elastic Container Service resources by using ABAC policies”: https://aws.amazon.com/blogs/security/control-access-to-amazon-elastic-container-service-resources-by-using-abac-policies/ “Introducing s2n-quic—‘sin-i-quick?' ‘sin-two-quick?' Yeah—a new open-source QUIC protocol implementation in Rust”: https://aws.amazon.com/blogs/security/introducing-s2n-quic-open-source-protocol-rust/ “Top 2021 AWS Security service launches security professionals should review–Part 1”: https://aws.amazon.com/blogs/security/top-2021-aws-security-service-launches-part-1/ Ghostbuster: https://blog.assetnote.io/2022/02/13/dangling-eips/ 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 our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: Somehow a week without an S3 Bucket Negligence Award to pass out for anyone. I really hope I'm not tempting fate by pointing that out, but good work, everyone.So, from the community. Redmonk's Rachel Stephens once again hits the nail on the head with her post, “Developer Experience is Security”. I don't believe it's a coincidence that for a while now I've thought that Google Cloud offers not only the best developer experience of the hyperscale clouds but also the best security. I didn't come to that conclusion lightly.Also, now that the professional football season is over, the San Francisco 49ers eagerly turn to their off-season task of cleansing their network of ransomware. Ouch. Not generally a great thing when you find that your organization has been compromised and you can't access any of your data.Now, AWS had a couple of interesting things out there. “Control access to Amazon Elastic Container Service resources by using ABAC policies”. I was honestly expecting there to be a lot more stories by now of improper tagging being used to gain access via ABAC. The problem here is that for the longest time tagging was at best a billing metadata construct; it made sense to have everything be able to tag itself. Suddenly, with the advent of attribute-based access control, anything that can tag resources now becomes a security challenge.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.“Introducing s2n-quic—‘sin-i-quick?' ‘sin-two-quick?' Yeah—a new open-source QUIC protocol implementation in Rust”. Now, with a name like that, you know it came out of AWS. This is a bit in the weeds for most of us, but the overall lesson to take from the release-slash-announcement is, “Don't roll your own cryptographic implementation,” with the obvious exception case of, “Unless you are AWS.”“Top 2021 AWS Security service launches security professionals should review–Part 1”. Okay, this summary post highlights an issue with how AWS talks about things. Some of these enhancements are helpful, some are not, but every last one of them are features to an existing service. Sometimes those refinements are helpful, other times they simply add unneeded complexity to a given customer's use case. This feels a lot more like a comprehensive listing than it does a curated selection, but maybe that's just me.And lastly, I stumbled over a tool called Ghostbuster which is surprisingly easy to use. It scans your DNS records and finds dangling Elastic IPs that can be misused for a variety of different purposes, none of which are going to benefit you directly. It's been a while since I found a new tool that I was this happy with how straightforward and simple it was to use. Good work. And that's what happened last week in AWS security. I'm Corey Quinn. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links Referenced: CanaryTokens: https://www.canarytokens.org/ Found a solid way to avoid that sneaky method: https://blog.thinkst.com/2022/02/a-safety-net-for-aws-canarytokens.html?m=1 The folks at Orca found a vulnerability around OCI's handling of Server Side Request Forgery (SSRF) Metadata: https://orca.security/resources/blog/Oracle-server-side-request-forgery-ssrf-attack-metadata/ S3 Bucket Negligence Award: https://techcrunch.com/2022/02/08/ottawa-trucker-freedom-convoy-exposed-donation/ Only 22% of enterprise customers: https://therecord.media/microsoft-says-mfa-adoption-remains-low-only-22-among-enterprise-customers/ Modified their hypervisor: https://www.bleepingcomputer.com/news/security/google-cloud-hypervisor-modified-to-detect-cryptominers-without-agents/ Amazon CloudTrail: https://aws.amazon.com/cloudtrail/ Amazon API Gateway CORS Configurator: https://cors.serverlessland.com/ 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 our friends at Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: So, last week was fairly tame and—no. I'm not going to say that because the last time I said that, all hell broke loose with Log4J and I can't go through that again.So, let's see what happened last week in AWS Security. I like this one very much. Thinkst Canary provides, for free via CanaryTokens.org, an AWS credential generator that spits out IAM credentials with no permissions. The single thing they do is scream bloody murder if someone attempts to use them because those credentials have been stolen. There are some sneaky ways to avoid having the testing of those tokens show up in CloudTrail logs, but they've just found a solid way to avoid that sneaky method. It's worth digging into.I've been a fan of Oracle Cloud for a while, which has attracted some small amount of controversy. I stand by my opinion. That said, there's been some debate over whether they're a viable cloud provider at scale. There are certain things I look for as indicators that a cloud provider is a serious contender, and one of them has just been reached: the folks at Orca found a vulnerability around OCI's handling of Server Side Request Forgery (SSRF) Metadata. It sounds like I'm kidding here, but I'm not. When third-party researchers find a vulnerability that is non-obvious to most of us, that's an indication that real companies are using services built on top of the platform. Onward.A donation site raising funds for the Ottawa truckers' convoy nonsense that's been going on scored itself an S3 Bucket Negligence Award. No matter how much I may dislike an organization or its policies, I maintain that cybersecurity needs to be available to all.Corey: You know the drill: you're just barely falling asleep and you're jolted awake by an emergency page. That's right, it's your night on call, and this is the bad kind of Call of Duty. The good news is, is that you've got New Relic, so you can quickly run down the incident checklist and find the problem. You have an errors inbox that tells you that Lambdas are good, RUM is good, but something's up in APM. So, you click the error and find the deployment marker where it all began. Dig deeper, there's another set of errors. What is it? Of course, it's Kubernetes, starting after an update. You ask that team to roll back and bam, problem solved. That's the value of combining 16 different monitoring products into a single platform: you can pinpoint issues down to the line of code quickly. That's why the Dev and Ops teams at DoorDash, GitHub, Epic Games, and more than 14,000 other companies use New Relic. The next late-night call is just waiting to happen, so get New Relic before it starts. And you can get access to the whole New Relic platform at 100 gigabytes of data free, forever, with no credit card. Visit newrelic.com/morningbrief that's newrelic.com/morningbrief.I knew MFA adoption was struggling among consumers, but I was stunned by Microsoft's statement that only 22% of enterprise customers have adopted an additional security factor. Please, if you haven't enabled MFA in your important accounts—and yes, your cloud provider is one of those—please go ahead and do it now.An interesting security advancement over in the land of Google Cloud, they've modified their hypervisor to detect cryptocurrency mining without needing an agent inside of the VM. This beats my usual method of ‘looking for instances with lots of CPU usage because most of the time the fleet is bored.'Over in AWS-land, they didn't have anything particularly noteworthy that came out last week for security, so I want to talk a little bit about a service that gets too little love: Amazon CloudTrail. Think of this as an audit log for all of the management events that happen in your AWS account. You're going to want to secure where the logs live, ideally in another account for your AWS organization. To AWS's credit, they made the first management trail free a few years ago and enabled it across all accounts by default as a result. This is going to help someone out there, I suspect. Remember, if you haven't heard about it before, it's new to you.And I found a fun tool that's just transformative because if the bully who beat you up and stole your lunch money in middle school were a technology, they would undoubtedly be CORS, or ‘Cross-Origin Resource Sharing.' The Amazon API Gateway CORS Configurator tool helps you make it work with API Gateway, and I love this so much. And that's what happened last week in AWS security. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Stephen Kuenzli and I lead several cloud migration projects. In this conversation, we shared our learnings focusing on AWS security and IAM (Identity and Access Management). The result is advice and inspiration that will help you in your daily work. Our conversation is available as a video or podcast episode. In the following, you will also find a summary of our discussion.

This week, we're continuing our series looking at each of the pillars of the well architected framework. We talked about the operational excellence pillar in the last episode. We're going to talk about security this time which is our favourite well architected pillar. There are 10 questions for this pillar and a couple of different sections. The well architected security pillar is aimed at checking how secure your organisation is. It goes into things like: How are you managing accounts?  Is your control tower hooked up? Are you using guard duty? It promotes team awareness of security across the organisation. The types of things to engage with when looking at workload are blast radius: If something goes down, how are we going to recover it? Or is there a case there for failover? Or resiliency? It is broad but there are things you can zoom in and focus on in that question. With the modern techniques, capabilities and improvements, you can be fine grained and have more accounts. Single sign also helps manage that burden. And AWS organisations, control tower and cloud trail are mature capabilities that help you get a good initial posture. One thing about well architected is that there is a nice flow to the questions and sessions. The first question: 'how do you securely operate your workload?', straight away gets into identity and access management, your inventory of people on machines and how you manage that. Or how do you manage blast radius, permissions, and the process of adding and removing people, accounts, machine accounts and different resources. In a modern cloud environment, rule number one is that it is tightly managed and automated. Normally, it ties back into the enterprise or a broader policy and it gets teams asking what are the authorization controls for this component. The Least Privilege principle comes to the fore especially for serverless workloads. As you ephemerally spin stuff up and down, you can be tempted to give star-star to everything and open up the world meaning your blast radius is massive and you've got a big security hole. So you need to be aware of the Least Privilege principle and give it the minimal amount to be functional. You have got to automate that and build it as part of your automation. Otherwise it becomes unmanageable burden and an ephemeral sort of workspace. The next is one of my favourite: detective controls, how you detect and control security events. I always love the way security people talk about 'left of attack': all the things that happen before the attack. There is the time when the attack happens and that's panic stations. But there's usually a whole bunch of stuff before that, that you can act on. And that could be two years prior. So there's a whole mindset around detecting weird activity when people are probing your system, before the actual attack. That's the hunter side of cybersecurity when people try to find breaches. It's about keeping abreast of latest developments and responding to new emerging threat vectors, like 'Log4j'. How do you respond to that new information to the left of your detection? Do you have the right logging, monitoring, alerting and alarming for rapidly detecting and remediating these events? The next one is data protection. There's stuff here about both encryption etc, in rest and in transition. We have mentioned that code as a liability. Your data can also be a liability that you need to manage appropriately. Organisations have a good data classification document or something that describes data classification as it pertains to the industry or the organisation. I think the challenge you've got is getting engineering teams to understand it. Previously we've woven in data classification into the threat model exercise so the first section is what sort of data are we dealing with. The last section is 'incident response'. It's fairly self explanatory. How do you respond and recover from incidents? You want to be well drilled with as much automation as possible. Sounds straightforward. But it's complicated. It ties back to the operational excellence pillar. You're anticipating these events ahead of time. If you're anticipating them, you have associated runbooks or playbooks to facilitate squads in particular circumstances.  So there's a lot around education as well and making sure that everybody in the organisation understands what you do in the event of an incident. You don't want a junior developer noticing something, and not feeling confident or capable to raise their hand and say something is not right here. You want a psychologically safe environment for everybody to raise an incident or a query something that's not quite right. In the security pillar, there's a nice arc that starts with people and ends with people. It goes through all the technical stuff in the middle. But security is a 'people' responsibility. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

Links: S3 Bucket Negligence Award: http://saharareporters.com/2022/01/10/exclusive-hacker-breaks-nimc-server-steals-over-three-million-national-identity-numbers Anyone in a VPC, any VPC, anywhere: https://Twitter.com/santosh_ankr/status/1481387630973493251 A disgruntled developer corrupts their own NPM libs ‘colors' and ‘faker', breaking thousands of apps: https://www.bleepingcomputer.com/news/security/dev-corrupts-npm-libs-colors-and-faker-breaking-thousands-of-apps/ “Top ten security best practices for securing backups in AWS”: https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/ Glue: https://aws.amazon.com/security/security-bulletins/AWS-2022-002/ CloudFormation: https://aws.amazon.com/security/security-bulletins/AWS-2022-001/ S3-credentials: https://simonwillison.net/2022/Jan/18/weeknotes/ 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 my friends at Thinkst Canary. Most companies find out way too late that they've been breached. Thinkst Canary changes this and I love how they do it. Deploy canaries and canary tokens in minutes, and then forget about them. What's great is then attackers tip their hand by touching them, giving you one alert, when it matters. I use it myself and I only remember this when I get the weekly update with a, “We're still here, so you're aware,” from them. It's glorious. There is zero admin overhead to this, there are effectively no false positives unless I do something foolish. Canaries are deployed and loved on all seven continents. You can check out what people are saying atcanary.love. And, their Kube config canary token is new and completely free as well. You can do an awful lot without paying them a dime, which is one of the things I love about them. It is useful stuff and not a, “Oh, I wish I had money.” It is spectacular. Take a look. That'scanary.love because it's genuinely rare to find a security product that people talk about in terms of love. It really is a neat thing to see.Canary.love. Thank you to Thinkst Canary for their support of my ridiculous, ridiculous nonsense.Corey: So, yesterday's episode put the boots to AWS, not so much for the issues that Orca Security uncovered, but rather for its poor communication around the topic. Now that that's done, let's look at the more mundane news from last week's cloud world. Every day is a new page around here, full of opportunity and possibility in equal measure.This week's S3 Bucket Negligence Award goes to the Nigerian government for exposing millions of their citizens to a third party who most assuredly did not follow coordinated disclosure guidelines. Whoops.There's an interesting tweet, and exploring it is still unfolding at time of this writing, but it looks that making an API Gateway ‘Private' doesn't mean, “To your VPCs,” but rather, “To anyone in a VPC, any VPC, anywhere.” This is evocative of the way that, “Any Authenticated AWS User,” for S3 buckets caused massive permissions issues industry-wide.And a periodic and growing concern is one of software supply chain—which is a fancy way of saying, “We're all built on giant dependency chains”—what happens when, say, a disgruntled developer corrupts their own NPM libs ‘colors' and ‘faker', breaking thousands of apps across the industry, including some of the AWS SDKs? How do we manage that risk? How do we keep developers gruntled?Corey: Are you building cloud applications with a distributed team? Check out Teleport, an open-source identity-aware access proxy for cloud resources. Teleport provides secure access for anything running somewhere behind NAT: SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers.Get access to everything via single sign-on with multi-factor, list and see all of SSH servers, Kubernetes clusters, or databases available to you in one place, and get instant access to them using tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport is open-source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com.AWS had a couple of interesting things. The first is “Top ten security best practices for securing backups in AWS”. People really don't consider the security implications of their backups anywhere near seriously enough. It's not ‘live' but it's still got—by definition—a full set of your data just waiting to be harvested by nefarious types. Be careful with that.And of course, AWS had two security bulletins, one about its Glue issues, one about its CloudFormation issues. The former allowed cross-account access to other tenants. In theory. In practice, AWS did the responsible thing and kept every access event logged, going back for the full five years of the service's life. That's remarkably impressive.And lastly, I found an interesting tool called S3-credentials last week, and what it does is it helps generate tightly-scoped IAM policies that were previously limited to a single S3 bucket, but now are limited to a single prefix within that bucket. You can also make those credential sets incredibly short-lived. More things like this, please. I just tend to over-scope things way too much. And that's what happened Last Week in AWS: Security. Please feel free to reach out and tell me exactly what my problem is.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links: Comes with a cryptominer: https://krebsonsecurity.com/2022/01/norton-360-now-comes-with-a-cryptominer/ You could be federally charged with wire fraud for paying off a security researcher: https://www.justice.gov/usao-ndca/pr/former-uber-chief-security-officer-face-wire-fraud-charges-0 A source code leak of its Azure App Service: https://www.theregister.com/2021/12/24/azure_app_service_not_legit_source_code_leak/ “Comprehensive Cyber Security Framework for Primary (Urban) Cooperative Banks (UCBs)”: https://aws.amazon.com/blogs/security/comprehensive-cyber-security-framework-for-primary-urban-cooperative-banks/ “Disabling Security Hub controls in a multi account environment”: https://aws.amazon.com/blogs/security/disabling-security-hub-controls-in-a-multi-account-environment/ Ipv6-ghost-ship: https://github.com/aidansteele/ipv6-ghost-ship 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.This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So, the idea being that you can run stateless things without having to worry about scaling, placement, et cetera, and the rest. They claim significant cost savings, and they're able to wind up taking what you're running as it is in AWS with no changes, and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them, so that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem and they get out there in public and say, “We're solving a problem,” it's very hard to snark about that. Multus Medical, Construx.ai and Stax have seen significant results by using them. And it's worth exploring. So, if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or batch, consider checking them out. Visit risingcloud.com/benefits. That's risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.Welcome to Last Week in AWS: Security. Let's dive in. Norton 360—which sounds like a prelude to an incredibly dorky attempt at the moonwalk—now comes with a cryptominer. You know, the thing that use tools like this to avoid having on your computer? This is apparently to offset how zippy modern computers have gotten, in a direct affront to Norton's ability to make even maxed-out laptops run like total garbage. Speaking of total garbage, you almost certainly want to use literally any other vendor for this stuff now.“What's the worst that can happen?” Is sometimes a comforting thought when dealing with professional challenges. If you're the former Uber CISO, the answer to that question is apparently, “you could be federally charged with wire fraud for paying off a security researcher.”And lastly, Azure continues to have security woes, this time in the form of a source code leak of its Azure App Service. It's a bad six months and counting to be over in Microsoft-land when it comes to cloud.Let's take a look what AWS has done. “Comprehensive Cyber Security Framework for Primary (Urban) Cooperative Banks (UCBs)”. This is a perfect case study in what's wrong with the way we talk about security. First, clicking the link to the report in the blog post threw an error; I had to navigate to the AWS Artifact console and download the PDF manually. Then, the PDF is all of two pages long, as it apparently has an embedded Excel document within it that Preview on my Mac can't detect. The proper next step is to download Adobe Acrobat for Mac in order to read this, but I've given up by this point. This may be the most remarkable case of AWS truly understanding its customer mentality that we've seen so far this year.Are you building cloud applications with a distributed team? Check out Teleport, an open-source identity-aware access proxy for cloud resources. Teleport provides secure access for anything running somewhere behind NAT: SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers. Get access to everything via single sign-on with multi-factor, list and see all of SSH servers, Kubernetes clusters, or databases available to you in one place, and get instant access to them using tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport is open-source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com.“Disabling Security Hub controls in a multi account environment”. I hate that this is a solution instead of a native feature, but it's important. There are some Security Hub controls that are just nonsense. “Oh no, you didn't encrypt your EBS volumes.” “Oh dear, you haven't rotated your IAM credentials in 90 days.” “Holy CRAP, the S3 bucket serving static assets to the world is world-readable.” You get the picture.And a tool I found fun, “Port Knocking” is an old security technique in which you attempt to connect to a host on a predetermined sequence of ports. Get it right and you're now able to connect to the host in question on the port that you want. ipv6-ghost-ship has done something similar yet ever more ridiculous: It takes advantage of the fact that IPv6 means that each EC2 instance gets 281 trillion IP addresses to only accept SSH connections when the last three octets of the IP address on the instance match the time-based authentication code. This is a ridiculous hack, and I love it oh so very much. I'm Chief Cloud Economist at The Duckbill Group, and this has been Last Week in AWS: Security. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links: “Tokyo police lose 2 floppy disks containing personal info on 38 public housing applicants”: https://mainichi.jp/english/articles/20211227/p2a/00m/0na/072000c LastPass may have suffered a breach: https://news.ycombinator.com/item?id=29705957 “Worst AWS Data Breaches of 2021”: https://securityboulevard.com/2021/12/worst-aws-data-breaches-of-2021/ D.W. Morgan: https://www.hackread.com/logistics-giant-d-w-morgan-exposed-clients-data/ SEGA Europe: https://vpnoverview.com/news/sega-europe-suffers-major-security-breach/ “Identity Guide–Preventive controls with AWS Identity–SCPs”: https://aws.amazon.com/blogs/mt/identity-guide-preventive-controls-with-aws-identity-scps/ Log4j scanner: https://github.com/google/log4jscanner 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 LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: The first security round-up of the year in Last Week in AWS: Security. This is relatively light, just because it covers the last week of the year, where people didn't really “Work” so much as “Get into fights on Twitter.” Onward.So, from the community, ever see a data breach announcement that raises oh so very many more questions than it answers? I swear this headline is from a week or so ago, not 1998: “Tokyo police lose 2 floppy disks containing personal info on 38 public housing applicants”. Yes, I said floppy disks.The terrible orange website, also known as Hacker News, reports that LastPass may have suffered a breach. At the time I write this, the official LastPass blog has a, “No, it's just people reusing passwords.” Enough people I trust have seen this behavior that I'd be astounded if that were true. If you can't trust your password manager, ditch them immediately.Security Boulevard had a roundup of the “Worst AWS Data Breaches of 2021”, and it's the usual run-of-the-mill S3 bucket problems, but my personal favorite's the Twitch breach because it's particularly embarrassing, given that it is, in fact, an Amazon subsidiary.First one goes to D.W. Morgan by leaking 100GB of client data. And they're a logistics company that serves giant enterprises, so these are companies with zero sense of humor, so I would not want to be in D.W. Morgan's position this week.And the other is a little funnier. It goes to SEGA Europe, after Sonic the Hedgehog forgets to perform due diligence on his AWS environment.Corey: Are you building cloud applications with a distributed team? Check out Teleport, an open-source identity-aware access proxy for cloud resources. Teleport provides secure access for anything running somewhere behind NAT: SSH servers, Kubernetes clusters, internal web apps, and databases. Teleport gives engineers superpowers. Get access to everything via single sign-on with multi-factor, list and see all of SSH servers, Kubernetes clusters, or databases available to you in one place, and get instant access to them using tools you already have. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. And best of all, Teleport is open-source and a pleasure to use. Download Teleport at goteleport.com. That's goteleport.com.AWS had only a single thing that I found interesting: “Identity Guide–Preventive controls with AWS Identity–SCPs”. I've been waiting for a while for a good explainer on SCPs to come out for a while, and this looks like it actually is a thing that I want. I've been playing around with SCPs a lot more for the past couple of weeks. If you're unfamiliar, it's a way to override what the root user can do in an organization's member accounts. It's super handy to constrain people from doing things that are otherwise foolhardy.And lastly, an interesting tool came out from Google—which I should not have to explain what that is to you folks; they turn things off, like Reader—they also released a log4j scanner. This one scans files on disk to detect the bad versions of log4j—which is most of them—and can replace them with the good version—which is, of course, print statements. And that's what happened last week in AWS security. Hopefully next week will be… well, I don't want to say less contentful, but I do want to say it's at least not as exciting as the last month has been. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links: The internet is now on fire:https://www.engadget.com/log4shell-vulnerability-log4j-155543990.html Blog post:https://blog.cloudflare.com/exploitation-of-cve-2021-44228-before-public-disclosure-and-evolution-of-waf-evasion-patterns/ Expecting to be down for weeks:https://www.darkreading.com/attacks-breaches/kronos-suffers-ransomware-attack-expects-full-restoration-to-take-weeks- Update for the Apache Log4j2 Issue:https://aws.amazon.com/security/security-bulletins/AWS-2021-006/ Log4Shell Vulnerability Tester at log4shell.huntress.com:https://log4shell.huntress.com/ 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: It seems like there is a new security breach every day. Are you confident that an old SSH key or a shared admin account isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open-source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more, visit goteleport.com. And no, that's not me telling you to go away; it is, goteleport.com.Corey: I think I owe the entire internet a massive apology. See, last week I titled the episode, “A Somehow Quiet Security Week.” This is the equivalent of climbing to the top of a mountain peak during a violent thunderstorm, then waving around a long metal rod. While cursing God.So, long story short, the internet is now on fire due to a vulnerability in the log4j open-source logging library. Effectively, if you can get an arbitrary string into the logs of a system that uses a vulnerable version of the log4j library, it will make outbound network requests. It can potentially run arbitrary code.The impact is massive and this one's going to be with us for years. WAF is a partial solution, but the only real answer is to patch to an updated version, or change a bunch of config options, or disallow affected systems from making outbound connections. Further, due to how thoroughly embedded in basically everything it is—like S3; more on that in a bit—a whole raft of software you run may very well be using this without your knowledge. This is, to be clear, freaking wild. I am deeply sorry for taunting fate last week. The rest of this issue of course talks entirely about this one enormous concern.Corey: This episode is sponsored in part by my friends at Cloud Academy. Something special for you folks: if you missed their offer on Black Friday or Cyber Monday or whatever day of the week doing sales it is, good news, they've opened up their Black Friday promotion for a very limited time. Same deal: $100 off a yearly plan, 249 bucks a year for the highest quality cloud and tech skills content. Nobody else is going to get this, and you have to act now because they have assured me this is not going to last for much longer. Go to cloudacademy.com, hit the ‘Start Free Trial' button on the homepage and use the promo code, ‘CLOUD' when checking out. That's C-L-O-U-D. Like loud—what I am—with a C in front of it. They've got a free trial, too, so you'll get seven days to try it out to make sure it really is a good fit. You've got nothing to lose except your ignorance about cloud. My thanks to Cloud Academy once again for sponsoring my ridiculous nonsense.Cloudflare has a blog post talking about the timeline of what they see as a global observer of exploitation attempts of this nonsense. They're automatically shooting it down for all of their customers and users—to be clear, if you're not paying for a service you are not its customer, you're a marketing expense—and they're doing this as part of the standard service they provide. Meanwhile AWS's WAF has added the ruleset to its AWSManagedRulesKnownBadInputsRuleSet—all one word—managed rules—wait a minute; they named it that? Oh, AWS. You sad, ridiculous service-naming cloud. But yeah, you have to enable AWS WAF, for which there is effectively no free tier, and configure this rule to get its protection, as I read AWS's original update. I'm sometimes asked why I use CloudFlare as my CDN instead of AWS's offerings. Well, now you know.Also, Kronos, an HR services firm, won the ransomware timing lottery. They're expecting to be down for weeks, but due to the log4shell—which is what they're calling this exploit: The log4shell problem—absolutely nobody is paying attention to companies that are having ransomware problems or data breaches. Good job, Kronos.Now, what did AWS have to say? Well, they have an ongoing “Update for the Apache Log4j2 Issue” and they've been updating it as they go. But at the time of this recording, AWS is a Java shop, to my understanding.That means that basically everything internet-facing at AWS—which is, you know, more or less everything they sell—has some risk exposure to this vulnerability. And AWS has moved with a speed that can only be described as astonishing, and mitigated this on their managed services in a timeline I wouldn't have previously believed possible given the scope and scale here. This is the best possible argument to make for using higher-level managed services instead of building your own things on top of EC2. I just hope they're classy enough not to use that as a marketing talking point.And for the tool of the week, the Log4Shell Vulnerability Tester at log4shell.huntress.com automatically generates a string and then lets you know when that is exploited by this vulnerability what systems are connecting to is. Don't misuse it obviously, but it's great for validating whether a certain code path in your environment is vulnerable. And that's what happened last week in AWS Security, and I just want to say again how deeply, deeply sorry I am for taunting fate and making everyone's year suck. I'll talk to you next week, if I live.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links $1.3 billion in funding: https://www.reuters.com/technology/cloud-security-startup-lacework-valued-83-bln-after-mammoth-funding-round-2021-11-18/ NSA and CISA: https://www.csoonline.com/article/3640576/6-key-points-of-the-new-cisansa-5g-cloud-security-guidance.html Fined by Singapore's regulatory authority: https://www.theregister.com/2021/11/18/redoorz_fined_for_massive_data_leak/ 4 Security Questions to Ask About Your Salesforce Application: https://www.toolbox.com/it-security/security-vulnerabilities/guest-article/security-questions-to-ask-about-salesforce-application/ Managing temporary elevated access to your AWS environment: https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/ Everything you wanted to know about trusts with AWS Managed Microsoft AD: https://aws.amazon.com/blogs/security/everything-you-wanted-to-know-about-trusts-with-aws-managed-microsoft-ad/ Trailscraper: https://github.com/flosell/trailscraper 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: Writing ad copy to fit into a 30-second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days, or weeks. Visit Qtorque.io today, and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: Happy Thanksgiving. Lacework raised an eye-popping $1.3 billion in funding last week. I joke about it being a result of them sponsoring this podcast, for which I thank them, but that's not the entire story. “Why would someone pay for Lacework when AWS offers a bunch of security services?” Is a reasonable question. The answer is that AWS offers a bunch of security services, doesn't articulate how they all fit together super well, and the cost of running them all on a busy account likely exceeds the cost of a data breach. Security has to be simple to understand. An architecture diagram that looks busier than a London Tube map is absolutely not that. Cloud services are complex, but inside of that complexity lies a lot of room for misconfiguration. Being condescendingly told after the fact about AWS's Shared Responsibility Model is cold comfort. Vendors who can simplify that story and deliver on that promise stand to win massively here.Now, let's see what happened last week. The NSA and CISA have a new set of security guidelines for 5G networks. I'm sorry, but what about this is specific to 5G networks? It's all about zero trust, assuming that any given node inside the perimeter might be compromised, and the like. None of this is particularly germane to 5G, so I've got to ask, what am I missing?A company called RedDoorz—spelled with a Z, because of course it is—was fined by Singapore's regulatory authority for leaking 5.9 million records. That's good. The fine was $54,456 USD, which seems significantly less good? I mean, that's “Cost of doing business” territory when you're talking about data breaches. In an ideal world it would hurt a smidgen more as a goad to inspire companies to do better than they are? Am I just a dreamer here?I found a list of 4 Security Questions to Ask About Your Salesforce Application, and is great, and I don't give a toss about the Salesforce aspect of it. They are, one, who are the users with excessive privileges? Two, what would happen if a legitimate user started acting in a suspicious way? Three, what would happen if a threat actor gained access to sensitive data through a poor third-Party integration? And, four, what would happen if your incident log is not properly configured? These are important questions to ask about basically every application in your environment. I promise, you probably won't like the answers—but attackers ask them constantly. You should, too.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals: having the highest quality content in tech and cloud skills, and building a good community that is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. It's both useful for individuals and large enterprises, but here's what makes this something new—I don't use that term lightly—Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks, you'll have a chance to prove yourself. Compete in four unique lab challenges where they'll be awarding more than $2,000 in cash and prizes. I'm not kidding: first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey—C-O-R-E-Y. That's cloudacademy.com/corey. We're going to have some fun with this one.Corey: Now, from the mouth of AWS horse, there was an interesting article there. Managing temporary elevated access to your AWS environment. Now, this post is complicated, but yes, ideally users shouldn't be using accounts with permissions to destroy production in day-to-day use; more restricted permissions should be used for daily work, and then people elevate to greater permissions only long enough to perform a task that requires them. That's the Linux ‘sudo' model. Unfortunately, implementing this is hard and ‘sudo zsh' is often the only command people ever run from their non-admin accounts.And one more. Everything you wanted to know about trusts with AWS Managed Microsoft AD. Look, I don't touch these things myself basically ever. I haven't done anything with Active Directory since the mid-naughts, and I don't want to know anything about them. That said, I do accept that others will care about it and that's why I mention it. I'm here for you.And lastly, as far as tools go, have you ever tried to work with CloudTrail logs yourself? Yeah, you might have noticed the experience was complete crap. This is why I talk about trailscraper, which I discovered last week. It makes it way easier to look for specific patterns in your logs, or even just grab the logs in non-compressed format to work with more easily. And that's what happened last week in the world of AWS security. Next week is re:Invent, and Lord alone knows what nonsense we're going to uncover then. Strap in, it's going to be an experience. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.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: Writing ad copy to fit into a 30-second slot is hard, but if anyone can do it the folks at Quali can. Just like their Torque infrastructure automation platform can deliver complex application environments anytime, anywhere, in just seconds instead of hours, days, or weeks. Visit Qtorque.io today, and learn how you can spin up application environments in about the same amount of time it took you to listen to this ad.Corey: Happy Thanksgiving. Lacework raised an eye-popping $1.3 billion in funding last week. I joke about it being a result of them sponsoring this podcast, for which I thank them, but that's not the entire story. “Why would someone pay for Lacework when AWS offers a bunch of security services?” Is a reasonable question. The answer is that AWS offers a bunch of security services, doesn't articulate how they all fit together super well, and the cost of running them all on a busy account likely exceeds the cost of a data breach. Security has to be simple to understand. An architecture diagram that looks busier than a London Tube map is absolutely not that. Cloud services are complex, but inside of that complexity lies a lot of room for misconfiguration. Being condescendingly told after the fact about AWS's Shared Responsibility Model is cold comfort. Vendors who can simplify that story and deliver on that promise stand to win massively here.Now, let's see what happened last week. The NSA and CISA have a new set of security guidelines for 5G networks. I'm sorry, but what about this is specific to 5G networks? It's all about zero trust, assuming that any given node inside the perimeter might be compromised, and the like. None of this is particularly germane to 5G, so I've got to ask, what am I missing?A company called RedDoorz—spelled with a Z, because of course it is—was fined by Singapore's regulatory authority for leaking 5.9 million records. That's good. The fine was $54,456 USD, which seems significantly less good? I mean, that's “Cost of doing business” territory when you're talking about data breaches. In an ideal world it would hurt a smidgen more as a goad to inspire companies to do better than they are? Am I just a dreamer here?I found a list of 4 Security Questions to Ask About Your Salesforce Application, and is great, and I don't give a toss about the Salesforce aspect of it. They are, one, who are the users with excessive privileges? Two, what would happen if a legitimate user started acting in a suspicious way? Three, what would happen if a threat actor gained access to sensitive data through a poor third-Party integration? And, four, what would happen if your incident log is not properly configured? These are important questions to ask about basically every application in your environment. I promise, you probably won't like the answers—but attackers ask them constantly. You should, too.Corey: This episode is sponsored in part by something new. Cloud Academy is a training platform built on two primary goals: having the highest quality content in tech and cloud skills, and building a good community that is rich and full of IT and engineering professionals. You wouldn't think those things go together, but sometimes they do. It's both useful for individuals and large enterprises, but here's what makes this something new—I don't use that term lightly—Cloud Academy invites you to showcase just how good your AWS skills are. For the next four weeks, you'll have a chance to prove yourself. Compete in four unique lab challenges where they'll be awarding more than $2,000 in cash and prizes. I'm not kidding: first place is a thousand bucks. Pre-register for the first challenge now, one that I picked out myself on Amazon SNS image resizing, by visiting cloudacademy.com/corey—C-O-R-E-Y. That's cloudacademy.com/corey. We're going to have some fun with this one.Corey: Now, from the mouth of AWS horse, there was an interesting article there. Managing temporary elevated access to your AWS environment. Now, this post is complicated, but yes, ideally users shouldn't be using accounts with permissions to destroy production in day-to-day use; more restricted permissions should be used for daily work, and then people elevate to greater permissions only long enough to perform a task that requires them. That's the Linux ‘sudo' model. Unfortunately, implementing this is hard and ‘sudo zsh' is often the only command people ever run from their non-admin accounts.And one more. Everything you wanted to know about trusts with AWS Managed Microsoft AD. Look, I don't touch these things myself basically ever. I haven't done anything with Active Directory since the mid-naughts, and I don't want to know anything about them. That said, I do accept that others will care about it and that's why I mention it. I'm here for you.And lastly, as far as tools go, have you ever tried to work with CloudTrail logs yourself? Yeah, you might have noticed the experience was complete crap. This is why I talk about trailscraper, which I discovered last week. It makes it way easier to look for specific patterns in your logs, or even just grab the logs in non-compressed format to work with more easily. And that's what happened last week in the world of AWS security. Next week is re:Invent, and Lord alone knows what nonsense we're going to uncover then. Strap in, it's going to be an experience. Thanks for listening.Corey: Thank you for listening to the AWS Morning Brief: Security Edition with the latest in AWS security that actually matters. Please follow AWS Morning Brief on Apple Podcast, Spotify, Overcast—or wherever the hell it is you find the dulcet tones of my voice—and be sure to sign up for the Last Week in AWS newsletter at lastweekinaws.com.Announcer: This has been a HumblePod production. Stay humble.

Links: Disclosed a nasty auto-delete bug: https://arstechnica.com/information-technology/2021/10/researcher-refuses-telegrams-bounty-award-discloses-auto-delete-bug/ Enroll basically all of it's users: https://blog.google/technology/safety-security/making-sign-safer-and-more-convenient/ Worth taking a look: https://labs.bishopfox.com/tech-blog/IAM-vulnerable-assessing-the-aws-assessment-tools Enumerate those yourself: https://www.hezmatt.org/~mpalmer/blog/2021/10/07/enumerating-aws-iam-accounts.html AWS Access Keys: https://www.nojones.net/posts/aws-access-keys-a-reference/ Routes billions of text messages: https://www.vice.com/en/article/z3xpm8/company-that-routes-billions-of-text-messages-quietly-says-it-was-hacked “Enabling Data Classification for Amazon RDS database with Amazon Macie”: https://aws.amazon.com/blogs/security/enabling-data-classification-for-amazon-rds-database-with-amazon-macie/ “How to set up a two-way integration between AWS Security Hub and Jira Service Management”: https://aws.amazon.com/blogs/security/how-to-set-up-a-two-way-integration-between-aws-security-hub-and-jira-service-management/ “Update the alternate security contact across your AWS accounts for timely security notifications”: https://aws.amazon.com/blogs/security/update-the-alternate-security-contact-across-your-aws-accounts-for-timely-security-notifications/ CloudSploit: https://github.com/aquasecurity/cloudsploit 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 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 in the weeks ahead.Corey: To begin with, the big news is that week is the week of the year in which the Last Week in AWS charity shirt is available for sale. All proceeds to benefit 826 National. To get your snarky, sarcastic shirt, “The AWS Status Page,” this year, visit lastweekinaws.com/charityshirt and thank you in advance for your support.Now, last week's big security news was about Amazon's subsidiary, Twitch—or Twetch, depending upon pronunciation. It had a bunch of its code repos and streamer payouts leaked. Given that they are in fact an Amazon company largely hosted on AWS, you know, except for the streaming parts; are you a lunatic? That would cost ALL the money—this makes it tricky for AWS to message this as not their problem as per their vaunted Shared Responsibility Model. What's the takeaway? Too soon to say but, ouch.From the community. Telegram offered a researcher a €1,000 bounty, which is just insultingly small. The researcher said, “Not so much,” and disclosed a nasty auto-delete bug. If you're going to run a bug bounty program, ensure that you're paying researchers enough money to incentivize them to come forward and deal with your no-doubt obnoxious disclosure process.You can expect a whole bunch of people who don't care about security to suddenly be asking fun questions as Google prepares to enroll basically all of its users into two-factor-auth. Good move, but heads up, support folks.I found a detailed analysis of AWS account assessment tools. These use things like CloudSploit, which I'll talk about in a bit, IAM Vulnerable, et cetera. Fundamentally, they all look at slightly different things; they're also all largely the same, but it might be worth taking a look.AWS has made statements indicating that they don't believe that enumerating which IAM accounts exist in a given AWS account is a security risk, so someone has put out a great technique you can use to enumerate those yourself. Why not, since Amazon doesn't find this to be a problem.A reference to the various kinds of AWS Access Keys is also something I found relatively handy because I hadn't seen this ever explained before. It taught me a lot about the different kinds of key nonsense that I encounter in the wild from time to time. Take a look, it's worth the read.It didn't get a lot of attention in the press due to, you know, things last week, but a company that routes billions of text messages said that it was hacked. It's worth pointing out that SMS is a garbage second-factor, just because how lax security around it is. I'm a big believer in hardware keys like Yubikeys for important stuff, and an app like Authy or Google Authenticator for less important or shared accounts.I know, you shouldn't be sharing accounts; as soon as you come up with a better way for multiple people in different locations to do things that require root credentials in an AWS account, do let me know. Back to my point; treat SMS as a second factor only as better than nothing, not a serious security bulwark when it matters.Three things came out from the mouth of AWS horse last week. “Enabling Data Classification for Amazon RDS database with Amazon Macie.” While the idea of streaming from a relational database through a bunch of wildly expensive AWS services is of course ludicrous, the actual value of knowing what the data classification in your database is can't be understated.The best practice pattern here is to make sure that you're bounding the truly sensitive stuff to its own location. For instance, instead of storing credit card information in ‘the database'; have a token that references a completely separate database that contains that information that's severely locked down; that way any random business query doesn't return sensitive data, and you can restrict access to that data to only the queries or groups or situations that require it. Note that this is only an example and you should not in fact be storing credit card numbers yourself. Good God.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: “How to set up a two-way integration between AWS Security Hub and Jira Service Management.” Now, I'm not a big fan of either Jira or Security Hub, but integrating whatever it is that finds alerts into something that reports them to someone empowered to do something about them is kind of important. You've got to tune it, though. “Someone visited your website,” showing up 3000 times in an hour is going to be very noisy, and mask alerts of the form, “Your database is open to the world.”They also talk about how to “Update the alternate security contact across your AWS accounts for timely security notifications.” You definitely want to ensure that every AWS account in your cloud estate has the right addresses here configured, and hope that someone who's compromised your accounts doesn't use this API to simply change them back again. It'll stop you from doing that, right? Right? Hello?And finally, MetaSploit is famous as an exploitation toolkit for systems. CloudSploit is attempting to be the same thing, only for cloud accounts. It's not something you'll likely use day-to-day, but it is a great way to spend an afternoon tinkering while also learning new things. And that's what happened Last Week in AWS: Security. Thank you for listening and once again, I ask you, go ahead and visit lastweekinaws.com/charityshirt and get yours today.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.

Building a security culture starts in the C-suite. While this is championed by the CISO, every business and technical leader has a role in communicating and practicing good security behavior across their teams. Steve Schmidt, CISO for AWS Security, shares his best practices and approaches for driving the right behaviors related to proactive security posture, the impact security has on the bottom line, and a plan of action that every executive should have when partnering with their security teams.

In this week's episode of CISO's Secret, Cyber Security Evangelist Grant Asplund hosts  Brendan Staveley, Head of AWS Security Services, Americans 

In this episode we chat blueprints, security patterns, reference architectures, and plans. Basically what we've seen in terms of the left hand side of the SDLC in establishing requirements early. This topic came about after reading the recent AWS Security reference architecture and grappling with implementation. We get pretty metaphor and analogy heavy in this one with some examples that may or may not make sense. Ultimately, these things work! We've seen them in the real world in a variety of samples, and hopefully you'll use them tooAWS Security Reference Architecturehttps://aws.amazon.com/blogs/security/aws-security-reference-architecture-a-guide-to-designing-with-aws-security-services/Developer Take on Using Reference Architectureshttps://ab-lumos.medium.com/embedding-security-into-sdlc-using-reference-architectures-for-developers-29403c00fb3d

In this episode of the Virtual Coffee with Ashish edition, we spoke with Ely Khan (@elykahn) is the Principal Product Manager at AWS (@AWS). Episode ShowNotes, Links and Transcript on Cloud Security Podcast: www.cloudsecuritypodcast.tv Cloud Security Academy: www.cloudsecuritypodcast.tv/cloud-security-academy Host Twitter: @hashishrajan Guest Linkedin: @elykahn Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our YouTube Channel: - Cloud Security Podcast: https://www.youtube.com/c/cloudsecuritypodcast?sub_confirmation=1

In this episode of the Virtual Coffee with Ashish edition, we spoke with Scott Piper (@0xdabbad00) is a AWS Security Legend who has written AWS Security tools for the community and among other things is a Consultant and Trainer at Summit Route.. Episode ShowNotes, Links and Transcript on Cloud Security Podcast: www.cloudsecuritypodcast.tv Cloud Security Academy: www.cloudsecuritypodcast.tv/cloud-security-academy Host Twitter: @hashishrajan Guest Linkedin: @0xdabbad00 Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our YouTube Channel: - Cloud Security Podcast: https://www.youtube.com/c/cloudsecuritypodcast?sub_confirmation=1

    In episode 60, we chat with AJ Yawn about AWS security, compliance in the cloud, choosing an auditor and more. My 3 main takeaways were 1) How to make compliance not suck 2) How to automate security within an AWS environment and 3) What shared responsibility means when managing cloud infrastructure For more information, including the show notes check out: https://breachsense.io/podcast 

فهاد الحلقة دوينا على AWS Security groups In this episode, we talked about AWS Security groups #aws #ec2 #podcast #cloud #darija #morocco

Jesse Trucks is the Minister of Magic at Splunk, where he consults on security and compliance program designs and develops Splunk architectures for security use cases, among other things. He brings more than 20 years of experience in tech to this role, having previously worked as director of security and compliance at Peak Hosting, a staff member at freenode, a cybersecurity engineer at Oak Ridge National Laboratory, and a systems engineer at D.E. Shaw Research, among several other positions. Of course, Jesse is also the host of Meanwhile in Security, the podcast about better cloud security you're about to listen to.Links: aws.amazon.com/compliance aws.training docs.microsoft.com/asure/security TranscriptJesse: Welcome to Meanwhile in Security where I, your host Jesse Trucks, guides you to better security in the cloud.Announcer: If you have several PostgreSQL databases running behind NAT, check out Teleport, an open-source identity-aware access proxy. Teleport provides secure access to anything running behind NAT, such as SSH servers or Kubernetes clusters and—new in this release—PostgreSQL instances, including AWS RDS. Teleport gives users superpowers like authenticating via SSO with multi-factor, listing and seeing all database instances, getting instant access to them using popular CLI tools or web UIs. Teleport ensures best security practices like role-based access, preventing data exfiltration, providing visibility, and ensuring compliance. Download Teleport at goteleport.com. That's goteleport.com.Jesse: Trilogy of Threes and a New Mantra. Trilogy of Threes. Good security practices and good security programs are built on three separate but intertwined principles, each of which has three parts. Simon Sinek's Golden Circle framework lays the foundation for why you have a security program, which is a balance of risks to critical assets and services, and business objectives. The next part of how you apply the Golden Circle to your security program is about how you accomplish meeting these objectives and mitigating your risk through the People, Process, and Technology framework.The PPT method helps you define the roles are needed to implement your security program, the overview of processes or actions within your security program, and the types of technology that supports your security program. The final part of how you apply the Golden Circle encompasses what specific things you do to implement your security program using the Holy Trinity of Security: confidentiality, integrity, and availability, or the CIA triad. In your security program, you should define who should be allowed access to any data or service, how you monitor and protect any data or services, and how you keep data or services available for users. Although understanding how to build a security program from nothing is incredibly important, most of us are already operating within an existing security program. Many of us will have influence only on the specific implementation of tools for the Holy Trinity, CIA. All this theory is crucial to understand, but you still have a job to do. So, let's get practical.Where to start today. Searching online for ‘Top X for AWS Security' returns an expected long list of pages and there are shed-loads of fantastic tips in the results. However, reading through many of them, including AWS's own blog entry on the topic, shows that proper cloud security involves large projects and possibly fully re-architecting your entire environment. As is often the case in these things, all the best security advice in the cloud has to do right security from the very beginning. Yet this is like discovering a new love of playing the piano late in life like I did, [laugh] but someone telling you the right way to learn to play the piano is to take lessons as a child. This isn't so useful advice, now is it? Of course, it's too late to become a child piano prodigy, but it's not too late to take up the piano and do well.Fundamentals. In traditional non-cloud environments, physical security for everything leading up to touching a machine is usually the purview of a different part of the organization, or an entirely different organization than the security team or group responsible for system network and application security. Generally, most information or cybersecurity starts with accessing the software-based systems on a physical device's console or through a network connection. This, of course, includes accessing the network through some software path, usually a TCP or UDP-based protocol. In cloud environments, the cloud providers, such as Amazon Web Services—or AWS—Microsoft Azure, or Google Cloud Platform—GCP—maintains and is wholly responsible for all the physical environment and the virtual platform or platforms made available to their customers, including all security and availability required for protecting the buildings and hardware, up through the hypervisors presenting services allowing customers to run systems.All security above the hypervisor is the customer's responsibility, from the operating system or OS through applications and services running on these systems. For example, if you run Windows systems for Active Directory Services, and Linux systems for organizations' online presence, then you own all things in the Windows and Linux OSes, services running on those systems, and the data on those systems. This is called the shared responsibility model. AWS provides details on their compliance site aws.amazon.com/compliance as well as in a short video on their training and certification site aws.training.Microsoft describes their model on their documentation site docs.microsoft.com/asure/security. Google has lots of information in various places on their Google Cloud Platform GCP site, including a guided tour of their physical security for their data centers, but finding a simple explanation like the other two major services have available eluded me. Google does have a detailed explanation of their shared responsibility matrix, as they call it, which is an 87-page PDF. Luckily, given the overwhelming popularity over the other cloud providers, I tend to focus mostly on AWS. I didn't read the whole GCP document.Announcer: If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework. Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the Cloud: low effort, high visibility, and detection. To learn more, visit lacework.com. That's lacework.com.Jesse: basic AWS training. Amazon provides ample training and online tutorials on all things AWS. This includes AWS basics through advanced AWS architecture and various specialty areas like machine learning and security, among others. I encourage everyone who touches anything in AWS to go through their training courses online at aws.training.If you are new to AWS or cloud in general, go take AWS Cloud Practitioner Essentials, and then take some primers in AWS security: AWS Security Fundamentals; Introduction to AWS Identity and Access Management, or IAM; and AWS Foundations: Securing Your AWS Cloud. These are all eLearning-based and free. This will be some of the best nine to ten hours you can spend to build a foundation for securing your AWS infrastructure.Learning is great; doing is better. Whether you've taken the relevant AWS training or just want to dive in and make your AWS security better today, you'll want to go make a difference in your risk and exposure as quickly as possible. After all, unless you're listening to this as a seasoned security professional, you're probably here to learn how to make your security better as quickly and easily as possible. Anyone looking at the list of courses I've suggested and considering my fundamental approach might be trying to discern which first principles of good security I'll talk about first. If you're thinking along those lines, you might miss some of the very basics.As with all things in the tech world, there are some basics that can't be repeated often enough. The most simple and blatantly obvious advice is to secure your S3 buckets. Let's cover that again so nobody misses the point. Secure. Your. S3. Buckets. Now, repeat that 27 times every morning while you get ready for work before you touch your keyboard.This is the cloud version of securing FTP, meaning FTP isn't too bad protocol, but it's notorious for being misconfigured and allowing anonymous FTP uploads and downloads. If you want to fall into a hole learning everything there is to this, go read the Security Best Practices for Amazon S3 portion of the S3 User Guide. If you don't have time or energy for wading through that lengthy but valuable tome, check some basics for your maximum ROI for minimal effort. If you allow public access to S3 files directly, you should seriously reconsider your solution. There are dozens of ways to provide access to files that aren't as risky as opening direct access to data storage.You should block public access at the account level by going to the S3 services section in the AWS Management Console. And in the menu on the left, select ‘Block Public Access Settings for this Account.' If you can't do this immediately, go lockdown all buckets that don't have this insane requirement to be open to the public. Do this by selecting the bucket, and block access in the permissions tab.You should always be thinking of the fundamentals of great security, and you should always be learning and improving your skills, of course. You should also continually make little changes and review the basics. Some new project will go live and some S3 bucket will have horrible permission settings, or some other fundamental violation of security best practices will occur. We should always be looking out for violations of the basics, even while we work on the larger projects with greater apparent impact. I repeated my mantra 27 times today. Have you?Jesse: Thanks for listening. Please subscribe and rate us on Apple and Google Podcast, Spotify, or wherever you listen to podcasts.Announcer: This has been a HumblePod production. Stay humble.

A few months ago, I noticed a post on LinkedIn featuring one of my contacts and his recent promotion to America's Sales Leader for Amazon Web Services (AWS) Security at Amazon. I was pleasantly surprised when I read it was Brendan Staveley. I worked with Brendan at Check Point Software Technologies, Ltd. Point Software; it was his first job after graduating college. Fast-forward a little more than two decades and experiences at Fortinet and Cisco, Brendan now leads a lean team of AWS Security specialists covering the western hemisphere. I had a great time catching up with Brendan and hearing his comments and thoughts about the cloud. Hear Brendan discuss "empathy" and why it's a priority when assisting customers in their migration of workloads to the public cloud.

Conversamos com o Tales Casagrande e a Maria Ane Dias sobre os desafios da segurança em aplicações serverless, mas com certeza as dicas aqui servem para aplicações cloud de maneira geral. Paper da Trendmicro: https://www.trendmicro.com/vinfo/ph/security/news/virtualization-and-cloud/shedding-light-on-security-considerations-in-serverless-cloud-architectures OWASP Serverless Top 10: https://owasp.org/www-project-serverless-top-10/ AWS Security: https://docs.aws.amazon.com/pt_br/security AWS best practices DDoS resiliency : https://docs.aws.amazon.com/pt_br/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.pdf

Scott Piper is an AWS security consultant at Summit Route, a company he founded in 2014. He’s also the developer of flaws.cloud and an organizer for the virtual fwd:cloudsec conference. Scott brings 15 years of tech experience to his current position, having worked as director of security at CyberGRX, a security engineer at Yelp, a software developer at Parsons Corporation, and a software developer at the U.S. Department of Defense, among other positions. Join Corey and Scott as they talk about how Scott created a game to help teach people AWS security; how Scott likely got a red flag thrown on his account indicating he’s a hassle to deal with; what fwd:cloudsec is, why it was named the way it was, and how it came about; some of the reasons why virtual conferences are better than in-person conferences; why in-person conferences likely aren’t coming back anytime soon; what Scott thinks AWS does well and what he thinks AWS does not do well; what Scott believes the best security boundary on AWS is; and more.

In this episode of the Virtual Coffee with Ashish edition, we spoke with Matthew Fuller, co-Founder CloudSploit, Aqua Host: Ashish Rajan - Twitter @hashishrajan Guest: Matthew Fuller - Linkedin @mattdfuller In this episode, Matthew & Ashish spoke about What was your path into your current role? What was the inspiration behind CloudSpoilt? What does Cloud Security mean for you? What are your thoughts for organisations navigating the dilemma of buy first vs build first? What is Open Source? Open Source, what is the community driven model here? What is a role of a cloud security engineer? What are the absolute foundational challenges with Open Source? Is experience with Linux beneficial if you are going Open Source? Do the challenges change with hybridcloud, multicloud, polycloud etc? How were you away to stay away from the VCs and basically boot strap What are some of the considerations when choosing between open source and a vendor product? What are the challenges or the bad with Open Source? How do you assess the maturity of security of an environment? Are there cloud security myths that you want to debunk? Whats your advice to people who want to dabble in Open Source? Is there something that isn’t being talked enough about in the Cloud Security Space? As the cloud becomes more featured the amount of complexity and securing the cloud grows, even tools that help you with security require a lot more learning. Any comments on this statement? ShowNotes and Episode Transcript on www.cloudsecuritypodcast.tv Twitter - @kaizenteq @hashishrajan If you want to watch videos of this and previous episodes: - Twitch Channel: https://lnkd.in/gxhFrqw - Youtube Channel: https://lnkd.in/gUHqSai

In this episode I chat with Dylan Shields about his new book AWS Security. Dylan is a software engineer working on Quantum Computing at AWS. Previously, Dylan was the first engineer on the AWS Security Hub team. He has also worked at Google Cloud, focusing on the security and reliability of their serverless data warehouse, BigQuery.

In this episode of the Virtual Coffee with Ashish edition, we spoke with Houston Hopkins, Director CyberSecurity, Capital One Host: Ashish Rajan - Twitter @hashishrajan Guest: Houston Hopkins - Linkedin @houstonhopkins In this episode, Houston & Ashish spoke about What was your path into CyberSecurity? How Capital one pioneered as bank moving into AWS Cloud? What immediate security challenges does Cloud Security in a Hybrid world look like, without going into tools. Do you prefer to use AWS native tools for security observability or a vendor product? What are some of the Security challenges to solve when looking at a large cloud landscape? (threat detection at scale, continuous compliance etc) Is accountability a challenge for Cloud at Scale? Does this change quite a bit for security in one cloud compared to another? (resources that know multiple cloud etc) Which approach do you recommend - Standardizing security vs Operationalize and Manage with more staff for effective security across multi-cloud environments? Immediate challenges around multi-cloud - Maintaining visibility of assets and secure configurations in a large multi-cloud environment What does detection and prevention look like in a cloud landscape? How do you keep track of all the AWS services? What security controls across compute heavy vs serverless vs containers in a multi-cloud world How do you get visibility in the current poly-cloud or multi-cloud world? ShowNotes and Episode Transcript on www.cloudsecuritypodcast.tv Twitter - @kaizenteq @hashishrajan If you want to watch videos of this and previous episodes: - Twitch Channel: https://lnkd.in/gxhFrqw - Youtube Channel: https://lnkd.in/gUHqSai

In this episode I talk with Dylan Shields about AWS Security best practices. The cloud is great and does make deployment and scaling easier than ever, but security best practices still remain a big responsibility of the cloud customer. Connect with Dylan: LinkedIN: https://www.linkedin.com/in/dylan-shields-6802b1168 AWS Security Book: https://www.manning.com/books/aws-security Use discount code PODSYS19 for %40 off … Continue reading "SAS 048 – AWS Security with Dylan Shields"

This time we are discussing the white paper by Summit Route - AWS Security Maturity Roadmap 2020. Tune in to learn more about the white paper and recommendations that we pile up on top of it. To view show notes visit https://devsecops.fm Chat with hosts and suggest topics for upcoming episodes at our Gitter channel https://gitter.im/devsecopstalks/community

In this episode of the Virtual Coffee with Ashish edition, we spoke with Darpan Shah, Cloud Security Engineer. Darpan has 8 AWS Certificates, 6 GCP certificates and at his work, he works on both Google Cloud and AWS. This is episode not to miss. Host: Ashish Rajan - Twitter @hashishrajan Guest: Darpan Shah - Website Darpan & Ashish spoke about What was your path into CyberSecurity or your current role? What does Cloud Security mean for you? What public cloud provider do you focus on? What makes you like Google Cloud over AWS? Vice versa? Where does Kubernetes/Containers fit into maturity stages of Google Cloud? Is multi-cloud in the same organisation a reality? What does security in Google Cloud look like compared to AWS? - Basic security 101s differences, Auditing, threat management, EC2 vs project security examples How is security managed and operationalising across multi-cloud AWS & GCP Where can one start today with security on Google Cloud, if they already are on AWS? Security controls across EC2 vs serverless vs containers in a multi-cloud world Maintaining visibility of assets and secure configurations in a multi-cloud environment? What tools can you use to get a single view for multi-cloud? How do you monitor for threats? Orchestration or detection? What are people not talking about cloud security in multi-cloud? ShowNotes and Episode Transcript on www.cloudsecuritypodcast.tv Twitter - @kaizenteq @hashishrajan If you want to watch this and previous episodes: - Twitch Channel: https://lnkd.in/gxhFrqw - Youtube Channel: https://lnkd.in/gUHqSai

support networkchuck: https://bit.ly/join_networkchuck or buy me a coffee: https://ko-fi.com/networkchuck (affiliate links below) or buy your own coffee stuff: https://amzn.to/2kAwuW6 CEH Study: https://bit.ly/itprotvnetchuck CCNA: Lab: http://bit.ly/2X1vqIV Practice Exam: http://bit.ly/exsimboson #ceh #securityplus #ccna

AWS Morning Brief for the week of June 1, 2020

On the 33rd episode of Virtual Stack, I’m joined by Dylan Shields (Software Engineer at Google) and we talk about his upcoming book called AWS Security. In our discussion, we touch on many points; such as the security governance on public clouds, security services on AWS, best practices for networking/VPC, IAM and continuous monitoring.   Dylan’s book will be published by Manning Publications in Autumn 2020. I have free eBook codes for this book and you’ll get one if you’re one of the first 5 people to share my LinkedIn and Twitter posts with your network.   Besides that, you can use the code “podstack20” for a 40% discount on all Manning Publications products.   Virtual Stack is available on all major apps: Apple Podcast, Spotify, Google Podcast, Stitcher and more. As usual, feel free to share your feedback via Twitter (@emregirici), LinkedIn or virtualstack.tech.   Links: Dylan's book: "AWS Security" AWS Well Architected Framework Whitepapers AWS Security Blog

This session will give you a comprehensive look into automating the investigation and remediation of AWS security events using Splunk Phantom. The session will start with an overview and then progress to a live technical walkthrough of setting up Phantom to remediate an AWS security event. Speaker(s) Matt Tichenor, Product Manager, Splunk Slides PDF link - https://conf.splunk.com/files/2019/slides/SEC2187.pdf?podcast=1577146216 Product: Phantom Track: Security, Compliance and Fraud Level: Intermediate

This session will give you a comprehensive look into automating the investigation and remediation of AWS security events using Splunk Phantom. The session will start with an overview and then progress to a live technical walkthrough of setting up Phantom to remediate an AWS security event. Speaker(s) Matt Tichenor, Product Manager, Splunk Slides PDF link - https://conf.splunk.com/files/2019/slides/SEC2187.pdf?podcast=1577146239 Product: Phantom Track: Security, Compliance and Fraud Level: Intermediate

This session will give you a comprehensive look into automating the investigation and remediation of AWS security events using Splunk Phantom. The session will start with an overview and then progress to a live technical walkthrough of setting up Phantom to remediate an AWS security event. Speaker(s) Matt Tichenor, Product Manager, Splunk Slides PDF link - https://conf.splunk.com/files/2019/slides/SEC2187.pdf?podcast=1577146225 Product: Phantom Track: Security, Compliance and Fraud Level: Intermediate

Stephen Schmidt, chief information security officer for AWS, addresses the current state of security in the cloud, with a focus on feature updates, the AWS internal "secret sauce," and what's to come in terms of security, identity, and compliance tooling.

A vulnerability disclosure program should be part of any company's promise to its customers. The owner of a product must have a strategy to accept input from the security community regarding that product. In May 2019, the AWS Security team received a report regarding the AmazonSageMakerFullAccess managed security policy. This session covers the vulnerability disclosure process and includes a discussion of how AWS processed that report.

It's easy to forget not everyone started their move to the cloud eight or even ten years ago. Early adopters have a wealth of experiences that can benefit newcomers and experienced teams alike. A preview to August 14th's webinar "Top 5 AWS Security Mistakes and How to Stop Them Before You Lose Data", DisruptOps CEO Mike Rothman joins us on DevOps Chat. In this episode, we reflect on learnings and knowledge Mike and co-founder Rich Mogul incorporated into their product DisruptOps Guardrails. Be sure to register for the Aug. 14th webinar at https://webinars.devops.com/top-5-aws-security-mistakes-and-how-to-stop-them-before-you-lose-data.

In the latest AWS Security & Compliance Podcast, we sit down with VP of Security Chad Woolf, who answers your compliance and data privacy questions. Including one of the most frequently asked questions from customers around the world, which is: how many compliance programs does AWS have/attest to/audit against? Chad also shares what it was like to work at AWS in the early days. When he joined, AWS was housed on just a handful of floors, in a single building. Listen to the podcast to hear about company history and get answers to your tough questions. https://aws.amazon.com/compliance/ https://aws.amazon.com/compliance/data-privacy-faq/ https://twitter.com/realchadwoolf

According to Gartner, the IaaS market grew at a blistering 42.8% in 2017-twice as fast as SaaS. And with last year's high-profile data exposures, the focus on bolstering IaaS security practices has increased. We've worked with AWS and hundreds of IaaS security professionals to develop a list of security practices specifically designed to protect AWS environments and the applications and data within them. In this session, you'll discover: common yet preventable scenarios that can result in the loss of corporate data, security best practices for user and admin behavior monitoring, secure auditable configuration, Amazon S3 data loss and threat prevention, blueprints for how a solution-based approach (including bridging to your on-premises best practices) can provide IaaS visibility and control, step-by-step guidance on how to gain visibility across all workloads, protect against advanced threats, and discover insights into lateral threat movements, and recommendations for creating a successful DevOps workflow that integrates security.

In this session, we dive deep into the actual code behind various security automation and remediation functions. We demonstrate each script, describe the use cases, and perform a code review explaining the various challenges and solutions. All use cases are based on customer and C-level feedback and challenges. We look at things like IAM policy scope reduction, alert and ticket integration for security events, forensics and research on AWS resources, secure pipelines, and more. Please join us for a speaker meet-and-greet following this session at the Speaker Lounge (ARIA East, Level 1, Willow Lounge). The meet-and-greet starts 15 minutes after the session and runs for half an hour. Complete Title: AWS re:Invent 2018: Five New Security Automations Using AWS Security Services & Open Source (SEC403)

This is a Special Series from AWS Security & Compliance. In this podcast, we’re previewing the security track at re:Invent. Staffers developing security track content offer their advice for navigating the learning conference that is expected to draw 50,000 people from around the world. Learn about the newest hands-on session designed to give you even deeper technical insight. Plus, find out about the event change meant to make it easier to attend the talks that interest you. https://reinvent.awsevents.com/ https://aws.amazon.com/security/ https://aws.amazon.com/compliance/

The compliance, identity, and security services of AWS covers a large number of offerings.  Therefore, we will review these in a multi-part series of episodes.  The power and infrastructure provided by choosing AWS for your cloud provider become apparent with these tools.  We have a lot to cover in this first part. Access and Identity Management This should be the first step in your use of the AWS services.  AIM is a framework or set of features to help you define users, permissions, roles, and manage them.  Nearly every function points back to AIM as the way to set up and configure access as well as security for that service.  If you do not have at least a fundamental understanding of AIM, then you should start there before looking further in the security-related services. Single Sign-On No one likes to log in to every application they launch.  Thus, single sign-on is practically a must for any organization that requires users to access multiple applications on a regular basis.  Unfortunately, that covers nearly every organization in the modern landscape.  Never fear, Amazon understands that need and has made single sign-on relatively easy to implement and embrace for all of your AWS solutions. Artifact The Artifact offering is a repository more than a service.  This is where you go to get the Amazon official documentation about their platform, SLAs, and recent audit reports.  Most small companies will not have need of these documents.  However, a security audit will require these to be available, and it never hurts to review them, so you know exactly how secure and reliable AWS is. Shield This is not the group out of Marvel comics.  The Shield service has a standard offering that is free and helps guard your systems from distributed denial of service attacks (DDOS).  The paid version includes analytics and reporting to help you assess and defend against attempted attacks.  This is an excellent service for those of us that always worry about how secure and protected our systems are. Macie The AI and machine learning features that Amazon has embraced are starting to result in a bevy of new services.  Macie is one such service.  This tool helps you search and classify your data to help avoid releasing personally identified information (PII) to external sources that should not access it.  If you are trying to assess how vital PII protection needs to be to your organization, then this is an excellent place to start that research. Directory Services The directory services offering is your path to moving Active Directory out to the cloud.  For better or worse, AD is a part of most organizations' access and permissions management.  Amazon recognizes this and provides this service to help you keep all that work as you move to the cloud. Organizations Another of the security services that is easily understood from its name alone, Organizations provides you with the ability to relate AWS accounts to each other.  This makes it easier to share permissions and also to roll up billing as needed.  It is free to use and worth a look as your AWS needs grow. Web Application Firewall (WAF) This is an application level service to protect your solutions with a firewall.  Rather than lock down access on a server basis, this works with the dynamic nature of cloud systems to allow you to secure offerings at the best level to manage.

CloudGuard for AWS - Security Transit VPC Demonstration by Check Point CheckMates

Ken and Seth are joined by Scott Piper (@0xdabbad00) and talk AWS Security, including https://flaws.cloud, cloud mapper, and cloud tracker projects.

Ken and Seth are joined by Scott Piper (@0xdabbad00) and talk AWS Security, including https://flaws.cloud, cloud mapper, and cloud tracker projects.

Today the Datanauts explore how to lock down AWS services to ensure they aren't publicly exposed--and it's not just S3 buckets. Our guest is Scott Piper, who'll share tips and open-source tools. The post Datanauts 139: Getting AWS Security Right appeared first on Packet Pushers.

Today the Datanauts explore how to lock down AWS services to ensure they aren't publicly exposed--and it's not just S3 buckets. Our guest is Scott Piper, who'll share tips and open-source tools. The post Datanauts 139: Getting AWS Security Right appeared first on Packet Pushers.

Today the Datanauts explore how to lock down AWS services to ensure they aren't publicly exposed--and it's not just S3 buckets. Our guest is Scott Piper, who'll share tips and open-source tools. The post Datanauts 139: Getting AWS Security Right appeared first on Packet Pushers.

This talk dives deep on how to build end-to-end security capabilities using AWS. Our goal is orchestrating AWS Security services with other AWS building blocks to deliver enhanced security. We cover working with AWS CloudWatch Events as a queueing mechanism for processing security events, using Amazon DynamoDB to provide a stateful layer to provide tailored response to events and other ancillary functions, using DynamoDB as an attack signature engine, and the use of analytics to derive tailored signatures for detection with AWS Lambda. Log sources include available AWS sources and also more traditional logs, such as syslog. The talk aims to keep slides to a minimum and demo live as much as possible. The demos come together to demonstrate an end-to-end architecture for SecOps. You'll get a toolkit consisting of code and templates so you can hit the ground running.

Steve Schmidt, chief information security officer of AWS, addresses the current state of security in the cloud, with a particular focus on feature updates, the AWS internal "secret sauce," and what's on horizon in terms of security, identity, and compliance tooling.

This episode focuses on topics introduced by the following TechGenix articles: - Stay safe: AWS security best practices - Building a culture of IT to transform your business: A strategic guide for CIOs - Targeting the sweet spot of the Gartner Hype Cycle

Ensuring security and compliance across a globally distributed, large-scale AWS deployment requires a scalable process and a comprehensive set of technologies. This session will deep-dive into the AWS native monitoring and security services and some Splunk technologies leveraged globally to perform security monitoring across a large number of AWS accounts. You will learn about the collection plumbing including components of S3, Kinesis, CloudWatch, SNS, Dynamo DB and Lambda, as well as the tooling and processes used at Adobe to deliver scalable monitoring without managing an unwieldy number of API keys and input stanzas. Session sponsored by Splunk.

Welcome to this episode of the Cloud Cadet Podcast. Today, Anthony and Christophe sit down with Linux Academy’s core OpenStack instructor, Stephen. Stephen has been an instructor with us for just about two years. He features our Linux Essentials course (which is where we suggest everyone should start), but today he’s going to be talking a little bit about AWS.