Podcasts about inforce

Welcome to episode 310 of The Cloud Pod – where the forecast is always cloudy! Matt, Ryan and Justin are here to bring you all the latest and greatest in cloud and AI news.  Literally.  All of it.  This week we have announcements from re:Inforce, Manual Testing, GuardDuty, Government AI (what could go wrong?) Gemini 2.5 and, in a flash from the past, MS-DOS Editor. All this and more, this week in the cloud!  Titles we almost went with this week: ACM Finally Lets Its Certificates Leave the Nest Breaking Free: AWS Certificates Get Their Export Papers Certificate Manager Learns to Share Its Private Keys Skynet’s Origin Story: We Bullied It Into Existence Claude and Present Danger: When AI Fights Back Breaking Up is Hard to GPU EKS Marks the Spot for GuardDuty’s New Detection Powers Kubernetes Security: GuardDuty Connects the Dots Hub, Hub, Hooray for Unified Security Security Hub 2: Electric Boogaloo All Your Security Findings Are Belong to One Dashboard GuardDuty’s EKS-cellent Adventure in Attack Detection Shield Me From My Own Bad Decisions AWS Plays Network Security Whack-a-Mole Your VPC Called – It Wants Better Security Groups Permission Impossible: Your Express App Will Self-Authorize in 5 Minutes Breaking the Glass: AWS Backup Gets a Multi-Party System Gemini 2.5: Now With More Flash and Less Cash AI Goes to Washington GPT-4: Government Property Taxpayer-funded DDoS and Don’ts: A 45-Second Horror Story Google’s AI Models Get a Flash-y Upgrade (Lite on the Wallet) Flash Gordon Called – He Wants His Speed Back From Flash to Flash-Lite: Google’s AI Diet Plan Looker’s Pipeline Dreams Come True MS-DOS Editor: The Reboot Nobody Asked For But Everyone Needed Control-Alt-Delete Your Expectations: Microsoft Brings DOS to Linux Microsoft’s Text Editor Time Machine Now Runs on Your Toaster Copilot Gets Its Agent License Visual Studio’s AI Agent: Now Taking Orders The Bridge Over Troubled Prompts Azure’s Managed Compute Gets More Coherent Bring Your Own GPU Party: Cohere Models Join the Azure Bash Function Telemetry Gets Open Sourced (Kind Of) Azure Functions: Now Speaking Everyone’s Language (Except Java) Bucket List: AWS Makes S3 Policy Monitoring a Breeze The Policy Police: Keeping Your S3 Buckets in Check CDK Gets Its Own Town Hall (Infrastructure Not Included) Breaking: AWS Discovers Zoom, Plans to Use It Twice Per Quarter AWS and 1Password: A Secret Love Affair Keeping Secrets Has Never Been This Public Nano Nano: AWS Brings Alien-Level Time Precision to EC2 Time Flies When You’re Having Nanoseconds WorkSpaces Core: Now With More Cores to Work With Mount Compute-ier: AWS Builds AI Training Peak Making it Rain(ier): AWS Showers Anthropic with 5x More Compute Cache Me If You Can: Google’s Plugin Play CSI: Cloud Services Investigation General News  01:09 Defending the Internet: How Cloudflare blocked a monumental 7.3 Tbps DDoS attack Cloudflare blocked a record-breaking 7.3 Tbps DDoS

Send us a textThe landscape of cloud security is rapidly evolving as AWS flexes its muscles with a suite of new native security offerings unveiled at AWS re:Inforce. From enhanced threat correlation capabilities in AWS Security Hub to seamless Transit Gateway integration for Network Firewall, these announcements signal Amazon's strategic expansion into territory traditionally dominated by third-party security vendors.We dive deep into the HPE-Juniper acquisition that finally received regulatory approval, but with interesting conditions – including the requirement to license parts of the coveted Mist AI technology. This could potentially open doors for competitors to leverage the same technology that made Juniper so attractive to HPE in the first place, creating a fascinating dynamic in the networking market.The most compelling theme emerging from AWS re:Inforce centers around Amazon's continued investment in native security tooling. New offerings like AWS Shield Network Security Director and IAM Access Analyzer directly challenge third-party CSPM providers, while improvements to existing services reduce the friction and complexity of implementing robust security controls. For organizations already invested in the AWS ecosystem, these integrated solutions offer compelling advantages – but they also raise important questions about vendor lock-in and multi-cloud strategies.Security vendors without a strong moat or differentiated value proposition should be concerned. As cloud service providers continue to enhance their native security capabilities, the pressure on third-party tools will only intensify. This trend follows closely on the heels of Google's acquisition of Wiz, suggesting that cloud security is becoming an increasingly strategic battleground for the major providers.For security professionals navigating these waters, the proliferation of overlapping security services presents both opportunities and challenges. While AWS continues to simplify implementation, the growing catalog of similar-sounding services can create confusion about which tools to use in which scenarios. As we discuss on the podcast, this appears to reflect AWS's organizational structure as much as customer needs – shipping the org chart rather than truly differentiated services.What's your security strategy in this evolving landscape? Are you embracing native cloud security tools or maintaining investments in third-party solutions? The answers may vary widely depending on your organization's cloud adoption strategy, but one thing is clear – the security vendor ecosystem is transforming before our eyes.Purchase Chris and Tim's new book on AWS Cloud Networking: https://www.amazon.com/Certified-Advanced-Networking-Certification-certification/dp/1835080839/ Check out the Fortnightly Cloud Networking Newshttps://docs.google.com/document/d/1fkBWCGwXDUX9OfZ9_MvSVup8tJJzJeqrauaE6VPT2b0/Visit our website and subscribe: https://www.cables2clouds.com/Follow us on BlueSky: https://bsky.app/profile/cables2clouds.comFollow us on YouTube: https://www.youtube.com/@cables2clouds/Follow us on TikTok: https://www.tiktok.com/@cables2cloudsMerch Store: https://store.cables2clouds.com/Join the Discord Study group: https://artofneteng.com/iaatj

Simon and Jillian take you through all the big security announcements from AWS re:Inforce plus a host of cool new features and price reductions!

At AWS re:Inforce 2025, AWS introduced key security upgrades, including expanded identity tools, enhanced code and threat detection with Inspector and GuardDuty, and easier deployment through improved WAF and firewall features. New CISO Amy Herzog emphasized identity security, while AWS reinforced its focus on automation, secure development, and ecosystem collaboration.Time Stamps: 0:00 - Cold Open0:24 - Welcome to the Tech Field Day News Rundown1:36 - Simbian Launches First LLM Benchmark for SOC Performance6:33 - Record-Breaking 7.3Tbps DDoS Attack Hits Cloudflare Client11:56 - Qualcomm Acquires Alphawave15:51 - QuantumCTek Unveils Affordable 1,000+ Qubit Control System21:12 - Teradata Brings AI Platform to On-Premises Data Centers26:08 - Chinese Hackers Build Hidden Network Using Fake LAPD Certificates30:01 - AWS re:Inforce 2025 Highlights Security, Identity, and Automation38:55 - The Weeks Ahead42:08 - Thanks for Watching the Tech Field Day News RundownFollow our hosts ⁠⁠⁠⁠⁠⁠⁠Tom Hollingsworth⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠Alastair Cooke⁠⁠⁠⁠⁠⁠⁠, and ⁠⁠⁠⁠⁠⁠⁠Stephen Foskett⁠⁠⁠⁠⁠⁠⁠. Follow Tech Field Day ⁠⁠⁠⁠⁠⁠⁠on LinkedIn⁠⁠⁠⁠⁠⁠⁠, on ⁠⁠⁠⁠⁠⁠⁠X/Twitter⁠⁠⁠⁠⁠⁠⁠, on ⁠⁠⁠⁠⁠⁠⁠Bluesky⁠⁠⁠⁠⁠⁠⁠, and on ⁠⁠⁠⁠⁠⁠⁠Mastodon⁠⁠⁠⁠⁠⁠⁠.

AWS Morning Brief for the week of March 17th, with Corey Quinn. Links:Amazon Bedrock now supports multi-agent collaborationAmazon RDS for MySQL announces Extended Support minor 5.7.44-RDS.20250213Amazon Route 53 Traffic Flow introduces a new visual editor to improve DNS policy editingApplication Load Balancer announces integration with Amazon VPC IPAMAnnouncing the end of support for Node.js 14.x and 16.x in AWS CDKWatch the recordings from AWS Developer Day 2025How GoDaddy built a category generation system at scale with batch inference for Amazon BedrockFormula 1® unlocks the most competitive season yet with AWSSecure cloud innovation starts at re:Inforce 2025

Aaron Miller joins the vBrownBag to discuss the human side of DevOps, HumanOps, a recap of an AWS event in London, and his experience in the AWS New Voices program. 02:56 Introducing Aaron Miller 11:42 Aaron's quest to understand DevOps 13:00 What DevOps is all about 23:12 People, tools, and processes 36:10 What is HumanOps? 37:30 The five HumanOps principles 38:25 Recap of AWS London re:Inforce re:Cap Resources: https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/the-devops-sagas.html https://github.com/HumanOps/HumanOps

EPISODE 205 DETAILS How Hurricane Helene Affected Cattle Producers & How To Help Plus Beef Industry News  Cattlemen's Groups Help Those Affected By Hurricane Helene Our thoughts and prayers are with the farmers and ranchers impacted by Hurricane Helene and the floods following her path. This Category 4 hurricane affects producers across the Southeast from Florida northward into the Appalachians. Below is a list of resources for cattlemen and women to give and seek aid. North Carolina Cattlemen's Association The N.C. Cattlemen's Association is accepting donations that will be remitted to support recovery efforts through trusted organizations. If you would like to make a donation, please make your check payable to NC Cattlemen's Association, 2228 N Main Street, Fuquay-Varina, NC 27526 and include in the memo- Hurricane Helene Response. Please note that NCCA will not be able to provide a charitable donation receipt.  The NC Baptists on Mission also has the capability to accept donations and coordinate volunteers to help those affected by Hurricane Helene. Donations can be accepted through their website Baptists on Mission - Donations. If you would like to make a donation by check, please make your check payable to NC Baptists on Mission PO Box 1107 Cary, NC 27512 Their NC Disaster Relief is funded primarily by donations. 100% of your designated gift will be used in disaster relief efforts  You must designate that the funds are designated for Hurricane Helene Response- Agriculture Needs if that is your intent or it will go to their general response fund.  If you have groups interested in volunteering to support recovery efforts, we encourage you to work through their volunteer program at Baptists on Mission - Get Involved. They will need support for the coming months to help the western region of our state recover from this devastating storm. We encourage those that have expertise on farms to designate “agriculture” in the skills support section when completing the volunteer engagement form.  Florida Cattlemen's Association Producers in Florida can find resources from the Florida Cattlemen's Association here. For those wanting to donate to relief funds via check, please mail to: Florida Cattlemen's Foundation Hurricane Helene Relief P.O. Box 421929 Kissimmee, FL 34742-199 Georgia Cattlemen's Association To support Georgia cattle producers, donations can be sent via mail to: Georgia Cattlemen's Association 100 Cattlemen's Dr. Macon, GA 31220 Contact Georgia Cattlemen's Association at (478)-474-6560 or gca@gabeef.org. Latest Beef Industry News Strike Shuts Ports On East, Gulf Coasts Agricultural exports screeched to a halt Tuesday as dock workers walking off the job on the East and Gulf coasts, after the International Longshoremen's Association's contract expired Tuesday at midnight. The poultry industry — concentrated in southeastern states and still reeling from Hurricane Helene — could be hardest hit in the meat sector, but extended port closures would quickly be felt nationwide, with 13% of beef, 15% of poultry, and 25% of pork production exported annually. Erin Borror, U.S. Meat Export Federation vice president for economic analysis, said that the strike-hit Eastern and Southern ports are responsible for at least $100 million a week worth of pork and beef exports, with a typically faster pace of outbound shipments in the fourth quarter. Senators Introduce Bill To Amend Federal Meat Inspection Act U.S. Sen. Peter Welch, D-Vt., along with Sens. Bernie Sanders, I-Vt., and Cory Booker, D-N.J., introduced the Livestock Owned by Communities to Advance Local (LOCAL) Foods Act. The legislation aims to amend the Federal Meat Inspection Act of 1906 to support small-scale meat producers in rural areas by updating the "personal-use exemption." The bill would allow consumers to purchase live animals from local producers and designate agents for slaughter and processing, easing bottlenecks caused by the limited number of USDA-inspected slaughterhouses. The move is intended to help small farmers avoid delays and continue providing locally sourced food to their communities. Welch said the legislation would cut through regulations that favor large-scale operations, ensuring small producers remain competitive. The bill is supported by several farming organizations, including the Farm Action Fund and the National Family Farm Coalition, as a way to boost local food access and protect farmers' rights to sell directly to consumers. Cheap Burgers Becoming Harder To Find According to a report from Bloomberg, the rising cost of beef is pushing burgers out of reach for many Americans, as the price of fast food continues to climb. In the second quarter of 2024, the average fast-food burger cost $8.41, a 16% increase from five years ago, according to Technomic's Ignite Menu data. Even McDonald's has seen prices surge, with a Big Mac averaging $5.29 — up 21% since 2019. The report said the root of the issue lies in dwindling cattle numbers, which hit a 73-year low in early 2024. Severe droughts, beginning in 2020, have forced ranchers to reduce herds, further driving up prices. While recent rainfall has improved conditions, higher interest rates and operating costs have made it too expensive for ranchers to rebuild herds quickly. Beef prices are expected to rise until at least 2026, with long-term challenges posed by climate change. Fast-food chains are responding with promotions to attract customers, but experts predict that the days of dollar-menu burgers are largely behind us. Consumers may need to adjust to beef becoming a pricier delicacy, similar to pre-McDonald's times, as the cattle industry faces ongoing environmental and economic hurdles. Earn Rewards For Keeping Your Herd Healthy From The Zoetis Rebate Center A reminder to producers that are using such products as Draxxin® KP (tulathromycin and ketoprofen injection) Injectable Solution and Inforce 3® respiratory vaccine, Zoetis rebate programs can help you save and earn rebates when you purchase Zoetis vaccines and parasite control products.  We have the direct links available in the show notes at ranch it up show dot com for your convenience.  Click HERE for additional savings from Zoetis! RanchChannel.Com Now Has The Futures Markets Futures Markets RanchChannel.com now has futures markets at your fingertips!  Feeder Cattle, Live Cattle, Corn, Wheat, Soybeans, Soybean Oil, Milk Class IV, and Ethanol.  Information is provided by DTN and market information may be delayed by as much as 10 minutes.  Click Here for more information! UPCOMING SALES & EVENTS ISA Beefmasters: October 5, 2024, San Angelo, Texas JYJ Red Angus:  November 9, 2024, Columbia, Alabama Clear Springs Cattle Company: November, 20, 2024, Starbuck, MN World Famous Miles City Bucking Horse Sale: May 15 - 18, 2025 BULL SALE REPORT & RESULTS Churchill Cattle Company Van Newkirk Herefords Gardiner Angus Ranch Cow Camp Ranch Jungels Shorthorn Farms Ellingson Angus Edgar Brothers Angus Schaff Angus Valley Prairie Hills Gelbvieh Clear Springs Cattle Company CK Cattle Mrnak Hereford Ranch Frey Angus Ranch Hoffmann Angus Farms Topp Herefords River Creek Farms Upstream Ranch Gustin's Diamond D Gelbvieh Schiefelbein Farms Wasem Red Angus Raven Angus Krebs Ranch Yon Family Farms Chestnut Angus Eichacker Simmentals & JK Angus Windy Creek Cattle Company Pedersen Broken Heart Ranch Mar Mac Farms Warner Beef Genetics Arda Farms & Freeway Angus Leland Red Angus & Koester Red Angus Fast - Dohrmann - Strommen RBM Livestock Weber Land & Cattle Sundsbak Farms Hidden Angus Wheatland Cattle Company Miller Angus Farms L 83 Ranch U2 Ranch Vollmer Angus Ranch A & B Cattle Carter Angus Farms Roller Ranch Montgomery Ranch Jorgensen Farms DLCC Ranch Four Hill Farm North Country Angus Alliance Spruce Hill Ranch Wilson Angus Jorgensen Land & Cattle Motherlode Sale FEATURING Milo Lewis North Carolina Cattlemen's Association https://www.nccattle.com/ @nccattle Kirk Donsbach: Stone X Financial https://www.stonex.com/   @StoneXGroupInc    Mark Vanzee Livestock Market, Equine Market, Auction Time https://www.auctiontime.com/ https://www.livestockmarket.com/ https://www.equinemarket.com/ @LivestockMkt @EquineMkt @AuctionTime Shaye Koester Casual Cattle Conversation https://www.casualcattleconversations.com/ @cattleconvos Questions & Concerns From The Field? Call or Text your questions, or comments to 707-RANCH20 or 707-726-2420 Or email RanchItUpShow@gmail.com FOLLOW Facebook/Instagram: @RanchItUpShow SUBSCRIBE to the Ranch It Up YouTube Channel: @ranchitup Website: RanchItUpShow.com https://ranchitupshow.com/ The Ranch It Up Podcast is available on ALL podcasting apps. https://ranchitup.podbean.com/ Rural America is center-stage on this outfit. AND how is that? Tigger & BEC Live This Western American Lifestyle. Tigger & BEC represent the Working Ranch world and cattle industry by providing the cowboys, cowgirls, beef cattle producers & successful farmers the knowledge and education needed to bring high-quality beef & meat to your table for dinner. Learn more about Jeff 'Tigger' Erhardt & Rebecca Wanner aka BEC here: TiggerandBEC.com https://tiggerandbec.com/ #RanchItUp #StayRanchy #TiggerApproved #tiggerandbec #rodeo #ranching #farming References https://www.stonex.com/ https://www.livestockmarket.com/ https://www.equinemarket.com/ https://www.auctiontime.com/ https://gelbvieh.org/ https://www.imogeneingredients.com/ https://alliedgeneticresources.com/ https://westwayfeed.com/ https://medoraboot.com/ http://www.gostockmens.com/ https://www.imiglobal.com/beef https://www.tsln.com/ https://transova.com/ https://axiota.com/ https://axiota.com/multimin-90-product-label/ https://jorgensenfarms.com/ https://www.bredforbalance.com/ https://ranchchannel.com/ https://www.wrangler.com/ https://www.ruralradio147.com/ https://www.rfdtv.com/ https://www.meatingplace.com/Industry/News/Details/116192 https://www.meatingplace.com/Industry/News/Details/116206 https://www.zoetisus.com/services-and-programs/rebate-center/zoetis-rebate-center https://www.meatingplace.com/Industry/News/Details/116246

Vidcast:  https://www.instagram.com/p/DAbwpgwAdtn/ The Consumer Product Safety Commission and the Inforce company have recalled Ceither Adult Portable Bed Rails.  The bedrail design allows a person to become entrapped either within the bedrail or between the bedrail and the bed leading to possible death by asphyxiation. About 1170 of these bedrails were sold exclusively at amazon.com. Stop using these bedrails.  To receive.a refund, email a photo of the bedrail along with either a purchase receipt or a statement with the date of purchase to xchan524@outlook.com. https://www.cpsc.gov/Recalls/2024/Ceither-Adult-Portable-Bed-Rails-Recalled-Due-to-Serious-Entrapment-and-Asphyxia-Hazards-Violation-of-Federal-Regulations-for-Adult-Portable-Bed-Rails-Sold-Exclusively-on-Amazon-com-by-Inforce #ceither #bedrail #entrapment #asphyxiation #death #recall

TAKEAWAYSChris took InForce products from PetClub 247, which has moved into developing products for humans as well as beloved fur babiesAfter three weeks, Chris's tumor shrunk by more than 30 percent and his immune system doubled after taking the productOnce you have cancer, it will always be there lurking, waiting to reemerge, so supporting the immune system is criticalInForce promotes a healthy immune system, supports wellness, Non-GMO, 100% Vegan, 100% Natural, Gluten-Free, made in U.S.A.

A cloud service is only as good as the team of network engineers who keep it up and running. In this episode, AWS Vice President and Distinguished Engineer Tom Scholl breaks down the importance of security and legwork needed to support the company's massive infrastructure. Corey picks Tom's brain while singing the praises of the AWS DDoS Protection Team, marveling at the scale of the modern internet, and looking ahead to the next generation of network engineers that could land at AWS. If you've ever wondered about the inner workings of the AWS cloud, then this is the discussion for you.Show Highlights: (0:00) Intro(1:09) The Duckbill Group sponsor read(1:42) The importance of a good network for AWS(3:38) Evolution of networking(6:03) Efficiency of the AWS DDoS Protection Team(7:29) AWS Cloud and weathering DDoS attacks(10:03) Policing network abuse(12:08) Walking the SES tightrope and network attacks(15:00) Ensuring the security of the internet(17:53) The Duckbill Group sponsor read(18:37) Scale of the modern internet(20:47) Migrating the AWS network firewall(21:54) Internal network scaling(24:27) Preparing for DDoS disruption(29:14) Finding the next generation of network engineers(32:15) Where to learn more about AWS cloud securityAbout Tom Scholl:Tom Scholl is a VP and Distinguished Engineer at Amazon Web Services (AWS) in the infrastructure organization. His role includes working on AWS's global network backbone, as well as focusing on denial of service detection and mitigation systems. He has been with AWS for over 13 years.Prior to AWS, Tom was a Principal Network Engineer at nLayer and AT&T Labs (formerly SBC Telecom). He also previously held network engineering roles at OptimalPATH Digital Network and ANET Internet Services. Links Referenced:AWS Security Blog: https://aws.amazon.com/blogs/security/How AWS threat intelligence deters threat actors: https://aws.amazon.com/blogs/security/how-aws-threat-intelligence-deters-threat-actors/Using AWS Shield Advanced protection groups to improve DDoS detection and mitigation: https://aws.amazon.com/blogs/security/using-aws-shield-advanced-protection-groups-to-improve-ddos-detection-and-mitigation/AWS re:Inforce 2024 presentation on Sonaris and MadPot: https://www.youtube.com/watch?v=38Z9csvyFDgNANOG 2023 presentation on AWS networking infrastructure: https://www.youtube.com/watch?v=0tcR-iQce7s AWS re:Invent 2022 presentation on AWS networking infrastructure: https://www.youtube.com/watch?v=HJNR_dX8g8c AWS re:Invent 2022 presentation on Scaling network performance on next-gen Amazon EC2 instances: https://www.youtube.com/watch?v=jNYpWa7gf1A&t=1373sIEEE paper on Scalable Relatable Diagram (SRD): https://ieeexplore.ieee.org/document/9167399SponsorThe Duckbill Group: https://www.duckbillgroup.com/

Telegram's CEO is arrested by French police, presumably over moderation failures. A cyberattack disrupted services at Seattle-Tacoma International Airport and the Port of Seattle. SonicWall has warned customers of a critical vulnerability that could lead to unauthorized access or a firewall crash. Dutch and French regulators fined Uber €290 million for failing to protect the privacy of EU drivers. Microsoft will host a cybersecurity conference next month in response to the disastrous CrowdStrike software update. Radio Free Europe/Radio Liberty looks at Iran's active attempts to interfere in the upcoming U.S. presidential election. Our guests are Danielle Ruderman, Senior Manager for Worldwide Security Specialists at AWS, and Adam Mikeal, CISO at Texas A&M. They spoke with N2K's Brandon Karpf about CISO Circles, security challenges faced in higher education, and fostering the culture of security. Pig Butchering devastates a small town bank.  Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Our guests are Danielle Ruderman, Senior Manager for Worldwide Security Specialists at AWS, and Adam Mikeal, CISO at Texas A&M. They spoke with N2K's Brandon Karpf about CISO Circles, security challenges faced in higher education, and fostering the culture of security. Brandon spoke with Danielle and Adam at AWS' re:Inforce 2024.  Selected Reading Telegram CEO Pavel Durov arrested at French airport (BBC) Is Telegram really an encrypted messaging app? – A Few Thoughts on Cryptographic Engineering (Cryptography Engineering) The Port of Seattle and Sea-Tac Airport say they've been hit by ‘possible cyberattack' (TechCrunch) Nearly 32 Million Documents, Invoices, Contracts, and Agreements Exposed Online by Global Field Service Management Provider (Website Planet) SonicWall Patches Critical SonicOS Vulnerability (SecurityWeek) Uber fined €290 million for sending drivers' data outside Europe (Politico) Microsoft plans September cybersecurity event to discuss changes after CrowdStrike outage (CNBC) Iran Tries To 'Storm' U.S. Election With Russian-Style Disinformation Campaign (Radio Free Europe/Radio Liberty) Audit finds notable security gaps in FBI's storage media management (Bleeping Computer) Cryptocurrency 'pig butchering' scam wrecks Kansas bank, sends ex-CEO to prison for 24 years (CNBC) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

The Dem's 2024 party platform touches on cybersecurity goals. The feds warn of increased Iranian influence operations. A severe security flaw has been discovered in a popular WordPress donation plugin. The Lazarus Group exploits a Windows zero-day to install a rootkit. Krebs on Security takes a closer look at the significant data breach at National Public Data. Toyota confirms a data breach after their data shows up on a hacking forum. A critical Jenkins vulnerability is added to CISA's Known Exploited Vulnerabilities catalog. Cybercriminals steal credit card info from the Oregon Zoo. Guest CJ Moses, CISO at Amazon, discussing partnership and being a good custodian of the community in threat intel and information sharing. CISA gets new digs.  Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Guest CJ Moses, CISO at Amazon, speaks with N2K's Brandon Karpf about partnership and being a good custodian of the community in threat intel and information sharing at re:Inforce 2024. Selected Reading Democratic Party Platform Contains Three Cyber Goals (Metacurity) US warns of Iranian hackers escalating influence operations (Bleeping Computer) Critical WordPress Plugin RCE Vulnerability Impacts 100k+ Sites (Cyber Security News) Windows driver zero-day exploited by Lazarus hackers to install rootkit (Bleeping Computer) National Public Data Published Its Own Passwords (Krebs on Security) Toyota confirms breach after stolen data leaks on hacking forum (Bleeping Computer) Critical Jenkins vulnerability added to CISA's known vulnerabilities catalog (SC Media) Cybercriminals siphon credit card numbers from Oregon Zoo website (The Record) CISA to Get New $524 Million Headquarters in DC, Backed by Inflation Reduction Act Funding (SecurityWeek) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

The Trump campaign claims its email systems were breached by Iranian hackers. A Nashville man is arrested as part of an alleged North Korean IT worker hiring scam. At Defcon, researchers reveal significant vulnerabilities in Google's Quick Share. Ransomware attacks hit an Australian gold mining company as well as multiple U.S. local governments. GPS spoofing is a matter of time. Cisco readies another round of layoffs. Nearly 2.7 billion records of personal information for people in the United States have been shared on a hacking forum. Our own Rick Howard speaks with Mark Ryland, Director of Amazon Security, about formal verification.  A hacker hacks the hackers. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest On today's guest slot, N2K's CSO Rick Howard speaks with Mark Ryland, Director of Amazon Security at AWS, about formal verification, which is logical proofs about correctness of systems, at AWS re:Inforce. Rick and Mark caught up at AWS re:Inforce 2024.  Selected Reading Experts warn of election disruptions after Trump says campaign was hacked (Washington Post) Nashville man arrested for running “laptop farm” to get jobs for North Koreans (Ars Technica) Google Patches Critical Vulnerabilities in Quick Share After Researchers' Warning (Hackread) Australian gold mining company Evolution Mining announces ransomware attack (The Record) GPS spoofers 'hack time' on commercial airlines, researchers say (Reuters) Exclusive: Cisco to lay off thousands more in second job cut this year (Reuters) Hackers leak 2.7 billion data records with Social Security numbers (Bleeping Computer) Local gov'ts in Texas, Florida hit with ransomware as cyber leaders question best path forward (The Record) Simple Coding Errors Lead to Major Ransomware Takedown (Cybersecurity News) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

A North Korean hacker is indicted for major cyberattacks. CrowdStrike's in recovery mode. Phishing thrives in the wake of BSOD chaos. Wiz spells out no to Alphabet's $23bn offer. France goes full clean-up. Israel's secret shield in spyware saga. KOSA and COPPA 2.0 promise safer surfing for kids. N2K's CSO Rick Howard speaks with Steve Schmidt, CSO of Amazon, about the culture of security and what it means to the CSO role. And last but not least, hacking can happen to anyone. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest On today's guest slot, N2K's CSO Rick Howard speaks with Steve Schmidt, CSO of Amazon, about the culture of security and what it means to the CSO role. They touch upon the SEC reporting requirements and how testing is never done. Rick and Steve caught up at AWS re:Inforce 2024.  Selected Reading US indicts alleged North Korean state hacker for ransomware attacks on hospitals (The Record)  North Korean Military Hacker Indicted for String of US Attacks (Metacurity) CrowdStrike says over 97% of Windows sensors back online (Reuters) Threat Actors leveraging the recent CrowdStrike update outage (FortiGuard Labs)  Cyber-security firm rejects $23bn Google takeover (BBC) ECB's cyber security test shows 'room for improvement' for banks (Reuters)   France launches large-scale operation to fight cyber spying ahead of Olympics (The Record)  Israel Maneuvered to Prevent Disclosure of State Secrets amid WhatsApp vs NSO Lawsuit (Forbidden Stories)   KOSA, COPPA 2.0 Likely to Pass U.S. Senate (Inside Privacy)  A North Korean Hacker Tricked a US Security Vendor Into Hiring Him—and Immediately Tried to Hack Them (WIRED)  North Korean Fake IT Worker FAQ (KnowBe4)  Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

A Crowdstrike update takes down IT systems worldwide. A U.S. District Court judge dismissed most charges against SolarWinds. Sophos examines the ransomware threat to the energy sector. European web hosting companies suspend Doppelgänger propaganda. An Australian digital prescription services provider confirms a ransomware attack affecting nearly 13 million. A pair of Lockbit operators plead guilty. N2K's CSO Rick Howard speaks with AWS' CISO Chris Betz about strong security cultures and AI. A look inside the world's largest live-fire cyber-defense exercise.  Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guests Dave is joined by Andy Ellis, to discuss today's top story on the CrowdStrike-induced Microsoft outage. N2K's CSO Rick Howard recently caught up with AWS' CISO Chris Betz at the AWS re:Inforce 2024 event. They  discuss strong security cultures and AI. You can watch Chris' keynote from the event here. Read Chris' blog post, “How the unique culture of security at AWS makes a difference.” Selected Reading Huge Microsoft Outage Linked to CrowdStrike Takes Down Computers Around the World (WIRED) Counting the Costs of the Microsoft-CrowdStrike Outage (The New York Times) Major Microsoft 365 outage caused by Azure configuration change (Bleeping Computer) Most of SolarWinds hacking suit filed by SEC dismissed (SC Magazine) Ransomware Remains a Major Threat to Energy (BankInfoSecurity) Investigation prompts European hosting companies to suspend accounts linked to Russian disinfo (The Record) MediSecure Data Breach Impacts 12.9 Million Individuals (SecurityWeek) Russians plead guilty to involvement in LockBit ransomware attacks (Bleeping Computer) Inside the world's largest ‘live-fire' cyber-defense exercise (CSO Online) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

AT&T wireless announces a massive data breach. NATO will build a cyber defense center in Belgium. The White House outlines cybersecurity budget priorities.A popular phone spyware app suffers a major data breach.Some Linksys routers are sending user credentials in the clear. Sysdig describes Crystalray malware. A massive phishing campaign is exploiting Microsoft SharePoint servers. Germany strips Huawei and ZTE from 5G infrastructure. Our guest is Brigid Johnson, Director of AWS Identity, on the importance of identity management. The EU tells X-Twitter to clean up its act or pay the price. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest At the recent AWS re:Inforce 2024 conference, N2K's Brandon Karpf spoke with Brigid Johnson, Director of AWS Identity, about the importance of identity and where we need to go. You can watch a replay of Brigid's session at the event, IAM policy power hour, here.  Selected Reading AT&T Details Massive Breach of Customers' Call and Text Logs (Data Breach Today) NATO Set to Build New Cyber Defense Center (Infosecurity Magazine) New Presidential memorandum sets cybersecurity priorities for FY 2026, tasking OMB and ONCD to evaluate submissions (Industrial Cyber) mSpy Data Breach: Millions of Customers' Data Exposed (GB Hackers) Advance Auto Parts' Snowflake Breach Hits 2.3 Million People (Infosecurity Magazine) These Linksys routers are likely transmitting cleartext passwords (TechSpot) Known SSH-Snake bites more victims with multiple OSS exploitation (CSO Online) Beware of Phishing Attack that Abuses SharePoint Servers (Cyber Security News) Germany to Strip Huawei From Its 5G Networks (The New York Times) EU threatens Musk's X with a fine of up to 6% of global turnover (The Record) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

Microsoft is phasing out Android use for employees in China. Mastodon patches a security flaw exposing private posts. OpenAI kept a previous breach close to the vest. Nearly 10 billion passwords are leaked online. A Republican senator presses CISA for more information about a January hack. A breach of the Egyptian Health Department impacts 122,000 individuals. South Africa's National Health Laboratory Service (NHLS) suffers a ransomware attack. Eldorado is a new ransomware-as-a-service offering. CISA adds a Cisco command injection vulnerability to its Known Exploited Vulnerabilities catalog. N2K's CSO Rick Howard catches up with AWS' Vice President of Global Services Security Hart Rossman to discuss extending your security around genAI.  Ransomware scrambles your peace of mind. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Recently N2K's CSO Rick Howard caught up with AWS' Vice President of Global Services Security Hart Rossman at the AWS re:Inforce event. They discussed extending your security around genAI. Watch Hart's presentation from AWS re:Inforce 2024 - Securely accelerating generative AI innovation. Selected Reading Microsoft Orders China Staff to Switch From Android Phones to iPhones for Work (Bloomberg) Mastodon: Security flaw allows unauthorized access to posts (Stack Diary) A Hacker Stole OpenAI Secrets, Raising Fears That China Could, Too (The New York Times) “A treasure trove for adversaries”: 10 billion stolen passwords have been shared online in the biggest data leak of all time (ITPro) Senate leader demands answers from CISA on Ivanti-enabled hack of sensitive systems (The Record) Egyptian Health Department Data Breach: 120,000 Users' Data Exposed (GB Hackers) South African pathology labs down after ransomware attack (The Cape Independent) New Eldorado ransomware targets Windows, VMware ESXi VMs (Bleeping Computer) CISA adds Cisco NX-OS Command Injection bug to its Known Exploited Vulnerabilities catalog (Security Affairs) New RUSI Report Exposes Psychological Toll of Ransomware, Urges Action (Infosecurity Magazine) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

What is the future of AI Security and Data Protection? At AWS re:Inforce in Philadelphia this year, Ashish spoke to Dan Benjamin, Head of Data, Identity and AI Security at Prisma Cloud about the new category of AI-SPM (Artificial Intelligence Security Posture Management) and why does it fit within all the other toolings organisations have. They spoke about the importance of building an AI and data inventory, understanding AI access, and the critical role of DSPM (Data Security Posture Management) in creating effective AI security controls. Guest Socials:⁠ ⁠⁠Dan's Linkedin⁠ Podcast Twitter - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠@CloudSecPod⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Cloud Security Podcast- Youtube⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Cloud Security Newsletter ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ - ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Cloud Security BootCamp Questions asked: 00:00 Introduction 02:09 A bit about Dan 02:29 What is AISPM? 03:16 How should CISOs tackle AI Security? 06:16 Right Controls around AI Services 07:32 AISPM vs CSPM 09:52 The role of DSPM 10:25 Tackling data security in world of AI 13:28 Maturity Curve for CISOs to consider 16:36 Security Teams for AI Security 19:51 The Fun Section

TeamViewer tackles APT29 intrusion. Microsoft widens email breach alerts. Uncovering a malware epidemic. Google's distrust on Entrust. Safeguarding critical systems. FTC vs. MGM. Don't forget to backup your data. Polyfill's accidental exposé. Our guest is Caitlyn Shim, Director of AWS Cloud Governance, and she recently joined N2K's Rick Howard at AWS re:Inforce event. They're discussing  cloud governance, the growth and development of AWS, and diversity. And a telecom titan becomes telecom terror. Our 2024 N2K CyberWire Audience Survey is underway, make your voice heard and get in the running for a $100 Amazon gift card. Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Guest Caitlyn Shim, Director of AWS Cloud Governance, joined N2K's Rick Howard at AWS re:Inforce event recently in Philadelphia, PA. They spoke about cloud governance, the growth and development of AWS, and diversity. Caitlyn was part of the Women of Amazon Security Panel at the event. You can read more about Caitlyn and her colleagues as they discuss their diverse paths into security and offer advice for those looking to enter the field  here.  Selected Reading TeamViewer investigating intrusion of corporate IT environment (The Record) Microsoft reveals further emails compromised by Russian hack (Engadget) Chicago Children's Hospital Says 791,000 Impacted by Ransomware Attack (SecurityWeek) Unfurling Hemlock: New threat group uses cluster bomb campaign to distribute malware (Outpost 24) Google to block sites using Entrust certificates in bombshell move (The Stack)  US House Subcommittee examines critical infrastructure vulnerabilities, role of cyber insurance in resilience efforts (Industrial Cyber)  FTC Defends Investigation Into Cyberattack on MGM as Casino Giant Seeks to Block Probe (The National Law Journal) This is why you need backups: A cyber attack on an Indonesian data center caused havoc for public services – and its forcing a national rethink on data security (ITPro) Polyfill.io, BootCDN, Bootcss, Staticfile attack traced to 1 operator (Bleeping Computer)  ISP Sends Malware to Thousands of Customers to Stop Using File-Sharing Services (Cybersecurity News)   Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

Amazon Web Services recently held their re:Inforce conference, as the company attempts to partner with customers to deliver a securre environment. Following the shared responsibility model concept that was the focus last year, it seems that the company is emphasizing that security is a job for everyone in the modern cloud. We also saw product announcements from AWS, including enhancements to Nitro that control access to the underlying infrastructure. Time Stamps: 0:00 - Cold Open 0:54 - Welcome to the Rundown 1:47 - Veeam Looks to Cyber-Resiliency 6:21 - Enthusiasm for AI in the Enterprise is Waning 10:44 - Microsoft to Improve Security after Recall Delay 14:16 - Oracle, Microsoft, and OpenAI Join Forces 17:33 - Pure Storage Confirms Unauthorized Access 19:53 - Google Shares the Scope of Enterprise Cloud at Cloud Field Day 25:16 - Announcements from AWS re:Inforce 37:33 - The Weeks Ahead 39:56 - Thanks for Watching Hosts: Stephen Foskett: https://www.twitter.com/SFoskett Krista Macomber, Research Director of Cybersecurity at The Futurum Group: https://www.linkedin.com/in/krista-macomber/ Follow Gestalt IT Website: https://www.GestaltIT.com/ Twitter: https://www.twitter.com/GestaltIT LinkedIn: https://www.linkedin.com/company/Gestalt-IT Tags: #Rundown, @Veeam, @Microsoft, @OpenAI, @Oracle, @PureStorage, @SnowflakeDB, @Google, @GoogleCloud, @AWSCloud, @TheFuturumGroup, @GestaltIT, @SFoskett, @Krista_Lee, @TechFieldDay,

It was a big week for cybersecurity for Seattle's tech giants. Microsoft President Brad Smith was in Washington D.C., testifying before the U.S. House Homeland Security Committee about the Redmond company's security challenges. Listen for highlights at the end of the show.  Meanwhile, Amazon held its annual AWS re:Inforce cloud security conference in Philadelphia.The rise of AI has added some big new wrinkles to the issue of cybersecurity, and AI was one of the main topics in a conversation that I had a few weeks ago with one of the people who keynoted the AWS event this week, Steve Schmidt, Amazon's chief security officer. Hosted by Todd Bishop; edited by Curt Milton.See omnystudio.com/listener for privacy information.

Microsoft's President admits security failures in congressional testimony. Paul Nakasone joins OpenAI's board. The feds hold their first AI tabletop exercise. CISA reports on the integration of space-based infrastructure. Cleveland city hall remains closed after a cyber attack. Truist commercial bank confirms a data breach. Rockwell Automation patches three high-severity vulnerabilities. University of Illinois researchers develop autonomous AI hacking agents. Arynn Crow, Sr Manager of AWS User Authentication Products, talks with N2K's Brandon Karpf about security through MFA and FIDO Alliance passkeys, and her work on the Digital Identity Advancement Foundation. Can an AI run for mayor? Our 2024 N2K CyberWire Audience Survey is underway, make your voice heard and get in the running for a $100 Amazon gift card. Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest In the first of our interviews captured during the AWS re:Inforce event this past week, guest Arynn Crow, Senior Manager of AWS User Authentication Products, talks with N2K's Brandon Karpf about security through MFA and FIDO Alliance passkeys, and her work on the Digital Identity Advancement Foundation. Selected Reading Microsoft Admits Security Failings Allowed China's US Government Hack (Infosecurity Magazine) OpenAI adds Trump-appointed former NSA director Paul M. Nakasone to its board (The Washington Post) CISA leads first tabletop exercise for AI cybersecurity (CyberScoop) New CISA report addresses zero trust in space, boosting security for satellites and ground infrastructure (Industrial Cyber)  CISA adds Android Pixel, Microsoft Windows, Progress Telerik Report Server bugs to its Known Exploited Vulnerabilities catalog (Security Affairs) Insurance giant Globe Life investigating web portal breach (Bleeping Computer) Cleveland remains paralyzed by cyberattack (News 5 Cleveland) Truist Bank confirms breach after stolen data shows up on hacking forum (Bleeping Computer) Rockwell Automation Patches High-Severity Vulnerabilities in FactoryTalk View SE (SecurityWeek) Researchers at the University of Illinois have developed AI Agents that can Autonomously Hack Websites and Find Zero-Day Vulnerabilities (MarkTechPost) Wyoming mayoral candidate wants to govern by AI bot (Ars Technica)   Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

In today's episode, we explore recent major cybersecurity upgrades aimed at safeguarding the American healthcare system, including a new initiative by Microsoft to provide critical cybersecurity resources to rural hospitals. Additionally, we delve into the Ticketmaster-Snowflake data breach perpetrated by ShinyHunters, targeting 560 million users and exposing key vulnerabilities in cloud environments. Lastly, we cover AWS's new and improved security features announced at the re:Inforce conference, which include added multi-factor authentication options, expanded malware protection for Amazon S3, and updated AI apps governance. Read more at: https://www.helpnetsecurity.com/2024/06/12/american-healthcare-cybersecurity/ https://thehackernews.com/2024/06/lessons-from-ticketmaster-snowflake.html https://www.helpnetsecurity.com/2024/06/12/aws-security-features/ Thanks to Jered Jones for providing the music for this episode. https://www.jeredjones.com/ Logo Design by https://www.zackgraber.com/ Tags Microsoft, Cyberattacks, Healthcare systems, Rural hospitals, ShinyHunters, Breach, Data, Cybersecurity, AWS, FIDO2 passkeys, Malware protection, Cloud environment Search Phrases How Microsoft is protecting rural hospitals from cyberattacks Cybersecurity initiatives for rural healthcare by Microsoft ShinyHunters data breach impact on cloud security Essential measures to prevent cyberattacks in cloud environments Latest AWS security features from re:Inforce conference How FIDO2 passkeys enhance cloud environment security Updated malware protection for AWS S3 buckets Microsoft and Biden-Harris Administration cybersecurity efforts Impact of ShinyHunters breach on data security practices Advanced multi-factor authentication in AWS cloud environments Major cybersecurity upgrades announced to safeguard American healthcare https://www.helpnetsecurity.com/2024/06/12/american-healthcare-cybersecurity/ Rising Threats: Cyberattacks on American healthcare systems soared 128% from 2022 to 2023, leading to significant disruptions in hospital operations and payment systems. Actionable Insight: Healthcare professionals should stay vigilant and ensure their organizations have updated cybersecurity measures to mitigate risks. Impact of Recent Attacks: In early 2024, a major cyberattack affected one-third of healthcare claims in the U.S., delaying payments and services. Critical Implication: Entry to mid-level cybersecurity professionals should focus on protecting payment systems and ensuring quick recovery plans are in place. Government Initiatives: The Biden-Harris Administration launched several initiatives to bolster healthcare cybersecurity, including a new gateway website and voluntary performance goals. Actionable Insight: Healthcare institutions should leverage these resources to enhance their cybersecurity posture. Collaboration for Solutions: In May 2024, the White House gathered industry leaders to discuss cybersecurity challenges and promote secure-by-design solutions. Engagement Suggestion: Ask listeners how their organizations collaborate with other entities to share threat intelligence and improve security. ARPA-H UPGRADE Program: The Advanced Research Projects Agency for Health introduced the UPGRADE program, investing over $50 million in tools to defend hospital IT environments. Actionable Insight: IT teams should explore participation in this program to access cutting-edge cybersecurity tools and support. Rural Hospital Support: Cyber disruptions severely impact rural hospitals. Leading tech companies, including Microsoft and Google, committed to providing free or discounted cybersecurity resources to these institutions. Critical Implication: Rural hospital IT staff should take advantage of these offers to strengthen their defenses against cyberattacks. Microsoft's Cybersecurity Program: Microsoft announced a program offering up to 75% discounts on security products, free cybersecurity assessments, and training for rural hospitals. Actionable Insight: Rural healthcare providers should engage with Microsoft's program to improve their cybersecurity measures and resilience. Google's Contributions: Google will offer endpoint security advice and discounted communication tools to rural hospitals, along with a pilot program to tailor security solutions to their needs. Engagement Suggestion: Prompt listeners to consider what specific cybersecurity challenges their rural hospitals face and how these new initiatives could assist them. Continued Efforts: The White House and industry leaders emphasize the importance of private-public partnerships to ensure the security and functionality of healthcare systems nationwide. Efficiency Tip: Cybersecurity professionals should stay informed about these partnerships and actively participate to benefit from shared knowledge and resources. Lessons from the Ticketmaster-Snowflake Breach https://thehackernews.com/2024/06/lessons-from-ticketmaster-snowflake.html ShinyHunters Breach: Last week, hacker group ShinyHunters allegedly stole 1.3 terabytes of data from 560 million Ticketmaster users. The breach could expose massive amounts of personal data and has sparked significant concern. Listener Question: How can we ensure our data is safe with such large-scale breaches happening? Actionable Insight: Regularly update passwords and enable multi-factor authentication (MFA) on all accounts. Live Nation Confirms Breach: Live Nation confirmed the breach in an SEC filing, stating unauthorized activity occurred in a third-party cloud database. An investigation is ongoing, and law enforcement is involved. Listener Question: What steps should companies take immediately after discovering a breach? Actionable Insight: Initiate a comprehensive investigation, notify affected parties, and work with law enforcement. Santander Also Affected: ShinyHunters claim to have data from Santander, affecting millions of customers and employees in Chile, Spain, and Uruguay. The breach involved a third-party provider. Listener Question: Should we be worried about third-party services? Actionable Insight: Ensure third-party services adhere to stringent security protocols and regularly review their security measures. Snowflake Connection: Both Ticketmaster and Santander used Snowflake for their cloud databases. Snowflake warned of increased cyber threats targeting customer accounts, urging users to review logs for unusual activity. Listener Question: What can companies do to safeguard their cloud data? Actionable Insight: Enforce MFA, set network policies to limit access, and regularly rotate credentials. Snowflake's Response: Snowflake's CISO clarified their system wasn't breached; single-factor authentication vulnerabilities were exploited. They recommend MFA and network policy rules for enhanced security. Mitiga's Research: Mitiga found the attacks exploited environments without two-factor authentication, primarily using commercial VPN IPs to execute attacks. Listener Question: How can we protect against these types of attacks? Actionable Insight: Implement and enforce MFA, utilize corporate SSO, and regularly monitor for unusual login activity. Cloud Security Challenges: Modern cloud environments limit some security controls. Ensure platforms offer APIs for privileged identity management and integrate with corporate security. Listener Question: What should we look for in a cloud service provider? Actionable Insight: Choose providers that support MFA, SSO, password rotation, and centralized logging. Non-Human Identities: Protecting non-human identities like service accounts is challenging but necessary. Snowflake provides guidance on securing these accounts. Listener Question: How do we secure non-human identities? Actionable Insight: Use strong, unique passwords and rotate credentials frequently for service accounts. Cost of Cyber Attacks: Cybercriminals aim to maximize profit through mass, automated attacks like credential stuffing. Simple security measures can make these attacks less feasible. Listener Question: What simple measures can we take to protect against cyber attacks? Actionable Insight: Implement SSO, MFA, and regular password rotation to increase the cost and complexity for attackers. Remember, these insights are not just theoretical—they can help you strengthen your organization's security posture today!` AWS unveils new and improved security features https://www.helpnetsecurity.com/2024/06/12/aws-security-features/ Key Information and Actionable Insights Multi-Factor Authentication (MFA) Upgrades: New Option: AWS introduces support for FIDO2 passkeys as an additional MFA method. Security Assurance: FIDO2 security keys offer the highest level of security, ideal for environments with stringent regulatory requirements (FIPS-certified devices). Considerations: Evaluate passkey providers' security models, especially for access and recovery. Enhanced Access Management: IAM Access Analyzer Update: Now assists in identifying and removing unused roles, access keys, and passwords. Permissions Management: Helps set, verify, and refine unused permissions to maintain a streamlined and secure access environment. Malware Protection for Amazon S3: GuardDuty Expansion: Now detects malicious file uploads in S3 buckets. Configuration Options: Teams can set up post-scan actions like object tagging or use Amazon EventBridge to manage malware isolation processes. AI Apps Governance: Audit Manager Update: New AI best practice framework simplifies evidence collection and ongoing compliance audits. Standard Controls: Includes 110 pre-configured controls organized under domains such as accuracy, fairness, privacy, resilience, responsibility, safety, security, and sustainability. Additional Improvements: Log Analysis: Simplified through natural language queries that produce SQL queries (currently in preview). Network Services Integration: Streamlined process for incorporating firewalls, IDS/IPS, and other network services into customers' WANs.

Microsoft makes Recall opt-in. The Senate holds hearings on federal cybersecurity standards. Snowflake's scrutiny snowballs. New York Times source code is leaked online. Ransomware leads to British hospitals' desperate need for blood donors. Cisco Talos finds 15 serious vulnerabilities in PLCs. Sticky Werewolf targets Russia and Belarus. Frontier Communications warns 750,000 customers of a data breach. Chinese nationals get prison time in Zambia for cybercrimes. N2K's CSO Rick Howard speaks with Danielle Ruderman, Security GTM Leader, AWS about what keeps CISOs up at night. DIY cell towers can land you in hot water.  Our 2024 N2K CyberWire Audience Survey is underway, make your voice heard and get in the running for a $100 Amazon gift card. Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest N2K's CSO Rick Howard speaks with Danielle Ruderman, Security GTM Leader, AWS about what keeps CISOs up at night and learnings from AWS CISO Circles. Today, our team is at the AWS re:Inforce this week. Stay tuned for our coverage. Selected Reading Windows won't take screenshots of everything you do after all — unless you opt in (The Verge)  US Senate Committee holds hearing on harmonizing federal cybersecurity standards to address business challenges (Industrial Cyber) What Snowflake isn't saying about its customer data breaches (TechCrunch) New York Times source code stolen using exposed GitHub token (Bleeping Computer) London Hospitals Seek Biologics Backup After Ransomware Hit (GovInfo Security) Cisco Finds 15 Vulnerabilities in AutomationDirect PLCs (SecurityWeek) Sticky Werewolf targets the aviation industry in Russia and Belarus (Security Affairs) Frontier warns 750,000 of a data breach after extortion threats (Bleeping Computer) 22 Chinese Nationals Sentenced to Long Prison Terms in Zambia for Multinational Cybercrimes (SecurityWeek) Two arrested in UK over fake cell tower smishing campaign (The Register) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show.  Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices

In this podcast episode, we delve into the crucial topic of security related to AI and Machine Learning, with a particular focus on Generative AI. As AI and ML technologies rapidly advance, it is imperative to implement a robust security strategy based on the principle of Defense in Depth. We'll explore the potential security and privacy risks associated with AI/ML systems, highlighting the importance of Responsible AI practices. Additionally, we'll discuss practical approaches to implementing security measures within specific AI/ML services, such as Amazon Bedrock, a secure and compliant foundation for building and deploying AI/ML applications on AWS. Join us as we navigate the intricate landscape of AI/ML security, equipping you with the knowledge and best practices to safeguard your AI/ML deployments and mitigate potential risks.AWS re:Inforce 2024:https://hub.reinforce.awsevents.com/attendee-portal/catalog/?filters=5B4D572F-79F0-EE11-81DE-9CF328ECC866&search=APS351AWS Hosts: Nolan Chen & Malini ChatterjeeEmail Your Feedback: rethinkpodcast@amazon.com

In this episode, Jim and Jeff welcome back Sandy Bird, the CTO and Co-Founder of Sonrai Security, for a sequel to their first sponsor spotlight. Sandy returns to discuss the groundbreaking Cloud Permissions Firewall with Permissions on Demand. The trio dives into how this new solution revolutionizes the way organizations can clamp down on excessive cloud permissions, streamline operations, and secure their cloud environments with unprecedented speed and efficiency. The discussion illuminates the concept of "default deny," the exhilaration of zapping "zombie" identities, and the seamless integration with cloud native tools. Sandy also shares insights on how customers can measure success with Sonrai's solution and the significant security benefits provided. For a visual walkthrough of Sonrai's Cloud Permissions Firewall, visit http://sonrai.co/idac to see the demo in action and learn how you can try it out with a 14-day free trial. And if you're at RSA, AWS re:Inforce, or Gartner IAM, look for the Sonrai Security booth and experience the epiphany moment for yourself. Connect with Sandy on LinkedIn: https://www.linkedin.com/in/sandy-bird-835b5576 Learn more about Sonrai Security: https://sonrai.co/idac Introducing the Cloud Permissions Firewall (YouTube): https://www.youtube.com/watch?v=ffQbM6KGDbY Connect with us on LinkedIn: Jim McDonald: https://www.linkedin.com/in/jimmcdonaldpmp/ Jeff Steadman: https://www.linkedin.com/in/jeffsteadman/ Visit the show on the web at idacpodcast.com and follow @IDACPodcast on Twitter. Episode Keywords Identity And Access Management (Iam), Cloud Security, Aws, Azure, Gcp (Google Cloud Platform), Least Privilege, Identity Risk, Cloud Permissions Firewall, Infrastructure As Code, Security Operations (Secops), Cloud Operations (Cloudops), Permissions Management, Excessive Privileges, Zombie Identities, Identity Governance, Access Analyzer, Sensitive Permissions, Role-Based Access Control (Rbac), Service Control Policies (Scp), Cloud Native Security

Join Allen Helton and Jeremiah Dunham as they explore math in the world of computer science. Do developers use it as much as they thought they would or is it abstracted away to a point where we have no idea? What if there was a way to use math to prove the correctness of your code instead of writing unit tests? Guess what? It's possible. Tune into the episode as Allen and Jeremiah talk about the future of testing and exactly how you can (or can't) guarantee your code does what you expect it to. About Jeremiah Jeremiah is a Senior Software Development Manager on the AWS IAM Access Analyzer team. In 9+ years at Amazon, he's launched new services and features (AWS Elemental MediaStore and AWS IAM Access Analyzer custom policy checks), helped hundreds of people adopt AWS (including your podcast host!), received 10 patents, and spoken at several conferences, including re:Invent and re:Inforce. He cares deeply about using math to make the world a better place. When he's not thinking about things related to math, you'll probably find him running or enjoying a craft beer. Links LinkedIn -https://www.linkedin.com/in/jdunham AWS IAM Access Analyzer - https://aws.amazon.com/iam/access-analyzer Custom Policy Check Science Blog - https://www.amazon.science/blog/custom-policy-checks-help-democratize-automated-reasoning Dafny - https://dafny.org --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

https://chtbl.com/track/118312/traffic.libsyn.com/secure/talkinglead/TLP_500_TL_Friends_GAW_Adrian_Kelgren.mp3 Talking Lead's Monumental 500th Episode is coming in hot! Recorded from the KELTEC facilities in Cocoa, Florida, Lefty is joined by Chad Enos and Adrian Kellgren to make the big announcement for the Talking Lead & Friends FREEDOM GIVEAWAY! To celebrate Talking Lead's 10 years, 500 episodes and the official release of our new logo we are giving you the chance to win the most Badass-Freedom-Loving-Firearms package of a life time (starting in September). We have teamed up with KELTEC, Mission First Tactical, Kraken Case Company, Walker's Ear, Tactical RX, SEAL 1, Vortex, Inforce, STA Blades, Firebird Targets, Defiant Munitions, Dipstick Branding & Black Tie Digital Marketing to bring you everything needed to exercise your 2nd Amendment Freedom! Adrian Kellgren is a former Navy Pilot and now Director of Industrial Production at KELTEC. Adrian served for 15 years, deployed twice (North Arabian Seas and Afghanistan). He flew E-2 Hawkeyes and C-40 Clippers. During one of his missions he and his crew witnessed a UFO / UAP (Unidentified Flying Object / Unidentified Aerial Phenomenon) We get the full unedited story! We also get the exclusive on KELTEC's new SBR Firearm in 5.7x28mm, Adrian goes through the "New Guy" gauntlet of questions and we get some great personal George Kellgren stories. Chad Enos, Adrian Kellgren & Lefty recording the 500th Episode of the Talking Lead Podcast at KELTEC in Cocoa, FL Matt Stanek preparing media for the big Talking Lead & Friends Freedom Giveaway Lefty holding the KELTEC RDB Defender. Adrian Kellgren looking on Lefty, Adrian Kellgren & Chad Enos at KELTEC Cocoa, FL for the 5o0th episode of Talking Lead

In this episode, I spoke with Randall Hunt, who's the VP of Cloud Strategy and Innovation at Caylent and had previously worked at Vendia, Facebook AI, AWS and SpaceX.We talked about AWS Bedrock, what is it and how it works and saw a demo of a simple AI application built with Bedrock and LangChain. Randall explained the advantages of using Bedrock and why tales of AWS's supposedly weakness in AI are far-fetched.I had a lot of fun talking to Randall and learnt a lot from the conversation and I hope you will too. This episode includes some live demo, which is best enjoyed if you watch the episode on YouTube here.Links from the episode:The "Attention is all you need" whitepaper from 2017OWASP top 10 for LLM applicationsPinecone vector database for AIMomento announced its upcoming serverless vector database AWS re:Inforce 2023 talk on data security with BedrockCaylent's career pageFor more stories about real-world use of serverless technologies, please subscribe to the channel and follow me on X as @theburningmonk.And if you're hungry for more insights, best practices, and invaluable tips on building serverless apps, make sure to subscribe to our free newsletter and elevate your serverless game!Opening theme song:Cheery Monday by Kevin MacLeodLink: https://incompetech.filmmusic.io/song/3495-cheery-mondayLicense: http://creativecommons.org/licenses/by/4.0

In the serverless world, we sometimes take the word "managed" a little too seriously. We often forget that not ALL software responsibilities are taken over by cloud vendors. Oftentimes responsibilities are shared between builders and cloud vendors, like security. In this episode, Allen and Jason talk about ways to improve your security posture starting today. They dive deep into AWS organizations, talk about how to keep your app teams and security teams friendly with each other, and discuss ways to minimize blast radius. About JasonJason Kao is the Head of Security Research at CloudQuery and passionate about cloud security.  He's worked at large enterprises, starting as an engineer and quickly moving into cybersecurity.  Jason has both defensive and offensive security experience including building cloud security infrastructure and working as a security consultant with a wide range of clients from startups to large enterprises in different industries, including highly-regulated industries.Jason is an author on multiple security patents and has presented at multiple cloud conferences including the inaugural AWS security conference, AWS re:Inforce.  His cloud security research has been featured in multiple community security newsletters. Links Jason on LinkedIn - https://www.linkedin.com/in/kaojason CloudQuery - https://www.cloudquery.io AWS Organizations - https://aws.amazon.com/organizations --- Send in a voice message: https://podcasters.spotify.com/pod/show/readysetcloud/message Support this podcast: https://podcasters.spotify.com/pod/show/readysetcloud/support

Brandon Sherman, Cloud Security Engineer at Temporal Technologies Inc., joins Corey on Screaming in the Cloud to discuss his experiences at recent cloud conferences and the ongoing changes in cloud computing. Brandon shares why he enjoyed fwd:cloudsec more than this year's re:Inforce, and how he's seen AWS events evolve over the years. Brandon and Corey also discuss how the cloud has matured and why Brandon feels ongoing change can be expected to be the continuing state of cloud. Brandon also shares insights on how his perspective on Google Cloud has changed, and why he's excited about the future of Temporal.io.About BrandonBrandon is currently a Cloud Security Engineer at Temporal Technologies Inc. One of Temporal's goals is to make our software as reliable as running water, but to stretch the metaphor it must also be *clean* water. He has stared into the abyss and it stared back, then bought it a beer before things got too awkward. When not at work, he can be found playing with his kids, working on his truck, or teaching his kids to work on his truck.Links Referenced: Temporal: https://temporal.io/ Personal website: https://brandonsherman.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: In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats. What's Runtime Insights, you ask? Visit sysdig.com/screaming to learn more. That's S-Y-S-D-I-G.com/screaming.My thanks as well to Sysdig for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined today by my friend who I am disappointed to say I have not dragged on to this show before. Brandon Sherman is a cloud security engineer over at Temporal. Brandon, thank you for finally giving in.Brandon: Thanks, Corey, for finally pestering me enough to convince me to join. Happy to be here.Corey: So, a few weeks ago as of this recording—I know that time is a flexible construct when it comes to the podcast production process—you gave a talk at fwd:cloudsec, the best cloud security conference named after an email subject line. Yes, I know re:Inforce also qualifies; this one's better. Tell me about what you talked about.Brandon: Yeah, definitely agree on this being the better the two conferences. I gave a talk about how the ground shifts underneath us, kind of touching on how these cloud services that we operate—and I'm mostly experienced in AWS and that's kind of the references that I can give—but these services work as a contract basis, right? We use their APIs and we don't care how they're implemented behind the scenes. At this point, S3 has been rewritten I don't know how many times. I'm sure that other AWS services, especially the longer-lived ones have gone through that same sort of rejuvenation cycle.But as a security practitioner, these implementation details that get created are sort of byproducts of, you know, releasing an API or releasing a managed service can have big implications to how you can either secure that service or respond to actions or activities that happen in that service. And when I say actions and activity, I'm kind of focused on, like, security incidents, breaches, your ability to do incident response from that.Corey: One of the reasons I've always felt that cloud providers have been cagey around how the services work under the hood is not because they don't want to talk about it so much as they don't want to find themselves committed to certain patterns that are not guaranteed as a part of the definition of the service. So if, “Yeah, this is how it works under the hood,” and you start making plans and architecting in accordance with that and they rebuild the service out from under you like they do with S3, then very often, those things that you depend upon being true could very easily no longer be true. And there's no announcement around those things.Brandon: No. It's very much Amazon is… you know, they're building a service to meet the needs of their customers. And they're trying to grow these services as the customers grow along with them. And it's absolutely within their right to act that way, to not have to tell us when they make a change because in some contexts, right, Amazon's feature update might be me as a customer a breaking change. And Amazon wants to try and keep that, what they need to tell me, as small as possible, probably not out of malice, but just because there's a lot of people out there using their services and trying to figure out what they've promised to each individual entity through either literal contracts or their API contracts is hard work. And that's not the job I would want.Corey: No. It seems like it's one of those thankless jobs where you don't get praise for basically anything. Instead, all you get to do is deal with the grim reality that people either view as invisible or a problem.Brandon: Yeah. It sort of feels like documentation. Everyone wants more and better documentation, but it's always an auxiliary part of the service creation process. The best documentation always starts out when you write the documentation first and then kind of build backwards from that, but that's rarely how I've seen software get made.Corey: No. I feel like I left them off the hook, on some level, when we say this, but I also believe in being fair. I think there's a lot of things that cloud providers get right and by and large, with any of the large cloud providers, they are going to do a better job of securing the fundamentals than you are yourself. I know that that is a controversial statement to some folks who spent way too much time in the data centers, but I stand by it.Brandon: Yeah, I agree. I've had to work in both environments and some of the easiest, best wins in security is just what do I have, so that way I know what I have to protect, what that is there. But even just that asset inventory, that's the sort of thing that back in the days of data centers—and still today; it was data centers all over the place—to do an inventory you might need to go and send an actual human with an actual clipboard or iPad or whatever, to the actual physical location and hope that they read the labels on hundreds of thousands of servers correctly and get their serial numbers and know what you have. And that doesn't even tell you what's running on them, what ports are open, what stuff you have to care about. In AWS, I can run a couple of describe calls or list calls and that forms the backbone of my inventory.There's no server that, you know, got built into a wall or lost behind and some long-forgotten migration. A lot of those basic stuff that really, really helps. Not to mention then the user-managed service like S3, you never have to care about patch notes or what an update might do. Plenty of times I've, like, hesitated upgrading a software package because I didn't know what was going to happen. Control Tower, I guess, is kind of an exception to that where you do have to care about the version of your cloud service, but stuff like, yeah, these other services is absolutely right. The undifferentiated heavy lifting it's taken care of. And hopefully, we always kind of hope that the undifferentiated heavy lifting doesn't become differentiated and heavy and lands on us.Corey: So, now that we've done the obligatory be nice to cloud providers thing, let's potentially be a little bit harsher. While you were speaking at fwd:cloudsec, did you take advantage of the fact that you were in town to also attend re:Inforce?Brandon: I did because I was given a ticket, and I wanted to go see some people who didn't have tickets to fwd:cloudsec. Yeah, we've been nice to cloud providers, but as—I haven't found I've learned a lot from the re:Inforce sessions. They're all recorded anyway. There's not even an open call for papers, right, for talking about at a re:Inforce session, “Hey, like, this would be important and fresh or things that I would be wanting to share.” And that's not the sort of thing that Amazon does with their conferences.And that's something that I think would be really interesting to change if there was a more community-minded track that let people submit, not just handpicked—although I suppose any kind of Amazon selection committee is going to be involved, but to pick out, from the community, stories or projects that are interesting that can be, not just have to get filtered through your TAM but something you can actually talk to and say, “Hey, this is something I'd like to talk about. Maybe other people would find it useful.”Corey: One of the things that I found super weird about re:Inforce this year has been that, in a normal year, it would have been a lot more notable, I think. I know for a fact that if I had missed re:Invent, for example, I would have had to be living in a cave not to see all of the various things coming out of that conference on social media, in my email, in all the filters I put out there. But unless you're looking for it, you've would not know that they had a conference that costs almost as much.Brandon: Yeah. The re:Invent-driven development cycle is absolutely a real thing. You can always tell in the lead up to re:Invent when there's releases that get pushed out beforehand and you think, “Oh, that's cool. I wonder why this doesn't get a spot at re:Invent, right, some kind of announcement or whatever.” And I was looking for that this year for re:Inforce and didn't see any kind of announcement or that kind of pre-release trickle of things that are like, oh, there's a bunch of really cool stuff. And that's not to say that cool stuff didn't happen; it just there was a very different marketing feel to it. Hard to say, it's just the vibes around felt different [laugh].Corey: Would you recommend that people attend next year—well let me back up. I've heard that they had not even announced a date for next year. Do you think there will be a re:Inforce next year?Brandon: Making me guess, predict the future, something that I'm—Corey: Yeah, do a prediction. Why not?Brandon: [laugh]. Let's engage in some idle speculation, right? I think that not announcing it was kind of a clue that there's a decent chance it won't happen because in prior years, it had been pre-announced at the—I think it was either at closing or opening ceremonies. Or at some point. There's always the, “Here's what you can look forward to next year.”And that didn't happen, so I think that's there's a decent chance this may have been the last re:Inforce, especially once all the data is crunched and people look at the numbers. It might just be… I don't know, I'm not a marketing-savvy kind of person, but it might just be that a day at re:Invent next year is dedicated to security. But then again, security is always job zero at Amazon so maybe re:Invent just becomes re:Inforce all the time, right? Do security, everybody.Corey: It just feels like a different type of conference. Whenever re:Invent there's something for everyone. At re:Inforce, there's something for everyone as long as they work in InfoSec. Because other than that, you wind up just having these really unfortunate spiels of them speaking to people that are not actually present, and it winds up missing the entire forest for the trees, really.Brandon: I don't know if I'd characterize it as that. I feel like some of the re:Inforce content was people who were maybe curious about the cloud or making progress in their companies and moving to the cloud—and in Amazon's case when they say the cloud, they mean themselves. They don't mean any other cloud. And re:Inforce tries to dispel the notion there are any other clouds.But at the same time, it feels like an attempt to try and make people feel better. There's a change underway in the industry and it still is going to continue for a while. There's still all kinds of non-cloud environments people are going to operate for probably until the end of time. But at the same time, a lot of these are moving to the cloud and they want the people who are thinking about this or engaged in it, to be comforted by that Amazon that either has these services, or there's a pattern you can follow to do something in a secure manner. I think that's that was kind of the primary audience of re:Inforce was people who were charged with doing cloud security or were exploring moving their corporate systems to AWS and they wanted some assurance that they're going to actually be doing things the right way, or someone else hadn't made those mistakes first. And if that audience has been sort of saturated, then maybe there isn't a need for that style of conference anymore.Corey: It feels like it's not intended to be the same thing at re:Invent, which is probably I guess, a bigger problem. Re:Invent for a long time has attempted to be all things to all people, and it has grown to a scale where that is no longer possible. So, they've also done a poor job of signaling that, so you wind up attending Adam Selipsky's keynote, and in many cases, find yourself bored absolutely to tears. Or you go in expecting it to be an Andy Jassy style of, “Here are 200 releases, four of them good,” and instead, you wind up just having what feels like a relatively paltry number doled out over a period of days. And I don't know that their wrong to do it; I just think it doesn't align with pre-existing expectations. I also think people expecting to go to re:Inforce to see a whole bunch of feature releases are bound to be disappointed.Brandon: Like, both of those are absolutely correct. The number of releases on the slide must always increase up and the right; away we go; we're pushing more code and making more changes to services. I mean, if you look at the history, there's always new instance types. Do they count each instance type as a new release, or they not do that?Corey: Yeah, it honestly feels like that sometimes. They also love to do price cuts where they—you wind up digging into them and something like 90% of them are services you've never heard of in regions you couldn't find on a map if your life depended on it. It's not quite the, “Yeah, the bill gets lower all the time,” that they'd love to present it as being.Brandon: Yeah. And you may even find that there's services that had updates that you didn't know about until you go and check the final bill, the Cost and Usage Report, and you look and go, “Oh, hey. Look at all the services that we were using, that our engineers started using after they heard announcements at re:Invent.” And then you find out how much you're actually paying for them. [pause]. Or that they were in use in the first place. There's no better way to find what is actually happening in your environment than, look at the bill.Corey: It's depressing that that's true. At least they finally stopped doing the slides where they talk about year-over-year, they have a histogram of number of feature and service releases. It's, no one feels good about that, even the people building the services and features because they look at that and think, “Oh, whatever I do is going to get lost in the noise.” And they're not wrong. Customers see it and freak out because how am I ever going to keep current with all this stuff? I take a week off and I spend a month getting caught back up again.Brandon: Yeah. And are you going to—you know, what's your strategy for dealing with all these new releases and features? Do you want to have a strategy of saying, “No, you can't touch any of those until we've vetted and understand them?” I mean, you don't even have to talk about security in that context; just the cost alone, understanding it's someone, someone going to run an experiment that bankrupts your company by forgetting about it or by growing into some monster in the bill. Which I suspect helps [laugh] helps you out when those sorts of things happen, right, for companies don't have that strategy.But at the same time, all these things are getting released. There's not really a good way of understanding which of these do I need to care about. Which of these is going to really impact my operational flow, my security impacts? What does this mean to me as a user of the service when there's, I don't know, an uncountable number really, or at least a number that's so big, it stops mattering that it got any bigger?Corey: One thing that I will say was great about re:Invent, I want to say 2021, was how small it felt. It felt like really a harkening back to the old re:Invents. And then you know, 2022 hit, and we go there and half of us wound up getting Covid because of course we did. But it was also this just this massive rush of, we're talking with basically the population of a midsize city just showing up inside of this entire enormous conference. And you couldn't see the people you wanted to see, it was difficult to pay attention to all there was to pay attention to, and it really feels like we've lost something somewhere.Brandon: Yeah, but at the same time is that just because there are more people in this ecosystem now? You know, 2021 may have been a callback to that a decade ago. And these things were smaller when it was still niche, but growing in kind of the whole ecosystem. And parts of—let's say, the ecosystem there, I'm talking about like, how—when I say that ecosystem there, I'm kind of talking about how in general, I want to run something in technology, right? I need a server, I need an object store, I need compute, whatever it is that you need, there is more attractive services that Amazon offers to all kinds of customers now.So, is that just because, right, we've been in this for a while and we've seen the cloud grow up and like, oh, wow, you're now in your awkward teenage phase of cloud computing [laugh]? Have we not yet—you know, we're watching the maturity to adulthood, as these things go? I really don't know. But it definitely feels a little, uh… feels a little like we've watched this cloud thing grow from a half dozen services to now, a dozen-thousand services all operating different ways.Corey: Part of me really thinks that we could have done things differently, had we known, once upon a time, what the future was going to hold. So, much of the pain I see in Cloud is functionally people trying to shove things into the cloud that weren't designed with Cloud principles in mind. Yeah, if I was going to build a lot of this stuff from scratch myself, then yeah, I would have absolutely made a whole universe of different choices. But I can't predict the future. And yet, here we are.Brandon: Yep. If I could predict the future, I would have definitely won the lottery a lot more times, avoided doing that one thing I regretted that once back in my history [laugh]. Like, knowing the future change a lot of things. But at least unless you're not letting on with something, then that's something that no one's got the ability to, do not even at Amazon.Corey: So, one of the problems I've always had when I come back from a conference, especially re:Invent, it takes me a few… well, I'll be charitable and say days, but it's more like weeks, to get back into the flow of my day-to-day work life. Was there any of that with you and re:Inforce? I mean, what is your day job these days anyway? What are you up to?Brandon: What is my day job? There's a lot. So, Temporal is a small, but quickly growing company. A lot of really cool customers that are doing really cool things with our technology and we need to build a lot of basics, essentially, making sure that when we grow, that we're going to kind of grow into our security posture. There's not anything talking about predicting the future. My prediction is that the company I work for is going to do well. You can hold your analysis on that [laugh].So, while I'm predicting what the company that I'm working at is going to do well, part of it is also what are the things that I'm going to regret not having in two or three years' time. So, some baseline cloud monitoring, right? I want that asset inventory across all of our accounts; I want to know what's going on there. There's other things that are sort of security adjacent. So, things like DNS records, domain names, a lot of those things where if we can capture this and centralize it early and build it in a way—especially that users are less unhappy about, like, not everyone, for example, is hosting their own—buying their own domains on personal cards and filing for reimbursement, that DNS records aren't scattered across a dozen different software projects and manipulated in different ways, then that sets us up.It may not be perfect today, but in a year, year-and-a-half, two years, we have the ability to then say, “Okay, we know what we're pointing at. What are the dangling subdomains? What are the things that are potential avenues of being taken over? What do we have? What are people doing?” And trying to understand how we can better help users with their needs day-to-day.Also as a side part of my day job is advising a startup Common Fate. Does just-in-time access management. And that's been a lot of fun to do as well because fundamentally—this is maybe a hot take—that, in a lot of cases, you really only need admin access and read-only access when you're doing really intensive work. In Temporal day job, we've got infrastructure teams that are building stuff, they need lots of permissions and it'd be very silly to say you can't do your job just because you could potentially use IAM and privilege escalate yourself to administrator. Let's cut that out. Let's pretend that you are a responsible adult. We can monitor you in other ways, we're not going to put restrictions between you and doing your job. Have admin access, just only have it for a short period of time, when you say you're going to need it and not all the time, every account, every service, all the time, all day.Corey: I do want to throw a shout-in for that startup you advise, Common Fate. I've been a big fan of their Granted offering for a while now. granted.dev for those who are unfamiliar. I use that to automatically generate console logins, do all kinds of other things. When you're moving between a bunch of different AWS accounts, which it kind of feels like people building the services don't have to do somehow because of their Isengard system handling it for them. Well, as a customer, can I just say that experience absolutely sucks and Granted goes a long way toward making it tolerable, if not great.Brandon: Mm-hm. Yeah, I remember years ago, the way that I would have to handle this is I would have probably a half-dozen different browsers at the same time, Safari, Chrome, the Safari web developer preview, just so I could have enough browsers to log into with, to see all the accounts I needed to access. And that was an extremely painful experience. And it still feels so odd that the AWS console today still acts like you have one account. You can switch roles, you can type in a [role 00:21:23] on a different account, but it's very clunky to use, and having software out there that makes this easier is definitely, definitely fills a major pain point I have with using these services.Corey: Tired of Apache Kafka's complexity making your AWS bill look like a phone number? Enter Redpanda. You get 10x your streaming data performance without having to rob a bank. And migration? Smoother than a fresh jar of peanut butter. Imagine cutting as much as 50% off your AWS bills. With Redpanda, it's not a dream, it's reality. Visit go.redpanda.com/duckbill. Redpanda: Because Kafka shouldn't cause you nightmares.Corey: Do you believe that there's hope? Because we have seen some changes where originally AWS just had the AWS account you'd log into, it's the root user. Great. Then they had IAM. Now, they're using what used to be known as AWS SSO, which they wound up calling IAM Access Identity Center, or—I forget the exact words they put in order, but it's confusing and annoying. But it does feel like the trend is overall towards something that's a little bit more coherent.Brandon: Mm-hm.Corey: Is the future five years from now better than it looks like today?Brandon: That's certainly the hope. I mean, we've talked about how we both can't predict the future, but I would like to hope that the future gets better. I really like GCP's project model. There's complaints I have with how Google Cloud works, and it's going to be here next year, and if the permission model is exactly how I'd like to use it, but I do like the mental organization that feels like Google was able to come in and solve a lot of those problems with running projects and having a lot of these different things. And part of that is, there's still services in AWS that don't really respect resource-based permissions or tag-based permissions, or I think the new one is attribute-based access control.Corey: One of the challenges I see, too, is that I don't think that there's been a lot of thought put into how a lot of these things are going to work between different AWS accounts. One of my bits of guidance whenever I'm talking to someone who's building anything, be it at AWS or external is, imagine an architecture diagram and now imagine that between any two resources in that diagram is now an account boundary. Because someone somewhere is going to have one there, so it sounds ridiculous, but you can imagine a microservices scenario where every component is in its own isolated account. What are you going to do now as a result? Because if you're going to build something that scales, you've got to respect those boundaries. And usually, that just means the person starts drinking.Brandon: Not a bad place to start, the organizational structure—lowercase organizations, not the Amazon service, Organizations—it's still a little tricky to get it in a way that sort of… I guess, I always kind of feel that these things are going to change and that the—right, the only constant is change. That's true. The services we use are going to change. The way that we're going to want to organize them is going to change. Our researcher is going to come out with something and say, “Hey, I found a really cool way to do something really terrible to the stuff in your cloud environment.”And that's going to happen eventually, in the fullness of time. So, how do we be able to react quickly to those kinds of changes? And how can we make sure that if you know, suddenly, we do need to separate out these services to go, you know, to decompose the monolith even more, or whatever the cool, current catchphrase is, and we have those account boundaries, which are phenomenal boundaries, they make it so much easier to do—if you can do multi-account then you've solved multi-regional on the way, you've sold failover, you've solve security issues. You have not solved the fact that your life is considerably more challenging at the moment, but I would really hope that in you know, even next year, but by the time five years comes around, that that's really been taken to heart within Amazon and it's a lot easier to be working creating services in different accounts that can talk to each other, especially in the current environment where it's kind of a mess to wire these things all together. ClickOps has its place, but some console applications just don't want to believe that you have a KMS key in another account because well, why would you put that over there? It's not like if your current account has a problem, you want to lose all your data that's encrypted.Corey: It's one of those weird things, too, where the clouds almost seem to be arguing against each other. Like, I would be hard-pressed to advise someone not to put a ‘rehydrate the entire business' level of backups into a different cloud provider entirely, but there's so steeped in the orthodoxy of no other clouds ever, that that message is not something that they can effectively communicate. And I think they're doing their customers a giant disservice by that, just because it is so much easier to explain to your auditor that you've done it than to explain why it's not necessary. And it's never true; you always have the single point of failure of the payment instrument, or the contract with that provider that could put things at risk.Is it a likely issue? No. But if you're running a publicly traded company on top of it, you'd be negligent not to think about it that way. So, why pretend otherwise?Brandon: Is that a question for me because [laugh]—Corey: Oh, that was—no, absolutely. That was a rant ending in a rhetorical question. So, don't feel you have to answer it. But getting the statement out there because hopefully, someone at Amazon is listening to this.Brandon: That's, uh, hopefully, if you find out who's the one that listens to this and can affect it, then yeah, I'd like to send them a couple of emails because absolutely. There's room out there, there will always be room for at least two providers.Corey: Yeah, I'd say a third, but I don't know that Google is going to have the attention span to still have a cloud offering by lunchtime today.Brandon: Yeah. I really wish that I had more faith in the services and that they weren't going—you know, speaking of services changing underneath you, that's definitely a—speaking of services changing underneath, you definitely a major disservice if you don't know—if you're going to put into work into architecting and really using cloud providers as they're meant to be used. Not in a, sort of, least common denominator sense, in which case, you're not in good shape.Corey: Right. You should not be building something with an idea toward what if this gets deprecated. You shouldn't have to think about that on a consistent basis.Brandon: Mm-hm. Absolutely. You should expect those things to change because they will, right, the performance impact. I mean, the performance of these services is going to change, the underlying technology that the providers use is going to change, but you should still be able to mostly expect that at least the API calls you make are going to still be there and still be consistent come this time next year.Corey: The thing that really broke me was the recent selling off of Google domains to Squarespace. Nothing against Squarespace, but they have a different target market in many respects. And oh, I'm a Google customer, you're now going to give all of my information to a third party I never asked to deal with. Great. And more to the point, if I recommend Google to folks because as has happened in years past, then they canceled the thing that I recommended, then I looked like a buffoon. So, we've gotten to a point now where it has become so steady and so consistent, that I fear I cannot, in good conscience, recommend a Google product without massive caveats. Otherwise, I look like a clown or worse, a paid shill.Brandon: Yeah. And when you want to start incorporating these things into the core of your business, to take that point about, you know, total failover scenarios, you should, you know, from you want it to have a domain registered in a Google service that was provisioned to Google Cloud services, that whole sort of ecosystem involved there, that's now gone, right? If I want to use Google Cloud with a Google Cloud native domain name hosting services, I can't. How am—I just—now I can't [laugh]. There's, like, not workarounds available.I've got to go to some other third-party and it just feels odd that an organization would sort of take those core building blocks and outsource them. [I know 00:29:05] that Google's core offering isn't Google Cloud; it's not their primary focus, and it kind of reflects that, which was a shame. There's things that I'd love to see grow out of Google Cloud and get better. And, you know, competition is good for the whole cloud computing industry.Corey: I think that it's a sad thing, but it's real, that there are people who were passionate defenders of Google over the years. I used to be one. We saw a bunch of them with Stadia fans coming out of the woodwork, and then all those people who have defended Google and said, “No, no, you can trust Google on this service because it's different,” for some reason or other, then wind up looking ridiculous. And some of the staunchest Google defenders that I've seen are starting to come around to my point of view. Eventually, you've run out of people who are willing to get burned if you burn them all.Brandon: Yeah. I've always been a little, uh… maybe this is the security Privacy part of me; I've always been a little leery of the services that really want to capture and gather your data. But I always respected the Google engineering that went into building these things at massive scale. It's something beyond my ability to understand as I haven't worked in something that big before. And Google made it look… maybe not effortless, but they made it look like they knew what they were doing, they could build something really solid.And I don't know if that's still true because it feels like they might know how to build something, and then they'll just dismantle it and turn it over to somebody else, or just dismantle it completely. And I think humans, we do a lot of things because we don't want to look foolish and… now recommending Google Cloud starts to make you wonder, “Am I going to look foolish?” Is this going to be a reflection on me in a year or two years, when you got to come in to say, “Hey, I guess that whole thing we architected around, it's being sold to someone else. It's being closed down. We got to transfer and rearchitect our whole whatever we built because of factors out of our control.” I want to be rearchitecting things because I screwed it up. I want to be rearchitecting things because I made an interesting novel mistake, not something that's kind of mundane, like, oh, I guess the thing we were going to use got shut down. Like, that makes it look like not only can I not predict the future, but I can't even pretend to read the tea leaves.Corey: And that's what's hard is because, on some level, our job, when we work in operations and cloud and try and make these decisions, is to convince the business we know what we're talking about. And when we look foolish, we don't make that same mistake again.Brandon: Mm-hm. Billing and security are oftentimes frequently aligned with each other. We're trying to convince the business that we need to build things a certain way to get a certain outcome, right? Either lower costs or more performance for the dollar, so that way, we don't wind up in the front page of newspapers, any kinds of [laugh] any kind of those things.Corey: Oh, yes. I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place for them to find you?Brandon: The best place to find me, I have a website about me, [brandonsherman.com 00:32:13]. That's where I post stuff. There's some links to—I have a [Mastodon 00:32:18] profile. I'm not much of a social, sort of post your information out there kind of person, but if you want to get a hold of me, then that's probably the best way to find me and contact me. Either that or head out to the desert somewhere, look for a silver truck out in the dunes and without technology around. It's another good spot if you can find me there.Corey: And I will include a link to that, of course, in the [show notes 00:32:45]. Thank you so much for taking the time to speak with me today. As always, I appreciate it.Brandon: Thank you very much for having me, Corey. Good to chat with you.Corey: Brandon Sherman, cloud security engineer at Temporal. 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 along with an angry comment that will somehow devolve into you inviting me to your new uninspiring cloud security conference that your vendor is putting on, and is of course named after an email subject line.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.

Jonathan (Koz) Kozolchyk, General Manager for Certificate Services at AWS, joins Corey on Screaming in the Cloud to discuss the best practices he recommends around certificates. Jonathan walks through when and why he recommends private certs, and the use cases where he'd recommend longer or unusual expirations. Jonathan also highlights the importance of knowing who's using what cert and why he believes in separating expiration from rotation. Corey and Jonathan also discuss their love of smart home devices as well as their security concerns around them and how they hope these concerns are addressed moving forward. About JonathanJonathan is General Manager of Certificate Services for AWS, leading the engineering, operations, and product management of AWS certificate offerings including AWS Certificate Manager (ACM) AWS Private CA, Code Signing, and Encryption in transit. Jonathan is an experienced leader of software organizations, with a focus on high availability distributed systems and PKI. Starting as an intern, he has built his career at Amazon, and has led development teams within our Consumer and AWS businesses, spanning from Fulfillment Center Software, Identity Services, Customer Protection Systems and Cryptography. Jonathan is passionate about building high performing teams, and working together to create solutions for our customers. He holds a BS in Computer Science from University of Illinois, and multiple patents for his work inventing for customers. When not at work you'll find him with his wife and two kids or playing with hobbies that are hard to do well with limited upside, like roasting coffee.Links Referenced: AWS website: https://www.aws.com Email: mailto:koz@amazon.com Twitter: https://twitter.com/seakoz 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: In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats. What's Runtime Insights, you ask? Visit sysdig.com/screaming to learn more. That's S-Y-S-D-I-G.com/screaming.My thanks as well to Sysdig for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. As I record this, we are about a week and a half from re:Inforce in Anaheim, California. I am not attending, not out of any moral reason not to because I don't believe in cloud security or conferences that Amazon has that are named after subject lines, but rather because I am going to be officiating a wedding on the other side of the world because I am an ordained minister of the Church of There Is A Problem With This Website's Security Certificate. So today, my guest is going to be someone who's a contributor, in many ways, to that religion, Jonathan Kozolchyk—but, you know, we all call him Koz—is the general manager for Certificate Services at AWS. Koz, thank you for joining me.Koz: Happy to be here, Corey.Corey: So, one of the nice things about ACM historically—the managed service that handles certificates from AWS—is that for anything public-facing, it's free—which is always nice, you should not be doing upcharges for security—but you also don't let people have the private portion of the cert. You control all of the endpoints that terminate SSL. Whereas when I terminate SSL myself, it terminates on the floor because I've dropped things here and there, which means that suddenly the world of people exposing things they shouldn't or expiry concerns just largely seemed to melt away. What was the reason that Amazon looked around at the landscape and said, “Ah, we're going to launch our own certificate service, but bear with me here, we're not going to charge people money for it.” It seems a little bit out of character.Koz: Well, Amazon itself has been battling with certificates for years, long before even AWS was a thing, and we learned that you have to automate. And even that's not enough; you have to inspect and you have to audit, you need a controlled loop. And we learned that you need a closed loop to truly manage it and make sure that you don't have outages. And so, when we built ACM, we built it saying, we need to provide that same functionality to our customers, that certificates should not be the thing that makes them go out. Is that we need to keep them available and we need to minimize the sharp edges customers have to deal with.Corey: I somewhat recently caught some flack on one of the Twitter replacement social media sites for complaining about the user experience of expired SSL certs. Because on the one hand, if I go to my bank's website, and the response is that instead, the server is sneakyhackerman.com, it has the exact same alert and failure mode as, holy crap, this certificate reached its expiry period 20 minutes ago. And from my perspective, one of those is a lot more serious than the other. What also I wind up encountering is not just when I'm doing banking, but when I'm trying to read some random blog on how to solve a technical problem. I'm not exactly putting personal information into the thing. It feels like that was a missed opportunity, agree or disagree?Koz: Well, I wouldn't categorize it as a missed opportunity. I think one of the things you have to think about with security is you have to keep it simple so that everyone, whether they're a technologist or not, can abide by the rules and be safe. And so, it's much easier to say to somebody, “There's something wrong. Period. Stop.” versus saying there are degrees of wrongness. Now, that said, boy, do I wish we had originally built PKI and TLS such that you could submit multiple certificates to somebody, in a connection for example, so that you could always say, you know, my certificates can expire, but I've got two, and they're off by six months, for example. Or do something so that you don't have to close failed because the certificate expired.Corey: It feels like people don't tend to think about what failure modes are going to look like. Because, pfhh, as an expired certificate? What kind of irresponsible buffoon would do such a thing? But I've worked in enough companies where you have historically, the wildcard cert because individual certs cost money, once upon a time. So, you wound up getting the one certificate that could work on all of the stuff that ends in the same domain.And that was great, but then whenever it expired, you had to go through and find all the places that you put it and you always miss some, so things would break for a while and the corporate response was, “Ugh, that was awful. Instead of a one-year certificate, let's get a five-year or a ten-year certificate this time.” And that doesn't make the problem better; it makes it absolutely worse because now it proliferates forever. Everyone who knows where that thing lives is now long gone by the time it hits again. Counterintuitively, it seems the industry has largely been moving toward short-lived certs. Let's Encrypt, for example, winds up rotating every 90 days, by my estimation. ACM is a year, if memory serves.Koz: So, ACM certs are 13 months, and we start rotating them around the 11th month. And Let's Encrypt offers you 90-day certs, but they don't necessarily require you to rotate every 90 days; they expire in 90 days. My tip for everybody is divorce expiration from rotation. So, if your cert is a 90-day cert, rotate it at 45 days. If your cert is a year cert, give yourself a couple of months before expiration to start the rotation. And then you can alarm on it on your own timeline when something fails, and you still have time to fix it.Corey: This makes a lot of sense in—you know, the second time because then you start remembering, okay, everywhere I use this cert, I need to start having alarms and alerts. And people are bad at these things. What ACM has done super well is that it removes that entire human from the loop because you control all of the endpoints. You folks have the ability to rotate it however often you'd like. You could have picked arbitrary timelines of huge amounts of time or small amounts of time and it would have been just fine.I mean, you log into an EC2 instance role and I believe the credentials get passed out of either a 6 or a 12-hour validity window, and they're consistently rotating on the back end and it's completely invisible to the customer. Was there ever thought given to what that timeline should be,j what that experience should be? Or did you just, like, throw a dart at a wall? Like, “Yeah, 13 months feels about right. We're going to go with that.” And never revisited it. I have a guess which—Koz: [laugh].Corey: Side of that it was. Did you think at all about what you were doing at the time, or—yeah.Koz: So, I will admit, this happened just before I got there. I got to ACM after—Corey: Ah, blame the predecessor. Always a good call.Koz: —the launch. It's a God-given right to blame your predecessor.Corey: Oh, absolutely. It's their entire job.Koz: I think they did a smart job here. What they did was they took the longest lifetime cert that was then allowed, at 13 months, knowing that we were going to automate the rotation and basically giving us as much time as possible to do it, right, without having to worry about scaling issues or having to rotate overly frequently. You know, there are customers who while I don't—I strongly disagree with [pinning 00:07:35], for example, but there are customers out there who don't like certs to change very often. I don't recommend pinning at all, but I understand these cases are out there, and changing it once every year can be easier on customers than changing it every 20 minutes, for example. If I were to pick an ideal rotation time, it'd probably be under ten days because an OCSP response is good for ten days and if you rotate before, then I never have to update an OCSP response, for example. But changing that often would play havoc with many systems because of just the sheer frequency you're rotating what is otherwise a perfectly valid certificate.Corey: It is computationally expensive to generate certificates at scale, I would imagine.Koz: It starts to be a problem. You're definitely putting a lot of load on the HSMs at that point, [laugh] when you're generating. You know, when you have millions of certs out in deployment, you're generating quite a few at a time.Corey: There is an aspect of your service that used to be part of ACM and now it's its own service—which I think is probably the right move because it was confusing for a lot of customers—Amazon looks around and sees who can we compete with next, it feels like sometimes. And it seemed like you were squarely focused on competing against your most desperate of all enemies, my crappy USB key where I used to keep the private CA I used at any given job—at the time; I did not keep it after I left, to be very clear—for whatever I'm signing things for certificates for internal use. You're, like, “Ah, we can have your crappy USB key as a service.” And sure enough, you wound up rolling that out. It seems like adoption has been relatively brisk on that, just because I see it in almost every client account I work with.Koz: Yeah. So, you're talking about the private CA offering which is—Corey: I—that's right. Private CA was the new service name. Yes, it used to be a private certificate authority was an aspect of ACM, and now you're—mmm, we're just going to move that off.Koz: And we split it out because like you said customers got confused. They thought they had to only use it with ACM. They didn't understand it was a full standalone service. And it was built as a standalone service; it was not built as part of ACM. You know, before we built it, we talked to customers, and I remember meeting with people running fairly large startups, saying, “Yes, please run this for me. I don't know why, but I've got this piece of paper in my sock drawer that one of my security engineers gave me and said, ‘if something goes wrong with our CA, you and two other people have to give me this piece of paper.'” And others were like, “Oh, you have a piece of paper? I have a USB stick in my sock drawer.” And like, this is what, you know, the startup world was running their CAs from sock drawers as far as I can tell.Corey: Yeah. A piece of paper? Someone wrote out the key by hand? That sounds like hell on earth.Koz: [sigh]. It was a sharding technique where you needed, you know, three of five or something like that to—Corey: Oh, they, uh, Shamir's Secret Sharing Service.Koz: Yes.Corey: The SSSS. Yeah.Koz: Yes. You know, and we looked at it. And the other alternative was people would use open-source or free certificate authorities, but without any of the security, you'd want, like, HSM backing, for example, because that gets really expensive. And so yeah, we did what our customers wanted: we built this service. We've been very happy with the growth it's taken and, like you said, we love the places we've seen it. It's gone into all kinds of different things, from the traditional enterprise use cases to IoT use cases. At one point, there's a company that tracks sheep and every collar has one of our certs in it. And so, I am active in the sheep-tracking industry.Corey: I am certain that some wit is going to comment on this. “Oh, there's a company out there that tracks sheep. Yeah, it's called Apple,” or Facebook, or whatever crappy… whatever axe someone has to grind against any particular big company. But you're talking actual sheep as in baa, smell bad, count them when going to sleep?Koz: Yes. Actual sheep.Corey: Excellent, excellent.Koz: The certs are in drones, they're in smart homes, so they're everywhere now.Corey: That is something I want to ask you about because I found that as a competition going on between your service, ACM because you won't give me the private keys for reasons that we already talked about, and Let's Encrypt. It feels like you two are both competing to not take my money, which is, you know, an odd sort of competition. You're not actually competing, you're both working for a secure internet in different ways, but I wind up getting certificates made automatically for me for all of my internal stuff using Let's Encrypt, and with publicly resolvable domain names. Why would someone want a private CA instead of an option that, okay, yeah, we're only using it internally, but there is public validity to the certificate?Koz: Sure. And just because I have to nitpick, I wouldn't say we're competing with them. I personally love Let's Encrypt; I use them at home, too. Amazon supports them financially; we give them resources. I think they're great. I think—you know, as long as you're getting certs I'm happy. The world is encrypted and I—people use private CA because fundamentally, before you get to the encryption, you need secure identity. And a certificate provides identity. And so, Let's Encrypt is great if you have a publicly accessible DNS endpoint that you can prove you own and get a certificate for and you're willing to update it within their 90-day windows. Let's use the sheep example. The sheep don't have publicly valid DNS endpoints and so—Corey: Or to be very direct with you, they also tend to not have terrific operational practices around updating their own certificates.Koz: Right. Same with drones, same with internal corporate. You may not want your DNS exposed to the internet, your internal sites. And so, you use a private certificate where you own both sides of the connection, right, where you can say—because you can put the CA in the trust store and then that gets you out of having to be compliant with the CA browser form and the web trust rules. A lot of the CA browser form dictates what a public certificate can and can't do and the rules around that, and those are built very much around the idea of a browser connecting to a client and protecting that user.Corey: And most people are not banking on a sheep.Koz: Most people are not banking on a sheep, yes. But if you have, for example, a database that requires a restart to pick up a new cert, you're not going to want to redo that every 90 days. You're probably going to be fine with a five-year certificate on that because you want to minimize your downtime. Same goes with a lot of these IoT devices, right? You may want a thousand-year cert or a hundred-year cert or cert that doesn't expire because this is a cert that happens at—that is generated at creation for the device. And it's at birth, the machine is manufactured and it gets a certificate and you want it to live for the life of that device.Or you have super-secret-project.internal.mycompany.com and you don't want a publicly visible cert for that because you're not ready to launch it, and so you'll start with a private cert. Really, my advice to customers is, if you own both pieces of the connection, you know, if you have an API that gets called by a client you own, you're almost always better off with a private certificate and managing that trust store yourself because then you are subject not to other people's rules, but the rules that fit the security model and the threat assessment you've done.Corey: For the publication system for my newsletter, when I was building it out, I wanted to use client certificates as a way of authenticating that it was me. Because I only have a small number of devices that need to talk to this thing; other people don't, so how do I submit things into my queue and manage it? And back in those ancient days, the API Gateways didn't support TLS authentication. Now, they do. I would redo it a bunch of different ways. They did support API key as an authentication mechanism, but the documentation back then was so terrible, or I was so new to this stuff, I didn't realize what it was and introduced it myself from first principles where there's a hard-coded UUID, and as long as there's the right header with that UUID, I accept it, otherwise drop it on the floor. Which… there are probably better ways to do that.Koz: Sure. Certificates are, you know, a very popular way to handle that situation because they provide that secure identity, right? You can be assured that the thing connecting to you can prove it is who they say they are. And that's a great use of a private CA.Corey: Changing gears slightly. As we record this, we are about two weeks before re:Inforce, but I will be off doing my own thing on that day. Anything interesting and exciting coming out of your group that's going to be announced, with the proviso, of course, that this will not air until after re:Inforce.Koz: Yes. So, we are going to be pre-announcing the launch of a connector for Active Directory. So, you will be able to tie your private CA instance to your Active Directory tree and use private CA to issue certificates for use by Active Directory for all of your Windows hosts for the users in that Active Directory tree.Corey: It has been many years since I touched Windows in anger, but in 2003 or so, I was a mediocre Small Business Windows Server Admin. Doesn't Active Directory have a private CA built into it by default for whenever you're creating a new directory?Koz: It does.Corey: Is that one of the FSMO roles? I'm trying to remember offhand.Koz: What's a Fimal?Corey: FSMO. F-S-M-O. There are—I forget, it's some trivia question that people love to haze each other with in Microsoft interviews. “What are the seven FSMO roles?” At least back then. And have to be moved before you decommission a domain controller or you're going to have tears before bedtime.Koz: Ah. Yeah, so Microsoft provides a certificate authority for use with Active Directory. They've had it for years and they had to provide it because back then nobody had a certificate authority, but AD needed one. The difference here is we manage it for you. And it's backed by HSMs. We ensure that the keys are kept secure. It's a serverless connection to your Active Directory tree, you don't have to run any software of ours on your hosts. We take care of all of it.And it's been the top requests from customers for years now. It's been quite [laugh] a bit of effort to build it, but we think customers are going to love it because they're going to get all the security and best practices from private CA that they're used to and they can decommission their on-prem certificate authority and not have to go through the hassle of running it.Corey: A big area where I see a lot of private CA work has been in the realm of desktops for corporate environments because when you can pass out your custom trusted root or trusted CA to all of the various nodes you have and can control them, it becomes a lot easier. I always tended to shy away from it, just because in small businesses like the one that I own, I don't want to play corporate IT guy more than I absolutely have to.Koz: Yeah. Trust or management is always a painful part of PKI. As if there weren't enough painful things in PKI. Trust store management is yet another one. Thankfully, in the large enterprises, there are good tooling out there to help you manage it for the corporate desktops and things like that.And with private CA, you can also, if you already have an offline root that is in all of your trust stores in your enterprise, you can cross-sign the route that we give you from private CA into that hierarchy. And so, then you don't have to distribute a new trust store out if you don't want to.Corey: This is a tricky release and I'm very glad I'm taking the week off it's getting announced because there are two reactions that are going to happen to any snarking I can do about this. The first is no one knows what the hell this is and doesn't have any context for the rest, and the other folks are going to be, “Yes, shut up clown. This is going to change my workflow in amazing ways. I'll deal with your nonsense later. I want to do this.” And I feel like one of those constituencies is very much your target market and the other isn't. Which is fine. No service that AWS offers—except the bill—is for every customer, but every service is for someone.Koz: That's right. We've heard from a lot of our customers, especially as they—you know, the large international ones, right, they find themselves running separate Active Directory CAs in different countries because they have different regulatory requirements and separations that they want to do. They are chomping at the bit to get this functionality because we make it so easy to run a private CA in these different regions. There's certainly going to be that segment at re:Inforce, that's just happy certificates happen in the background and they don't think anything about where they come from and this won't resonate with them, but I assure you, for every one of them, they have a colleague somewhere else in the building that is going to do a happy dance when this launches because there's a great deal of customer heavy-lifting and just sharp edges that we're taking away from them. And we'll manage it for them, and they're going to love it.[midroll 0:21:08]Corey: One thing that I have seen the industry shift to that I love is the Let's Encrypt model, where the certificate expires after 90 days. And I love that window because it is a quarter, which means yes, you can do the crappy thing and have a calendar reminder to renew the thing. It's not something you have to do every week, so you will still do it, but you're also not going to love it. It's just enough friction to inspire people to automate these things. And that I think is the real win.There's a bunch of things like Certbot, I believe the protocol is called ACME A-C-M-E, always in caps, which usually means an acronym or someone has their caps lock key pressed—which is of course cruise control for cool. But that entire idea of being able to have a back-and-forth authentication pass and renew certificates on a schedule, it's transformative.Koz: I agree. ACM, even Amazon before ACM, we've always believed that automation is the way out of a lot of this pain. As you said earlier, moving from a one-year cert to a five-year cert doesn't buy you anything other than you lose even more institutional knowledge when your cert expires. You know, I think that the move to further automation is great. I think ACME is a great first step.One of the things we've learned is that we really do need a closed loop of monitoring to go with certificate issuance. So, at Amazon, for example, every cert that we issue, we also track and the endpoints emit metrics that tell us what cert they're using. And it's not what's on disk, it's what's actually in the endpoint and what they're serving from memory. And we know because we control every cert issued within the company, every cert that's in use, and if we see a cert in use that, for example, isn't the latest one we issued, we can send an alert to the team that's running it. Or if we've issued a cert and we don't see it in use, we see the old ones still in use, we can send them an alert, they can alarm and they can see that, oh, we need to do something because our automation failed in this case.And so, I think ACME is great. I think the push Let's Encrypt did to say, “We're going to give you a free certificate, but it's going to be short-lived so you have to automate,” that's a powerful carrot and stick combination they have going, and I think for many customers Certbot's enough. But you'll see even with ACM where we manage it for our customers, we have that closed loop internally as well to make sure that the cert when we issue a new cert to our client, you know, to the partner team, that it does get picked up and it does get loaded. Because issuing you a cert isn't enough; we have to make sure that you're actually using the new certificate.Corey: I also have learned as a result of this, for example, that AWS certificate manager—Amazon Certificate Manager, the ACM, the certificate thingy that you run, that so many names, so many acronyms. It's great—but it has a limit—by default—of 2500 certificates. And I know this because I smacked into it. Why? I wasn't sitting there clicking and adding that many certificates, but I had a delightful step function pattern called ‘The Lambda invokes itself.' And you can exhaust an awful lot of resources that way because I am bad at programming. That is why for safety, I always recommend that you iterate development-wise in an account that is not production, and preferably one that belongs to someone else.Koz: [laugh]. We do have limits on cert issuance.Corey: You have limits on everything in AWS. As it should because it turns out that whatever there's not a limit, A, free database just dropped, and B, things get hammered to death. You have to harden these things. And it's one of those things that's obvious once you've operated at a certain point of scale, but until you do, it just feels arbitrary and capricious. It's one of those things where I think Amazon is still—and all the cloud companies who do this—are misunderstood.Koz: Yeah. So, in the case of the ACM limits, we look at them fairly regularly. Right now, they're high enough that most of our customers, vast majority, never come close to hitting it. And the ones that do tend to go way over.Corey: And it's been a mistake, as in my case as well. This was not a complaint, incidentally. It was like, well, I want to wind up having more waste and more ridiculous nonsense. It was not my concern.Koz: No no no, but we do, for those customers who have not mistake use cases but actual use cases where they need more, we're happy to work with their account teams and with the customer and we can up those limits.Corey: I've always found that limit increases, with remarkably few exceptions, the process is, “Explain to you what your use case is here.” And I feel like that is a screen for, first, are you doing something horrifying for which there's a better solution? And two, it almost feels like it's a bit of a customer research approach where this is fine for most customers. What are you folks doing over there and is there a use case we haven't accounted for in how we use the service?Koz: I always find we learned something when we look at the [P100 00:26:05] accounts that they use the most certificates, and how they're operating.Corey: Every time I think I've seen it all on AWS, I just talk to one more customer, and it's back to school I go.Koz: Yep. And I thank them for that education.Corey: Oh, yeah. That is the best part of working with customers and honestly being privileged enough to work with some of these things and talk to the people who are building really neat stuff. I'm just kibitzing from the sideline most of the time.Koz: Yeah.Corey: So, one last topic I want to get into before we call it a show. You and I have been talking a fair bit, out of school, for lack of a better term, around a couple of shared interests. The one more germane to this is home automation, which is always great because especially in a married situation, at least as I am and I know you are as well, there's one partner who is really into home automation and the other partner finds himself living in a haunted house.Koz: [laugh]. I knew I had won that battle when my wife was on a work trip and she was in a hotel and she was talking to me on the phone and she realized she had to get out of bed to turn the lights off because she didn't have our Alexa Good Night routine available to her to turn all the lights off and let her go to bed. And so, she is my core customer when I do the home automation stuff. And definitely make sure my use cases and my automations work for her. But yeah, I'm… I love that space.Coincidentally, it overlaps with my work life quite a bit because identity in smart home is a challenge. We're really excited about the Matter standard. For those listening who aren't sure what that is, it's a new end-all be-all smart home standard for defining devices in a protocol-independent way that lets your hubs talk to devices without needing drivers from each company to interact with them. And one of the things I love about it is every device needs a certificate to identify it. And so, private CA has been a great partner with Matter, you know, it goes well with it.In fact, we're one of the leading certificate authorities for Matter devices. Customers love the pricing and the way they can get started without talking to anybody. So yeah, I'm excited to see, you know, as a smart home junkie and as a PKI guy, I'm excited to see Matter take off. Right now I have a huge amalgamation of smart home devices at home and seeing them all go to Matter will be wonderful.Corey: Oh, it's fantastic. I am a little worried about aspects of this, though, where you have things that get access to the internet and then act as a bridge. So suddenly, like, I have a IoT subnet with some controls on it for obvious reasons and honestly, one of the things I despise the most in this world has been the rise of smart TVs because I just want you to be a big dumb screen. “Well, how are you going to watch your movies?” “With the Apple TV I've plugged into the thing. I just want you to be a screen. That's it.” So, I live a bit in fear of the day where these things find alternate ways to talk to the internet and, you know, report on what I'm watching.Koz: Yeah, I think Matter is going to help a lot with this because it's focused on local control. And so, you'll have to trust your hub, whether that's your TV or your Echo device or what have you, but they all communicate securely amongst themselves. They use certificates for identification, and they're building into Matter a robust revocation mechanism. You know, in my case at home, my TV's not connected to the internet because I use my Fire TV to talk to it, similar to your Apple TV situation. I want a device I control not my TV, doing it. I'm happy with the big dumb screen.And I think, you know, what you're going to end up doing is saying there's a device out there you'll trust maybe more than others and say, “That's what I'm going to use as my hub for my Matter devices and that's what will speak to the internet,” and otherwise my Matter devices will talk directly to my hub.Corey: Yeah, there's very much a spectrum of trust. There's the, this is a Linux distribution on a computer that I installed myself and vetted and wound up contributing to at one point on the one end of the spectrum, and the other end of the spectrum of things you trust the absolute least in this world, which are, of course, printers. And most things fall somewhere in between.Koz: Yes, right, now, it is a Wild West of rebranded white-label applications, right? You have all kinds of companies spitting out reference designs as products and white labeling the control app for it. And so, your phone starts collecting these smart home applications to control each one of these things because you buy different switches from different people. I'm looking forward to Matter collapsing that all down to having one application and one control model for all of the smart home devices.Corey: Wemo explicitly stated that they're not going to be pursuing this because it doesn't let them differentiate the experience. Read as, cash grab. I also found out that Wemo—which is, of course, a Belkin subsidiary—had a critical vulnerability in some of the light switches it offered, including the one built into the wall in this room—until a week ago—where they're not going to be releasing a patch for it because those are end-of-life. Really? Because I log into the Wemo app and the only way I would have known this has been the fact that it's been a suspiciously long time since there was a firmware update available for it. But that's it. Like, the only way I found this out was via a security advisory, at which point that got ripped out of the wall and replaced with something that isn't, you know, horrifying. But man did that bother me.Koz: Yeah. I think this is still an open issue for the smart home world.Corey: Every company wants a moat of some sort, but I don't want 15 different apps to manage this stuff. You turned me on to Home Assistant, which is an open-source, home control automation system and, on some level, the interface is very clearly built by a bunch of open-source people—good for them; they could benefit from a graphic designer or three to—or user experience person to tie it all together, but once you wrap your head around it, it works really well, where I have automations let me do different things. They even have an Apple Watch app [without its 00:32:14] complications on it. So, I can tap the thing and turn on the lights in my office to different levels if I don't want to talk to the robot that runs my house. And because my daughter has started getting very deeply absorbed into some YouTube videos from time to time, after the third time I asked her what—I call her name, I tap a different one and the internet dies to her iPad specifically, and I wait about 30 to 45 seconds, and she'll find me immediately.Koz: That's an amazing automation. I love Home Assistant. It's certainly more technical than I could give to my parents, for example, right now. I think things like Matter are going to bring a lot of that functionality to the easier-to-use hubs. And I think Home Assistant will get better over time as well.I think the only way to deal with these devices that are going to end-of-life and stop getting support is have them be local control only and so then it's your hub that keeps getting support and that's what talks to the internet. And so, you don't—you know, if there's a vulnerability in the TCP stack, for example, in your light switch, but your light switch only talks to the hub and isn't allowed to talk to anything else, how severe is that? I don't think it's so bad. Certainly, I wall off all of my IoT devices so that they don't talk to the rest of my network, but now you're getting a fairly complicated networking… mojo that listeners to your podcast I'm sure capable of, but many people aren't.Corey: I had something that did something very similar and then I had to remove a lot of those restrictions, try to diagnose a phantom issue that it appears was an unreported bug in the wireless AP when you use its second ethernet port as a bridge, where things would intermittently not be able to cross VLANs when passing through that. As in, the initial host key exchange for SSH would work and then it would stall and resets on both sides and it was a disaster. It was, what is going on here? And the answer was it was haunted. So, a small architecture change later, and the problem has not recurred. I need to reapply those restrictions.Koz: I mean, these are the kinds of things that just make me want to live in a shack in the woods, right? Like, I don't know how you manage something like that. Like, these are just pain points all over. I think over time, they'll get better, but until then, that shack in the woods with not even running water sounds pretty appealing.Corey: Yeah, at some level, having smart lights, for example, one of the best approaches that all the manufacturers I've seen have taken, it still works exactly as you would expect when you hit the light switch on the wall because that's something that you really need to make work or it turns out for those of us who don't live alone, we will not be allowed to smart home things anymore.Koz: Exactly. I don't have any smart bulbs in my house. They're all smart switches because I don't want to have to put tape over something and say, “Don't hit that switch.” And then watch one of my family members pull the tape off and hit the switch anyways.Corey: I have floor lamps with smart bulbs in them, but I wind up treating them all as one device. And I mean, I've taken the switch out from the root because it's, like, too many things to wind up slicing and dicing. But yeah, there's a scaling problem because right now a lot of this stuff—because Matter is not quite there all winds up using either Zigbee—which is fine; I have no problem with that it feels like it's becoming Matter quickly—or WiFi. And there is an upper bound to how many devices you want or can have on some fairly limited frequency.Koz: Yeah. I think this is still something that needs to be resolved. You know, I've got hundreds of devices in my house. Thankfully, most of them are not WiFi or Zigbee. But I think we're going to see this evolve over time and I'm excited for it.Corey: I was talking to someone where I was explaining that, well, how this stuff works. Like, “Well, how many devices could you possibly have on your home network?” And at the time it was about 70 or 80. And they just stared at me for the longest time. I mean, it used to be that I could name all the computers in my house. I can no longer do that.Koz: Sure. Well, I mean, every light switch ends up being a computer.Corey: And that's the weirdest thing is that it's, I'm used to computers, being a thing that requires maintenance and care and feeding and security patches and—yes, relevant to your work—an SSL certificate. It's like, so what does all of that fancy wizardry do? Well, when it receives a signal, it completes a circuit. The end. And it's, are really better off for some of these things? There are days we wonder.Koz: Well, my light bill, my electric bill, is definitely better off having these smart switches because nobody in my house seems to know how to turn a light switch off. And so, having the house do it itself helps quite a bit.Corey: To be very clear, I would skewer you if you worked on an AWS service that actually charged money for anything for what you just said about the complaining about light bills and optimizing light bills and the rest—Koz: [laugh].Corey: —but I've never had to optimize your service's certificate bill beca—after you've spun off the one thing that charges—because you can't cost optimize free, as it turns out, and I've yet to find a way to the one optimization possible where now you start paying customers money. I'm sure there's a way to do that somewhere but damned if I can find it.Koz: Well, if you find a way to optimize free, please let me know and I'll share it with all of our customers.Corey: [laugh]. Isn't that the truth? I really want to thank you for taking the time to speak with me today. If people want to learn more, where's the best place for them to find you?Koz: I can give you the standard AWS answer.Corey: Yeah, www.aws.com. Yeah.Koz: Well, I would have said koz@amazon.com. I'm always happy to talk about certs and PKI. I find myself less active on social media lately. You can find me, I guess, on Twitter as @seakoz and on Bluesky as [kozolchyk.com 00:38:03].Corey: And we will put links to all of that in the [show notes 00:38:06]. Thank you so much for being so generous with your time. I appreciate it.Koz: Always happy, Corey.Corey: Jonathan Kozolchyk, or Koz as we all call him, general manager for Certificate Services at AWS. 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 along with an angry, insulting comment that then will fail to post because your podcast platform of choice has an expired security certificate.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.

Welcome to the newest episode of The Cloud Pod podcast - where the forecast is always cloudy! Today your hosts are Jonathan and Matt as we discuss all things cloud and AI, including Temporary Elevated Access Management (or TEAM, since we REALLY like acronyms today)  FTP servers, SQL servers and all the other servers, as well as pipelines, whether or not the government should regulate AI (spoiler alert: the AI companies don't think so) and some updates to security at Amazon and Google.  Titles we almost went with this week: The Cloud Pod's FTP server now with post-quantum keys support The CloudPod can now Team into your account, but only temporarily  The CloudPod dusts off their old floppy drive  The CloudPod dusts off their old SQL server disks The CloudPod is feeling temporarily elevated to do a podcast The CloudPod promise that AI will not take over the world The CloudPod duals with keys The CloudPod is feeling temporarily elevated. 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.

Last week in security news: Videos from fwd:cloudsec are now available on YouTube, AWS announces AWS Payment Cryptography, Amazon CodeGuru Security is now available in preview, and more!Links: There was lots of great content presented at fwd:cloudsec.  The day-long videos are up on YouTube. You can use the schedule to help find the talks you're interested in. In contrast to AWS's "Shared Responsibility Model", I appreciate GCP's "Shared Fate Model" where they put their own skin in the game in ensuring their customers are protected.  In their New Cryptomining Protection Program, they offer $1M in what is basically an insurance policy that comes with Security Command Center Premium. Bob McMillan from the WSJ reports that North Korean hackers have stolen more than $3 billion in crypto over the last 5 years, and their heists are now funding fully half of its ballistic missile program. a16z writes Hiring a Chief Information Security Officer. Removing header remapping from Amazon API Gateway, and notes about our work with security researchers - AWS made a breaking change to respond to a security issue. The security researchers that found the issue wrote their side of the story, describing it as AWS API Gateway header smuggling and cache confusion. Issue with AWS Directory Service EnableRoleAccess - AWS released a security bulletin for this issue, which they seem to do at random for security issues. Ben Bridts from Cloudar found and reported this issue which AWS has fixed.  He goes into more detail in his blog post and in a talk at fwd:cloudsec. Amazon CloudWatch Logs data protection account level policy configuration AWS WAF Fraud Control launches account creation fraud prevention and reduced pricing AWS announces AWS Payment Cryptography AWS Transfer Family announces quantum-safe key exchange for SFTP Amazon CodeGuru Security is now available in preview Amazon Inspector announces the general availability of Code Scans for AWS Lambda function AWS announces Software Bill of Materials export capability in Amazon Inspector Amazon EC2 Instance Connect supports SSH and RDP connectivity without public IP address Amazon GuardDuty enhances console experience with findings summary view Amazon Detective extends finding groups to Amazon Inspector Amazon S3 announces dual-layer server-side encryption for compliance workloads AWS CloudTrail Lake launches curated dashboards for visualizing top CloudTrail trends AWS IAM Identity Center now supports automated user provisioning from Google Workspace

In this inaugural installment of Infrastructure Matters, we established the basis of the podcast - why does infrastructure matter in a cloud-crazed world? Co-hosts Steven Dickens, Camberley Bates, and Krista Macomber shared their individual takes on why infrastructure matters and shared key insights from events they have recently attended. Our conversation covered the following: How infrastructure impacts the availability and performance of hybrid cloud IT services How infrastructure impacts the security of hybrid cloud IT services. Issues pertaining to the manageability of hybrid multi cloud IT services. Issues driving placement of workloads and data across particular cloud environments. Insights from AWS re:Inforce. Insights from NetApp's Analyst Summit. Insights from a recent visit to Lenovo's manufacturing facility in Germany. Be sure to visit our YouTube Channel and subscribe, so you don't miss an episode.

In this week's episode of Wealth Warehouse, Dave and Paul, pressed for time, are fielding some of your burning questions!You'll hear from one of Dave's clients that has witnessed first-hand their parent's struggle in retirement – and what led them there. You'll get a refresher (or a great explanation) on interest, loan repayments and the dreaded task of storing your capital in someone else's bank.Whether you're a veteran or a newcomer, you won't want to miss these nuggets of information!Episode Highlights:(0:00) - Introduction(0:29) - Episode beginning(3:27) - Illustrations are never going to look the same(6:47) - How interest and loan repayments work(13:37) - What separates IBC as a financial product(17:12) - Not relying on the market for your retirement(22:06) - Episode wrap-upABOUT YOUR HOSTS:David Befort and Paul Fugere are the hosts of the Wealth Warehouse Podcast. David is the Founder/CEO of Max Performance Financial. He founded the company with the mission of educating people on the truths about money. David's mission is to show you how you can control your own money, earn guarantees, grow it tax-free, and maintain penalty-free access to it to leverage for opportunities that will provide passive income for the rest of your life. Paul, on the other hand, is an Active Duty U.S. Army officer who graduated from Norwich University in 2002 with a B.A. in History and again in 2012 with a MA in Diplomacy and International Terrorism. Paul met his wife Tammy at Norwich. As a family, they enjoy boating, traveling, sports, hunting, automobiles, and are self-proclaimed food people. Catch up with David and Paul, visit the links below! Website: https://infinitebanking.org/agents/Fugere494 https://infinitebanking.org/agents/Befort399 LinkedIn: https://www.linkedin.com/in/david-a-befort-jr-09663972/ https://www.linkedin.com/in/paul-fugere-762021b0/ Email: davidandpaul@theibcguys.com

Last week in security news: Gain insights and knowledge at AWS re:Inforce 2023, InvalidClientTokenId, a repository of AWS customer breaches, and more!Links: If you're in New York City proper, I hope to see you tonight at 7PM at Vol de Nuit We're hiring an Account Exec to handle media sales for this very podcast. Should you be the person who refers the successful candidate, we'll give you a $3K USD referral fee. Nick Frichette has found an undocumented Amplify API and used it to leak AWS Account IDs. Friend of the newsletter Chris Farris has started an AWS security consulting practice. Gain insights and knowledge at AWS re:Inforce 2023  How to use Amazon GuardDuty and AWS WAF v2 to automatically block suspicious hosts InvalidClientTokenId: The security token included in the request is invalid error Someone is curating this repository of AWS customer breaches.

Episode SummaryChris Farris, Cloud Security Nerd at Turbot, joins Corey on Screaming in the Cloud to discuss the latest events in cloud security, which leads to an interesting analysis from Chris on how legal departments obscure valuable information that could lead to fewer security failures in the name of protecting company liability, and what the future of accountability for security failures looks like. Chris and Corey also discuss the newest dangers in cloud security and billing practices, and Chris describes his upcoming cloud security conference, fwd:cloudsec. About ChrisChris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team's objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he's architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one of the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS's building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Mastodon, Twitter and his website https://www.chrisfarris.comLinks Referenced: Turbot: https://turbot.com/ fwd:cloudsec: https://fwdcloudsec.org/ Mastodon: https://infosec.exchange/@jcfarris Personal website: https://chrisfarris.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: Welcome to Screaming in the Cloud. I'm Corey Quinn and we are here today to learn exciting things, steal exciting secrets, and make big trouble for Moose and Squirrel. Maybe that's the podcast; maybe that's the KGB, we're not entirely sure. But I am joined once again by Chris Farris, cloud security nerd at Turbot, which I will insist on pronouncing as ‘Turbo.' Chris, thanks for coming back.Chris: Thanks for having me.Corey: So, it's been a little while and it's been an uneventful time in cloud security with nothing particularly noteworthy happening, not a whole lot of things to point out, and honestly, we're just sort of scraping the bottom of the barrel for news… is what I wish I could say, but it isn't true. Instead, it's, “Oh, let's see what disastrous tire fire we have encountered this week.” What's top of mind for you as we record this?Chris: I think the most interesting one I thought was, you know, going back and seeing the guilty plea from Nickolas Sharp, who formerly was an employee at Ubiquiti and apparently had, like, complete access to everything there and then ran amok with it.Corey: Mm-hm.Chris: The details that were buried at the time in the indictment, but came out in the press releases were he was leveraging root keys, he was leveraging lifecycle policies to suppress the CloudTrail logs. And then of course, you know, just doing dumb things like exfiltrating all of this data from his home IP address, or exfiltrating it from his home through a VPN, which have accidentally dropped and then exposed his home IP address. Oops.Corey: There's so much to dive into there because I am not in any way shape or form, saying that what he did was good, or I endorse any of those things. And yeah, I think he belongs in prison for what he did; let's be very clear on this. But I personally did not have a business relationship with him. I am, however, Ubiquiti's customer. And after—whether it was an insider threat or whether it was someone external breaching them, Krebs On Security wound up doing a whole write-up on this and was single-sourcing some stuff from the person who it turned out, did this.And they made a lot of hay about this. They sued him at one point via some terrible law firm that's entire brand is suing media companies. And yeah, just wonderful, wonderful optics there and brilliant plan. But I don't care about the sourcing. I don't care about the exact accuracy of the reporting because what I'm seeing here is that what is not disputed is this person, who whether they were an employee or not was beside the point, deleted all of the audit logs and then as a customer of Ubiquiti, I received an email saying, “We have no indication or evidence that any customer data was misappropriated.” Yeah, you just turn off your logs and yeah, you could say that always and forever and save money on logging costs. [unintelligible 00:03:28] best practice just dropped, I guess. Clowns.Chris: So, yeah. And there's definitely, like, compliance and standards and everything else that say you turn on your logs and you protect your logs, and service control policies should have been able to detect that. If they had a security operations center, you know, the fact that somebody was using root keys should have been setting off red flags and causing escalations to occur. And that wasn't happening.Corey: My business partner and I have access to our AWS org, and when I was setting this stuff up for what we do here, at a very small company, neither of us can log in with root credentials without alarms going off that alert the other. Not that I don't trust the man; let's be very clear here. We both own the company.Chris: In business together. Yes.Corey: Ri—exactly. It is, in many ways, like a marriage in that one of us can absolutely ruin the other without a whole lot of effort. But there's still the idea of separation of duties, visibility into what's going on, and we don't use root API keys. Let me further point out that we are not pushing anything that requires you to send data to us. We're not providing a service that is software powered to people, much less one that is built around security. So, how is it that I have a better security posture than Ubiquiti?Chris: You understand AWS and in-depth cloud better. You know, it really comes down to how do you, as an AWS customer, understand all of the moving parts, all of the security tooling, all of the different ways that something can happen. And Amazon will say, “Well, it's in the documentation,” but you know, they have, what, 357 services? Are you reading the security pages of all of those? So, user education, I agree, you should have, and I have on all of my accounts, if anything pops up, if any IAM change happens, I'm getting text messages. Which is great if my account got compromised, but is really annoying when I'm actually making a change and my phone is blowing up.Corey: Yeah. It's worth pointing out as well that yes, Ubiquiti is publicly traded—that is understood and accepted—however, 93% of it is owned by their CEO-founder god-king. So, it is effectively one person's personal fiefdom. And I tend to take a very dim view as a direct result. When you're in cloud and you have suffered a breach, you have severely screwed something up somewhere. These breaches are never, “Someone stole a whole bunch of drives out of an AWS data center.” You have misconfigured something somewhere. And lashing out at people who reported on it is just a bad look.Chris: Definitely. Only error—now, of course, part of the problem here is that our legal system encourages people to not come forward and say, “I screwed up. Here's how I screwed up. Everybody come learn from my mistakes.” The legal professions are also there to manage risk for the company and they're like, “Don't say anything. Don't say anything. Don't even tell the government. Don't say anything.”Whereas we all need to learn from these errors. Which is why I think every time I do see a breach or I do see an indictment, I start diving into it to learn more. I did a blog post on some of the things that happened with Drizly and GitHub, and you know, I think the most interesting thing that came out of Drizly case was the ex-CEO of Drizly, who was CEO at the time of the breach, now has following him, for the rest of his life, an FTC order that says he must implement a security program wherever he goes and works. You know, I don't know what happens when he becomes a Starbucks barista or whatever, but that is on him. That is not on the company; that is on him.And I do think that, you know, we will start seeing more and more chief executive officers, chief security or information security officers becoming accountable to—or for the breaches and being personally accountable or professionally accountable for it. I think we kind of need it, even though, you know, there's only so much a CISO can do.Corey: One of the things that I did when I started consulting independently on AWS bills back in 2016 was, while I was looking at customer environments, I also would do a quick check for a few security baseline things. And I stopped doing it because I kept encountering a bunch of things that needed attention and it completely derailed the entire stated purpose of the engagement. And, frankly, I don't want to be running a security consultancy. There's a reason I focus on AWS bills. And people think I'm kidding, but I swear to you I'm not, when I say that the reason is in part because no one has a middle-of-the-night billing emergency. It is strictly a business-hours problem. Whereas with security, wake up.In fact, the one time I have been woken up in the middle of the night by a customer phone call, they were freaking out because it was a security incident and their bill had just pegged through the stratosphere. It's, “Cool. Fix the security problem first, then we'll worry about the bill during business hours. Bye.” And then I stopped leaving my phone off of Do Not Disturb at night.Chris: Your AWS bill is one of your indicators of compromise. Keep an eye on it.Corey: Oh, absolutely. We've had multiple engagements discover security issues on that. “So, what are these instances in Australia doing?” “We don't have anything there.” “I believe you're being sincere when you say this.”Chris: Yes.Corey: However.Chris: “Last month, you're at $1,000 and this month, you're at $50,000. And oh, by the way, it's the ninth, so you might want to go look at that.”Corey: Here's the problem that you start seeing in large-scale companies though. You or I wind up posting our IAM credentials on GitHub somewhere in public—and I do this from time to time, intentionally with absolutely no permissions attached to a thing—and I started look at the timeline of, “Okay 3, 2, 1, go,” with the push and now I start counting. What happens? At what time does the quarantine policy apply? When do I get an email alert? When do people start trying to exploit it? From where are they trying to exploit it?It's a really interesting thing to look into, just from the position of how this stuff all fits together and works. And that's great, but there's a whole ‘nother piece to it where if you or I were to do such a thing and actually give it admin credentials, okay, my, I don't know, what, $50, $100 a month account that I use for a lot of my test stuff now starts getting charged enormous piles of money that winds up looking like a mortgage in San Francisco, I'm going to notice that. But if you have a company that spending, I don't know, between ten and $20 million a month, do you have any idea how much Bitcoin you've got to be mining in that account to even make a slight dent in the overall trajectory of those accounts?Chris: In the overall bill, a lot. And in a particularly mismanaged account, my experience is you will notice it if you're monitoring billing anomalies on a per-account basis. I think it's important to note, you talked about that quarantine policy. If you look at what actually Amazon drops a deny on, it's effectively start EC2 instances and change IAM policies. It doesn't prevent anybody from listing all your buckets and exfiltrating all your data. It doesn't prevent anybody from firing up Lambdas and other less commonly used resources. Don't assume oh, Amazon dropped the quarantine policy. I'm safe.Corey: I was talking to somebody who spends $4 a month on S3 and they wound up suddenly getting $60 grand a day and Lambda charges, because max out the Lambda concurrency in every region and set it to mine crypto for 15 minutes apiece, yeah, you'll spend $60,000 a day to get, what $500 in crypto. But it's super economical as long as it's in someone else's account. And then Amazon hits them with a straight face on these things, where, “Please pay the bill.” Which is horrifying when there's several orders of magnitude difference between your normal bill and what happens post-breach. But what I did my whole post on “17 Ways to Run Containers on AWS,” followed by “17 More Ways to Run Containers on AWS,” and [unintelligible 00:12:00] about three services away from having a third one ready to go on that, the point is not, “Too many ways to run containers,” because yes, that is true and it's also amusing to me—less so to the containers team at AWS which does not have a sense of humor or sense of self-awareness of which they have been alerted—and fine, but every time you're running a container, it is a way to turn it into a crypto mining operation, in some way shape or form, which means there are almost 40-some-odd services now that can reasonably be used to spin up cryptocurrency mining. And that is the best-case breach scenario in a bunch of ways. It costs a bunch of money and things to clean up, but ‘we lost customer data.' That can destroy companies.Chris: Here's the worst part. Crypto mining is no longer profitable even when I've got stolen API keys because bitcoin's in the toilet. So, now they are going after different things. Actually, the most recent one is they look to see if your account is out of the SCS sandbox and if so, they go back to the tried-and-true way of doing internet scams, which is email spam.Corey: For me, having worked in operations for a very long time, I've been in situations where I worked at Expensify and had access to customer data there. I have worked in other finance companies—I worked at Blackrock. Where I work now, I have access to customer billing data. And let me be serious here for a second, I take all of these things seriously, but I also in all of those roles slept pretty well at night. The one that kept me up was a brief stint I did as the Director of Tech Ops at Grindr over ten years ago because unlike the stuff where I'm spending the rest of my career and my time now, it's not just money anymore.Whereas today, if I get popped, someone can get access to what a bunch of companies are paying AWS. It's scandalous, and I will be sued into oblivion and my company will not exist anymore and I will have a cloud hanging over my head forever. So, I have to be serious about it—Chris: But nobody will die.Corey: Nobody dies. Whereas, “Oh, this person is on Grindr and they're not out publicly,” or they live in a jurisdiction where that is punishable by imprisonment or death, you have blood on your hands, on some level, and I have never wanted that kind of responsibility.Chris: Yeah. It's reasonably scary. I've always been happy to say that, you know, the worst thing that I had to do was keep the Russians off CNN and my friends from downloading Rick and Morty.Corey: Exactly. It's, “Oh, heavens, you're winding up costing some giant conglomerate somewhere theoretical money on streaming subscriptions.” It's not material to the state of the world. And part of it, too, is—what's always informed my approach to things is, I'm not a data hoarder in the way that it seems our entire industry is. For the Last Week in AWS newsletter, the data that I collect and track is pretty freaking small.It's, “You want to sign up for the lastweekinaws.com newsletter. Great, I need your email address.” I don't need your name, I don't need the company you work at. You want to give me a tagged email address? Fine. You want to give me some special address that goes through some anonymizing thing? Terrific. I need to know where I'm sending the newsletter. And then I run a query on that for metrics sometimes, which is this really sophisticated database query called a count. How many subscribers do I have at any given point because that matters to our sponsors. But can we get—you give us any demographic? No, I cannot. I can't. I have people who [unintelligible 00:15:43] follow up surveys sometimes and that's it.Chris: And you're able to make money doing that. You don't have to collect, okay, you know, Chris's zip code is this and Bob's zip code is that and Frank's zip code is the other thing.Corey: Exactly.Chris: Or job titles, or you know, our mother's maiden name or anything else like that.Corey: I talk about what's going on in the world of AWS, so it sort of seems to me that if you're reading this stuff every week, either because of the humor or in spite of the humor, you probably are in a position where services and goods tied to that ecosystem would be well-received by you or one of the other 32,000 people who happen to be reading the newsletter or listening to the podcast or et cetera, et cetera, et cetera. It's an old-timey business model. It's okay, I want to wind up selling, I don't know, expensive wristwatches. Well, maybe I'll advertise in a magazine that caters to people who have an interest in wristwatches, or caters to a demographic that traditionally buys those wristwatches. And okay, we'll run an ad campaign and see if it works.Chris: It's been traditional advertising, not the micro-targeting stuff. And you know, television was the same way back in the broadcast era, you know? You watched a particular show, people of that demographic who watched that particular show had certain advertisers they wanted.Corey: That part of the challenge I've seen too, from sponsors of this show, for example, is they know it works, but they're trying to figure out how to do any form of attribution on this. And my answer—which sounds self-serving, but it's true—is, there's no effective way to do it because every time you try, like, “Enter this coupon code,” yeah, I assure you, some of these things wind up costing millions of dollars to deploy at large companies at scale and they provide value for doing it. No one's going to punch in a coupon code to get 10% off or something like that. Procurement is going to negotiate custom contracts and it's going to be brought up maybe by someone who heard the podcast ad. Maybe it just sits in the back of their mind until they hear something and it just winds of contributing to a growing awareness of these things.You're never going to do attribution that works on things like that. People try sometimes to, “Oh, you'll get $25 in credit,” or, “We'll give you a free t-shirt if you fill out the form.” Yeah, but now you're biasing for people who find that a material motivator. When I'm debating what security suite I'm going to roll out at my enterprise I don't want a free t-shirt for that. In fact, if I get a free t-shirt and I wear that shirt from the vendor around the office while I'm trying to champion bringing that thing in, I look a little compromised.Chris: Yeah. Yeah, I am—[laugh] I got no response to that [laugh].Corey: No, no. I hear you. One thing I do want to talk about is the last time we spoke, you mentioned you were involved in getting fwd:cloudsec—a conference—off the ground. Like all good cloud security conferences, it's named after an email subject line.It is co-located with re:Inforce this year in Anaheim, California. Somewhat ominously enough, I used to live a block-and-a-half away from the venue. But I don't anymore and in fact, because nobody checks the global event list when they schedule these things, I will be on the other side of the world officiating a wedding the same day. So, yet again, I will not be at re:Inforce.Chris: That is a shame because I think you would have made an excellent person to contribute to our call for papers and attend. So yes, fwd:cloudsec is deliberately actually named after a subject line because all of the other Amazon conferences seem to be that way. And we didn't want to be going backwards and thinking, you know, past tense. We were looking forward to our conference. Yeah, so we're effectively a vendor-neutral cloud security conference. We liked the idea of being able to take the talks that Amazon PR would never allow on stage at re:Inforce and run with it.Corey: I would question that. I do want to call that out because I gave a talk at re:Invent one year about a vulnerability I found and reported, with the help of two other people, Scott Piper and Brandon Sherman, to the AWS security team. And we were able to talk about that on stage with Zack Glick, who at the time, was one of basically God's own prototypes, working over in the AWS environment next to Dan [Erson 00:19:56]. Now, Dan remains the salt of the earth, and if he ever leaves basically just short the entire US economy. It's easier. He is amazing. I digress. The point being is that they were very open about talking about an awful lot of stuff that I would never have expected that they would be okay with.Chris: And last year at re:Inforce, they had an excellent, excellent chalk talk—but it was a chalk talk, not recorded—on how ransomware attacks operate. And they actually, like, revealed some internal, very anonymized patterns of how attacks are working. So, they're starting to realize what we've been saying in the cloud security community for a while, which is, we need more legitimate threat intelligence. On the other hand, they don't want to call it threat intelligence because the word threat is threatening, and therefore, you know, we're going to just call it, you know, patterns or whatever. And our conference is, again, also multi-cloud, a concept that until recently, AWS, you know, didn't really want to acknowledge that there were other clouds and that people would use both of them [crosstalk 00:21:01]—Corey: Multi-cloud security is a nightmare. It's just awful.Chris: Yeah, I don't like multi-cloud, but I've come to realize that it is a thing. That you will either start at a company that says, “We're AWS and we're uni-cloud,” and then next thing, you know, either some rogue developer out there has gone and spun up an Azure subscription or your acquire somebody who's in GCP, or heaven forbid, you have to go into some, you know, tinhorn dictator's jurisdiction and they require you to be on-prem or leverage Oracle Cloud or something. And suddenly, congratulations, you're now multi-cloud. So yes, our goal is really to be the things that aren't necessarily onstage or aren't all just, “It's great.” Even your talk was how great the incident response and vulnerability remediation process was.Corey: How great my experience with it was at the time, to be clear. Because I also have gotten to a point where I am very aware that, in many cases when dealing with AWS, my reputation precedes me. So, when I wind up tweeting about a problem or opening a support case, I do not accept as a given that my experience is what everyone is going to experience. But a lot of the things they did made a lot of sense and I was frankly, impressed that they were willing to just talk about anything that they did internally. Because previously that had not been a thing that they did in open forums like that.Chris: But you go back to the Glue incident where somebody found a bug and they literally went and went to every single CloudTrail event going back to the dawn of the service to validate that, okay, the, only two times we ever saw this happen were between the two researcher's accounts who disclosed it. And so, kudos to them for that level of forward communication to their customers because yeah, I think we still haven't heard anything out of Azure for last year's—or a year-and-a-half ago's Wiz findings.Corey: Well, they did do a broad blog post about this that they put out, which I thought, “Okay, that was great. More of this please.” Because until they start talking about security issues and culture and the remediation thereof, I don't give a shit what they have to say about almost anything else because it all comes back to security. The only things I use Azure for, which admittedly has some great stuff; their computer vision API? Brilliant—but the things I use them for are things that I start from a premise of security is not important to that service.The thing I use it for on the soon-to-be-pivoted to Mastodon Twitter thread client that I built, it writes alt-text for images that are about to be put out publicly. Yeah, there's no security issue from that perspective. I am very hard-pressed to imagine a scenario in which that were not true.Chris: I can come up with a couple, but you know—Corey: It feels really contrived. And honestly, that's the thing that concerns me, too: the fact that I finally read, somewhat recently, an AWS white paper talking about—was it a white paper or was it blog post? I forget the exact media that it took. But it was about how they are seeing ransomware attacks on S3, which was huge because before that, I assumed it was something that was being made up by vendors to sell me something.Chris: So, that was the chalk talk.Corey: Yes.Chris: They finally got the chalk talk from re:Inforce, they gave it again at re:Invent because it was so well received and now they have it as a blog post out there, so that, you know, it's not just for people who show up in the room, they can hear it; it's actually now documented out there. And so, kudos to the Amazon security team for really getting that sort of threat intelligence out there to the community.Corey: Now, it's in writing, and that's something that I can cite as opposed to, “Well, I was at re:Invent and I heard—” Yeah, we saw the drink tab. We know what you might have thought you heard or saw at re:Invent. Give us something we can take to the board.Chris: There were a lot of us on that bar tab, so it's not all you.Corey: Exactly. And it was my pleasure to do it, to be clear. But getting back to fwd:cloudsec, I'm going to do you a favor. Whether it's an actual favor or the word favor belongs in quotes, the way that I submit CFPs, or conference talks, is optimized because I don't want to build a talk that is never going to get picked up. Why bother to go through all the work until I have to give it somewhere?So, I start with a catchy title and then three to five sentences. And if people accept it, great, then I get to build the talk. This is a forcing function in some ways because if you get a little delayed, they will not move the conference for you. I've checked. But the title of a talk that I think someone should submit for fwd:cloudsec is, “I Am Smarter Than You, so Cloud Security is Easy.”And the format and the conceit of the talk is present it with sort of a stand-it-up-to-take-it-down level of approach where you are over-confident in the fact that you are smarter than everyone else and best practices don't apply to you and so much of this stuff is just security theater designed as a revenue extraction mechanism as opposed to something you should actually be doing. And talk about why none of these things matter because you use good security and you know, it's good because you came up with it and there's no way that you could come up with something that you couldn't break because you're smart. It says so right in the title and you're on stage and you have a microphone. They don't. Turn that into something. I feel like there's a great way to turn that in a bunch of different directions. I'd love to see someone give that talk.Chris: I think Nickolas Sharp thought that too.Corey: [laugh]. Exactly. In fact, that will be a great way to bring it back around at the end. And it's like, “And that's why I'm better at security than you are. If you have any questions beyond this, you can reach me at whatever correctional institute I go in on Thursday.” Exactly. There's ways to make it fun and engaging. Because from my perspective, talks have to be entertaining or people don't pay attention.Chris: They're either entertaining, or they're so new and advanced. We're definitely an advanced cloud security practice thing. They were 500 levels. Not to brag or anything, but you know, you want the two to 300-level stuff, you can go CCJ up the street. We're hitting and going above and beyond what a lot of the [unintelligible 00:27:18]—Corey: I am not as advanced on that path as you are; I want to be very clear on this. You speak, I listen. You're one of those people when it comes to security. Because again, no one's life is hanging in the balance with respect to what I do. I am confident in our security posture here, but nothing's perfect. Everything is exploitable, on some level.It's also not my core area of focus. It is yours. And if you are not better than I am at this, then I have done something sort of strange, or so of you, in the same way that it is a near certainty—but not absolute—that I am better at optimizing AWS bills than you are. Specialists exist for a reason and to discount that expertise is the peak of hubris. Put that in your talk.Chris: Yeah. So, one talk I really want to see, and I've been threatening to give it for a while, is okay, if there's seventeen ways—or sorry, seventeen times two, soon to be seventeen times three ways to run containers in AWS, there's that many ways to exfiltrate credentials from those containers. What are all of those things? Do we have a holistic way of understanding, this is how credentials can be exfiltrated so that we then as defenders can go figure out, okay, how do we build detections and mitigations for this?Corey: Yeah. I'm a huge fan of Canarytokens myself, for that exact purpose. There are many devices I have where the only credentials in plain text on disk are things that as soon as they get used, I wind up with a bunch of things screaming at me that there's been a problem and telling me where it is. I'm not saying that my posture is impenetrable. Far from it. But you're going to have to work for it a little bit harder than running some random off-the-shelf security scanner against my AWS account and finding, oops, I forgot to turn on a bucket protection.Chris: And the other area that I think is getting really interesting is, all of the things that have credentials into your Cloud account, whether it's something like CircleCI or GitHub. I was having a conversation with somebody just this morning and we were talking about Roles Anywhere, and I was like, “Roles Anywhere is great if you've got a good strong PKI solution and can keep that private certificate or that certificate you need safe.” If you just put it on a disk, like, you would have put your AKIA and secret on a desk, congratulations, you haven't really improved security. You've just gotten rid of the IAM users that are being flagged in your CSPM tool, and congratulations, you have, in fact, achieved security theater.Corey: It's obnoxious, on some level. And part of the problem is cost and security are aligned and that people care about them right after they really should have cared about them. The difference is you can beg, cry, whine, et cetera to AWS for concessions, you can raise another round of funding; there have solutions with money. But security? That ship has already sailed.Chris: Yeah. Once the data is out, the data is out. Now, I will say on the bill, you get reminded of it every month, about three or four days after. It's like, “Oh. Crap, yeah, I should have turned off that EC2 instance. I just burned $100.” Or, “Oh hey, we didn't turn off that application. I just burned $100,000.” That doesn't happen on security. Security events tend to be few and far between; they're just much bigger when they happen.Corey: I really want to thank you for taking the time to chat with me. I'm sure I'll have you back on between now and re:Inforce slash fwd:cloudsec or anything else we come up with that resembles an email subject line. If people want to learn more and follow along with your adventures—as they should—where's the best place for him to find you these days?Chris: So, I am now pretty much living on Mastodon on the InfoSec Exchange. And my website, chrisfarris.com is where you can find the link to that because it's not just at, you know, whatever. You have to give the whole big long URL in Mastodon. It's no longer—Corey: Yeah. It's like a full-on email address with weird domains.Chris: Exactly, yeah. So, find me at http colon slash slash infosec dot exchange slash at jcfarris. Or just hit Chris Farris and follow the links. For fwd:cloudsec, we are conveniently located at fwdcloudsec.org, which is F-W-D cloud sec dot org. No colons because I don't think those are valid in whois.Corey: Excellent choice. And of course, links to that go in the [show notes 00:31:32], so click the button. It's easier. Thanks again for your time. I really appreciate it.Chris: Thank you.Corey: Chris Farris, Cloud Security Nerd at Turbot slash Turbo. 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, along with an angry comment that resembles a lawsuit being filed, and then have it processed-served to me because presumably, you work at Ubiquiti.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.

About Chris Chris Farris has been in the IT field since 1994 primarily focused on Linux, networking, and security. For the last 8 years, he has focused on public-cloud and public-cloud security. He has built and evolved multiple cloud security programs for major media companies, focusing on enabling the broader security team's objectives of secure design, incident response and vulnerability management. He has developed cloud security standards and baselines to provide risk-based guidance to development and operations teams. As a practitioner, he's architected and implemented multiple serverless and traditional cloud applications focused on deployment, security, operations, and financial modeling.Chris now does cloud security research for Turbot and evangelizes for the open source tool Steampipe. He is one if the organizers of the fwd:cloudsec conference (https://fwdcloudsec.org) and has given multiple presentations at AWS conferences and BSides events.When not building things with AWS's building blocks, he enjoys building Legos with his kid and figuring out what interesting part of the globe to travel to next. He opines on security and technology on Twitter and his website https://www.chrisfarris.comLinks Referenced: Turbot: https://turbot.com/ fwd:cloudsec: https://fwdcloudsec.org/ Steampipe: https://steampipe.io/ Steampipe block: https://steampipe.io/blog 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: Tailscale SSH is a new, and arguably better way to SSH. Once you've enabled Tailscale SSH on your server and user devices, Tailscale takes care of the rest. So you don't need to manage, rotate, or distribute new SSH keys every time someone on your team leaves. Pretty cool, right? Tailscale gives each device in your network a node key to connect to your VPN, and uses that same key for SSH authorization and encryption. So basically you're SSHing the same way that you're already managing your network.So what's the benefit? Well, built-in key rotation, the ability to manage permissions as code, connectivity between any two devices, and reduced latency. You can even ask users to re-authenticate SSH connections for that extra bit of security to keep the compliance folks happy. Try Tailscale now - it's free forever for personal use.Corey: This episode is sponsored by our friends at Logicworks. Getting to the cloud is challenging enough for many places, especially maintaining security, resiliency, cost control, agility, etc, etc, etc. Things break, configurations drift, technology advances, and organizations, frankly, need to evolve. How can you get to the cloud faster and ensure you have the right team in place to maintain success over time? Day 2 matters. Work with a partner who gets it - Logicworks combines the cloud expertise and platform automation to customize solutions to meet your unique requirements. Get started by chatting with a cloud specialist today at snark.cloud/logicworks. That's snark.cloud/logicworksCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone that I have been meaning to invite slash drag onto this show for a number of years. We first met at re:Inforce the first year that they had such a thing, Amazon's security conference for cloud, as is Amazon's tradition, named after an email subject line. Chris Farris is a cloud security nerd at Turbot. He's also one of the organizers for fwd:cloudsec, another security conference named after an email subject line with a lot more self-awareness than any of Amazon's stuff. Chris, thank you for joining me.Chris: Oh, thank you for dragging me on. You can let go of my hair now.Corey: Wonderful, wonderful. That's why we're all having the thinning hair going on. People just use it to drag us to and fro, it seems. So, you've been doing something that I'm only going to describe as weird lately because your background—not that dissimilar from mine—is as a practitioner. You've been heavily involved in the security space for a while and lately, I keep seeing an awful lot of things with your name on them getting sucked up by the giant app surveillance apparatus deployed to the internet, looking for basically any mention of AWS that I wind up using to write my newsletter and feed the content grist mill every year. What are you doing and how'd you get there?Chris: So, what am I doing right now is, I'm in marketing. It's kind of a, you know, “Oops, I'm sorry I did that.”Corey: Oh, the running gag is, you work in DevRel; that means, “Oh, you're in marketing, but they're scared to tell you that.” You're self-aware.Chris: Yeah.Corey: Good for you.Chris: I'm willing to address that I'm in marketing now. And I've been a cloud practitioner since probably 2014, cloud security since about 2017. And then just decided, the problem that we have in the cloud security community is a lot of us are just kind of sitting in a corner in our companies and solving problems for our companies, but we're not solving the problems at scale. So, I wanted a job that would allow me to reach a broader audience and help a broader audience. Where I see cloud security having—you know, or cloud in general falling down is Amazon makes it really hard for you to do your side of shared responsibility, and so we need to be out there helping customers understand what they need to be doing. So, I am now at a company called Turbot and we're really trying to promote cloud security.Corey: One of the first promoted guest episodes of this show was David Boeke, your CTO, and one of the things that I regret is that I've sort of lost track of Turbot over the past few years because, yeah, one or two things might have been going on during that timeline as I look back at having kids in the middle of a pandemic and the deadly plague o'er land. And suddenly, every conversation takes place over Zoom, which is like, “Oh, good, it's like a happy hour only instead, now it's just like a conference call for work.” It's like, ‘Conference Calls: The Drinking Game' is never the great direction to go in. But it seems the world is recovering. We're going to be able to spend some time together at re:Invent by all accounts that I'm actively looking forward to.As of this recording, you're relatively new to Turbot, and I figured out that you were going there because, once again, content hits my filters. You wrote a fascinating blog post that hits on an interest of mine that I don't usually talk about much because it's off-putting to some folk, and these days, I don't want to get yelled at and more than I have to about the experience of traveling, I believe it was to an all-hands on the other side of the world.Chris: Yep. So, my first day on the job at Turbot, I was landing in Kuala Lumpur, Malaysia, having left the United States 24 hours—or was it 48? It's hard to tell when you go to the other side of the planet and the time zones have also shifted—and then having left my prior company day before that. But yeah, so Turbot about traditionally has an annual event where we all get together in person. We're a completely remote company, but once a year, we all get together in person in our integrate event.And so, that was my first day on the job. And then you know, it was basically two weeks of reasonably intense hackathons, building out a lot of stuff that hopefully will show up open-source shortly. And then yeah, meeting all of my coworkers. And that was nice.Corey: You've always had a focus through all the time that I've known you and all the public content that you've put out there that has come across my desk that seems to center around security. It's sort of an area that I give a nod to more often than I would like, on some level, but that tends to be your bread and butter. Your focus seems to be almost overwhelmingly on I would call it AWS security. Is that fair to say or is that a mischaracterization of how you view it slash what you actually do? Because, again, we have these parasocial relationships with voices on the internet. And it's like, “Oh, yeah, I know all about that person.” Yeah, you've met them once and all you know other than that is what they put on Twitter.Chris: You follow me on Twitter. Yeah, I would argue that yes, a lot of what I do is AWS-related security because in the past, a lot of what I've been responsible for is cloud security in AWS. But I've always worked for companies that were multi-cloud; it's just that 90% of everything was Amazon and so therefore 90% of my time, 90% of my problems, 90% of my risk was all in AWS. I've been trying to break out of that. I've been trying to understand the other clouds.One of the nice aspects of this role and working on Steampipe is I am now experimenting with other clouds. The whole goal here is to be able to scale our ability as an industry and as security practitioners to support multiple clouds. Because whether we want to or not, we've got it. And so, even though 90% of my spend, 90% of my resources, 90% of my applications may be in AWS, that 10% that I'm ignoring is probably more than 10% of my risk, and we really do need to understand and support major clouds equally.Corey: One post you had recently that I find myself in wholehearted agreement with is on the adoption of Tailscale in the enterprise. I use it for all of my personal nonsense and it is transformative. I like the idea of what that portends for a multi-cloud, or poly-cloud, or whatever the hell we're calling it this week, sort of architectures were historically one of the biggest problems in getting to clouds two speak to one another and manage them in an intelligent way is the security models are different, the user identity stuff is different as well, and the network stuff has always been nightmarish. Well, with Tailscale, you don't have to worry about that in the same way at all. You can, more or less, ignore it, turn on host-based firewalls for everything and just allow Tailscale. And suddenly, okay, I don't really have to think about this in the same way.Chris: Yeah. And you get the micro-segmentation out of it, too, which is really nice. I will agree that I had not looked at Tailscale until I was asked to look at Tailscale, and then it was just like, “Oh, I am completely redoing my home network on that.” But looking at it, it's going to scare some old-school network engineers, it's going to impact their livelihoods and that is going to make them very defensive. And so, what I wanted to do in that post was kind of address, as a practitioner, if I was looking at this with an enterprise lens, what are the concerns you would have on deploying Tailscale in your environment?A lot of those were, you know, around user management. I think the big one that is—it's a new thing in enterprise security, but kind of this host profiling, which is hey, before I let your laptop on the network, I'm going to go make sure that you have antivirus and some kind of EDR, XDR, blah-DR agents so that you know we have a reasonable thing that you're not going to just go and drop [unintelligible 00:09:01] on the network and next thing you know, we're Maersk. Tailscale, that's going to be their biggest thing that they are going to have to figure out is how do they work with some of these enterprise concerns and things along those lines. But I think it's an excellent technology, it was super easy to set up. And the ability to fine-tune and microsegment is great.Corey: Wildly so. They occasionally sponsor my nonsense. I have no earthly idea whether this episode is one of them because we have an editorial firewall—they're not paying me to set any of this stuff, like, “And this is brought to you by whatever.” Yeah, that's the sponsored ad part. This is just, I'm in love with the product.One of the most annoying things about it to me is that I haven't found a reason to give them money yet because the free tier for my personal stuff is very comfortably sized and I don't have a traditional enterprise network or anything like that people would benefit from over here. For one area in cloud security that I think I have potentially been misunderstood around, so I want to take at least this opportunity to clear the air on it a little bit has been that, by all accounts, I've spent the last, mmm, few months or so just absolutely beating the crap out of Azure. Before I wind up adding a little nuance and context to that, I'd love to get your take on what, by all accounts, has been a pretty disastrous year-and-a-half for Azure security.Chris: I think it's been a disastrous year-and-a-half for Azure security. Um—[laugh].Corey: [laugh]. That was something of a leading question, wasn't it?Chris: Yeah, no, I mean, it is. And if you think, though, back, Microsoft's repeatedly had these the ebb and flow of security disasters. You know, Code Red back in whatever the 2000s, NT 4.0 patching back in the '90s. So, I think we're just hitting one of those peaks again, or hopefully, we're hitting the peak and not [laugh] just starting the uptick. A lot of what Azure has built is stuff that they already had, commercial off-the-shelf software, they wrapped multi-tenancy around it, gave it a new SKU under the Azure name, and called is cloud. So, am I super-surprised that somebody figured out how to leverage a Jupyter notebook to find the back-end credentials to drop the firewall tables to go find the next guy over's Cosmos DB? No, I'm not.Corey: I find their failures to be less egregious on a technical basis because let's face it, let's be very clear here, this stuff is hard. I am not pretending for even a slight second that I'm a better security engineer than the very capable, very competent people who work there. This stuff is incredibly hard. And I'm not—Chris: And very well-funded people.Corey: Oh, absolutely, yeah. They make more than I do, presumably. But it's one of those areas where I'm not sitting here trying to dunk on them, their work, their efforts, et cetera, and I don't do a good enough job of clarifying that. My problem is the complete radio silence coming out of Microsoft on this. If AWS had a series of issues like this, I'm hard-pressed to imagine a scenario where they would not have much more transparent communications, they might very well trot out a number of their execs to go on a tour to wind up talking about these things and what they're doing systemically to change it.Because six of these in, it's like, okay, this is now a cultural problem. It's not one rando engineer wandering around the company screwing things up on a rotational basis. It's, what are you going to do? It's unlikely that firing Steven is going to be your fix for these things. So, that is part of it.And then most recently, they wound up having a blog post on the MSRC, the Microsoft Security Resource Center is I believe that acronym? The [mrsth], whatever; and it sounds like a virus you pick up in a hospital—but the problem that I have with it is that they spent most of that being overly defensive and dunking on SOCRadar, the vulnerability researcher who found this and reported it to them. And they had all kinds of quibbles with how it was done, what they did with it, et cetera, et cetera. It's, “Excuse me, you're the ones that left customer data sitting out there in the Azure equivalent of an S3 bucket and you're calling other people out for basically doing your job for you? Excuse me?”Chris: But it wasn't sensitive customer data. It was only the contract information, so therefore it was okay.Corey: Yeah, if I put my contract information out there and try and claim it's not sensitive information, my clients will laugh and laugh as they sue me into the Stone Age.Chris: Yeah well, clearly, you don't have the same level of clickthrough terms that Microsoft is able to negotiate because, you know, [laugh].Corey: It's awful as well, it doesn't even work because, “Oh, it's okay, I lost some of your data, but that's okay because it wasn't particularly sensitive.” Isn't that kind of up to you?Chris: Yes. And if A, I'm actually, you know, a big AWS shop and then I'm looking at Azure and I've got my negotiations in there and Amazon gets wind that I'm negotiating with Azure, that's not going to do well for me and my business. So no, this kind of material is incredibly sensitive. And that was an incredibly tone-deaf response on their part. But you know, to some extent, it was more of a response than we've seen from some of the other Azure multi-tenancy breakdowns.Corey: Yeah, at least they actually said something. I mean, there is that. It's just—it's wild to me. And again, I say this as an Azure customer myself. Their computer vision API is basically just this side of magic, as best I can tell, and none of the other providers have anything like it.That's what I want. But, you know, it almost feels like that service is under NDA because no one talks about it when they're using this service. I did a whole blog post singing its praises and no one from that team reached out to me to say, “Hey, glad you liked it.” Not that they owe me anything, but at the same time it's incredible. Why am I getting shut out? It's like, does this company just have an entire policy of not saying anything ever to anyone at any time? It seems it.Chris: So, a long time ago, I came to this realization that even if you just look at the terminology of the three providers, Amazon has accounts. Why does Amazon have Amazon—or AWS accounts? Because they're a retail company and that's what you signed up with to buy your underwear. Google has projects because they were, I guess, a developer-first thing and that was how they thought about it is, “Oh, you're going to go build something. Here's your project.”What does Microsoft have? Microsoft Azure Subscriptions. Because they are still about the corporate enterprise IT model of it's really about how much we're charging you, not really about what you're getting. So, given that you're not a big enterprise IT customer, you don't—I presume—do lots and lots of golfing at expensive golf resorts, you're probably not fitting their demographic.Corey: You're absolutely not. And that's wild to me. And yet, here we are.Chris: Now, what's scary is they are doing so many interesting things with artificial intelligence… that if… their multi-tenancy boundaries are as bad as we're starting to see, then what else is out there? And more and more, we is carbon-based life forms are relying on Microsoft and other cloud providers to build AI, that's kind of a scary thing. Go watch Satya's keynote at Microsoft Ignite and he's showing you all sorts of ways that AI is going to start replacing the gig economy. You know, it's not just Tesla and self-driving cars at this point. Dali is going to replace the independent graphics designer.They've got things coming out in their office suite that are going to replace the mom-and-pop marketing shops that are generating menus and doing marketing plans for your local restaurants or whatever. There's a whole slew of things where they're really trying to replace people.Corey: That is a wild thing to me. And part of the problem I have in covering AWS is that I have to differentiate in a bunch of different ways between AWS and its Amazon corporate parent. And they have that problem, too, internally. Part of the challenge they have, in many cases, is that perks you give to employees have to scale to one-and-a-half million people, many of them in fulfillment center warehouse things. And that is a different type of problem that a company, like for example, Google, where most of their employees tend to be in office job-style environments.That's a weird thing and I don't know how to even start conceptualizing things operating at that scale. Everything that they do is definitionally a very hard problem when you have to make it scale to that point. What all of the hyperscale cloud providers do is, from where I sit, complete freaking magic. The fact that it works as well as it does is nothing short of a modern-day miracle.Chris: Yeah, and it is more than just throwing hardware at the problem, which was my on-prem solution to most of the things. “Oh, hey. We need higher availability? Okay, we're going to buy two of everything.” We called it the Noah's Ark model, and we have an A side and a B side.And, “Oh, you know what? Just in case we're going to buy some extra capacity and put it in a different city so that, you know, we can just fail from our primary city to our secondary city.” That doesn't work at the cloud provider scale. And really, we haven't seen a major cloud outage—I mean, like, a bad one—in quite a while.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: The outages are always fascinating, just from the way that they are reported in the mainstream media. And again, this is hard, I get it. I am not here to crap on journalists. They, for some ungodly, unknowable reason, have decided not to spend their entire career focusing on the nuances of one very specific, very deep industry. I don't know why.But as [laugh] a result, they wind up getting a lot of their baseline facts wrong about these things. And that's fair. I'm not here to necessarily act as an Amazon spokesperson when these things happen. They have an awful lot of very well-paid people who can do that. But it is interesting just watching the blowback and the reaction of whatever there's an outage, the conversation is never “Does Amazon or Azure or Google suck?” It's, “Does cloud suck as a whole?”That's part of the reason I care so much about Azure getting their act together. If it were just torpedoing Microsoft's reputation, then well, that's sad, but okay. But it extends far beyond that to a point where it's almost where the enterprise groundhog sees the shadow of a data breach and then we get six more years of data center build-outs instead of moving things to a cloud. I spent too many years working in data centers and I have the scars from the cage nuts and crimping patch cables frantically in the middle of the night to prove it. I am thrilled at the fact that I don't believe I will ever again have to frantically drive across town in the middle of the night to replace a hard drive before the rest of the array degrades. Cloud has solved those problems beautifully. I don't want to go back to the Dark Ages.Chris: Yeah, and I think that there's a general potential that we could start seeing this big push towards going back on-prem for effectively sovereign data reasons, whether it's this country has said, “You cannot store your data about our citizens outside of our borders,” and either they're doing that because they do not trust the US Silicon Valley privacy or whatever, or because if it's outside of our borders, then our secret police agents can come knocking on the door at two in the morning to go find out what some dissidents' viewings habits might have been, I see sovereign cloud as this thing that may be a back step from this ubiquitous thing that we have right now in Amazon, Azure, and Google. And so, as we start getting to the point in the history books where we start seeing maps with lots of flags, I think we're going to start seeing a bifurcation of cloud as just a whole thing. We see it already right now. The AWS China partition is not owned by Amazon, it is not run by Amazon, it is not controlled by Amazon. It is controlled by the communist government of China. And nobody is doing business in Russia right now, but if they had not done what they had done earlier this year, we might very well see somebody spinning up a cloud provider that is completely controlled by and in the Russian government.Corey: Well, yes or no, but I want to challenge that assessment for a second because I've had conversations with a number of folks about this where people say, “Okay, great. Like, is the alt-right, for example, going to have better options now that there might be a cloud provider spinning up there?” Or, “Well, okay, what about a new cloud provider to challenge the dominance of the big three?” And there are all these edge cases, either geopolitically or politically based upo—or folks wanting to wind up approaching it from a particular angle, but if we were hired to build out an MVP of a hyperscale cloud provider, like, the budget for that MVP would look like one 100 billion at this point to get started and just get up to a point of critical mass before you could actually see if this thing has legs. And we'd probably burn through almost all of that before doing a single dime in revenue.Chris: Right. And then you're doing that in small markets. Outside of the China partition, these are not massively large markets. I think Oracle is going down an interesting path with its idea of Dedicated Cloud and Oracle Alloy [unintelligible 00:22:52].Corey: I like a lot of what Oracle's doing, and if younger me heard me say that, I don't know how hard I'd hit myself, but here we are. Their free tier for Oracle Cloud is amazing, their data transfer prices are great, and their entire approach of, “We'll build an entire feature complete region in your facility and charge you what, from what I can tell, is a very reasonable amount of money,” works. And it is feature complete, not, “Well, here are the three services that we're going to put in here and everything else is well… it's just sort of a toehold there so you can start migrating it into our big cloud.” No. They're doing it right from that perspective.The biggest problem they've got is the word Oracle at the front end and their, I would say borderline addiction to big-E enterprise markets. I think the future of cloud looks a lot more like cloud-native companies being founded because those big enterprises are starting to describe themselves in similar terminology. And as we've seen in the developer ecosystem, as go startups, so do big companies a few years later. Walk around any big company that's undergoing a digital transformation, you'll see a lot more Macs on desktops, for example. You'll see CI/CD processes in place as opposed to, “Well, oh, you want something new, it's going to be eight weeks to get a server rack downstairs and accounting is going to have 18 pages of forms for you to fill out.” No, it's “click the button,” or—Chris: Don't forget the six months of just getting the financial CapEx approvals.Corey: Exactly.Chris: You have to go through the finance thing before you even get to start talking to techies about when you get your server. I think Oracle is in an interesting place though because it is embracing the fact that it is number four, and so therefore, it's like we are going to work with AWS, we are going to work with Azure, our database can run in AWS or it can run in our cloud, we can interconnect directly, natively, seamlessly with Azure. If I were building a consumer-based thing and I was moving into one of these markets where one of these governments was demanding something like a sovereign cloud, Oracle is a great place to go and throw—okay, all of our front-end consumer whatever is all going to sit in AWS because that's what we do for all other countries. For this one country, we're just going to go and build this thing in Oracle and we're going to leverage Oracle Alloy or whatever, and now suddenly, okay, their data is in their country and it's subject to their laws but I don't have to re-architect to go into one of these, you know, little countries with tin horn dictators.Corey: It's the way to do multi-cloud right, from my perspective. I'll use a component service in a different cloud, I'm under no illusions, though, in doing that I'm increasing my resiliency. I'm not removing single points of failure; I'm adding them. And I make that trade-off on a case-by-case basis, knowingly. But there is a case for some workloads—probably not yours if you're listening to this; assume not, but when you have more context, maybe so—where, okay, we need to be across multiple providers for a variety of strategic or contextual reasons for this workload.That does not mean everything you build needs to be able to do that. It means you're going to make trade-offs for that workload, and understanding the boundaries of where that starts and where that stops is going to be important. That is not the worst idea in the world for a given appropriate workload, that you can optimize stuff into a container and then can run, more or less, anywhere that can take a container. But that is also not the majority of most people's workloads.Chris: Yeah. And I think what that comes back to from the security practitioner standpoint is you have to support not just your primary cloud, your favorite cloud, the one you know, you have to support any cloud. And whether that's, you know, hey, congratulations. Your developers want to use Tailscale because it bypasses a ton of complexity in getting these remote island VPCs from this recent acquisition integrated into your network or because you're going into a new market and you have to support Oracle Cloud in Saudi Arabia, then you as a practitioner have to kind of support any cloud.And so, one of the reasons that I've joined and I'm working on, and so excited about Steampipe is it kind of does give you that. It is a uniform interface to not just AWS, Azure, and Google, but all sorts of clouds, whether it's GitHub or Oracle, or Tailscale. So, that's kind of the message I have for security practitioners at this point is, I tried, I fought, I screamed and yelled and ranted on Twitter, against, you know, doing multi-cloud, but at the end of the day, we were still multi-cloud.Corey: When I see these things evolving, is that, yeah, as a practitioner, we're increasingly having to work across multiple providers, but not to a stupendous depth that's the intimidating thing that scares the hell out of people. I still remember my first time with the AWS console, being so overwhelmed with a number of services, and there were 12. Now, there are hundreds, and I still feel that same sense of being overwhelmed, but I also have the context now to realize that over half of all customer spend globally is on EC2. That's one service. Yes, you need, like, five more to get it to work, but okay.And once you go through learning that to get started, and there's a lot of moving parts around it, like, “Oh, God, I have to do this for every service?” No, take Route 53—my favorite database, but most people use it as a DNS service—you can go start to finish on basically everything that service does that a human being is going to use in less than four hours, and then you're more or less ready to go. Everything is not the hairy beast that is EC2. And most of those services are not for you, whoever you are, whatever you do, most AWS services are not for you. Full stop.Chris: Yes and no. I mean, as a security practitioner, you need to know what your developers are doing, and I've worked in large organizations with lots of things and I would joke that, oh, yeah, I'm sure we're using every service but the IoT, and then I go and I look at our bill, and I was like, “Oh, why are we dropping that much on IoT?” Oh, because they wanted to use the Managed MQTT service.Corey: Ah, I start with the bill because the bill is the source of truth.Chris: Yes, they wanted to use the Managed MQTT service. Okay, great. So, we're now in IoT. But how many of those things have resource policies, how many of those things can be made public, and how many of those things are your CSPM actually checking for and telling you that, hey, a developer has gone out somewhere and made this SageMaker notebook public, or this MQTT topic public. And so, that's where you know, you need to have that level of depth and then you've got to have that level of depth in each cloud. To some extent, if the cloud is just the core basic VMs, object storage, maybe some networking, and a managed relational database, super simple to understand what all you need to do to build a baseline to secure that. As soon as you start adding in on all of the fancy services that AWS has. I re—Corey: Yeah, migrating your Step Functions workflow to other cloud is going to be a living goddamn nightmare. Migrating something that you stuffed into a container and run on EC2 or Fargate is probably going to be a lot simpler. But there are always nuances.Chris: Yep. But the security profile of a Step Function is significantly different. So, you know, there's not much you can do there wrong, yet.Corey: You say that now, but wait for their next security breach, and then we start calling them Stumble Functions instead.Chris: Yeah. I say that. And the next thing, you know, we're going to have something like Lambda [unintelligible 00:30:31] show up and I'm just going to be able to put my Step Function on the internet unauthenticated. Because, you know, that's what Amazon does: they innovate, but they don't necessarily warn security practitioners ahead of their innovation that, hey, you're we're about to release this thing. You might want to prepare for it and adjust your baselines, or talk to your developers, or here's a service control policy that you can drop in place to, you know, like, suppress it for a little bit. No, it's like, “Hey, these things are there,” and by the time you see the tweets or read the documentation, you've got some developer who's put it in production somewhere. And then it becomes a lot more difficult for you as a security practitioner to put the brakes on it.Corey: I really want to thank you for spending so much time talking to me. If people want to learn more and follow your exploits—as they should—where can they find you?Chris: They can find me at steampipe.io/blog. That is where all of my latest rants, raves, research, and how-tos show up.Corey: And we will, of course, put a link to that in the [show notes 00:31:37]. Thank you so much for being so generous with your time. I appreciate it.Chris: Perfect, thank you. You have a good one.Corey: Chris Farris, cloud security nerd at Turbot. 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 along with an angry insulting comment, and be sure to mention exactly which Azure communications team you work on.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.

About AshishAshish has over 13+yrs experience in the Cybersecurity industry with the last 7 focusing primarily helping Enterprise with managing security risk at scale in cloud first world and was the CISO of a global Cloud First Tech company in his last role. Ashish is also a keynote speaker and host of the widely poplar Cloud Security Podcast, a SANS trainer for Cloud Security & DevSecOps. Ashish currently works at Snyk as a Principal Cloud Security Advocate. He is a frequent contributor on topics related to public cloud transformation, Cloud Security, DevSecOps, Security Leadership, future Tech and the associated security challenges for practitioners and CISOs.Links Referenced: Cloud Security Podcast: https://cloudsecuritypodcast.tv/ Personal website: https://www.ashishrajan.com/ LinkedIn: https://www.linkedin.com/in/ashishrajan/ Twitter: https://twitter.com/hashishrajan Cloud Security Podcast YouTube: https://www.youtube.com/c/CloudSecurityPodcast Cloud Security Podcast LinkedIn: https://www.linkedin.com/company/cloud-security-podcast/ 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 Thinkst Canary. Most folks find out way too late that they've been breached. Thinkst Canary changes this. Deploy canaries and canary tokens in minutes, and then forget about them. Attackers tip their hand by touching them, giving you one alert, when it matters. With zero administrative overhead to this and almost no false positives, Canaries are deployed and loved on all seven continents. Check out what people are saying at canary.love today. Corey: This episode is bought to you in part by our friends at Veeam. Do you care about backups? Of course you don't. Nobody cares about backups. Stop lying to yourselves! You care about restores, usually right after you didn't care enough about backups.  If you're tired of the vulnerabilities, costs and slow recoveries when using snapshots to restore your data, assuming you even have them at all living in AWS-land, there is an alternative for you. Check out Veeam, thats V-E-E-A-M for secure, zero-fuss AWS backup that won't leave you high and dry when it's time to restore. Stop taking chances with your data. Talk to Veeam. My thanks to them for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is brought to us once again by our friends at Snyk. Snyk does amazing things in the world of cloud security and terrible things with the English language because, despite raising a whole boatload of money, they still stubbornly refuse to buy a vowel in their name. I'm joined today by Principal Cloud Security Advocate from Snyk, Ashish Rajan. Ashish, thank you for joining me.Corey: Your history is fascinating to me because you've been around for a while on a podcast of your own, the Cloud Security Podcast. But until relatively recently, you were a CISO. As has become relatively accepted in the industry, the primary job of the CISO is to get themselves fired, and then, “Well, great. What's next?” Well, failing upward is really the way to go wherever possible, so now you are at Snyk, helping the rest of us fix our security. That's my headcanon on all of that anyway, which I'm sure bears scant, if any, resemblance to reality, what's your version?Ashish: [laugh]. Oh, well, fortunately, I wasn't fired. And I think I definitely find that it's a great way to look at the CISO job to walk towards the path where you're no longer required because then I think you've definitely done your job. I moved into the media space because we got an opportunity to go full-time. I spoke about this offline, but an incident inspired us to go full-time into the space, so that's what made me leave my CISO job and go full-time into democratizing cloud security as much as possible for anyone and everyone. So far, every day, almost now, so it's almost like I dream about cloud security as well now.Corey: Yeah, I dream of cloud security too, but my dreams are of a better world in which people didn't tell me how much they really care about security in emails that demonstrate how much they failed to care about security until it was too little too late. I was in security myself for a while and got out of it because I was tired of being miserable all the time. But I feel that there's a deep spiritual alignment between people who care about cost and people who care about security when it comes to cloud—or business in general—because you can spend infinite money on those things, but it doesn't really get your business further. It's like paying for fire insurance. It isn't going to get you to your next milestone, whereas shipping faster, being more effective at launching a feature into markets, that can multiply revenue. That's what companies are optimized around. It's, “Oh, right. We have to do the security stuff,” or, “We have to fix the AWS billing piece.” It feels, on some level, like it's a backburner project most of the time and it's certainly invested in that way. What's your take on that?Ashish: I tend to disagree with that, for a couple reasons.Corey: Excellent. I love arguments.Ashish: I feel this in a healthy way as well. A, I love the analogy of spiritual animals where they are cost optimization as well as the risk aversion as well. I think where I normally stand—and this is what I had to unlearn after doing years of cybersecurity—was that initially, we always used to be—when I say ‘we,' I mean cybersecurity folks—we always used to be like police officers. Is that every time there's an incident, it turns into a crime scene, and suddenly we're all like, “Pew, pew, pew,” with trying to get all the evidence together, let's make this isolated as much—as isolated as possible from the rest of the environment, and let's try and resolve this.I feel like in Cloud has asked people to become more collaborative, which is a good problem to have. It also encourages that, I don't know how many people know this, but the reason we have brakes in our cars is not because we can slow down the car; it's so that we can go faster. And I feel security is the same thing. The guardrails we talk about, the risks that you're trying to avert, the reason you're trying to have security is not to slow down but to go faster. Say for example in an ideal world, to quote what you were saying earlier if we were to do the right kind of encryption—I'm just going to use the most basic example—if we just do encryption, right, and just ensure that as a guardrail, the entire company needs to have encryption at rest, encryption in transit, period, nothing else, no one cares about anything else.But if you just lay that out as a framework and this is our guardrail, no one brakes this, and whoever does, hey we—you know, slap on the wrist and come back on to the actual track, but keep going forward. That just means any project that comes in that meets [unintelligible 00:04:58] criteria. Keeps going forward, as many times we want to go into production. Doesn't matter. So, that is the new world of security that we are being asked to move towards where Amazon re:Invent is coming in, there will be another, I don't know, three, four hundred services that will be released. How many people, irrespective of security, would actually know all of those services? They would not. So, [crosstalk 00:05:20]—Corey: Oh, we've long since passed the point where I can convincingly talk about AWS services that don't really exist and not get called out on it by Amazon employees. No one keeps them on their head. Except me because I'm sad.Ashish: Oh, no, but I think you're right, though. I can't remember who was it—maybe Andrew Vogel or someone—they didn't release a service which didn't exist, and became, like, a thing on Twitter. Everyone—Corey: Ah, AWS's Infinidash. I want to say that was Joe Nash out of Twilio at the time. I don't recall offhand if I'm right on that, but that's how it feels. Yeah, it was certainly not me. People said that was my idea. Nope, nope, I just basically amplified it to a huge audience.But yeah, it was a brilliant idea, just because it's a fake service so everyone could tell stories about it. And amazing product feedback, if you look at it through the right lens of how people view your company and your releases when they get this perfect, platonic ideal of what it is you might put out there, what do people say about it?Ashish: Yeah. I think that's to your point, I will use that as an example as well to talk about things that there will always be a service which we will be told about for the first time, which we will not know. So, going back to the unlearning part, as a security team, we just have to understand that we can't use the old ways of, hey, I want to have all the controls possible, cover all there is possible. I need to have a better understanding of all the cloud services because I've done, I don't know, 15 years of cloud, there is no one that has 10, 15 years of cloud unless you're I don't know someone from Amazon employee yourself. Most people these days still have five to six years experience and they're still learning.Even the cloud engineering folks or the DevOps folks, they're all still learning and the tooling is continuing to evolve. So yeah, I think I definitely find that the security in this cloud world a lot more collaborative and it's being looked at as the same function as a brake would have in car: to help you go faster, not to just slam the brake every time it's like, oh, my God, is the situation isolated and to police people.Corey: One of the points I find that is so aligned between security and cost—and you alluded to it a minute ago—is the idea of helping companies go faster safely. To that end, guardrails have to be at least as easy as just going off and doing it cow-person style. Because if it's not, it's more work in any way, shape, or form, people won't do it. People will not tag their resources by hand, people will not go through and use the dedicated account structure you've got that gets in their way and screams at them every time they try to use one of the native features built into the platform. It has to get out of their way and make things easier, not worse, or people fight it, they go around it, and you're never going to get buy-in.Ashish: Do you feel like cost is something that a lot more people pay a lot more attention to because, you know, that creeps into your budget? Like, as people who've been leaders before, and this was the conversation, they would just go, “Well, I only have, I don't know, 100,000 to spend this quarter,” or, “This year,” and they are the ones who—are some of them, I remember—I used to have this manager, once, a CTO would always be conscious about the spend. It's almost like if you overspend, where do you get the money from? There's no money to bring in extra. Like, no. There's a set money that people plan for any year for a budget. And to your point about if you're not keeping an eye on how are we spending this in the AWS context because very easy to spend the entire money in one day, or in the cloud context. So, I wonder if that is also a big driver for people to feel costs above security? Where do you stand on that?Corey: When it comes to cost, one of the nice things about it—and this is going to sound sarcastic, but I swear to you it's not—it's only money.Ashish: Mmm.Corey: Think about that for a second because it's true. Okay, we wound up screwing up and misconfiguring something and overspending. Well, there are ways around that. You can call AWS, you can get credits, you can get concessions made for mistakes, you can sign larger contracts and get a big pile of proof of concept credit et cetera, et cetera. There are ways to make that up, whereas with security, it's there are no do-overs on security breaches.Ashish: No, that's a good point. I mean, you can always get more money, use a credit card, worst case scenario, but you can't do the same for—there's a security breach and suddenly now—hopefully, you don't have to call New York Times and say, “Can you undo that article that you just have posted that told you it was a mistake. We rewinded what we did.”Corey: I'm curious to know what your take is these days on the state of the cloud security community. And the reason I bring that up is, well, I started about a year-and-a-half ago now doing a podcast every Thursday. Which is Last Week in AWS: Security Edition because everything else I found in the industry that when I went looking was aimed explicitly at either—driven by the InfoSec community, which is toxic and a whole bunch of assumed knowledge already built in that looks an awful lot like gatekeeping, which is the reason I got out of InfoSec in the first place, or alternately was completely vendor-captured, where, okay, great, we're going to go ahead and do a whole bunch of interesting content and it's all brought to you by this company and strangely, all of the content is directly align with doing some pretty weird things that you wouldn't do unless you're trying to build a business case for that company's product. And it just feels hopelessly compromised. I wanted to find something that was aimed at people who had to care about security but didn't have security as part of their job title. Think DevOps types and you're getting warmer.That's what I wound up setting out to build. And when all was said and done, I wasn't super thrilled with, honestly, how alone it still felt. You've been doing this for a while, and you're doing a great job at it, don't get me wrong, but there is the question that—and I understand they're sponsoring this episode, but the nice thing about promoted guest episodes is that they can buy my attention, not my opinion. How do you retain creative control of your podcast while working for a security vendor?Ashish: So, that's a good question. So, Snyk by themselves have not ever asked us to change any piece of content; we have been working with them for the past few months now. The reason we kind of came along with Snyk was the alignment. And we were talking about this earlier for I totally believe that DevSecOps and cloud security are ultimately going to come together one day. That may not be today, that may not be tomorrow, that may not be in 2022, or maybe 2023, but there will be a future where these two will sit together.And the developer-first security mentality that they had, in this context from cloud prospective—developers being the cloud engineers, the DevOps people as you called out, the reason you went in that direction, I definitely want to work with them. And ultimately, there would never be enough people in security to solve the problem. That is the harsh reality. There would never be enough people. So, whether it's cloud security or not, like, for people who were at AWS re:Inforce, the first 15 minutes by Steve Schmidt, CSO of Amazon, was get a security guardian program.So, I've been talking about it, everyone else is talking about right now, Amazon has become the first CSP to even talk about this publicly as well that we should have security guardians. Which by the way, I don't know why, but you can still call it—it is technically DevSecOps what you're trying to do—they spoke about a security champion program as part of the keynote that they were running. Nothing to do with cloud security, but the idea being how much of this workload can we share? We can raise, as a security team—for people who may be from a security background listening to this—how much elevation can we provide the risk in front of the right people who are a decision-maker? That is our role.We help them with the governance, we help with managing it, but we don't know how to solve the risk or close off a risk, or close off a vulnerability because you might be the best person because you work in that application every day, every—you know the bandages that are put in, you know all the holes that are there, so the best threat model can be performed by the person who works on a day-to-day, not a security person who spent, like, an hour with you once a week because that's the only time they could manage. So, going back to the Snyk part, that's the mission that we've had with the podcast; we want to democratize cloud security and build a community around neutral information. There is no biased information. And I agree with what you said as well, where a lot of the podcasts outside of what we were finding was more focused on, “Hey, this is how you use AWS. This is how you use Azure. This is how you use GCP.”But none of them were unbiased in the opinion. Because real life, let's just say even if I use the AWS example—because we are coming close to the AWS re:Invent—they don't have all the answers from a security perspective. They don't have all the answers from an infrastructure perspective or cloud-native perspective. So, there are some times—or even most times—people are making a call where they're going outside of it. So, unbiased information is definitely required and it is not there enough.So, I'm glad that at least people like yourself are joining, and you know, creating the world where more people are trying to be relatable to DevOps people as well as the security folks. Because it's hard for a security person to be a developer, but it's easy for a developer or an engineer to understand security. And the simplest example I use is when people walk out of their house, they lock the door. They're already doing security. This is the same thing we're asking when we talk about security in the cloud or in the [unintelligible 00:14:49] as well. Everyone is, it just it hasn't been pointed out in the right way.Corey: I'm curious as to what it is that gets you up in the morning. Now, I know you work in security, but you're also not a CISO anymore, so I'm not asking what gets you up at 2 a.m. because we know what happens in the security space, then. There's a reason that my area of business focus is strictly a business hours problem. But I'd love to know what it is about cloud security as a whole that gets you excited.Ashish: I think it's an opportunity for people to get into the space without the—you know, you said gatekeeper earlier, those gatekeepers who used to have that 25 years experience in cybersecurity, 15 years experience in cybersecurity, Cloud has challenged that norm. Now, none of that experience helps you do AWS services better. It definitely helps you with the foundational pieces, definitely helps you do identity, networking, all of that, but you still have to learn something completely new, a new way of working, which allows for a lot of people who earlier was struggling to get into cybersecurity, now they have an opening. That's what excites me about cloud security, that it has opened up a door which is beyond your CCNA, CISSP, and whatever else certification that people want to get. By the way, I don't have a CISSP, so I can totally throw CISSP under the bus.But I definitely find that cloud security excites me every morning because it has shown me light where, to what you said, it was always a gated community. Although that's a very huge generalization. There's a lot of nice people in cybersecurity who want to mentor and help people get in. But Cloud security has pushed through that door, made it even wider than it was before.Corey: I think there's a lot to be said for the concept of sending the elevator back down. I really have remarkably little patience for people who take the perspective of, “Well, I got mine so screw everyone else.” The next generation should have it easier than we did, figuring out where we land in the ecosystem, where we live in the space. And there are folks who do a tremendous job of this, but there are also areas where I think there is significant need for improvement. I'm curious to know what you see as lacking in the community ecosystem for folks who are just dipping their toes into the water of cloud security.Ashish: I think that one, there's misinformation as well. The first one being, if you have never done IT before you can get into cloud security, and you know, you will do a great job. I think that is definitely a mistake to just accept the fact if Amazon re:Invent tells you do all these certifications, or Azure does the same, or GCP does the same. If I'll be really honest—and I feel like I can be honest, this is a safe space—that for people who are listening in, if you're coming to the space for the first time, whether it's cloud or cloud security, if you haven't had much exposure to the foundational pieces of it, it would be a really hard call. You would know all the AWS services, you will know all the Azure services because you have your certification, but if I was to ask you, “Hey, help me build an application. What would be the architecture look like so it can scale?”“So, right now we are a small pizza-size ten-people team”—I'm going to use the Amazon term there—“But we want to grow into a Facebook tomorrow, so please build me an architecture that can scale.” And if you regurgitate what Amazon has told you, or Azure has told you, or GCP has told you, I can definitely see that you would struggle in the industry because that's not how, say every application is built. Because the cloud service provider would ask you to drink the Kool-Aid and say they can solve all your problems, even though they don't have all the servers in the world. So, that's the first misinformation.The other one too, for people who are transitioning, who used to be in IT or in cybersecurity and trying to get into the cloud security space, the challenge over there is that outside of Amazon, Google, and Microsoft, there is not a lot of formal education which is unbiased. It is a great way to learn AWS security on how amazing AWS is from AWS people, the same way Microsoft will be [unintelligible 00:19:10], however, when it comes down to actual formal education, like the kind that you and I are trying to provide through a podcast, me with the Cloud Security Podcast, you with Last Week in AWS in the Security Edition, that kind of unbiased formal education, like free education, like what you and I are doing does definitely exist and I guess I'm glad we have company, that you and I both exist in this space, but formal education is very limited. It's always behind, say an expensive paid wall sometimes, and rightly so because it's information that would be helpful. So yeah, those two things. Corey: This episode is sponsored in part by our friends at Uptycs. Attackers don't think in silos, so why would you have siloed solutions protecting cloud, containers, and laptops distinctly? Meet Uptycs - the first unified solution prioritizes risk across your modern attack surface—all from a single platform, UI, and data model. Stop by booth 3352 at AWS re:Invent in Las Vegas to see for yourself and visit uptycs.com. That's U-P-T-Y-C-S.com. Corey: One of the problems that I have with the way a lot of cloud security stuff is situated is that you need to have something running to care about the security of. Yeah, I can spin up a VM in the free tier of most of these environments, and okay, “How do I secure a single Linux box?” Okay, yes, there are a lot of things you can learn there, but it's very far from a holistic point of view. You need to have the infrastructure running at reasonable scale first, in order to really get an effective lab that isn't contrived.Now, Snyk is a security company. I absolutely understand and have no problem with the fact that you charge your customers money in order to get security outcomes that are better than they would have otherwise. I do not get why AWS and GCP charge extra for security. And I really don't get why Azure charges extra for security and then doesn't deliver security by dropping the ball on it, which is neither here nor there.Ashish: [laugh].Corey: It feels like there's an economic form of gatekeeping, where you must spend at least this much money—or work for someone who does—in order to get exposure to security the way that grownups think about it. Because otherwise, all right, I hit my own web server, I have ten lines in the logs. Now, how do I wind up doing an analysis run to figure out what happened? I pull it up on my screen and I look at it. You need a point of scale before anything that the modern world revolves around doesn't seem ludicrous.Ashish: That's a good point. Also because we don't talk about the responsibility that the cloud service provider has themselves for security, like the encryption example that I used earlier, as a guardrail, it doesn't take much for them to enable by default. But how many do that by default? I feel foolish sometimes to tell people that, “Hey, you should have encryption enabled on your storage which is addressed, or in transit.”It should be—like, we have services like Let's Encrypt and other services, which are trying to make this easily available to everyone so everyone can do SSL or HTTPS. And also, same goes for encryption. It's free and given the choice that you can go customer-based keys or your own key or whatever, but it should be something that should be default. We don't have to remind people, especially if you're the providers of the service. I agree with you on the, you know, very basic principle of why do I pay extra for security, when you should have already covered this for me as part of the service.Because hey, technically, aren't you also responsible in this conversation? But the way I see shared responsibility is that—someone on the podcast mentioned it and I think it's true—shared responsibility means no one's responsible. And this is the kind of world we're living in because of that.Corey: Shared responsibility has always been an odd concept to me because AWS is where I first encountered it and they, from my perspective, turn what fits into a tweet into a 45-minute dog-and-pony show around, “Ah, this is how it works. This is the part we're responsible for. This is the part where the customer responsibility is. Now, let's have a mind-numbingly boring conversation around it.” Whereas, yeah, there's a compression algorithm here. Basically, if the cloud gets breached, it is overwhelmingly likely that you misconfigured something on your end, not the provider doing it, unless it's Azure, which is neither here nor there, once again.The problem with that modeling, once you get a little bit more business sophistication than I had the first time I made the observation, is that you can't sit down with a CISO at a company that just suffered a data breach and have your conversation be, “Doesn't it suck to be you—[singing] duh, duh—because you messed up. That's it.” You need that dog-and-pony show of being able to go in-depth and nuance because otherwise, you're basically calling out your customer, which you can't really do. Which I feel occludes a lot of clarity for folks who are not in that position who want to understand these things a bit better.Ashish: You're right, Corey. I think definitely I don't want to be in a place where we're definitely just educating people on this, but I also want to call out that we are in a world where it is true that Amazon, Azure, Google Cloud, they all have vulnerabilities as well. Thanks to research by all these amazing people on the internet from different companies out there, they've identified that, hey, these are not pristine environments that you can go into. Azure, AWS, Google Cloud, they themselves have vulnerabilities, and sometimes some of those vulnerabilities cannot be fixed until the customer intervenes and upgrades their services. We do live in a world where there is not enough education about this as well, so I'm glad you brought this up because for people who are listening in, I mean, I was one of those people who would always say, “When was the last time you heard Amazon had a breach?” Or, “Microsoft had a breach?” Or, “Google Cloud had a breach?”That was the idea when people were just buying into the concept of cloud and did not trust cloud. Every cybersecurity person that I would talk to they're like, “Why would you trust cloud? Doesn't make sense.” But this is, like, seven, eight years ago. Fast-forward to today, it's almost default, “Why would you not go into cloud?”So, for people who tend to forget that part, I guess, there is definitely a journey that people came through. With the same example of multi-factor authentication, it was never a, “Hey, let's enable password and multi-factor authentication.” It took a few stages to get there. Same with this as well. We're at that stage where now cloud service providers are showing the kinks in the armor, and now people are questioning, “I should update my risk matrix for what if there's actually a breach in AWS?”Now, Capital One is a great example where the Amazon employee who was sentenced, she did something which has—never even [unintelligible 00:25:32] on before, opened up the door for that [unintelligible 00:25:36] CISO being potentially sentenced. There was another one. Because it became more primetime news, now people are starting to understand, oh, wait. This is not the same as it used to be. Cloud security breaches have evolved as well.And just sticking to the Uber point, when Uber has that recent breach where they were talking about, “Hey, so many data records were gone,” what a lot of people did not talk about in that same message, it also mentioned the fact that, hey, they also got access to the AWS console of Uber. Now, that to me, is my risk metrics has already gone higher than where it was before because it just not your data, but potentially your production, your pre-prod, any development work that you were doing for, I don't know, self-driving cars or whatever that Uber [unintelligible 00:26:18] is doing, all that is out on the internet. But who was talking about all of that? That's a much worse a breach than what was portrayed on the internet. I don't know, what do you think?Corey: When it comes to trusting providers, where I sit is that I think, given their scale, they need to be a lot more transparent than they have been historically. However, I also believe that if you do not trust that these companies are telling you the truth about what they're doing, how they're doing it, what their controls are, then you should not be using them as a customer, full stop. This idea of confidential computing drives me nuts because so much of it is, “Well, what if we assume our cloud provider is lying to us about all of these things?” Like, hypothetically there's nothing stopping them from building an exact clone of their entire control plane that they redirect your request to that do something completely different under the hood. “Oh, yeah, of course, we're encrypting it with that special KMS key.” No, they're not. For, “Yeah, sure we're going to put that into this region.” Nope, it goes right back to Virginia. If you believe that's what's going on and that they're willing to do that, you can't be in cloud.Ashish: Yeah, a hundred percent. I think foundational trust need to exist and I don't think the cloud service providers themselves do a great job of building that trust. And maybe that's where the drift comes in because the business has decided they're going to cloud. The cyber security people are trying to be more aware and asking the question, “Hey, why do we trust it so blindly? I don't have a pen test report from Amazon saying they have tested service.”Yes, I do have a certificate saying it's PCI compliant, but how do I know—to what you said—they haven't cloned our services? Fortunately, businesses are getting smarter. Like, Walmart would never have their resources in AWS because they don't trust them. It's a business risk if suddenly they decide to go into that space. But the other way around, Microsoft may decides tomorrow that they want to start their own Walmart. Then what do you do?So, I don't know how many people actually consider that as a real business risk, especially because there's a word that was floating around the internet called supercloud. And the idea behind this was—oh, I can already see your reaction [laugh].Corey: Yeah, don't get me started on that whole mess.Ashish: [laugh]. Oh no, I'm the same. I'm like, “What? What now?” Like, “What are you—” So, one thing I took away which I thought was still valuable was the fact that if you look at the cloud service providers, they're all like octopus, they all have tentacles everywhere.Like, if you look at the Amazon of the world, they not only a bookstore, they have a grocery store, they have delivery service. So, they are into a lot of industries, the same way Google Cloud, Microsoft, they're all in multiple industries. And they can still have enough money to choose to go into an industry that they had never been into before because of the access that they would get with all this information that they have, potentially—assuming that they [unintelligible 00:29:14] information. Now, “Shared responsibility,” quote-unquote, they should not do it, but there is nothing stopping them from actually starting a Walmart tomorrow if they wanted to.Corey: So, because a podcast and a day job aren't enough, what are you going to be doing in the near future given that, as we record this, re:Invent is nigh?Ashish: Yeah. So, podcasting and being in the YouTube space has definitely opened up the creative mindset for me. And I think for my producer as well. We're doing all these exciting projects. We have something called Cloud Security Villains that is coming up for AWS re:Invent, and it's going to be released on our YouTube channel as well as my social media.And we'll have merchandise for it across the re:Invent as well. And I'm just super excited about the possibility that media as a space provides for everyone. So, for people who are listening in and thinking that, I don't know, I don't want to write for a blog or email newsletter or whatever the thing may be, I just want to put it out there that I used to be excited about AWS re:Invent just to understand, hey, hopefully, they will release a new security service. Now, I get excited about these events because I get to meet community, help them, share what they have learned on the internet, and sound smarter [laugh] as a result of that as well, and get interviewed where people like yourself. But I definitely find that at the moment with AWS re:Invent coming in, a couple of things that are exciting for me is the release of the Cloud Security Villains, which I think would be an exciting project, especially—hint, hint—for people who are into comic books, you will definitely enjoy it, and I think your kids will as well. So, just in time for Christmas.Corey: We will definitely keep an eye out for that and put a link to that in the show notes. I really want to thank you for being so generous with your time. If people want to learn more about what you're up to, where's the best place for them to find you?Ashish: I think I'm fortunate enough to be at that stage where normally if people Google me—and it's simply Ashish Rajan—they will definitely find me [laugh]. I'll be really hard for them not find me on the internet. But if you are looking for a source of unbiased cloud security knowledge, you can definitely hit up cloudsecuritypodcast.tv or our YouTube and LinkedIn channel.We go live stream every week with a new guest talking about cloud security, which could be companies like LinkedIn, Twilio, to name a few that have come on the show already, and a lot more than have come in and been generous with their time and shared how they do what they do. And we're fortunate that we get ranked top 100 in America, US, UK, as well as Australia. I'm really fortunate for that. So, we're doing something right, so hopefully, you get some value out of it as well when you come and find me.Corey: And we will, of course, put links to all of that in the show notes. Thank you so much for being so generous with your time. I really appreciate it.Ashish: Thank you, Corey, for having me. I really appreciate this a lot. I enjoyed the conversation.Corey: As did I. Ashish Rajan, Principal Cloud Security Advocate at Snyk who is sponsoring this promoted guest episode. 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, along with an insulting comment pointing out that not every CISO gets fired; some of them successfully manage to blame the intern.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.

Links: Last week LastPass reported (yet another) security issue, wherein their source code was stolen.  Finally: an honest recap of fwd:cloudsec and re:Inforce 2022 from someone who had the stomach to sit through the entirety of the latter. The Register reports on a growing trend of using AWS resources to hide phishing attacks. Expanded eligibility for the free MFA security key program  How to centralize findings and automate deletion for unused IAM roles Identifying publicly accessible resources with Amazon VPC Network Access Analyzer  The tool of the week: popeye is a Kubernetes cluster resource sanitizer.

On The Cloud Pod this week, the team gets skeptical on Prime Day numbers. Plus: AWS re:Inforce brings GuardDuty, Detective and Identity Center updates and announcements; Google Cloud says hola to Mexico with a new Latin American region; and Azure introduces its new cost API for EC and MCA customers. A big thanks to this week's sponsor, Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. This week's highlights

About JeffJeff Smith has been in the technology industry for over 20 years, oscillating between management and individual contributor. Jeff currently serves as the Director of Production Operations for Basis Technologies (formerly Centro), an advertising software company headquartered in Chicago, Illinois. Before that he served as the Manager of Site Reliability Engineering at Grubhub.Jeff is passionate about DevOps transformations in organizations large and small, with a particular interest in the psychological aspects of problems in companies. He lives in Chicago with his wife Stephanie and their two kids Ella and Xander.Jeff is also the author of Operations Anti-Patterns, DevOps Solutions with Manning publishing. (https://www.manning.com/books/operations-anti-patterns-devops-solutions) Links Referenced: Basis Technologies: https://basis.net/ Operations Anti-Patterns: https://attainabledevops.com/book Personal Site: https://attainabledevops.com LinkedIn: https://www.linkedin.com/in/jeffery-smith-devops/ Twitter: https://twitter.com/DarkAndNerdy Medium: https://medium.com/@jefferysmith duckbillgroup.com: https://duckbillgroup.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 by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. One of the fun things about doing this show for long enough is that you eventually get to catch up with people and follow up on previous conversations that you've had. Many years ago—which sounds like I'm being sarcastic, but is increasingly actually true—Jeff Smith was on the show talking about a book that was about to release. Well, time has passed and things have changed. And Jeff Smith is back once again. He's the Director of Product Operations at Basis Technologies, and the author of DevOps Anti-Patterns? Or what was the actual title of the book it was—Jeff: Operations Anti-Patterns.Corey: I got hung up in the anti-patterns part because it's amazing. I love the title.Jeff: Yeah, Operations Anti-Patterns, DevOps Solutions.Corey: Got you. Usually in my experience, alway been operations anti-patterns, and here I am to make them worse, probably by doing something like using DNS as a database or some godforsaken thing. But you were talking about the book aspirationally a few years ago, and now it's published and it has been sent out to the world. And it went well enough that they translated it to Japanese, I believe, and it has seen significant uptick. What was your experience of it? How did it go?Jeff: You know, it was a great experience. This is definitely the first book that I've written. And the Manning process was extremely smooth. You know, they sort of hold your hand through the entire process. But even after launch, just getting feedback from readers and hearing how it resonated with folks was extremely powerful.I was surprised to find out that they turned it into an audiobook as well. So, everyone reaches out and says, “Did you read the audiobook? I was going to buy it, but I wasn't sure.” I was like, “No, unfortunately, I don't read it.” But you know, still cool to have it out there.Corey: My theory has been for a while now that no one wants to actually write a book; they want to have written a book. Now that you're on the other side, how accurate is that? Are you in a position of, “Wow, sure glad that's done?” Or are you, “That was fun. Let's do it again because I like being sad all the time.” I mean, you do work Kubernetes for God's sake. I mean, there's a bit of masochism inherent to all of us in this space.Jeff: Yeah. Kubernetes makes me cry a little bit more than the writing process. But it's one of the things when you look back on it, you're like, “Wow, that was fun,” but not in the heat of the moment, right? So, I totally agree with the sentiment that people want to have written a book but not actually gone through the process. And that's evident by the fact that how many people try to start a book on their own without a publisher behind them, and they end up writing it for 15 years. The process is pretty grueling. The feedback is intense at first, but you start to get into a groove and you—I could see, you know, in a little while wanting to write another book. So, I can see the appeal.Corey: And the last time you were on the show, I didn't really bother to go in a particular topical direction because, what's the point? It didn't really seem like it was a top-of-mind issue to really bring up because what's it matter; it's a small percentage of the workforce. Now I feel like talking about remote work is suddenly taking on a bit of a different sheen than it was before the dark times arrived. Where do you land on the broad spectrum of opinions around the idea of remote work, given that you have specialized in anti-patterns, and well, as sarcastic as I am, I tend to look at almost every place I've ever worked is expressing different anti-patterns from time to time. So, where do you land on the topic?Jeff: So, it's funny, I started as a staunch office supporter, right? I like being in the office. I like collaborating in person; I thought we were way more productive. Since the pandemic, all of us are forced into remote work, I've hired almost half of my team now as remote. And I am somewhat of a convert, but I'm not on the bandwagon of remote work is just as good or is better as in person work.I've firmly landed in the camp of remote work is good. It's got its shortcomings, but it's worth the trade off. And I think acknowledging what those trade-offs are important to keeping the team afloat. We just recently had a conversation with the team where we were discussing, like, you know, there's definitely been a drop in productivity over the past six months to a year. And in that conversation, a lot of the things that came up were things that are different remote that were better in person, right, Slack etiquette—which is something, you know, I could talk a little bit about as well—but, you know, Slack etiquette in terms of getting feedback quickly, just the sort of camaraderie and the lack of building that camaraderie with new team members as they come on board and not having those rituals to replace the in-person rituals. But through all that, oddly enough, no one suggested going back into the office. [laugh].Corey: For some strange reason, yeah. I need to be careful what I say here, I want to disclaim the position that I'm in. There is a power imbalance and nothing I say is going to be able to necessarily address that because I own the company and if my team members are listening to this, they're going to read a lot into what I say that I might not necessarily intend. But The Duckbill Group, since its founding, has been a fully distributed company. My business partner lives in a different state than I do so there's never been the crappy version of remote, which is, well, we're all going to be in the same city, except for Theodore. Theodore is going to be timezones away and then wonder why he doesn't get to participate in some of the conversations where the real decisions get made.Like that's crappy. I don't like that striated approach to things. We don't have many people who are co-located in any real sense, nor have we for the majority of the company's life. But there are times when I am able to work on a project in a room with one of my colleagues, and things go a lot more smoothly. As much as we want to pretend that video is the same, it quite simply isn't.It is a somewhat poor substitute for the very high bandwidth of a face-to-face interaction. And yes, I understand this is also a somewhat neurotypical perspective, let's be clear with that as well, and it's not for everyone. But I think that for the base case, a lot of the remote work advocates are not being fully, I guess, honest with themselves about some of the shortcomings remote has. That is where I've mostly landed on this. Does that generally land with where you are?Jeff: Yeah, that's exactly where I'm at. I completely agree. And when we take work out of the equation, I think the shortcomings lay themselves bare, right? Like I was having a conversation with a friend and we were like, well, if you had a major breakup, right, I would never be like, “Oh, man. Grab a beer and hop on Zoom,” right? [laugh]. “Let's talk it out.”No, you're like, hey, let's get in person and let's talk, right? We can do all of that conversation over Zoom, but the magic of being in person and having that personal connection, you know, can't be replaced. So, you know, if it's not going to work, commiserating over beers, right? I can't imagine it's going to work, diagramming some complex workflows and trying to come to an answer or a solution on that. So again, not to say that, you know, remote work is not valuable, it's just different.And I think organizations are really going to have to figure out, like, okay, if I want to entice people back into the office, what are the things that I need to do to make this realistic? We've opened the floodgates on remote hiring, right, so now it's like, okay, everyone's janky office setup needs to get fixed, right? So, I can't have a scenario where it's like, “Oh, just point your laptop at the whiteboard, right?” [laugh]. Like that can't exist, we have to have office spaces that are first-class citizens for our remote counterparts as well.Corey: Right because otherwise, the alternative is, “Great, I expect you to take the home that you pay for and turn it into an area fit for office use. Of course, we're not going to compensate you for that, despite the fact that, let's be realistic, rent is often larger than the AWS bill.” Which I know, gasp, I'm as shocked as anyone affected by that, but it's true. “But oh, you want to work from home? Great. That just means you can work more hours.”I am not of the school of thought where I consider time in the office to be an indicator of anything meaningful. I care if the work gets done and at small-scale, this works. Let me also be clear, we're an 11-person company. A lot of what I'm talking about simply will not scale to companies that are orders of magnitude larger than this. And from where I sit, that's okay. It doesn't need to.Jeff: Right. And I think a lot of the things that you talk about will scale, right? Because in most scenarios, you're not scaling it organizationally so much as you are with a handful of teams, right? Because when I think about all the different teams I interact with, I never really interact with the organization as a whole, I interact with my little neighborhood in the organization. So, it is definitely something that scales.But again, when it comes to companies, like, enticing people back into the office, now that I'm talking about working from home five days a week, I've invested in my home setup. I've got the monitor I want, I've got the chair that I want, I've got the mouse and keyboard that I want. So, you're going to bring me back to the office so I can have some standard Dell keyboard and mouse with some janky, you know—maybe—21-inch monitor or something like that, right? Like, you really have to decide, like, okay, we're going to make the office a destination, we're going to make it where people want to go there where it's not just even about the collaboration aspect, but people can still work and be effective.And on top of that, I think how we look at what the office delivers is going to change, right? Because now when I go to the office now, I do very little work. It's connections, right? It's like, you know, “Oh, I haven't seen you in forever. Let's catch up.” And a lot of that stuff is valuable. You know, there's these hallway conversations that exist that just weren't happening previously because how do I accidentally bump into you on Slack? [laugh]. Right, it has to be much more it of a—Corey: Right. It takes some contrivance to wind up making that happen. I remember back in the days of working in offices, I remember here in San Francisco where we had unlimited sick time and unlimited PTO, I would often fake a sick day, but just stay home and get work done. Because I knew if I was in the office, I'd be constantly subjected to drive-bys the entire time of just drive-by requests, people stopping by to ask, “Oh, can you just help me with this one thing,” that completely derails my train of thought. Then at the end of the day, they'd tell me, “You seem distractible and you didn't get a lot of work done.”It's, “Well, no kidding. Of course not. Are you surprised?” And one of the nice things about starting your own company—because there are a lot of downsides, let me be very clear—one of the nice things is you get to decide how you want to work. And that was a study in, first, amazement, and then frustration.It was, “All right, I just landed a big customer. I'm off to the races and going to take this seriously for a good six to twelve months. Great sky's the limit, I'm going to do up my home office.” And then you see how little money it takes to have a nice chair, a good standing desk, a monitor that makes sense and you remember fighting tooth-and-nail for nothing that even approached this quality at companies and they acted like it was going to cost them 20-grand. And here, it's two grand at most, when I decorated this place the first time.And it was… “What the hell?” Like, it feels like the scales fall away from your eyes, and you start seeing things that you didn't realize were a thing. Now I worry that five years in, there's no way in the world I'm ever fit to be an employee again, so this is probably the last job I'll ever have. Just because I've basically made myself completely unemployable across six different axes.Jeff: [laugh]. And I think one of the things when it comes to, like, furniture, keyboard, stuff like that, I feel like part of it was just, like, this sort of enforced conformity, right, that the office provided us the ability to do. We can make sure everyone's got the same monitor, the same keyboard that way, when it breaks, we can replace it easily. In a lot of organizations that I've been in, you know, that sort of like, you know, even if it was the same amount or ordering a custom keyboard was a big exception process, right? Like, “Oh, we've got to do a whole thing.” And it's just like, “Well, it doesn't have to be that complicated.”And like you said, it doesn't cost much to allow someone to get the tools that they want and prefer and they're going to be more productive with. But to your point really quickly about work in the office, until the pandemic, I personally didn't recognize how difficult it actually was to get work done in the office. I don't think I appreciated it. And now that I'm remote, I'm like, wow, it is so much easier for me to close this door, put my headphones on, mute Slack and go heads down. You know, the only drive-by I've got is my wife wondering if I want to go for a walk, and that's usually a text message that I can ignore and come back to later.Corey: The thing that just continues to be strange for me and breaks in some of the weirdest ways has just been the growing awareness of how much of office life is unnecessary and ridiculous. When you're in the office every day, you have to find a way to make it work and be productive and you have this passive-aggressive story of this open office, it's for collaboration purposes. Yeah, I can definitively say that is not true. I had a boss who once told me that there was such benefits to working in an open plan office that if magically it were less expensive to give people individual offices, he would spare the extra expense for open plan. That was the day I learned he would lie to me while looking me in the eye. Because of course you wouldn't.And it's for collaboration. Yeah, it means two loud people—often me—are collaborating and everyone else wears noise-canceling headphones trying desperately to get work done, coming in early, hours before everyone else to get things done before people show up and distracted me. What the hell kind of day-to-day work environment is that?Jeff: What's interesting about that, though, is those same distractions are the things that get cited as being missed from the perspective of the person doing the distracting. So, everyone universally hates that sort of drive-by distractions, but everyone sort of universally misses the ability to say like, “Hey, can I just pull on your ear for a second and get your feedback on this?” Or, “Can we just walk through this really quickly?” That's the thing that people miss, and I don't think that they ever connect it to the idea that if you're not the interruptee, you're the interruptor, [laugh] and what that might do to someone else's productivity. So, you would think something like Slack would help with that, but in reality, what ends up happening is if you don't have proper Slack etiquette, there's a lot of signals that go out that get misconstrued, misinterpreted, internalized, and then it ends up impacting morale.Corey: And that's the most painful part of a lot of that too. Is that yeah, I want to go ahead and spend some time doing some nonsense—as one does; imagine that—and I know that if I'm going to go into an office or meet up with my colleagues, okay, that afternoon or that day, yeah, I'm planning that I'm probably not going to get a whole lot of deep coding done. Okay, great. But when that becomes 40 hours a week, well, that's a challenge. I feel like being full remote doesn't work out, but also being in the office 40 hours a week also feels a little sadistic, more than almost anything else.I don't know what the future looks like and I am privileged enough that I don't have to because we have been full remote the entire time. But what we don't spend on office space we spend on plane tickets back and forth so people can have meetings. In the before times, we were very good about that. Now it's, we're hesitant to do it just because it's we don't want people traveling before the feel that it's safe to do so. We've also learned, for example, when dealing with our clients, that we can get an awful lot done without being on site with them and be extraordinarily effective.It was always weird have traveled to some faraway city to meet with the client, and then you're on a Zoom call from their office with the rest of the team. It's… I could have done this from my living room.Jeff: Yeah. I find those sorts of hybrid meetings are often worse than if we were all just remote, right? It's just so much easier because now it's like, all right, three of us are going to crowd around one person's laptop, and then all of the things that we want to do to take advantage of being in person are excluding the people that are remote, so you got to do this careful dance. The way we've been sort of tackling it so far—and we're still experimenting—is we're not requiring anyone to come back into the office, but some people find it useful to go to the office as a change of scenery, to sort of, like break things up from their typical routine, and they like the break and the change. But it's something that they do sort of ad hoc.So, we've got a small group that meets, like, every Thursday, just as a day to sort of go into the office and switch things up. I think the idea of saying everyone has to come into the office two or three days a week is probably broken when there's no purpose behind it. So, my wife technically should go into the office twice a week, but her entire team is in Europe. [laugh]. So, what point does that make other than I am a body in a chair? So, I think companies are going to have to get flexible with this sort of hybrid environment.But then it makes you wonder, like, is it worth the office space and how many people are actually taking advantage of it when it's not mandated? We find that our office time centers around some event, right? And that event might be someone in town that's typically remote. That might be a particular project that we're working on where we want to get ideas and collaborate and have a workshop. But the idea of just, like, you know, we're going to systematically require people to be in the office x many days, I don't see that in our future.Corey: No, and I hope you're right. But it also feels like a lot of folks are also doing some weird things around the idea of remote such as, “Oh, we're full remote but we're going to pay you based upon where you happen to be sitting geographically.” And we find that the way that we've done this—and again, I'm not saying there's a right answer for everyone—but we wind up paying what the value of the work is for us. In many cases, that means that we would be hard-pressed to hire someone in the Bay Area, for example. On the other hand, it means that when we hire people who are in places with relatively low cost of living, they feel like they've just hit the lottery, on some level.And yeah, some of them, I guess it does sort of cause a weird imbalance if you're a large Amazon-scale company where you want to start not disrupting local economies. We're not hiring that many people, I promise. So, there's this idea of figuring out how that works out. And then where does the headquarters live? And well, what state laws do we wind up following on what we're doing? Just seems odd.Jeff: Yeah. So, you know, one thing I wanted to comment on that you'd mentioned earlier, too, was the weird things that people are doing, and organizations are doing with this, sort of, remote work thing, especially the geographic base pay. And you know, a lot of it is, how can we manipulate the situation to better us in a way that sounds good on paper, right? So, it sounds perfectly reasonable. Like, oh, you live in New York, I'm going to pay you in New York rates, right?But, like, you live in Des Moines, so I'm going to pay you Des Moines rates. And on the surface, when you just go you're like, oh, yeah, that makes sense, but then you think about it, you're like, “Wait, why does that matter?” Right? And then, like, how do I, as a manager, you know, level that across my employees, right? It's like, “Oh, so and so is getting paid 30 grand less. Oh, but they live in a cheaper area, right?” I don't know what your personal situation is, and how much that actually resonates or matters.Corey: Does the value that they provide to your company materially change based upon where they happen to be sitting that week?Jeff: Right, exactly. But it's a good story that you can tell, it sounds fair at first examination. But then when you start to scratch the surface, you're like, “Wait a second, this is BS.” So, that's one thing.Corey: It's like tipping on some level. If you can't afford the tip, you can't afford to eat out. Same story here. If you can't afford to compensate people the value that they're worth, you can't afford to employ people. And figure that out before you wind up disappointing people and possibly becoming today's Twitter main character.Jeff: Right. And then the state law thing is interesting. You know, when you see states like California adopting laws similar to, like, GDPR. And it's like, do you have to start planning for the most stringent possibility across every hire just to be safe and to avoid having to have this sort of patchwork of rules and policies based on where someone lives? You might say like, “Okay, Delaware has the most stringent employer law, so we're going to apply Delaware's laws across the board.” So, it'll be interesting to see how that sort of plays out in the long run. Luckily, that's not a problem I have to solve, but it'll be interesting to see how it shakes out.Corey: It is something we had to solve. We have an HR consultancy that helps out with a lot of these things, but the short answer is that we make sure that we obey with local laws, but the way that we operate is as if everyone were a San Francisco employee because that is—so far—the locale that, one, I live here, but also of every jurisdiction we've looked at in the United States, it tends to have the most advantageous to the employee restrictions and requirements. Like one thing we do is kind of ridiculous—and we have to do for me and one other person, but almost no one else, but we do it for everyone—is we have to provide stipends every month for electricity, for cellphone usage, for internet. They have to be broken out for each one of those categories, so we do 20 bucks a month for each of those. It adds up to 100 bucks, as I recall, and we call it good. And employees say, “Okay. Do we just send you receipts? Please don't.”I don't want to look at your cell phone bill. It's not my business. I don't want to know. We're doing this to comply with the law. I mean, if it were up to me, it would be this is ridiculous. Can we just give everyone $100 a month raise and call it good? Nope. The forms must be obeyed. So, all right.We do the same thing with PTO accrual. If you've acquired time off and you leave the company, we pay it out. Not every state requires that. But paying for cell phone access and internet access as well, is something Amazon is currently facing a class action about because they didn't do that for a number of their California employees. And even talking to Amazonians, like, “Well, they did, but you had to jump through a bunch of hoops.”We have the apparatus administratively to handle that in a way that employees don't. Why on earth would we make them do it unless we didn't want to pay them? Oh, I think I figured out this sneaky, sneaky plan. I'm not here to build a business by exploiting people. If that's the only way to succeed, and the business doesn't deserve to exist. That's my hot take of the day on that topic.Jeff: No, I totally agree. And what's interesting is these insidious costs that sneak up that employees tend to discount, like, one thing I always talk about with my team is all that time you're thinking about a problem at work, right, like when you're in the shower, when you're at dinner, when you're talking it over with your spouse, right? That's work. That's work. And it's work that you're doing on your time.But we don't account for it that way because we're not typing; we're not writing code. But, like, think about how much more effective as people, as employees, we would be if we had time dedicated to just sit and think, right? If I could just sit and think about a problem without needing to type but just critically think about it. But then it's like, well, what does that look like in the office, right? If I'm just sitting there in my chair like this, it doesn't look like I'm doing anything.But that's so important to be able to, like, break down and digest some of the complex problems that we're dealing with. And we just sort of write it off, right? So, I'm like, you know, you got to think about how that bleeds into your personal time and take that into account. So yeah, maybe you leave three hours early today, but I guarantee you, you're going to spend three hours throughout the week thinking about work. It's the same thing with these cellphone costs that you're talking about, right? “Oh, I've got a cell phone anyways; I've got internet anyways.” But still, that's something that you're contributing to the business that they're not on the hook for, so it seems fair that you get compensated for that.Corey: I just think about that stuff all the time from that perspective, and now that I you know, own the place, it's one of those which pocket of mine does it come out of? But I hold myself to a far higher standard about that stuff than I do the staff, where it's, for example, I could theoretically justify paying my internet bill here because we have business-class internet and an insane WiFi system because of all of the ridiculous video production I do. Now. It's like, like, if anyone else on the team was doing this, yes, I will insist we pay it, but for me, it just it feels a little close to the edge. So, it's one of those areas where I'm very conservative around things like that.The thing that also continues to just vex me, on some level, is this idea that time in a seat is somehow considered work. I'll never forget one of the last jobs I had before I started this place. My boss walked past me and saw that I was on Reddit. And, “Is that really the best use of your time right now?” May I use the bathroom when I'm done with this, sir?Yeah, of course it is. It sounds ridiculous, but one of the most valuable things I can do for The Duckbill Group now is go on the internet and start shit posting on Twitter, which sounds ridiculous, but it's also true. There's a brand awareness story there, on some level. And that's just wild to me. It's weird, we start treating people like adults, they start behaving that way. And if you start micromanaging them, they live up or down to the expectations you tend to hold. I'm a big believer in if I have to micromanage someone, I should just do the job myself.Jeff: Yeah. The Reddit story makes me think of, like, how few organizations have systematic ways of getting vital information. So, the first thing I think about is, like, security and security vulnerabilities, right? So, how does Basis Technologies, as an organization, know about these things? Right now, it's like, well, my team knows because we're plugged into Reddit and Twitter, right, but if we were gone Basis, right, may not necessarily get that information.So, that's something we're trying to correct, but it just sort of highlights the importance of freedom for these employees, right? Because yeah, I'm on Reddit, but I'm on /r/sysadmin. I'm on /r/AWS, right, I'm on /r/Atlassian. Now I'm finding out about this zero-day vulnerability and it's like, “Oh, guys, we got to act. I just heard about this thing.” And people are like, “Oh, where did this come from?” And it's like it came from my network, right? And my network—Corey: Mm-hm.Jeff: Is on Twitter, LinkedIn, Reddit. So, the idea that someone browsing the internet on any site, really, is somehow not a productive use of their time, you better be ready to itemize exactly what that means and what that looks like. “Oh, you can do this on Reddit but you can't do that on Reddit.”Corey: I have no boss now, I have no oversight, but somehow I still show up with a work ethic and get things done.Jeff: Right. [laugh].Corey: Wow, I guess I didn't need someone over my shoulder the whole time. Who knew?Jeff: Right. That's all that matters, right? And if you do it in 30 hours or 40 hours, that doesn't really matter to me, you know? You want to do it at night because you're more productive there, right, like, let's figure out a way to make that happen. And remote work is actually empowering us ways to really retain people that wasn't possible before I had an employee that was like, you know, I really want to travel. I'm like, “Dude, go to Europe. Work from Europe. Just do it. Work from Europe,” right? We've got senior leaders on the C-suite that are doing it. One of the chief—Corey: I'm told they have the internet, even there. Imagine that?Jeff: Yeah. [laugh]. So, our chief program officer, she was in Greece for four weeks. And it worked. It worked great. They had a process. You know, she would spent one week on and then one week off on vacation. But you know, she was able to have this incredible, long experience, and still deliver. And it's like, you know, we can use that as a model to say, like—Corey: And somehow the work got done. Wow, she must be amazing. No, that's the baseline expectation that people can be self-managing in that respect.Jeff: Right.Corey: They aren't toddlers.Jeff: So, if she can do that, I'm sure you can figure out how to code in China or wherever you want to visit. So, it's a great way to stay ahead of some of these companies that have a bit more lethargic policies around that stuff, where it's like, you know, all right, I'm not getting that insane salary, but guess what, I'm going to spend three weeks in New Zealand hanging out and not using any time off or anything like that, and you know, being able to enjoy life. I wish this pandemic had happened pre-kids because—Corey: Yeah. [laugh].Jeff: —you know, we would really take advantage of this.Corey: You and me both. It would have very different experience.Jeff: Yeah. [laugh]. Absolutely, right? But with kids in school, and all that stuff, we've been tethered down. But man, I you know, I want to encourage the young people or the single people on my team to just, like, hey, really, really embrace this time and take advantage of it.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: One last topic I want to get into before we call it an episode is, I admit, I read an awful lot of books, it's a guilty pleasure. And it's easy to fall into the trap, especially when you know the author, of assuming that snapshot of their state of mind at a very fixed point in time is somehow who they are, like a fly frozen in amber, and it's never true. So, my question for you is, quite simply, what have you learned since your book came out?Jeff: Oh, man, great question. So, when I was writing the book, I was really nervous about if my audience was as big as I thought it was, the people that I was targeting with the book.Corey: Okay, that keeps me up at night, too. I have no argument there.Jeff: Yeah. You know what I mean?Corey: Please, continue.Jeff: I'm surrounded, you know, by—Corey: Is anyone actually listening to this? Yeah.Jeff: Right. [laugh]. So, after the book got finished and it got published, I would get tons of feedback from people that so thoroughly enjoyed the book, they would say things like, you know, “It feels like you were in our office like a fly on the wall.” And that was exciting, one, because I felt like these were experiences that sort of resonated, but, two, it sort of proved this thesis that sometimes you don't have to do something revolutionary to be a positive contribution to other people, right? So, like, when I lay out the tips and things that I do in the book, it's nothing earth-shattering that I expect Google to adopt. Like, oh, my God, this is the most unique view ever.But being able to talk to an audience in a way that resonates with them, that connects with them, that shows that I understand their problem and have been there, it was really humbling and enlightening to just see that there are people out there that they're not on the bleeding edge, but they just need someone to talk to them in a language that they understand and resonate with. So, I think the biggest thing that I learned was this idea that your voice is important, your voice matters, and how you tell your story may be the difference between someone understanding a concept and someone not understanding a concept. So, there's always an audience for you out there as you're writing, whether it be your blog post, the videos that you produce, the podcasts that you make, somewhere there's someone that needs to hear what you have to say, and the unique way that you can say it. So, that was extremely powerful.Corey: Part of the challenge that I found is when I start talking to other people, back in the before times, trying to push them into conference talks and these days, write blog posts, the biggest objection I get sometimes is, “Well, I don't have anything worth saying.” That is provably not true. One of my favorite parts about writing Last Week in AWS is as I troll the internet looking for topics about AWS that I find interesting, I keep coming across people who are very involved in one area or another of this ecosystem and have stories they want to tell. And I love, “Hey, would you like to write a guest post for Last Week in AWS?” It's always invite only and every single one of them has been paid because people die of exposure and I'm not about that exploitation lifestyle.A couple have said, “Oh, I can't accept payment for a variety of reasons.” Great. Pick a charity that you would like it to go to instead because we do not accept volunteer work, we are a for-profit entity. That is the way it works here. And that has been just one of the absolute favorite parts about what I do just because you get to sort of discover new voices.And what I find really neat is that for a lot of these folks, this is their start to writing and telling the story, but they don't stop there, they start telling their story in other areas, too. It leads to interesting career opportunities for them, it leads to interesting exposure that they wouldn't have necessarily had—again, not that they're getting paid in exposure, but the fact that they are able to be exposed to different methodologies, different ways of thinking—I love that. It's one of my favorite parts about doing what I do. And it seems to scale a hell of a lot better than me sitting down with someone for two hours to help them build a CFP that they wind up not getting accepted or whatnot.Jeff: Right. It's a great opportunity that you provide folks, too, because of, like, an instant audience, I think that's one of the things that has made Medium so successful as, like, a blogging platform is, you know, everyone wants to go out and build their own WordPress site and launch it, but then it like, you write your blog post and it's crickets. So, the ability for you to, you know, use your platform to also expose those voices is great and extremely powerful. But you're right, once they do it, it lights a fire in a way that is admirable to watch. I have a person that I'm mentoring and that was my biggest piece of advice I can give. It was like, you know, write. Just write.It's the one thing that you can do without anyone else. And you can reinforce your own knowledge of a thing. If you just say, you know, I'm going to teach this thing that I just learned, just the writing process helps you solidify, like, okay, I know this stuff. I'm demonstrating that I know it and then four years from now, when you're applying for a job, someone's like, “Oh, I found your blog post and I see that you actually do know how to set up a Kubernetes cluster,” or whatever. It's just extremely great and it—Corey: It's always fun. You're googling for how to do something and you find something you wrote five years ago.Jeff: Right, yeah. [laugh]. And it's like code where you're like, “Oh, man, I would do that so much differently now.”Corey: Since we last spoke, one of the things I've been doing is I have been on the hook to write between a one to two-thousand-word blog post every week, and I've done that like clockwork, for about a year-and-a-half now. And I was no slouch at storytelling before I started doing that. I've given a few hundred conference talks in the before times. And I do obviously long Twitter threads in the past and I write reports a lot. But forcing me to go through that process every week and then sit with an editor and go ahead and get it improved, has made me a far better writer, it's made me a better storyteller, I am far better at articulating my point of view.It is absolutely just unlocking a host of benefits that I would have thought I was, oh, I passed all this. I'm already good at these things. And I was, but I'm better now. I think that writing is one of those things that people need to do a lot more of.Jeff: Absolutely. And it's funny that you mentioned that because I just recently, back in April, started to do the same thing I said, I'm going to write a blog post every week, right? I'm going to get three or four in the can, so that if life comes up and I miss a beat, right, I'm not actually missing the production schedule, so I have a steady—and you're right. Even after writing a book, I'm still learning stuff through the writing process, articulating my point of view.It's just something that carries over, and it carries over into the workforce, too. Like, if you've ever read a bad piece of documentation, right, that comes from—Corey: No.Jeff: Right? [laugh]. That comes from an inability to write. Like, you know, you end up asking these questions like who's the audience for this? What is ‘it' in this sentence? [laugh].Corey: Part of it too, is that people writing these things are so close to the problem themselves that the fact that, “Well, I'm not an expert in this.” That's why you should write about it. Talk about your experience. You're afraid everyone's going to say, “Oh, you're a fool. You didn't understand how this works.”Yeah, my lived experiences instead—and admittedly, I have the winds of privilege of my back on this—but it's also yeah, I didn't understand that either. It turns out that you're never the only person who has trouble with a concept. And by calling it out, you're normalizing it and doing a tremendous service for others in your shoes.Jeff: Especially when you're not an expert because I wrote some documentation about the SSL process and it didn't occur to me that these people don't use the AWS command line, right? Like, you know, in our organization, we sort of mask that from them through a bunch of in-house automation. Now we're starting to expose it to them and simple things like oh, you need to preface the AWS command with a profile name. So, then when we're going through the setup, we're like, “Oh. What if they already have an existing profile, right?” Like, we don't want to clobber that.SSo, it just changed the way you write the documentation. But like, that's not something that initially came to mind for me. It wasn't until someone went through the docs, and they're like, “Uh, this is blowing up in a weird way.” And I was like, “Oh, right. You know, like, I need to also teach you about profile management.”Corey: Also, everyone has a slightly different workflow for the way they interact with AWS accounts, and their shell prompts, and the way they set up local dev environments.Jeff: Yeah, absolutely. So, not being an expert on a thing is key because you're coming to it with virgin eyes, right, and you're able to look at it from a fresh perspective.Corey: So, much documentation out there is always coming from the perspective of someone who is intimately familiar with the problem space. Some of the more interesting episodes that I have, from a challenge perspective, are people who are deep technologists in a particular area and they love they fallen in love with the thing that they are building. Great. Can you explain it to the rest of us mere mortals so that we can actually we can share your excitement on this? And it's very hard to get them to come down to a level where it's coherent to folks who haven't spent years thinking deeply about that particular problem space.Jeff: Man, the number one culprit for that is, like, the AWS blogs where they have, like, a how-to article. You follow that thing and you're like, “None of this is working.” [laugh]. Right? And then you realize, oh, they made an assumption that I knew this, but I didn't right?So, it's like, you know, I didn't realize this was supposed to be, like, a handwritten JSON document just jammed into the value field. Because I didn't know that, I'm not pulling those values out as JSON. I'm expecting that just to be, like, a straight string value. And that has happened more and more times on the AWS blog than I can count. [laugh].Corey: Oh, yeah, very often. And then there's other problems, too. “Oh, yeah. Set up your IAM permissions properly.” That's left as an exercise for the reader. And then you wonder why everything's full of stars. Okay.Jeff: Right. Yep, exactly, exactly.Corey: Ugh. It's so great to catch up with you and see what you've been working on. If people want to learn more, where's the best place to find you?Jeff: So, the best place is probably my website, attainabledevops.com. That's a place where you can find me on all the other places. I don't really update that site much, but you can find me on LinkedIn, Twitter, from that jumping off point, links to the book are there if anyone's interested in that. Perfect stocking stuffers. Mom would love it, grandma would love it, so definitely, definitely buy multiple copies of that.Corey: Yeah, it's going to be one of my two-year-old's learning to read books, it'd be great.Jeff: Yeah, it's perfect. You know, you just throw it in the crib and walk away, right? They're asleep at no time. Like I said, I've also been taking to, you know, blogging on Medium, so you can catch me there, the links will be there on Attainable DevOps as well.Corey: Excellent. And that link will of course, be in the show notes. Thank you so much for being so generous with your time. I really do appreciate it. And it's great to talk to you again.Jeff: It was great to catch up.Corey: Really was. Jeff Smith, Director of Product Operations at Basis Technologies. 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 buttons on the YouTubes, whereas if you've hated this podcast, do the exact same thing—five-star review, smash the buttons—but also leave an angry, incoherent comment that you're then going to have edited and every week you're going to come back and write another incoherent comment that you get edited. And in the fullness of time, you'll get much better at writing angry, incoherent comments.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.

The AWS Cloud Adoption Framework (AWS CAF) leverages AWS experience and best practices to help you digitally transform and accelerate your business outcomes through innovative use of AWS. In this episode, Simon is joined by Dr. Saša Baškarada (Worldwide Lead, AWS CAF) and Jason Turse (Senior Practice Manager, Defense Advisory), to discuss the latest updates to the AWS CAF, how customers, partners, and AWS teams are using it, and some of the best practices that the AWS CAF recommends. Learn more - https://aws.amazon.com/professional-services/CAF/ Register for re:Inforce - https://reinforce.awsevents.com/?did=pc_card-body&trk=pc_card-body Leave us feedback - https://d1ox81nm0qxip8.cloudfront.net/index.html

About BenjaminBenjamin Anderson is CTO, Cloud at EDB, where he is responsible for developing and driving strategy for the company's Postgres-based cloud offerings. Ben brings over ten years' experience building and running distributed database systems in the cloud for multiple startups and large enterprises. Prior to EDB, he served as chief architect of IBM's Cloud Databases organization, built an SRE practice at database startup Cloudant, and founded a Y Combinator-funded hardware startup.Links Referenced: EDB: https://www.enterprisedb.com/ BigAnimal: biganimal.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.I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: This episode is sponsored by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends at EDB. And not only do they bring us this promoted episode, they bring me their CTO for Cloud, Benjamin Anderson. Benjamin, thank you so much for agreeing to suffer the slings and arrows that I will no doubt throw at you in a professional context, because EDB is a database company, and I suck at those things.Benjamin: [laugh]. Thanks, Corey. Nice to be here.Corey: Of course. So, databases are an interesting and varied space. I think we can all agree—or agree to disagree—that the best database is, of course, Route 53, when you misuse TXT records as a database. Everything else is generally vying for number two. EDB was—back in the days that I was your customer—was EnterpriseDB, now rebranded as EDB, which is way faster to say, and I approve of that.But you were always the escalation point of last resort. When you're stuck with a really weird and interesting Postgres problem, EDB was where you went because if you folks couldn't solve the problem, it was likely not going to get solved. I always contextualized you folks as a consulting shop. That's not really what you do. You are the CTO for Cloud.And, ah, interesting. Do databases behave differently in cloud environments? Well, they do when you host them as a managed service, which is an area you folks have somewhat recently branched into. How'd you get there?Benjamin: Ah, that's interesting. So, there's a bunch of stuff to unpack there. I think EDB has been around for a long time. It's something like 13, 14, 15 years, something like that, and really it's just been kind of slowly growing, right? We did start very much as a product company. We built some technology to help customers get from Oracle database on to Postgres, way back in 2007, 2008.That business has just slowly been growing. It's been going quite well. Frankly, I only joined about 18 months ago, and it's really cool tech, right? We natively understand some things that Oracle is doing. Customers don't have to change their schemas to migrate from Oracle to Postgres. There's some cool technology in there.But as you point out, I think a lot of our position in the market has not been that product focused. There's been a lot of people seeing us as the Postgres experts, and as people who can solve Postgres problems, in general. We have, for a long time, employed a lot of really sharp Postgres people. We still employ a lot of really sharp Postgres people. That's very much, in a lot of ways, our bread and butter. That we're going to fix Postgres problems as they come up.Now, over the past few years, we've definitely tried to shift quite a bit into being more of a product company. We've brought on a bunch of people who've been doing more enterprise software product type development over the past few years, and really focusing ourselves more and more on building products and investing in ourselves as a product company. We're not a services company. We're not a consulting company. We do, I think, provide the best Postgres support in the market. But it's been a journey. The cloud has been a significant part of that as well, right? You can't get away.Corey: Oh, yeah. These days, when someone's spinning up a new workload, it's unlikely—in most cases—they're going to wind up spinning up a new data center, if they don't already have one. Yes, there's still a whole bunch of on-prem workloads. But increasingly, the default has become cloud. Instead of, “Why cloud?” The question's become, “Why not?”Benjamin: Right, exactly. Then, as people are more and more accepting of managed services, you have to be a product company. You have to be building products in order to support your database customers because what they want his managed services. I was working in managed databases and service, something like, ten years ago, and it was like pulling teeth. This is after RDS launched. This was still pulling teeth trying to get people to think about, oh, I'm going to let you run my database. Whereas, now obviously, it's just completely different. We have to build great products in order to succeed in the database business, in general.Corey: One thing that jumped out at me when you first announced this was the URL is enterprisedb.com. That doesn't exactly speak to, you know, non-large companies, and EDB is what you do. You have a very corporate logo, but your managed service is called BigAnimal, which I absolutely love. It actually expresses a sense of whimsy and personality that I can no doubt guess that a whole bunch of people argued against, but BigAnimal, it is. It won through. I love that. Was that as contentious as I'm painting it to be, or people actually have a sense of humor sometimes?Benjamin: [laugh]. Both, it was extremely contentious. I, frankly, was one of the people who was not in favor of it at first. I was in favor of something that was whimsical, but maybe not quite that whimsical.Corey: Well, I call it Postgres-squeal, so let's be very clear here that we're probably not going to see eye-to-eye on most anything in pronunciation things. But we can set those differences aside and have a conversation.Benjamin: Absolutely, no consider that. It was deliberate, though, to try to step away a little bit from the blue-suit-and-tie, enterprise, DB-type branding. Obviously, a lot of our customers are big enterprises. We're good at that. We're not trying to be the hip, young startup targeting business in a lot of ways. We have a wide range of customers, but we want to branch out a little bit.Corey: One of the challenges right now is if I spin up an environment inside of AWS, as one does, and I decide I certainly don't want to take the traditional approach of running a database on top of an EC2 instance—the way that we did in the olden days—because RDS was crappy. Now that it's slightly less crappy, that becomes a not ideal path. I start looking at their managed database offerings, and there are something like 15 distinct managed databases that they offer, and they never turn anything off. And they continue to launch things into the far future. And it really feels, on some level, like 20 years from now—what we call a DBA today—their primary role is going to look a lot more like helping a company figure out which of Amazon's 40 managed databases is the appropriate fit for this given workload. Yet, when I look around at what the industry has done, it seems that when we're talking about relational databases. Postgres has emerged back when I was, more or less, abusing servers in person in my data center days, it was always MySQL. These days, Postgres is the de facto standard, full stop. I admit that I was mostly keeping my aura away from any data that was irreplaceable at that time. What happened? What did I miss?Benjamin: It's a really good question. And I certainly am not a hundred percent on all the trends that went on there. I know there's a lot of folks that are not happy about the MySQL acquisition by Oracle. I think there's a lot of energy that was adopted by the NoSQL movement, as well. You have people who didn't really care about transactional semantics that were using MySQL because they needed a place to store their data. And then, things like MongoDB and that type of system comes along where it's significantly easier than MySQL, and that subset of the population just sort of drifts away from MySQL.Corey: And in turn, those NoSQL projects eventually turn into something where, okay, now we're trying to build a banking system on top of it, and it's, you know, I guess you can use a torque wrench as a hammer if you're really creative about it, but it seems like there's a better approach.Benjamin: Yeah, exactly. And those folks are coming back around to the relational databases, exactly. At the same time, the advancements in Postgres from the early eight series to today are significant, right? We shouldn't underestimate how much Postgres has really moved forward. It wasn't that long ago that replication was hardly a thing and Postgres, right? It's been a journey.Corey: One thing that your website talks about is that you accelerate your open-sourced database transformation. And this is a bit of a hobby horse I get on from time to time. I think that there are a lot of misunderstandings when people talk about this. You have the open-source purists—of which I shamefully admit I used to be one—saying that, “Oh, it's about the idea of purity and open and free as in software.” Great. Okay, awesome. But when I find that corporate customers are talking about when they say open-source database, they don't particularly care if they have access to the source code because they're not going to go in and patch a database engine, we hope. But what they do care about is regardless of where they are today—even if they're perfectly happy there—they don't want to wind up beholden to a commercial database provider, and/or they don't want to wind up beholden to the environment that is running within. There's a strategic Exodus that's available in theory, which on some level serves to make people feel better about not actually Exodus-ing, but it also means if they're doing a migration at some point, they don't also have to completely redo their entire data plan.Benjamin: Yeah, I think that's a really good point. I mean, I like to talk—there's a big rat's nest of questions and problems in here—but I generally like talk to about open APIs, talk about standards, talk about how much is going to have to change if you eliminate this vendor. We're definitely not open-source purists. Well, we employ a lot of open-source purists. I also used to be an open—Corey: Don't let them hear you say that, then. Fair enough. Fair enough.Benjamin: [laugh] we have proprietary software at EDB, as well. There's a kind of wide range of businesses that we participate in. Glad to hear you also mention this where-it's-hosted angle, as well. I think there's some degree to which people are—they figured out that having at least open APIs or an open-source-ish database is a good idea rather than being beholden to proprietary database. But then, immediately forget that when they're picking a cloud vendor, right? And realizing that putting their data in Cloud Vendor A versus Cloud Vendor B is also putting them in a similar difficult situation. They need to be really wary of when they're doing that. Now, obviously, I work at an independent software company, and I have some incentive to say this, but I do think it's true. And you know, there's meaningful data gravity risk.Corey: I assure you, I have no incentive. I don't care what cloud provider you're on. My guidance has been, for years, to—as a general rule—pick a provider, I care about which one, and go all in until there's a significant reason to switch. Trying to build an optionality, “Oh, everything we do should be fully portable at an instance notice.” Great. Unless you're actually doing it, you're more or less, giving up a whole bunch of shortcuts and feature velocity you could otherwise have, in the hopes of one day you'll do a thing, but all the assumptions you're surrounded by baked themselves in regardless. So, you're more or less just creating extra work for yourself for no defined benefit. This is not popular in some circles, where people try to sell something that requires someone to go multi-cloud, but here we are.Benjamin: No, I think you're right. I think people underestimate the degree to which the abstractions are just not very good, right, and the degree to which those cloud-specific details are going to leak in if you're going to try to get anything done, you end up in kind of a difficult place. What I see more frequently is situations where we have a big enterprise—not even big, even medium-sized companies where maybe they've done an acquisition or two, they've got business units that are trying to do things on their own. And they end up in two or three clouds, sort of by happenstance. It's not like they're trying to do replication live between two clouds, but they've got one business unit in AWS and one business unit and Azure, and somebody in the corporate—say enterprise architect or something like that—really would like to make things consistent between the two so they get a consistent security posture and things like that. So, there are situations where the multi-cloud is a reality at a certain level, but maybe not at a concrete technical level. But I think it's still really useful for a lot of customers.Corey: You position your cloud offering in two different ways. One of them is the idea of BigAnimal, and the other—well, it sort of harkens back to when I was in sixth grade going through the American public school system. They had a cop come in and talk to us and paint to this imaginary story of people trying to push drugs. “Hey, kid. You want to try some of this?” And I'm reading this and it says EDB, Postgres for Kubernetes. And I'm sent back there, where it's like, “Hey, kid. You want to run your stateful databases on top of Kubernetes?” And my default answer to that is good lord, no. What am I missing?Benjamin: That's a good question. Kubernetes has come a long way—I think is part of that.Corey: Oh, truly. I used to think of containers as a pure story for stateless things. And then, of course, I put state into them, and then, everything exploded everywhere because it turns out, I'm bad at computers. Great. And it has come a long way. I have been tracking a lot of that. But it still feels like the idea being that you'd want to have your database endpoints somewhere a lot less, I guess I'll call it fickle, if that makes sense.Benjamin: It's an interesting problem because we are seeing a lot of people who are interested in our Kubernetes-based products. It's actually based on—we recently open-sourced the core of it under a project called cloud-native PG. It's a cool piece of technology. If you think about sort of two by two. In one corner, you've got self-managed on-premise databases. So, you're very, very slow-moving, big-iron type, old-school database deployments. And on the opposite corner, you've got fully-managed, in the cloud, BigAnimal, Amazon RDS, that type of thing. There's a place on that map where you've got customers that want a self-service type experience. Whether that's for production, or maybe it's even for dev tests, something like that. But you don't want to be giving the management capability off to a third party.For folks that want that type of experience, trying to build that themselves by, like, wiring up EC2 instances, or doing something in their own data center with VMware, or something like that, can be extremely difficult. Whereas if you've go to a Kubernetes-based product, you can get that type of self-service experience really easily, right? And customers can get a lot more flexibility out of how they run their databases and operate their databases. And what sort of control they give to, say application developers who want to spin up a new database for a test or for some sort of small microservice, that type of thing. Those types of workloads tend to work really well with this first-party Kubernetes-based offering. I've been doing databases on Kubernetes in managed services for a long time as well. And I don't, frankly, have any concerns about doing it. There are definitely some sharp edges. And if you wanted to do to-scale, you need to really know what you're doing with Kubernetes because the naive thing will shoot you in the foot.Corey: Oh, yes. So, some it feels almost like people want to cosplay working for Google, but they don't want to pass the technical interview along the way. It's a bit of a weird moment for it.Benjamin: Yeah, I would agree.Corey: I have to go back to my own experiences with using RDS back at my last real job before I went down this path. We were migrating from EC2-Classic to VPC. So, you could imagine what dates me reasonably effectively. And the big problem was the database. And the joy that we had was, “Okay, we have to quiesce the application.” So, the database is now quiet, stop writes, take a snapshot, restore that snapshot into the environment. And whenever we talk to AWS folks, it's like, “So, how long is this going to take?” And the answer was, “Guess.” And that was not exactly reassuring. It went off without a hitch because every migration has one problem. We were sideswiped in an Uber on the way home. But that's neither here nor there. This was two o'clock in the morning, and we finished in half the maintenance time we had allotted. But it was the fact that, well, guess we're going to have to take the database down for many hours with no real visibility, and we hope it'll be up by morning. That wasn't great. But that was the big one going on, on an ongoing basis, there were maintenance windows with a database. We just stopped databasing for a period of time during a fairly broad maintenance window. And that led to a whole lot of unfortunate associations in my mind with using relational databases for an awful lot of stuff. How do you handle maintenance windows and upgrading and not tearing down someone's application? Because I have to assume, “Oh, we just never patch anything. It turns out that's way easier,” is in fact, the wrong answer.Benjamin: Yeah, definitely. As you point out, there's a bunch of fundamental limitations here, if we start to talk about how Postgres actually fits together, right? Pretty much everybody in RDS is a little bit weird. The older RDS offerings are a little bit weird in terms of how they do replication. But most folks are using Postgres streaming replication, to do high availability, Postgres in managed services. And honestly, of course—Corey: That winds up failing over, or the application's aware of both endpoints and switches to the other one?Benjamin: Yeah—Corey: Sort of a database pooling connection or some sort of proxy?Benjamin: Right. There's a bunch of subtleties that get into their way. You say, well, did the [vit 00:16:16] failover too early, did the application try to connect and start making requests before the secondaries available? That sort of thing.Corey: Or you misconfigure it and point to the secondary, suddenly, when there's a switchover of some database, suddenly, nothing can write, it can only read, then you cause a massive outage on the weekend?Benjamin: Yeah. Yeah.Corey: That may have been of an actual story I made up.Benjamin: [laugh] yeah, you should use a managed service.Corey: Yeah.Benjamin: So, it's complicated, but even with managed services, you end up in situations where you have downtime, you have maintenance windows. And with Postgres, especially—and other databases as well—especially with Postgres, one of the biggest concerns you have is major version upgrades, right? So, if I want to go from Postgres 12 to 13, 13 to 14, I can't do that live. I can't have a single cluster that is streaming one Postgres version to another Postgres version, right?So, every year, people want to put things off for two years, three years sometimes—which is obviously not to their benefit—you have this maintenance, you have some sort of downtime, where you perform a Postgres upgrade. At EDB, we've got—so this is a big problem, this is a problem for us. We're involved in the Postgres community. We know this is challenging. That's just a well-known thing. Some of the folks that are working EDB are folks who worked on the Postgres logical replication tech, which arrived in Postgres 10. Logical replication is really a nice tool for doing things like change data capture, you can do Walter JSON, all these types of things are based on logical replication tech.It's not really a thing, at least, the code that's in Postgres itself doesn't really support high availability, though. It's not really something that you can use to build a leader-follower type cluster on top of. We have some techs, some proprietary tech within EDB that used to be called bi-directional replication. There used to be an open-source project called bi-directional replication. This is a kind of a descendant of that. It's now called Postgres Distributed, or EDB Postgres Distributed is the product name. And that tech actually allows us—because it's based on logical replication—allows us to do multiple major versions at the same time, right? So, we can upgrade one node in a cluster to Postgres 14, while the other nodes in the clusters are at Postgres 13. We can then upgrade the next node. We can support these types of operations in a kind of wide range of maintenance operations without taking a cluster down from maintenance.So, there's a lot of interesting opportunities here when we start to say, well, let's step back from what your typical assumptions are for Postgres streaming replication. Give ourselves a little bit more freedom by using logical replication instead of physical streaming replication. And then, what type of services, and what type of patterns can we build on top of that, that ultimately help customers build, whether it's faster databases, more highly available databases, so on and so forth.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: One approach that I took for, I guess you could call it backup sort of, was intentionally staggering replication between the primary and the replica about 15 minutes or so. So, if I drop a production table or something like that, I have 15 short minutes to realize what has happened and sever the replication before it is now committed to the replica and now I'm living in hell. It felt like this was not, like, option A, B, or C, or the right way to do things. But given that meeting customers where they are as important, is that the sort of thing that you support with BigAnimal, or do you try to talk customers into not being ridiculous?Benjamin: That's not something we support now. It's not actually something that I hear that many asks for these days. It's kind of interesting, that's a pattern that I've run into a lot in the past.Corey: I was an ancient, grumpy sysadmin. Again, I'm dating myself here. These days, I just store everything at DNS text records, and it's way easier. But I digress.Benjamin: [laugh] yeah, it's something that we see a lot for and we had support for a point-in-time restore, like pretty much anybody else in the business at this point. And that's usually the, “I fat-fingered something,” type response. Honestly, I think there's room to be a bit more flexible and room to do some more interesting things. I think RDS is setting a bar and a lot of database services out there and kind of just meeting that bar. And we all kind of need to be pushing a little bit more into more interesting spaces and figuring out how to get customers more value, get customers to get more out of their money for the database, honestly.Corey: One of the problems we tend to see, in the database ecosystem at large, without naming names or companies or anything like that, is that it's a pretty thin and blurry line between database advocate, database evangelist, and database zealot. Where it feels like instead, we're arguing about religion more than actual technical constraints and concerns. So, here's a fun question that hopefully isn't too much of a gotcha. But what sort of workloads would you actively advise someone not to use BigAnimal for in the database world? But yes, again, if you try to run a DNS server, it's probably not fit for purpose without at least a shim in the way there. But what sort of workloads are you not targeting that a customer is likely to have a relatively unfortunate time with?Benjamin: Large-scale analytical workloads is the easy answer to that, right? If you've got a problem where you're choosing between Postgres and Snowflake, you're seriously considering—you actually have as much data that you seriously be considering Snowflake? You probably don't want to be using Postgres, right? You want to be using something that's column, or you want to be using a query planner that really understands a columnar layout that's going to get you the sorts of performance that you need for those analytical workloads. We don't try to touch that space.Corey: Yeah, we're doing some of that right now with just the sheer volume of client AWS bills we have. We don't really need a relational model for a lot of it. And Athena is basically fallen down on the job in some cases, and, “Oh, do you want to use Redshift, that's basically Postgres.” It's like, “Yeah, it's Postgres, if it decided to run on bars of gold.” No, thank you. It just becomes this ridiculously overwrought solution for what feels like it should be a lot similar. So, it's weird, six months ago or so I wouldn't have had much of an idea what you're talking about. I see it a lot better now. Generally, by virtue of trying to do something the precise wrong way that someone should.Benjamin: Right. Yeah, exactly. I think there's interesting room for Postgres to expand here. It's not something that we're actively working on. I'm not aware of a lot happening in the community that Postgres is, for better or worse, extremely extensible, right? And if you see the JSON-supported Postgres, it didn't exist, I don't know, five, six years ago. And now it's incredibly powerful. It's incredibly flexible. And you can do a lot of quote-unquote, schemaless stuff straight in Postgres. Or you look at PostGIS, right, for doing GIS geographical data, right? That's really a fantastic integration directly in the database.Corey: Yeah, before that people start doing ridiculous things almost looks similar to a graph database or a columnar store somehow, and yeah.Benjamin: Yeah, exactly. I think sometimes somebody will do a good column store that's an open-source deeply integrated into Postgres, rather than—Corey: I've seen someone build one on top of S3 bucket with that head, a quarter of a trillion objects in it. Professional advice, don't do that.Benjamin: [laugh]. Unless you're Snowflake. So, I mean, it's something that I'd like to see Postgres expand into. I think that's an interesting space, but not something that, at least especially for BigAnimal, and frankly, for a lot of EDB customers. It's not something we're trying to push people toward.Corey: One thing that I think we are seeing a schism around is the idea that some vendors are one side of it, some are on the other, where on the one side, you have, oh, every workload should have a bespoke, purpose-built database that is exactly for this type of workload. And the other school of thought is you should generally buy us for a general-purpose database until you have a workload that is scaled and significant to a point where running that on its own purpose-built database begins to make sense. I don't necessarily think that is a binary choice, where do you tend to fall on that spectrum?Benjamin: I think everybody should use Postgres. And I say not just because I work in a Postgres company.Corey: Well, let's be clear. Before this, you were at IBM for five years working on a whole bunch of database stuff over there, not just Postgres. And you, so far, have not struck me as the kind of person who's like, “Oh, so what's your favorite database?” “The one that pays me.” We've met people like that, let's be very clear. But you seem very even-handed in those conversations.Benjamin: Yeah, I got my start in databases, actually, with Apache CouchDB. I am a committer on CouchDB. I worked on a managed at CouchDB service ten years ago. At IBM, I worked on something in nine different open-source databases and managed services. But I love having conversations about, like, well, I've got this workload, should I use Postgres, rr should I use Mongo, should I use Cassandra, all of those types of discussions. Frankly, though, I think in a lot of cases people are—they don't understand how much power they're missing out on if they don't choose a relational database. If they don't understand the relational model well enough to understand that they really actually want that. In a lot of cases, people are also just over-optimizing too early, right? It's just going to be much faster for them to get off the ground, get product in customers hands, if they start with something that they don't have to think twice about. And they don't end up with this architecture with 45 different databases, and there's only one guy in the company that knows how to manage the whole thing.Corey: Oh, the same story of picking a cloud provider. It's, “Okay, you hire a team, you're going to build a thing. Which cloud provider do you pick?” Every cloud provider has a whole matrix and sales deck, and the rest. The right answer, of course, is the one your team's already familiar with because learning a new cloud provider while trying not to run out of money at your startup, can't really doesn't work super well.Benjamin: Exactly. Yeah.Corey: One thing that I think has been sort of interesting, and when I saw it, it was one of those, “Oh, I sort of like them.” Because I had that instinctive reaction and I don't think I'm alone in this. As of this recording a couple of weeks ago, you folks received a sizable investment from private equity. And default reaction to that is, “Oh, well, I guess I put a fork in the company, they're done.” Because the narrative is that once private equity takes an investment, well, that company's best days are probably not in front of it. Now, the counterpoint is that this is not the first time private equity has invested in EDB, and you folks from what I can tell are significantly better than you were when I was your customer a decade ago. So clearly, there is something wrong with that mental model. What am I missing?Benjamin: Yeah. Frankly, I don't know. I'm no expert in funding models and all of those sorts of things. I will say that my experience has been what I've seen at EDB, has definitely been that maybe there's private equity, and then there's private equity. We're in this to build better products and become a better product company. We were previously owned by a private equity firm for the past four years or so. And during the course of those four years, we brought on a bunch of folks who were very product-focused, new leadership. We made a significant acquisition of a company called 2ndQuadrant, which they employed a lot of the European best Postgres company. Now, they're part of EDB and most of them have stayed with us. And we built the managed cloud service, right? So, this is a pretty significant—private equity company buying us to invest in the company. I'm optimistic that that's what we're looking at going forward.Corey: I want to be clear as well, I'm not worried about what I normally would be in a private equity story about this, where they're there to save money and cut costs, and, “Do we really need all these database replicas floating around,” and, “These backups, seems like that's something we don't need.” You have, at last count, 32 Postgres contributors, 7 Postgres committers, and 3 core members. All of whom would run away screaming loudly and publicly, in the event that such a thing were taking place. Of all the challenges and concerns I might have about someone running a cloud service in the modern day. I do not have any fear that you folks are not doing what will very clearly be shown to be the right thing by your customers for the technology that you're building on top of. That is not a concern. There are companies I do not have that confidence in, to be clear.Benjamin: Yeah, I'm glad to hear that. I'm a hundred percent on board as well. I work here, but I think we're doing the right thing, and we're going to be doing great stuff going forward.Corey: One last topic I do want to get into a little bit is, on some level, launching in this decade, a cloud-hosted database offering at a time when Amazon—whose product strategy of yes is in full display—it seems like something ridiculous, that is not necessarily well thought out that why would you ever try to do this? Now, I will temper that by the fact that you are clearly succeeding in this direction. You have customers who say nice things about you, and the reviews have been almost universally positive anywhere I can see things. The negative ones are largely complaining about databases, which I admit might be coming from me.Benjamin: Right, it is a crowded space. There's a lot of things happening. Obviously, Amazon, Microsoft, Google are doing great things, both—Corey: Terrible things, but great, yes. Yes.Benjamin: [laugh] right, there's good products coming in. I think AlloyDB is not necessarily a great product. I haven't used it myself yet, but it's an interesting step in the direction. I'm excited to see development happening. But at the end of the day, we're a database company. Our focus is on building great databases and supporting great databases. We're not entering this business to try to take on Amazon from an infrastructure point of view. In fact, the way that we're structuring the product is really to try to get the strengths of both worlds. We want to give customers the ability to get the most out of the AWS or Azure infrastructure that they can, but come to us for their database.Frankly, we know Postgres better than anybody else. We have a greater ability to get bugs fixed in Postgres than anybody else. We've got folks working on the database in the open. We got folks working on the database proprietary for us. So, we give customers things like break/fix support on that database. If there is a bug in Postgres, there's a bug in the tech that sits around Postgres. Because obviously, Postgres is not a batteries-included system, really. We're going to fix that for you. That's part of the contract that we're giving to our customers. And I know a lot of smaller companies maybe haven't been burned by this sort of thing very much. We start to talk about enterprise customers and medium, larger-scale customers, this starts to get really valuable. The ability to have assurance on top of your open-source product. So, I think there's a lot of interesting things there, a lot of value that we can provide there.I think also that I talked a little bit about this earlier, but like the box, this sort of RDS-shaped box, I think is a bit too small. There's an opportunity for smaller players to come in and try to push the boundaries of that. For example, giving customers more support by default to do a good job using their database. We have folks on board that can help consult with customers to say, “No, you shouldn't be designing your schemas that way. You should be designing your schemas this way. You should be using indexes here,” that sort of stuff. That's been part of our business for a long time. Now, with a managed service, we can bake that right into the managed service. And that gives us the ability to kind of make that—you talk about shared responsibility between the service writer and the customer—we can change the boundaries of that shared responsibility a little bit, so that customers can get more value out of the managed database service than they might expect otherwise.Corey: There aren't these harsh separations and clearly defined lines across which nothing shall pass, when it makes sense to do that in a controlled responsible way.Benjamin: Right, exactly. Some of that is because we're a database company, and some of that is because, frankly, we're much smaller.Corey: I'll take it a step further beyond that, as well, that I have seen this pattern evolve a number of times where you have a customer running databases on EC2, and their AWS account managers suggests move to RDS. So, they do. Then, move to Aurora. So, they do. Then, I move this to DynamoDB. At which point, it's like, what do you think your job is here, exactly? Because it seems like every time we move databases, you show up in a nicer car. So, what exactly is the story here, and what are the incentives? Where it just feels like there is a, “Whatever you're doing is not the way that it should be done. So, it's time to do, yet, another migration.”There's something to be said for companies who are focused around a specific aspect of things. Then once that is up and working and running, great. Keep on going. This is fine. As opposed to trying to chase the latest shiny, on some level. I have a big sense of, I guess, affinity for companies that wind up knowing where they start, and most notably, where they stop.Benjamin: Yeah, I think that's a really good point. I don't think that we will be building an application platform anytime soon.Corey: “We're going to run Lambda functions on top of a database.” It's like, “Congratulations. That is the weirdest stored procedure I can imagine this week, but I'm sure we can come up with a worse one soon.”Benjamin: Exactly.Corey: I really want to thank you for taking the time to speak with me so much about how you're thinking about this, and what you've been building over there. If people want to learn more, where's the best place to go to find you?Benjamin: biganimal.com.Corey: Excellent. We will throw a link to that in the show notes and it only just occurred to me that the Postgres mascot is an elephant, and now I understand why it's called BigAnimal. Yeah, that's right. He who laughs last, thinks slowest, and today, that's me. I really want to thank you for being so generous with your time. I appreciate it.Benjamin: Thank you. I really appreciate it.Corey: Benjamin Anderson, CTO for Cloud at EDB. 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, along with an angry comment that you then wind up stuffing into a SQLite database, converting to Base64, and somehow stuffing into the comment field.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.

About BrandonBrandon West was raised in part by video games and BBSes and has been working on web applications since 1999. He entered the world of Developer Relations in 2011 as an evangelist for a small startup called SendGrid and has since held leadership roles at companies like AWS. At Datadog, Brandon is focused on helping developers improve the performance and developer experience of the things they build. He lives in Seattle where enjoys paddle-boarding, fishing, and playing music.Links Referenced: Datadog: https://www.datadoghq.com/ Twitter: https://twitter.com/bwest 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 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: This episode is sponsored in part by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today is someone I've been trying to get on the show for years, but I'm very bad at, you know, following up and sending the messages and all the rest because we all struggle with our internal demons. My guest instead struggles with external demons. He is the team lead for developer experience and tools advocacy at what I can only assume is a Tinder for Pets style company, Date-A-Dog. Brendon West, thank you for joining me today.Brandon: Hey, Corey, thanks for having me. I'm excited to be here. Finally, like you said, it's been a couple of years. But glad that it's happening. And yeah, I'm on the DevRel team at Datadog.Corey: Yes, I'm getting a note here in the headset of breaking news coming in. Yes, you're not apparently a dog dating company, you are a monitoring slash observability slash whatever the cool kids are calling it today telemetry outputer dingus nonsense. Anyone who has ever been to a community or corporate event has no doubt been tackled by one of the badge scanners that you folks have orbiting your booth, but what is it that you folks do?Brandon: Well, the observability, the monitoring, the distributed tracing, all that stuff that you mentioned. And then a lot of other interesting things that are happening. Security is a big focus—InfoSec—so we're adding some products around that, automated security monitoring, very cool. And then the sort of stuff that I'm representing is stuff that helps developers provide a better experience to their end-users. So, things like front-end monitoring, real-time user monitoring, synthetic testing of your APIs, whatever it might be.Corey: Your path has been somewhat interesting because you—well, everyone's path has been somewhat interesting; yours has been really interesting because back in 2011, you entered the world of developer relations, or being a DevReloper as I insist on calling it. And you were in a—you call it a small startup called SendGrid. Which is, on some level, hilarious from my point of view. I've been working with you folks—you folks being SendGrid—for many years now. I cared a lot about email once upon a time.And now I send an email newsletter every week, that deep under the hood, through a couple of vendor abstraction layers is still SendGrid, and I don't care about email because that's something that I can pay someone else to worry about. You went on as well to build out DevRel teams at AWS. You decided okay, you're going to take some time off after that. You went to a small scrappy startup and ah, nice. You could really do things right and you have a glorious half of the year and then surprise, you got acquired by Datadog. Congratu-dolances on that because now you're right back in the thick of things at big company-style approaches. Have I generally nailed the trajectory of the past decade for you?Brandon: Yeah, I think the broad strokes are all correct there. SendGrid was a small company when I joined, you know? There were 30 of us or so. So, got to see that grow into what it is today, which was super, super awesome. But other than that, yeah, I think that's the correct path.Corey: It's interesting to me, in that you were more or less doing developer relations before that was really a thing in the ecosystem. And I understand the challenge that you would have in a place like SendGrid because that is large-scale email sending, transactional or otherwise, and that is something that by and large, has slipped below the surface level of awareness for an awful lot of folks in your target market. It's, “Oh, okay, and then we'll just have the thing send an email,” they say, hand-waving over what is an incredibly deep and murky pool. And understanding that is a hard thing requires a certain level of technical sophistication. So, you started doing developer relations for something that very clearly needed some storytelling chops. How did you fall into it originally?Brandon: Well, I wanted to do something that let me use those storytelling chops, honestly. I had been writing code at an agency for coal mines and gold mines and really actively inserting evil into the world, power plants, and that sort of thing. And, you know, I went to school for English literature. I loved writing. I played in thrash metal bands when I was a kid, so I've been up on stage being cussed at and told that I suck. So I—Corey: Oh, I get that conference talks all the time.Brandon: Yeah, right? So, that's why when people ask me to speak, I'm like, “Absolutely.” There's no way I can bomb harder than I've bombed before. No fear, right? So yeah, I wanted to use those skills. I wanted to do something different.And one of my buddies had a company that he had co-founded that was going through TechStars in Boulder. SendGrid was the first accelerator-backed company to IPO which is pretty cool. But they had gone through TechStars in 2009. They were looking for a developer evangelist. So, SendGrid was looking for developer evangelist and my friend introduced me said, “I think you'd be good at this. You should have a conversation.” My immediate thought was what the hell is a developer evangelist?Corey: And what might a SendGrid be? And all the rest. Yes, it's that whole, “Oh, how do I learn to swim?” Someone throws you off the end of the dock and then retrospect, it's, “I don't think they were trying to teach me how to swim.” Yeah. Hindsight.Brandon: Yeah. It worked out great. I will say, though, that I think DevRel has been around for a long time, you know? The title has been around since the original Macintosh at Apple in 1980-ish. There's a whole large part of the tech world that would like you to think that it's new because of all the terrible things that their DevRel team did at Microsoft in the late-90s.And you can go read all about this. There were trials about it. These documents were released to the public, James Plamondon is the lead architect of all of this nastiness. But I think there was then a concerted effort to memory-hole that and say, “No, DevRel is new and shiny.” And then Google came along and said, “Well, it's not evangelism anymore. It's advocacy.”Corey: It's not sysadmin work anymore. It's SRE. It's not on-prem, it's Sparkling Kubernetes, et cetera, et cetera.Brandon: Yeah, so there's this sense in a lot of places that DevRel is new, but it's actually been around a long time. And you can learn a lot from reading about the history and understanding it, something I've given a talk on and written a bit about. So.Corey: My philosophy around developer relations for a while has been that in many cases, its biggest obstacle is the way that it is great at telling stories about fantastically complex, deeply technical things; it can tell stories about almost anything except itself. And I keep seeing similar expressions of the same problem again, and again, and again. I mean, AWS, where you worked, as an example: they love to talk about their developer advocates, and you read the job descriptions and these are high-level roles with sweeping responsibilities, broad basis of experience being able to handle things at a borderline executive level. And then they almost neuter the entire thing by slapping a developer advocate title on top of those people, which means that some of the people that would be most effectively served by talking to them will dismiss them as, “Well, I'm a director”—or a VP—“What am I going to do talking to a developer advocate?” It feels like there's a swing and a miss as far as encapsulating the value that the function provides.I want to be clear, I am not sitting here shitting on DevRel or its practitioners, I see a problem with how it [laugh] is being expressed. Now, feel free to argue with me and just scream at me for the next 20 minutes, and this becomes a real short show. But—Brandon: [laugh].Corey: —It'll be great. Hit me.Brandon: No, you're correct in many ways, which makes me sad because these are the same conversations that I've been having for the 11, 12 years that I've been in DevRel now. And I thought we would have moved past this at some point, but the problem is that we are bad at advocating for advocacy. We do a bad job of relating to people about DevRel because we spend so much time worried about stuff that doesn't really matter. And we get very loud voices in the echo chamber screaming about titles and evangelism versus advocate versus community manager, and which department you should report up to, and all of these things that ultimately don't matter. And it just seems like bickering from the outside. I think that the core of what we do is super awesome. And I don't think it's very hard to articulate. It's just that we don't spend the time to do that.Corey: It's always odd to me when I talk to someone like, “Oh, you're in DevRel. What does that mean?” And their immediate response is, “Well, it's not marketing, I'll tell you that.” It's feels like there might be some trauma that is being expressed in some strange ways. I do view it as marketing, personally, and people who take umbrage at that don't generally tend to understand what marketing is.Yeah, you can look at any area of business or any function and judge it by some of the worst examples that we've all seen, but when someone tells me they work in sales, I don't automatically assume that they are sending me horrifyingly passive-aggressive drip campaigns, or trying to hassle me in a car lot. It's no, there's a broad spectrum of people. Just like I don't assume that you're an engineer. And I immediately think, oh, you can't solve FizzBuzz on a whiteboard. No, there's always going to be a broad spectrum of experience.Marketing is one of those awesome areas of business that's dramatically misunderstood a lot. Similarly to the fact that, you know, DevRel can't tell stories, you think marketing could tell stories about itself, but it's still struggles, too, in a bunch of ways. But I do believe that even if they're not one of the same, developer relations and marketing are aligned around an awful lot of things like being able to articulate value that is hard to quantify.Brandon: I completely agree with that. And if I meet someone in DevRel that starts off the conversation by saying that they're not in marketing, then I know they're probably not that great at their job. I mean, I think there's a place of tech hubris, where we want to disrespect anything that's not a hard skill where it's not putting zeros and ones into a chip—Corey: And spoiler, they're all very hard skills.Brandon: [laugh]. Yeah. And so, first off, like, stop disrespecting marketing. It's important; your business probably wouldn't survive if you didn't have it. And second of all, you're not immune to it, right?Like, Heartbleed had a logo and a name for vulnerability because tech people are so susceptible to it, right? People don't just wake up and wait in line for three days for a new iPhone because tech marketing doesn't work, right?Corey: “Oh, tech marketing doesn't work on me,” says someone who's devoted last five years of their life to working on Kubernetes. Yeah, sure it doesn't.Brandon: Yeah exactly. So, that whole perspective is silly. I think part of the problem is that they don't want to invest in learning how to communicate what they do to a marketing org. They don't want to spend the time to say, “Here's how the marketing world thinks, and here's how we can fit into that perspective.” They want to come in and say, “Well, you don't understand DevRel. Let me define DevRel for you and tell you what we do.” And all those sorts of things. It's too prescriptive and less collaborative.Corey: Anytime you start getting into the idea of metrics around how do you measure someone in a developer advocacy role, the answer is, “Well, your metrics that you're using are wrong, and any metrics you use are wrong, and there's no good way to do it.” And I am sympathetic to that. When I started this place, I knew that if I went to a bunch of events and did my thing, good things would happen for the business. And how did I articulate that? Gut feel, but when you own the place, you can do that.Whereas when you are a function inside of another org, inside of another org, and you start looking at from the executive leadership position at these things, it's, “Okay, so let me get this straight. You cost as much as an engineer, you cost as much as that again, in your expenses because you're traveling all the time, you write zero production code, whenever people ask you what it is you do here, you have a very strange answer, and from what we can tell, it looks like you hang out with your friends in exotic locations, give a 15-minute talk from time to time that mentions our name at the beginning, and nothing else relevant to our business, and then you go around and the entire story is ‘just trust me, I'm adding value.'” Yeah, when it's time to tighten belts and start cutting back, is it any wonder that the developer advocacy is often one of the first departments hit from that perspective?Brandon: It doesn't surprise me. I mean, I've been a part of DevRel teams where we had some large number of events that we had attended for the year—I think 450-something—and the director of the team was very excited to show that off, right, you should have seen the CFOs face when he heard that, right, because all he sees is outgoing dollar signs. Like, how much expense? What's the ROI on 450 events?Corey: Yeah, “450 events? That's more than one a day. Okay, great. That's a big number and I already know what we're spending. Great. How much business came out of that?”And that's when the hemming and hawing starts. Like, well, sort of, and yadda—and yeah, it doesn't present well in the language that they are prepared to speak. But marketing can tell those stories because they have for ages. Like, “Okay, how much business came from our Superbowl ad?” “I dunno. The point is, is that there's a brand awareness play, there's the chance to remain top of the mental stack when people think about this space. And over the next few months, we can definitely see there's been a dramatic uptick in our business. Now, how do we attribute that back? Well, I don't know.”There's a saying in marketing, that half of your marketing budget is wasted. Now, figuring out which half will spend the rest of your career, you'll never get even close. Because people don't know the journey that customers go through, not really. Even customers don't often see it.Take this podcast, for example. I have sponsors that I do love and appreciate who say things from time to time on this show. And people will hear it and occasionally will become customers of those sponsors. But very often, it's, “Oh, I heard about that on the podcast. I'll Google it when I get to work and then I'll have a conversation with my team and we'll agree to investigate that.”And any UTM tracking has long since fallen by the wayside. You might get to that from discussions with users in their interview process, but very often, they won't remember where it came up. And it's one of those impossible to quantify things. Now, I sound like one of those folks where I'm trying to say, “Oh, buy sponsorships that you can never prove add value.” But that is functionally how advertising tends to work, back in the days before it spied on you.Brandon: Yeah, absolutely. And we've added a bunch of instrumentation to allow us to try and put that multi-touch attribution model together after the fact, but I'm still not sure that that's worth the squeeze, right? You don't get much juice out. One of the problems with metrics in DevRel is that the things that you can measure are very production-focused. It's how many talks did you give? How many audience members did you reach?Some developer relations folks do actually write production code, so it might be how many of the official SDK that you support got downloaded? That can be more directly attributed to business impact, those sorts of things are fantastic. But a lot of it is kind of fuzzy and because it's production-focused, it can lead to burnout because it's disconnected from business impact. “It's how many widgets did your line produce today?” “Well, we gave all these talks and we had 150,000 engaged developer hours.” “Well, cool, what was the business outcome?” And if you can't answer that for your own team and for your own self in your role, that leads pretty quickly to burnout.Corey: Anytime you start measuring something and grading people based on it, they're going to optimize for what you measure. For example, I send an email newsletter out, at time of this recording, to 31,000 people every week and that's awesome. I also periodically do webinars about the joys of AWS bill optimization, and you know, 50 people might show up to one of those things. Okay, well, from a broad numbers perspective, yeah, I'd much rather go and send something out to those 31,000, folks until you realize that the kind of person that's going to devote half an hour, forty-five minutes to having a discussion with you about AWS bill optimization is far likelier to care about this to the point where they become a customer than someone who just happens to be in an audience for something that is orthogonally-related. And that is the trick because otherwise, we would just all be optimizing for the single biggest platforms out there if oh, I'm going to go talk at this conference and that conference, not because they're not germane to what we do, but because they have more people showing up.And that doesn't work. When you see that even on the podcast world, you have Joe Rogan, as the largest podcast in the world—let's not make too many comparisons in different ways because I don't want to be associated with that kind of tomfoolery—but there's a reason that his advertisers, by and large, are targeting a mass-market audience, whereas mine are targeting B2B SaaS, by and large. I'm not here shilling for various mattress companies. I'm instead talking much more about things that solve the kind of problem that listeners to this show are likely to have. It's the old-school of thought of advertising, where this is a problem that is germane to a certain type of audience, and that certain type of audience listens to shows like this. That was my whole school of thought.Brandon: Absolutely. I mean, the core value that you need to do DevRel, in my opinion is empathy. It's all about what Maya Angelou said, right? “People may not remember what you said, but they'll definitely remember how you made them feel.” And I found that to be incredibly true.Like, the moments that I regret the most in DevRel are the times when someone that I've met and spent time with before comes up to have a conversation and I don't remember them because I met 200 people that night. And then I feel terrible, right? So, those are the metrics that I use internally. It's hearts and minds. It's how do people feel? Am I making them feel empowered and better at their craft through the work that I do?That's why I love DevRel. If I didn't get that fulfillment, I'd go write code again. But I don't get that sense of satisfaction, and wow, I made an impact on this person's trajectory through their career that I do from DevRel. So.Corey: I come bearing ill tidings. Developers are responsible for more than ever these days. Not just the code that they write, but also the containers and the cloud infrastructure that their apps run on. Because serverless means it's still somebody's problem. And a big part of that responsibility is app security from code to cloud. And that's where our friend Snyk comes in. Snyk is a frictionless security platform that meets developers where they are - Finding and fixing vulnerabilities right from the CLI, IDEs, Repos, and Pipelines. Snyk integrates seamlessly with AWS offerings like code pipeline, EKS, ECR, and more! As well as things you're actually likely to be using. Deploy on AWS, secure with Snyk. Learn more at Snyk.co/scream That's S-N-Y-K.co/screamCorey: The way that I tend to see it, too, is that there's almost a bit of a broadening of DevRel. And let's be clear, it's a varied field with a lot of different ways to handle that approach. I'm have a terrible public speaker, so I'm not going to ever succeed in DevRel. Well, that's certainly not true. People need to write blog posts; people need to wind up writing some of the sample code, in some cases; people need to talk to customers in a small group environment, as opposed to in front of 3000 people and talk about the things that they're seeing, and the rest.There's a broad field and different ways that it applies. But I also see that there are different breeds of developer advocate as well. There are folks, like you for example. You and I have roughly the same amount of time in the industry working on different things, whereas there's also folks who it seems like they graduate from a boot camp, and a year later, they're working in a developer advocacy role. Does that mean that they're bad developer advocates?I don't think so, but I think that if they try and present things the same way that you were I do from years spent in the trenches working on these things, they don't have that basis of experience to fall back on, so they need to take a different narrative path. And the successful ones absolutely do.Brandon: Yeah.Corey: I think it's a nuanced and broad field. I wish that there was more acceptance and awareness of that.Brandon: That's absolutely true. And part of the reason people criticize DevRel and don't take it seriously, as they say, “Well, it's inconsistent. This org, it reports to product; or, this org, it reports up to marketing; this other place, it's part of engineering.” You know, it's poorly defined. But I think that's true of a lot of roles in tech.Like, engineering is usually done a different way, very differently at some orgs compared to others. Product teams can have completely different methodologies for how they track and manage and estimate their time and all of those things. So, I would like to see people stop using that as a cudgel against the whole profession. It just doesn't make any sense. At the same time, two of the best evangelist I ever hired were right out of university, so you're completely correct.The key thing to keep in mind there is, like, who's the audience, right, because ultimately, it's about building trust with the audience. There's a lot of rooms where if you and I walk into the room; if it's like a college hackathon, we're going to have a—[laugh], we're going to struggle.Corey: Yeah, we have some real, “Hello fellow kids,” energy going on when we do that.Brandon: Yeah. Which is also why I think it's incredibly important for developer relations teams to be aware of the makeup of their team. Like, how diverse is your team, and how diverse are the audiences you're speaking to? And if you don't have someone who can connect, whether it's because of age or lived experience or background, then you're going to fail because like I said that the number one thing you need to be successful in this role is empathy, in my opinion.Corey: I think that a lot of the efforts around a lot of this—trying to clarify what it is—some cases gone in well, I guess I'm going to call it the wrong direction. And I know that sounds judgy and I'm going to have to live with that, I suppose, but talk to me a bit about the, I guess, rebranding that we've seen in some recent years around developer advocates. Specifically, like, I like calling folks DevRelopers because it's cutesy, it's a bit of a portmanteau. Great. But it's also not something I seriously suggest most people put on business cards.But there are people who are starting to, I think, take a similar joke and actually identify with it where they call themselves developer avocados, which I don't fully understand. I have opinions on it, but again, having opinions that are not based in data is something I try not to start shouting from the rooftops wherever I can. You live in that world a lot more posted than I do, where do you stand?Brandon: So, I think it was well-intentioned and it was an attempt to do some of the awareness and brand building for DevRel, broadly, that we had lacked. But I see lots of problems with it. One, we already struggle to be taken seriously in many instances, as we've been discussing, and I don't think we do ourselves any favors by giving ourselves cutesy nicknames that sort of infantilize the role like I can't think of any other job that has a pet name for the work that they do.Corey: Yeah. The “ooh-woo accounting”. Yeah, I sort of don't see that happening very often in most business orgs.Brandon: Yeah. It's strange to me at the same time, a lot of the people who came up with it and popularized it are people that I consider friends and good colleagues. So hopefully, they won't be too offended, but I really think that it kind of set us back in many ways. I don't want to represent the work that I do with an emoji.Corey: Funny, you bring that up. As we record this through the first recording, I have on my new ridiculous desktop computer thing from Apple, which I have named after a—you know, the same naming convention that you would expect from an AWS region—it's us-shitpost-one. Instead of the word shit, it has the poop emoji. And you'd be amazed at the number of things that just melt when you start trying to incorporate that. GitHub has a problem with that being the name of an SSH key, for example.I don't know if I'll keep it or I'll just fall back to just spelling words out, but right now, at least, it really is causing all kinds of strange computer problems. Similarly, it causes strange cultural problems when you start having that dissonance and seeing something new and different like that in a business context. Because in some cases, yeah, it helps you interact with your audience and build rapport; in many others, it erodes trust and confidence that you know what you're talking about because people expect things to be cast a certain way. I'm not saying they're right. There's a shitload of bias that bakes into that, but at the same time, I'd like to at least bias for choosing when and where I'm going to break those expectations.There's a reason that increasingly, my Duckbillgroup.com website speaks in business terms, rather than in platypus metaphors, whereas lastweekinaws.com, very much leans into the platypus. And that is the way that the branding is breaking down, just because people expect different things in different places.Brandon: Yeah and, you know, this framing matters. And I've gone through two exercises now where I've helped rename an evangelism team to an advocacy team, not because I think it's important to me—it's a bunch of bikeshedding—but it has external implications, right? Especially evangelism, in certain parts of the world, has connotations. It's just easier to avoid those. And how we present ourselves, the titles that we choose are important.I wish we would spend way less time arguing about them, you know, advocacy has won evangelism, don't use it. DevRel, if you don't want to pick one, great. DevRel is broader umbrella. If you've got community managers, people who can't write code that do things involving your events or whatever, program managers, if they're on your team, DevRel, great description. I wish we could just settle that. Lots of wasted air discussing that one.Corey: Constantly. It feels like this is a giant distraction that detracts from the value of DevRel. Because I don't know about you, but when I pick what I want to do next in my career, the things I want to explain to people and spend that energy on are never, I want to explain what it is that I do. Like I've never liked those approaches where you have to first educate someone before they're going to be in a position where they want to become your customer.I think, honestly, that's one of the things that Datadog has gotten very right. One of the early criticisms lobbed against Datadog when it first came out was, “Oh, this is basically monitoring by Fisher-Price.” Like, “This isn't the deep-dive stuff.” Well yeah, but it turns out a lot of your buying audience are fundamentally toddlers with no visibility into what's going on. For an awful lot of what I do, I want it to be click, click, done.I am a Datadog customer for a reason. It's not because I don't have loud and angry opinions about observability; it's because I just want there to be a dashboard that I can look at and see what's working, what's not, and do I need to care about things today? And it solves that job admirably because if I have those kinds of opinions about every aspect, I'm never going to be your customer anyway, or anyone's customer. I'm going to go build my own and either launch a competitor or realize this is my what I truly love doing and go work at a company in this space, possibly yours. There's something to be said for understanding the customer journey that those customers do not look like you.And I think that's what's going on with a lot of the articulation around what developer relations is or isn't. The people on stage who go to watch someone in DevRel give a talk, do not care, by and large, what DevRel is. They care about the content that they're about to hear about, and when the first half of it is explaining what the person's job is or isn't, people lose interest. I don't even like intros at the beginning of a talk. Give me a hook. Talk for 45 seconds. Give me a story about why I should care before you tell me who you are, what your credentials are, what your job title is, who you work for. Hit me with something big upfront and then we'll figure it out from there.Brandon: Yeah, I agree with you. I give this speaking advice to people constantly. Do not get up on stage and introduce yourself. You're not a carnival hawker. You're not trying to get people to roll up and see the show.They're already sitting in the seat. You've established your credibility. If they had questions about it, they read your abstract, and then they went and checked you out on LinkedIn, right? So, get to the point; make it engaging and entertaining.Corey: I have a pet theory about what's going on in some cases where, I think, on some level, it's an outgrowth of an impostor-syndrome-like behavior, where people don't believe that they deserve to be onstage talking about things, so they start backing up their bona fides to almost reassure themselves because they don't believe that they should be up there and if they don't believe it, why would anyone else. It's the wrong approach. By holding the microphone, you inherently deserve to hold the microphone. And go ahead and tell your story. If people care enough to dig into you and who you are and well, “What is this person's background, really?” Rest assured the internet is pretty easy to use these days, people will find out. So, let them do that research if they care. If they don't, then there's an entire line of people in this world who are going to dislike you or say you're not qualified for what it is you're doing or you don't deserve it. Don't be in that line, let alone at the front of it.Brandon: So, you mentioned imposter syndrome and it got me thinking a little bit. And hopefully this doesn't offend anyone, but I kind of starting to think that imposter syndrome is in many ways invented by people to put the blame on you for something that's their fault. It's like a carbon footprint to the oil and gas industry, right? These companies can't provide you psychological safety and now they've gone and convinced you that it's your fault and that you're suffering from this syndrome, rather than the fact that they're not actually making you feel prepared and confident and ready to get up on that stage, even if it's your first time giving a talk, right?Corey: I hadn't considered it like that before. And again, I do tend to avoid straying into mental health territory on this show because I'm not an—Brandon: Yes.Corey: Expert. I'm a loud, confident white guy in tech. My failure mode is a board seat and a book deal, but I am not board-certified, let's be clear. But I think you're onto something here because early on in my career, I was very often faced with a whole lot of nebulous job description-style stuff and I was never sure if I was working on the right thing. Now that I'm at this stage of my career, and as you become more senior, you inherently find yourselves in roles, most of the time, that are themselves mired in uncertainty. That is, on some level, what seniority leads to.And that's fine, but early on in your career, not knowing if you're succeeding or failing, I got surprise-fired a number of times when I thought I was doing great. There are also times that I thought I was about to be fired on the spot and, “Come on in; shut the door.” And yeah, “Here's a raise because you're just killing it.” And it took me a few years after that point to realize, wait a minute. They were underpaying me. That's what that was, and they hope they didn't know.But it's that whole approach of just trying to understand your place in the world. Do I rock? Do I suck? And it's that constant uncertainty and unknowing. And I think companies do a terrible job, by and large, of letting people know that they're okay, they're safe, and they belong.Brandon: I completely agree. And this is why I would strongly encourage people—if you have the privilege—please do not work at a company that does not want you to bring your whole self to work, or that bans politics, or however they want to describe it. Because that's just a code word for we won't provide you psychological safety. Or if they're going to, it ends at a very hard border somewhere between work and life. And I just don't think anyone can be successful in those environments.Corey: I'm sure it's possible, but it does bias for folks who, frankly, have a tremendous amount of privilege in many respects where I mentioned about, like, I'm a white dude in tech—you are too—and when we say things, we are presumed competent and people don't argue with us by default. And that is a very easy to forget thing. Not everyone who looks like us is going to have very similar experiences. I have gotten it hilariously wrong before when I gave talks on how to wind up negotiating for salaries, for example, because well, it worked for me, what's the problem? Yeah, I basically burned that talk with fire, redid the entire thing and wound up giving it with a friend of mine who was basically everything that I am not.She was an attorney, she was a woman of color, et cetera, et cetera. And suddenly, it was a much stronger talk because it wasn't just, “How to Succeed for White Guys.” There's value in that, but you also have to be open to hearing that and acknowledging that you were born on third; you didn't hit a triple. There's a difference. And please forgive the sports metaphor. They do not sound natural coming from me.Brandon: [laugh]. I don't think I have anything more interesting to add on that topic.Corey: [laugh]. So, I really want to thank you for taking the time to speak with me today. If people want to learn more about what you're up to and how you view the world, what's the best place to find you.Brandon: So, I'm most active on Twitter at @bwest, but you know, it's a mix of things so you may or may not just get tech. Most recently, I've been posting about a—Corey: Oh, heaven forbid you bring your whole self to school.Brandon: Right? I think most recently, I've been posting about a drill press that I'm restoring. So, all kinds of fun stuff on there.Corey: I don't know it sounds kind of—wait for it—boring to me. Bud-dum-tiss.Brandon: [laugh]. [sigh]. I can't believe I missed that one.Corey: You're welcome.Brandon: Well, done. Well, done. And then I also will be hiring for a couple of developer relations folks at Datadogs soon, so if that's interesting and you like the words I say about how to do DevRel, then reach out.Corey: And you can find all of that in the show notes, of course. I want to thank you for being so generous with your time. I really appreciate it.Brandon: Hey, thank you, Corey. I'm glad that we got to catch up after all this time. And hopefully get to chat with you again sometime soon.Corey: Brandon West, team lead for developer experience and tools advocacy at Datadog. 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 along with an angry and insulting comment that is talking about how I completely misunderstand the role of developer advocacy. And somehow that rebuttal features no fewer than 400 emoji shoved into it.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.

With Amazon Redshift Serverless, all users—including data analysts, developers, and data scientists—can use Amazon Redshift to get insights from data in seconds. In this episode, Hawn sits down with Ashish Agrawal, Sr. Technical Product Manager at AWS, to chat about the newly launched Redshift Serverless. Learn about how customers can take advantage of this new serverless option to tackle various use cases in areas of machine learning, reporting and dashboarding, real time analytics, and data sharing without worrying about managing data warehouse infrastructure. Get started - https://aws.amazon.com/redshift/redshift-serverless/ Learn more -  https://aws.amazon.com/blogs/aws/amazon-redshift-serverless-now-generally-available-with-new-capabilities/ Watch the video -  https://www.youtube.com/watch?v=XcRJjXudIf8 Register for re:Inforce - https://reinforce.awsevents.com/?did=pc_card-body&trk=pc_card-body

About SheeriAfter almost 2 decades as a database administrator and award-winning thought leader, Sheeri Cabral pivoted to technical product management. Her super power of “new customer” empathy informs her presentations and explanations. Sheeri has developed unique insights into working together and planning, having survived numerous reorganizations, “best practices”, and efficiency models. Her experience is the result of having worked at everything from scrappy startups such as Guardium – later bought by IBM – to influential tech companies like Mozilla and MongoDB, to large established organizations like Salesforce.Links Referenced: Collibra: https://www.collibra.com WildAid GitHub: https://github.com/wildaid Twitter: https://twitter.com/sheeri Personal Blog: https://sheeri.org 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 by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. My guest today is Sheeri Cabral, who's a Senior Product Manager of ETL lineage at Collibra. And that is an awful lot of words that I understand approximately none of, except maybe manager. But we'll get there. The origin story has very little to do with that.I was following Sheeri on Twitter for a long time and really enjoyed the conversations that we had back and forth. And over time, I started to realize that there were a lot of things that didn't necessarily line up. And one of the more interesting and burning questions I had is, what is it you do, exactly? Because you're all over the map. First, thank you for taking the time to speak with me today. And what is it you'd say it is you do here? To quote a somewhat bizarre and aged movie now.Sheeri: Well, since your listeners are technical, I do like to match what I say with the audience. First of all, hi. Thanks for having me. I'm Sheeri Cabral. I am a product manager for technical and ETL tools and I can break that down for this technical audience. If it's not a technical audience, I might say something—like if I'm at a party, and people ask what I do—I'll say, “I'm a product manager for technical data tool.” And if they ask what a product manager does, I'll say I helped make sure that, you know, we deliver a product the customer wants. So, you know, ETL tools are tools that transform, extract, and load your data from one place to another.Corey: Like AWS Glue, but for some of them, reportedly, you don't have to pay AWS by the gigabyte-second.Sheeri: Correct. Correct. We actually have an AWS Glue technical lineage tool in beta right now. So, the technical lineage is how data flows from one place to another. So, when you're extracting, possibly transforming, and loading your data from one place to another, you're moving it around; you want to see where it goes. Why do you want to see where it goes? Glad you asked. You didn't really ask. Do you care? Do you want to know why it's important?Corey: Oh, I absolutely do. Because it's—again, people who are, like, “What do you do?” “Oh, it's boring, and you won't care.” It's like when people aren't even excited themselves about what they work on, it's always a strange dynamic. There's a sense that people aren't really invested in what they do.I'm not saying you have to have this overwhelming passion and do this in your spare time, necessarily, but you should, at least in an ideal world, like what you do enough to light up a bit when you talk about it. You very clearly do. I'm not wanting to stop you. Please continue.Sheeri: I do. I love data and I love helping people. So, technical lineage does a few things. For example, a DBA—which I used to be a DBA—can use technical lineage to predict the impact of a schema update or migration, right? So, if I'm going to change the name of this column, what uses it downstream? What's going to be affected? What scripts do I need to change? Because if the name changes other thing—you know, then I need to not get errors everywhere.And from a data governance perspective, which Collibra is data governance tool, it helps organizations see if, you know, you have private data in a source, does it remain private throughout its journey, right? So, you can take a column like email address or government ID number and see where it's used down the line, right? GDPR compliance, CCPA compliance. The CCPA is a little newer; people might not know that acronym. It's California Consumer Privacy Act.I forget what GDPR is, but it's another privacy act. It also can help the business see where data comes from so if you have technical lineage all the way down to your reports, then you know whether or not you can trust the data, right? So, you have a report and it shows salary ranges for job titles. So, where did the data come from? Did it come from a survey? Did it come from job sites? Or did it come from a government source like the IRS, right? So, now you know, like, what you get to trust the most.Corey: Wait, you can do that without a blockchain? I kid, I kid, I kid. Please don't make me talk about blockchains. No, it's important. The provenance of data, being able to establish a almost a chain-of-custody style approach for a lot of these things is extraordinarily important.Sheeri: Yep.Corey: I was always a little hazy on the whole idea of ETL until I started, you know, working with large-volume AWS bills. And it turns out that, “Well, why do you have to wind up moving and transforming all of these things?” “Oh, because in its raw form, it's complete nonsense. That's why. Thank you for asking.” It becomes a problem—Sheeri: [laugh]. Oh, I thought you're going to say because AWS has 14 different products for things, so you have to move it from one product to the other to use the features.Corey: And two of them are good. It's a wild experience.Sheeri: [laugh].Corey: But this is also something of a new career for you. You were a DBA for a long time. You're also incredibly engaging, you have a personality, you're extraordinarily creative, and that—if I can slander an entire profession for a second—does not feel like it is a common DBA trait. It's right up there with an overly creative accountant. When your accountant has done a stand-up comedy, you're watching and you're laughing and thinking, “I am going to federal prison.” It's one of those weird things that doesn't quite gel, if we're speaking purely in terms of stereotypes. What has your career been like?Sheeri: I was a nerd growing up. So, to kind of say, like, I have a personality, like, my personality is very nerdish. And I get along with other nerdy people and we have a lot of fun, but when I was younger, like, when I was, I don't know, seven or eight, one of the things I really love to do is I had a penny collection—you know, like you do—and I love to sort it by date. So, in the states anyway, we have these pennies that have the date that they were minted on it. And so, I would organize—and I probably had, like, five bucks worth a pennies.So, you're talking about 500 pennies and I would sort them and I'd be like, “Oh, this is 1969. This was 1971.” And then when I was done, I wanted to sort things more, so I would start to, like, sort them in order how shiny the pennies were. So, I think that from an early age, it was clear that I wanted to be a DBA from that sorting of my data and ordering it, but I never really had a, like, “Oh, I want to be this when I grew up.” I kind of had a stint when I was in, like, middle school where I was like, maybe I'll be a creative writer and I wasn't as creative a writer as I wanted to be, so I was like, “Ah, whatever.”And I ended up actually coming to computer science just completely through random circumstance. I wanted to do neuroscience because I thought it was completely fascinating at how the brain works and how, like, you and I are, like, 99.999—we're, like, five-nines the same except for, like, a couple of genetic, whatever. But, like, how our brain wiring right how the neuron, how the electricity flows through it—Corey: Yeah, it feels like I want to store a whole bunch of data, that's okay. I'll remember it. I'll keep it in my head. And you're, like, rolling up the sleeves and grabbing, like, the combination software package off the shelf and a scalpel. Like, “Not yet, but you're about to.” You're right, there is an interesting point of commonality on this. It comes down to almost data organization and the—Sheeri: Yeah.Corey: —relationship between data nodes if that's a fair assessment.Sheeri: Yeah. Well, so what happened was, so I went to university and in order to take introductory neuroscience, I had to take, like, chemistry, organic chemistry, biology, I was basically doing a pre-med track. And so, in the beginning of my junior year, I went to go take introductory neuroscience and I got a D-minus. And a D-minus level doesn't even count for the major. And I'm like, “Well, I want to graduate in three semesters.”And I had this—I got all my requirements done, except for the pesky little major thing. So, I was already starting to take, like, a computer science, you know, basic courses and so I kind of went whole-hog, all-in did four or five computer science courses a semester and got my degree in computer science. Because it was like math, so it kind of came a little easy to me. So taking, you know, logic courses, and you know, linear algebra courses was like, “Yeah, that's great.” And then it was the year 2000, when I got my bachelor's, the turn of the century.And my university offered a fifth-year master's degree program. And I said, I don't know who's going to look at me and say, conscious bias, unconscious bias, “She's a woman, she can't do computer science, so, like, let me just get this master's degree.” I, like, fill out a one page form, I didn't have to take a GRE. And it was the year 2000. You were around back then.You know what it was like. The jobs were like—they were handing jobs out like candy. I literally had a friend who was like, “My company”—that he founded. He's like, just come, you know, it's Monday in May—“Just start, you will just bring your resume the first day and we'll put it on file.” And I was like, no, no, I have this great opportunity to get a master's degree in one year at 25% off the cost because I got a tuition reduction or whatever for being in the program. I was like, “What could possibly go wrong in one year?”And what happened was his company didn't exist the next year, and, like, everyone was in a hiring freeze in 2001. So, it was the best decision I ever made without really knowing because I would have had a job for six months had been laid off with everyone else at the end of 2000 and… and that's it. So, that's how I became a DBA is I, you know, got a master's degree in computer science, really wanted to use databases. There weren't any database jobs in 2001, but I did get a job as a sysadmin, which we now call SREs.Corey: Well, for some of the younger folks in the audience, I do want to call out the fact that regardless of how they think we all rode dinosaurs to school, databases did absolutely exist back in that era. There's a reason that Oracle is as large as it is of a company. And it's not because people just love doing business with them, but technology was head and shoulders above everything else for a long time, to the point where people worked with them in spite of their reputation, not because of it. These days, it seems like in the database universe, you have an explosion of different options and different ways that are great at different things. The best, of course, is Route 53 or other DNS TXT records. Everything else is competing for second place on that. But no matter what it is, you're after, there are options available. This was not the case back then. It was like, you had a few options, all of them with serious drawbacks, but you had to pick your poison.Sheeri: Yeah. In fact, I learned on Postgres in university because you know, that was freely available. And you know, you'd like, “Well, why not MySQL? Isn't that kind of easier to learn?” It's like, yeah, but I went to college from '96 to 2001. MySQL 1.0 or whatever was released in '95. By the time I graduated, it was six years old.Corey: And academia is not usually the early adopter of a lot of emerging technologies like that. That's not a dig on them any because otherwise, you wind up with a major that doesn't exist by the time that the first crop of students graduates.Sheeri: Right. And they didn't have, you know, transactions. They didn't have—they barely had replication, you know? So, it wasn't a full-fledged database at the time. And then I became a MySQL DBA. But yeah, as a systems administrator, you know, we did websites, right? We did what web—are they called web administrators now? What are they called? Web admins? Webmaster?Corey: Web admins, I think that they became subsumed into sysadmins, by and large and now we call them DevOps, or SRE, which means the exact same thing except you get paid 60% more and your primary job is arguing about which one of those you're not.Sheeri: Right. Right. Like we were still separated from network operations, but database stuff that stuff and, you know, website stuff, it's stuff we all did, back when your [laugh] webmail was your Horde based on PHP and you had a database behind it. And yeah, it was fun times.Corey: I worked at a whole bunch of companies in that era. And that's where basically where I formed my early opinion of a bunch of DBA-leaning sysadmins. Like the DBA in and a lot of these companies, it was, I don't want to say toxic, but there's a reason that if I were to say, “I'm writing a memoir about a career track in tech called The Legend of Surly McBastard,” people are going to say, “Oh, is it about the DBA?” There's a reason behind this. It always felt like there was a sense of elitism and a sense of, “Well, that's not my job, so you do your job, but if anything goes even slightly wrong, it's certainly not my fault.” And to be fair, all of these fields have evolved significantly since then, but a lot of those biases that started early in our career are difficult to shake, particularly when they're unconscious.Sheeri: They are. I'd never ran into that person. Like, I never ran into anyone who—like a developer who treated me poorly because the last DBA was a jerk and whatever, but I heard a lot of stories, especially with things like granting access. In fact, I remember, my first job as an actual DBA and not as a sysadmin that also the DBA stuff was at an online gay dating site, and the CTO rage-quit. Literally yelled, stormed out of the office, slammed the door, and never came back.And a couple of weeks later, you know, we found out that the customer service guys who were in-house—and they were all guys, so I say guys although we also referred to them as ladies because it was an online gay dating site.Corey: Gals works well too, in those scenarios. “Oh, guys is unisex.” “Cool. So's ‘gals' by that theory. So gals, how we doing?” And people get very offended by that and suddenly, yeah, maybe ‘folks' is not a terrible direction to go in. I digress. Please continue.Sheeri: When they hired me, they were like, are you sure you're okay with this? I'm like, “I get it. There's, like, half-naked men posters on the wall. That's fine.” But they would call they'd be, like, “Ladies, let's go to our meeting.” And I'm like, “Do you want me also?” Because I had to ask because that was when ladies actually might not have included me because they meant, you know.Corey: I did a brief stint myself as the director of TechOps at Grindr. That was a wild experience in a variety of different ways.Sheeri: Yeah.Corey: It's over a decade ago, but it was still this… it was a very interesting experience in a bunch of ways. And still, to this day, it remains the single biggest source of InfoSec nightmares that kept me awake at night. Just because when I'm working at a bank—which I've also done—it's only money, which sounds ridiculous to say, especially if you're in a regulated profession, but here in reality where I'm talking about it, it's I'm dealing instead, with cool, this data leaks, people will die. Most of what I do is not life or death, but that was and that weighed very heavily on me.Sheeri: Yeah, there's a reason I don't work for a bank or a hospital. You know, I make mistakes. I'm human, right?Corey: There's a reason I work on databases for that exact same reason. Please, continue.Sheeri: Yeah. So, the CTO rage-quit. A couple of weeks later, the head of customer service comes to me and be like, “Can we have his spot as an admin for customer service?” And I'm like, “What do you mean?” He's like, “Well, he told us, we had, like, ten slots of permission and he was one of them so we could have have, like, nine people.”And, like, I went and looked, and they put permission in the htaccess file. So, this former CTO had just wielded his power to be like, “Nope, can't do that. Sorry, limitations.” When there weren't any. I'm like, “You could have a hundred. You want every customer service person to be an admin? Whatever. Here you go.” So, I did hear stories about that. And yeah, that's not the kind of DBA I was.Corey: No, it's the more senior you get, the less you want to have admin rights on things. But when I leave a job, like, the number one thing I want you to do is revoke my credentials. Not—Sheeri: Please.Corey: Because I'm going to do anything nefarious; because I don't want to get blamed for it. Because we have a long standing tradition in tech at a lot of places of, “Okay, something just broke. Whose fault is it? Well, who's the most recent person to leave the company? Let's blame them because they're not here to refute the character assassination and they're not going to be angling for a raise here; the rest of us are so let's see who we can throw under the bus that can't defend themselves.” Never a great plan.Sheeri: Yeah. So yeah, I mean, you know, my theory in life is I like helping. So, I liked helping developers as a DBA. I would often run workshops to be like, here's how to do an explain and find your explain plan and see if you have indexes and why isn't the database doing what you think it's supposed to do? And so, I like helping customers as a product manager, right? So…Corey: I am very interested in watching how people start drifting in a variety of different directions. It's a, you're doing product management now and it's an ETL lineage product, it is not something that is directly aligned with your previous positioning in the market. And those career transitions are always very interesting to me because there's often a mistaken belief by people in their career realizing they're doing something they don't want to do. They want to go work in a different field and there's this pervasive belief that, “Oh, time for me to go back to square one and take an entry level job.” No, you have a career. You have experience. Find the orthogonal move.Often, if that's challenging because it's too far apart, you find the half-step job that blends the thing you do now with something a lot closer, and then a year or two later, you complete the transition into that thing. But starting over from scratch, it's why would you do that? I can't quite wrap my head around jumping off the corporate ladder to go climb another one. You very clearly have done a lateral move in that direction into a career field that is surprisingly distant, at least in my view. How'd that happen?Sheeri: Yeah, so after being on call for 18 years or so, [laugh] I decided—no, I had a baby, actually. I had a baby. He was great. And then I another one. But after the first baby, I went back to work, and I was on call again. And you know, I had a good maternity leave or whatever, but you know, I had a newborn who was six, eight months old and I was getting paged.And I was like, you know, this is more exhausting than having a newborn. Like, having a baby who sleeps three hours at a time, like, in three hour chunks was less exhausting than being on call. Because when you have a baby, first of all, it's very rare that they wake up and crying in the midnight it's an emergency, right? Like they have to go to the hospital, right? Very rare. Thankfully, I never had to do it.But basically, like, as much as I had no brain cells, and sometimes I couldn't even go through this list, right: they need to be fed; they need to be comforted; they're tired, and they're crying because they're tired, right, you can't make them go to sleep, but you're like, just go to sleep—what is it—or their diaper needs changing, right? There's, like, four things. When you get that beep of that pager in the middle of the night it could be anything. It could be logs filling up disk space, you're like, “Alright, I'll rotate the logs and be done with it.” You know? It could be something you need snoozed.Corey: “Issue closed. Status, I no longer give a shit what it is.” At some point, it's one of those things where—Sheeri: Replication lag.Corey: Right.Sheeri: Not actionable.Corey: Don't get me started down that particular path. Yeah. This is the area where DBAs and my sysadmin roots started to overlap a bit. Like, as the DBA was great at data analysis, the table structure and the rest, but the backups of the thing, of course that fell to the sysadmin group. And replication lag, it's, “Okay.”“It's doing some work in the middle of the night; that's normal, and the network is fine. And why are you waking me up with things that are not actionable? Stop it.” I'm yelling at the computer at that point, not the person—Sheeri: Right,right.Corey: —to be very clear. But at some point, it's don't wake me up with trivial nonsense. If I'm getting woken up in the middle of the night, it better be a disaster. My entire business now is built around a problem that's business-hours only for that explicit reason. It's the not wanting to deal with that. And I don't envy that, but product management. That's a strange one.Sheeri: Yeah, so what happened was, I was unhappy at my job at the time, and I was like, “I need a new job.” So, I went to, like, the MySQL Slack instance because that was 2018, 2019. Very end of 2018, beginning of 2019. And I said, “I need something new.” Like, maybe a data architect, or maybe, like, a data analyst, or data scientist, which was pretty cool.And I was looking at data scientist jobs, and I was an expert MySQL DBA and it took a long time for me to be able to say, “I'm an expert,” without feeling like oh, you're just ballooning yourself up. And I was like, “No, I'm literally a world-renowned expert DBA.” Like, I just have to say it and get comfortable with it. And so, you know, I wasn't making a junior data scientist's salary. [laugh].I am the sole breadwinner for my household, so at that point, I had one kid and a husband and I was like, how do I support this family on a junior data scientist's salary when I live in the city of Boston? So, I needed something that could pay a little bit more. And a former I won't even say coworker, but colleague in the MySQL world—because is was the MySQL Slack after all—said, “I think you should come at MongoDB, be a product manager like me.”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: If I've ever said, “Hey, you should come work with me and do anything like me,” people will have the blood drain from their face. And like, “What did you just say to me? That's terrible.” Yeah, it turns out that I have very hard to explain slash predict, in some ways. It's always fun. It's always wild to go down that particular path, but, you know, here we are.Sheeri: Yeah. But I had the same question everybody else does, which was, what's a product manager? What does the product manager do? And he gave me a list of things a product manager does, which there was some stuff that I had the skills for, like, you have to talk to customers and listen to them.Well, I've done consulting. I could get yelled at; that's fine. You can tell me things are terrible and I have to fix it. I've done that. No problem with that. Then there are things like you have to give presentations about how features were okay, I can do that. I've done presentations. You know, I started the Boston MySQL Meetup group and ran it for ten years until I had a kid and foisted it off on somebody else.And then the things that I didn't have the skills in, like, running a beta program were like, “Ooh, that sounds fascinating. Tell me more.” So, I was like, “Yeah, let's do it.” And I talked to some folks, they were looking for a technical product manager for MongoDB's sharding product. And they had been looking for someone, like, insanely technical for a while, and they found me; I'm insanely technical.And so, that was great. And so, for a year, I did that at MongoDB. One of the nice things about them is that they invest in people, right? So, my manager left, the team was like, we really can't support someone who doesn't have the product management skills that we need yet because you know, I wasn't a master in a year, believe it or not. And so, they were like, “Why don't you find another department?” I was like, “Okay.”And I ended up finding a place in engineering communications, doing, like, you know, some keynote demos, doing some other projects and stuff. And then after—that was a kind of a year-long project, and after that ended, I ended up doing product management for developer relations at MongoDB. Also, this was during the pandemic, right, so this is 2019, until '21; beginning of 2019, to end of 2020, so it was, you know, three full years. You know, I kind of like woke up from the pandemic fog and I was like, “What am I doing? Do I want to really want to be a content product manager?” And I was like, “I want to get back to databases.”One of the interesting things I learned actually in looking for a job because I did it a couple of times at MongoDB because I changed departments and I was also looking externally when I did that. I had the idea when I became a product manager, I was like, “This is great because now I'm product manager for databases and so, I'm kind of leveraging that database skill and then I'll learn the product manager stuff. And then I can be a product manager for any technical product, right?”Corey: I like the idea. Of some level, it feels like the product managers likeliest to succeed at least have a grounding or baseline in the area that they're in. This gets into the age-old debate of how important is industry-specific experience? Very often you'll see a bunch of job ads just put that in as a matter of course. And for some roles, yeah, it's extremely important.For other roles it's—for example, I don't know, hypothetically, you're looking for someone to fix the AWS bill, it doesn't necessarily matter whether you're a services company, a product company, or a VC-backed company whose primary output is losing money, it doesn't matter because it's a bounded problem space and that does not transform much from company to company. Same story with sysadmin types to be very direct. But the product stuff does seem to get into that industry specific stuff.Sheeri: Yeah, and especially with tech stuff, you have to understand what your customer is saying when they're saying, “I have a problem doing X and Y,” right? The interesting part of my folly in that was that part of the time that I was looking was during the pandemic, when you know, everyone was like, “Oh, my God, it's a seller's market. If you're looking for a job, employers are chomping at the bit for you.” And I had trouble finding something because so many people were also looking for jobs, that if I went to look for something, for example, as a storage product manager, right—now, databases and storage solutions have a lot in common; databases are storage solutions, in fact; but file systems and databases have much in common—but all that they needed was one person with file system experience that had more experience than I did in storage solutions, right? And they were going to choose them over me. So, it was an interesting kind of wake-up call for me that, like, yeah, probably data and databases are going to be my niche. And that's okay because that is literally why they pay me the literal big bucks. If I'm going to go niche that I don't have 20 years of experience and they shouldn't pay me as big a bucks right?Corey: Yeah, depending on what you're doing, sure. I don't necessarily believe in the idea that well you're new to this particular type of role so we're going to basically pay you a lot less. From my perspective it's always been, like, there's a value in having a person in a role. The value to the company is X and, “Well, I have an excuse now to pay you less for that,” has never resonated with me. It's if you're not, I guess, worth—the value-added not worth being paid what the stated rate for a position is, you are probably not going to find success in that role and the role has to change. That has always been my baseline operating philosophy. Not to yell at people on this, but it's, uh, I am very tired of watching companies more or less dunk on people from a position of power.Sheeri: Yeah. And I mean, you can even take the power out of that and take, like, location-based. And yes, I understand the cost of living is different in different places, but why do people get paid differently if the value is the same? Like if I want to get a promotion, right, my company is going to be like, “Well, show me how you've added value. And we only pay your value. We don't pay because—you know, you don't just automatically get promoted after seven years, right? You have to show the value and whatever.” Which is, I believe, correct, right?And yet, there are seniority things, there are this many years experience. And you know, there's the old caveat of do you have ten years experience or do you have two years of experience five times?Corey: That is the big problem is that there has to be a sense of movement that pushes people forward. You're not the first person that I've had on the show and talked to about a 20 year career. But often, I do wind up talking to folks as I move through the world where they basically have one year of experience repeated 20 times. And as the industry continues to evolve and move on and skill sets don't keep current, in some cases, it feels like they have lost touch, on some level. And they're talking about the world that was and still is in some circles, but it's a market in long-term decline as opposed to keeping abreast of what is functionally a booming industry.Sheeri: Their skills have depreciated because they haven't learned more skills.Corey: Yeah. Tech across the board is a field where I feel like you have to constantly be learning. And there's a bit of an evolve-or-die dinosaur approach. And I have some, I do have some fallbacks on this. If I ever decide I am tired of learning and keeping up with AWS, all I have to do is go and work in an environment that uses GovCloud because that's, like, AWS five years ago.And that buys me the five years to find something else to be doing until a GovCloud catches up with the modern day of when I decided to make that decision. That's a little insulting and also very accurate for those who have found themselves in that environment. But I digress.Sheeri: No, and I find it to with myself. Like, I got to the point with MySQL where I was like, okay, great. I know MySQL back and forth. Do I want to learn all this other stuff? Literally just today, I was looking at my DMs on Twitter and somebody DMed me in May, saying, “Hi, ma'am. I am a DBA and how can I use below service: Lambda, Step Functions, DynamoDB, AWS Session Manager, and CloudWatch?”And I was like, “You know, I don't know. I have not ever used any of those technologies. And I haven't evolved my DBA skills because it's been, you know, six years since I was a DBA.” No, six years, four or five? I can't do math.Corey: Yeah. Which you think would be a limiting factor to a DBA but apparently not. One last question that [laugh] I want to ask you, before we wind up calling this a show. You've done an awful lot across the board. As you look at all of it, what is it you would say that you're the most proud of?Sheeri: Oh, great question. What I'm most proud of is my work with WildAid. So, when I was at MongoDB—I referenced a job with engineering communications, and they hired me to be a product manager because they wanted to do a collaboration with a not-for-profit and make a reference application. So, make an application using MongoDB technology and make it something that was going to be used, but people can also see it. So, we made this open-source project called o-fish.And you know, we can give GitHub links: it's github.com/wildaid, and it has—that's the organization's GitHub which we created, so it only has the o-fish projects in it. But it is a mobile and web app where governments who patrol waters, patrol, like, marine protected areas—which are like national parks but in the water, right, so they are these, you know, wildlife preserves in the water—and they make sure that people aren't doing things they shouldn't do: they're not throwing trash in the ocean, they're not taking turtles out of the Galapagos Island area, you know, things like that. And they need software to track that and do that because at the time, they were literally writing, you know, with pencil on paper, and, you know, had stacks and stacks of this paper to do data entry.And MongoDB had just bought the Realm database and had just integrated it, and so there was, you know, some great features about offline syncing that you didn't have to do; it did all the foundational plumbing for you. And then the reason though, that I'm proud of that project is not just because it's pretty freaking cool that, you know, doing something that actually makes a difference in the world and helps fight climate change and all that kind of stuff, the reason I was proud of it is I was the sole product manager. It was the first time that I'd really had sole ownership of a product and so all the mistakes were my own and the credit was my own, too. And so, it was really just a great learning experience and it turned out really well.Corey: There's a lot to be said for pitching in and helping out with good causes in a way that your skill set winds up benefitting. I found that I was a lot happier with a lot of the volunteer stuff that I did when it was instead of licking envelopes, it started being things that I had a bit of proficiency in. “Hey, can I fix your AWS bill?” It turns out as some value to certain nonprofits. You have to be at a certain scale before it makes sense, otherwise it's just easier to maybe not do it that way, but there's a lot of value to doing something that puts good back into the world. I wish more people did that.Sheeri: Yeah. And it's something to do in your off-time that you know is helping. It might feel like work, it might not feel like work, but it gives you a sense of accomplishment at the end of the day. I remember my first job, one of the interview questions was—no, it wasn't. [laugh]. It wasn't an interview question until after I was hired and they asked me the question, and then they made it an interview question.And the question was, what video games do you play? And I said, “I don't play video games. I spend all day at work staring at a computer screen. Why would I go home and spend another 12 hours till three in the morning, right—five in the morning—playing video games?” And they were like, we clearly need to change our interview questions. This was again, back when the dinosaurs roamed the earth. So, people are are culturally sensitive now.Corey: These days, people ask me, “What's your favorite video game?” My answer is, “Twitter.”Sheeri: Right. [laugh]. Exactly. It's like whack-a-mole—Corey: Yeah.Sheeri: —you know? So, for me having a tangible hobby, like, I do a lot of art, I knit, I paint, I carve stamps, I spin wool into yarn. I know that's not a metaphor for storytelling. That is I literally spin wool into yarn. And having something tangible, you work on something and you're like, “Look. It was nothing and now it's this,” is so satisfying.Corey: I really want to thank you for taking the time to speak with me today about where you've been, where you are, and where you're going, and as well as helping me put a little bit more of a human angle on Twitter, which is intensely dehumanizing at times. It turns out that 280 characters is not the best way to express the entirety of what makes someone a person. You need to use a multi-tweet thread for that. If people want to learn more about you, where can they find you?Sheeri: Oh, they can find me on Twitter. I'm @sheeri—S-H-E-E-R-I—on Twitter. And I've started to write a little bit more on my blog at sheeri.org. So hopefully, I'll continue that since I've now told people to go there.Corey: I really want to thank you again for being so generous with your time. I appreciate it.Sheeri: Thanks to you, Corey, too. You take the time to interview people, too, so I appreciate it.Corey: I do my best. Sheeri Cabral, Senior Product Manager of ETL lineage at Collibra. 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 buttons on the YouTubes, whereas if you've hated it, do exactly the same thing—like and subscribe, hit those buttons, five-star review—but also leave a ridiculous comment where we will then use an ETL pipeline to transform it into something that isn't complete bullshit.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.

About MaishMaish Saidel-Keesing is a Senior Enterprise Developer Advocate @AWS working on containers and has been working in IT for the past 20 years and with a stronger focus on cloud and automation for the past 7.He has extensive experience with AWS Cloud technologies, DevOps and Agile practices and implementations, containers, Kubernetes, virtualization and, and a number of fun things he has done along the wayHe is constantly trying to bridge the gap between Developers and Operators to allow all of us provide a better service for our customers (and not wake up from pages in the middle of the night). He is an avid practitioner of dissolving silos - educating Ops how to code and explaining to Devs what the hell is OperationsLinks Referenced: @maishsk: https://twitter.com/maishsk duckbillgroup.com: https://duckbillgroup.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 by our friends at Fortinet. Fortinet's partnership with AWS is a better-together combination that ensures your workloads on AWS are protected by best-in-class security solutions powered by comprehensive threat intelligence and more than 20 years of cybersecurity experience. Integrations with key AWS services simplify security management, ensure full visibility across environments, and provide broad protection across your workloads and applications. Visit them at AWS re:Inforce to see the latest trends in cybersecurity on July 25-26 at the Boston Convention Center. Just go over to the Fortinet booth and tell them Corey Quinn sent you and watch for the flinch. My thanks again to my friends at Fortinet.Corey: Let's face it, on-call firefighting at 2am is stressful! So there's good news and there's bad news. The bad news is that you probably can't prevent incidents from happening, but the good news is that incident.io makes incidents less stressful and a lot more valuable. incident.io is a Slack-native incident management platform that allows you to automate incident processes, focus on fixing the issues and learn from incident insights to improve site reliability and fix your vulnerabilities. Try incident.io, recover faster and sleep more.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm a cloud economist at The Duckbill Group, and that was a fun thing for me to become because when you're starting to set out to solve a problem, well, what do you call yourself? I find that if you create a job title for yourself, well, no one knows quite how to categorize you and it leads to really interesting outcomes as a result. My guest today did something very similar. Maish Saidel-Keesing is an EntReloper, or Enterprise Developer Advocate, specifically for container services at AWS. Maish, thank you for joining me.Maish: Thank you for having me on the show, Corey. It's great to be here.Corey: So, how did you wind up taking a whole bunch of words such as enterprise, developer, advocate because I feel like the way you really express seniority at big companies, almost as a display of dominance, is to have additional words in your job title, which all those words are very enterprise-y, very business-y, and very serious. And in container services to boot, which is a somewhat interesting culture, just looking at the enterprise adoption of the pattern. And then at AWS, whose entire sense of humor can be distilled down into, “That's not funny.” You have the flexibility to refer to yourself as an EntReloper in public. I love it. Is it just something you started doing? Was there, like, 18 forms of approval you had to go through to do it? How did this happen? I love it.Maish: So, no. I didn't have to go through approval, of course. Same way, you didn't call yourself a cloud economist with anybody else's approval. But I got the idea mostly from you because I love your term of coining everybody who's in developer advocacy or developer relations as a DevReloper. And specifically, the reason that I coined the term of an EntReloper—and actually looked it up on Google to see if anybody had actually used that term before, and no they haven't—it's the fact of I came into the position on the premise of trying to bring the enterprise voice of the customer into developer advocacy.When we speak about developer advocates today, most of them are the people who are the small startups, developers who write the code, and we kind of forget that there is a whole big world outside of, besides small startups, which are these big, massive, behemoth sort of enterprise companies who kind of do things differently because they've been around for many, many years; they have many, many silos inside their organizations. And it's not the most simple thing to open up your laptop, and install whatever software you want on, because some of these people don't even give you admin rights on your laptop, or you're allowed to ssh out to a computer in the cloud because also the same thing: everything is blocked by corporate firewalls where you have to put in a ticket in order to get access to the outside world. I worked in companies like that when I was—before I moved to Amazon. So, I want to bring that perspective to the table on behalf of our customers.Corey: Bias is a very funny thing. I spent the overwhelming majority of my career in small environments like you describe. To me a big company is one that has 200 people there, and it turns out that there's a whole ‘nother sense of scale that goes beyond that. And there's, like, 18 different tiers beyond. But I still bias based upon my own experiences when I talk about how I do things and how I think about things to a certain persona that closely resembles my own experiences where, “Just install this thing as a tool and it'll be great,” ignoring entirely, the very realistic fact that you've got an entire universe out there of people who are not empowered to install things on their own laptop, for example.How is developer advocacy different within enterprises than in the common case of, “We're a startup. We're going to change the world with our amazing SaaS.” Great, maybe you will. Statistically, you won't. But enterprises have different concerns, different challenges, and absolutely a different sense of scale. How is the practice of advocacy different in those environments?Maish: So, I think the fact is, mostly working on standardization from the get-go that these big enterprises want things to work in a standard way where they can control it, they can monitor it, they can log everything, they can secure it mostly, of course, the most important thing. But it's also the fact that as a developer advocate, you don't always talk to developers within the enterprise. You also have to talk to the security team and to the network team and to the business itself or the C-level to understand. And as you also probably have found out as well in your job, you connect the people with inside the business one to another, these different groups, and get them talking to each other to make these decisions together. So, we act as kind of a bridge in between the people with inside their own company where they don't really talk to each other, or don't have the right connections, or the right conduit in order for them to start that conversation and make things better for themselves.Corey: On some level, my line about developer relations, developer advocacy, has generally taken the track of, “What does that mean? Well, it means you work in marketing, but they're scared to tell you that.” Do you view what you do as being within marketing, aligned with marketing, subtly different and I'm completely wrong, et cetera, et cetera? All positions are legitimate, by the way.Maish: So, I think, at the position that I'm currently in, which is a developer advocate but for the service team, is slightly different than a marketing developer advocate. The marketing developer advocate—and we have many of them which are amazing people and doing amazing work within AWS—their job is to teach everybody about the services and the capabilities available within AWS. That is also part of my job, but I would think that is the 40% of my job. I also go on stage, I go on podcasts like this, I present at conferences, I write blog posts. I also do the kind of marketing work as well.But the other 60% of my job as a service developer advocate is to seek out the feedback, or the signals, or the sentiment from our customers, and bring that back into the service teams, into the product management, into the engineering teams. And, as I said, sit as the enterprise customer in the chair in those meetings, to voice their concerns… their opinions, how they would like the products to go, how we can make the products better. So, the 60% is mostly what we call inbound, which is taking feedback from our customers back into the service teams directly in order to have some influence on the roadmap. And 40% is the outbound work, which we do, as I said, conferences, blog posts, and things like this.Corey: I have a perception. And I am thrilled to be corrected on this because it's not backed by data; it's backed by my own biases—and some people tend to conflate the two; I strive not to—that there's a—I think the term that I heard bandied around at one point was ‘the dark matter developers.' These are folks that primarily work in .NET or Java. They work for companies that are not themselves tech companies, but rather tech is a supporting function, usually in a central IT-style organization, that supports what the business actually does, and they generally are not visible to a lot of traditional developer advocacy approaches.They, by and large, don't go to conferences, they don't go on Twitter to yell at people about things, they commit the terrible sin—according to many startup folks—of daring to view the craft of writing software as this artistic thing, and they just view it as a job and a thing to make money for—filthy casuals—as opposed to this higher calling that's changing the world. Which I think is wild take. But there are a tremendous number of people out there who do fit the profile of they show up, they do their jobs working on this stuff, they don't go to conferences, they don't go out into the community, and they just do their job and go home. The end. Is that an accurate perception? Are there large swaths of folks like that in the industry, and if so, do they centralize or congregate more around enterprises than they do around smaller companies?Maish: I think that your perception is correct. Specifically, for my experience, when I worked, for example, my first two years before I was a developer advocate, I was an enterprise solutions architect which I worked with financial institutions, which are banks, which usually have software which are older than me, which are written in languages, which are older than I am. So, there are people which, as they say, they come there to—they do their job. They're not interested in looking at Twitter, or writing blog posts, or participating in any kind of thing which is outgoing. And they just, they're there to write the code. They go home at the end of the day.They also usually don't have pagers that page them in middle of the night because that's what you have operations teams for, not developers because they're completely different entities. So, I do think your perception might be correct, yes. There are people like that when you say, these dark matter people, dark matter developers.Corey: And I don't have any particular problem. I'm not here to cast shade on anything that they're doing, to be very clear.Maish: Not at all.Corey: Everyone makes different choices and that's great. I don't think necessarily everyone should have a job that is all-consuming, that eats them alive. I wish I didn't, some days. [laugh]. The challenge I have for you then is, as an EntReloper, how do you reach folks in positions like that? Or don't you?Maish: I think the way to reach those people is to firstly, expose them to technology, expose them to the capabilities that they can use in AWS in the cloud, specifically with my position in container services, and gain their trust because that's one of the LPs in Amazon itself: customer obsession. And we work consistently in order to—with our customers to gain their trust and help them along their journey, whatever it may be. If it might be the fact, okay, I only want to write software for nine to five and go home and do everything afterwards, which most normal people do without having to worry about work, or they still want to continue working and adopt the full model of you build it, you own it; manage everything in production on their own and go into the new world of modern software, which many enterprises, unfortunately, are not all the way there yet, but hopefully, they will get there sooner than later.Corey: There's a misguided perception in many corners that you have to be able to reach everyone at all times; wherever they are, you have to be able to go there. I don't think that's true. I think that showing up and badgering people who are just trying to get a job done into, “Hey, have you heard the good word of cloud?” It's like, evangelists knocking on your door at seven o'clock in the morning on a weekend and you're trying to sleep in because the kids are somewhere else for the week. Yeah, I might be projecting a little bit on that.I think that is the wrong direction to go. And I find that being able and willing to meet people where they are is key to success on this. I'm also a big believer in the idea that in any kind of developer advocacy role, regardless whether their targets are large, small, or in my case, patently ridiculous because my company is in fact ridiculous in some ways, you have to meet them where they are. There's no choice around that. Do you find that there are very different concerns that you have to wind up addressing with your audience versus a more, “Mainstream,” quote-unquote, developer advocacy role?Maish: For the enterprise audience, they need to, I would say, relate to what we're talking to. For an example, I gave a talk a couple of weeks ago on the AWS Summit here in Tel Aviv, of how to use App Runner. So, instead of explaining to the audiences how you use the console, this is what it does, you can deploy here, this is how the deployments work, blue, green, et cetera, et cetera, I made up an imaginary company and told the story of how the three people in the startup of this company would start working using App Runner in order to make the thing more relatable, something which people can hopefully remember and understand, okay, this is something which I would do as a startup, or this is what my project, which I'm doing or starting to work on, something I can use. So, to answer your question, in two words, tell stories instead of demo products.Corey: It feels like that's a… heavy lift, in many cases, because I guess it's also partially a perception issue on my part, where I'm looking at this across the board, where I see a company that has 5000 developers working there and, like, how do you wind up getting them to adopt cloud, or adopt new practices, or change anything? It feels like it's a Herculean, impossible task. But in practice, I feel like you don't try and do all of that at once. You start with small teams, you start with specific projects, and move on. Is that directionally accurate?Maish: Completely accurate. There's no way to move a huge mothership in one direction at one time. You have to do, as you say, start small, find the projects, which are going to bring value to the company or the business, and start small with those projects and those small teams, and continue that education within the organization and help the people with your teaching or introducing them to the cloud, to help others within inside their own organization. Make them, or enable them, or empower them to become leaders within their own organization. That's what I tried to do, at least.Corey: You and I have a somewhat similar background, which is weird given that we've just spent a fair bit of time talking about how different our upbringings were in tech at scales of companies and whatnot, but we're alike in that we are both fairly crusty, old operations-side folks, sysadmins—Maish: [laugh]. Yep.Corey: —grumpy people.Maish: Grumpy old sysadmins. Yeah, exactly.Corey: Exactly. Because do you ever notice there's never a happy one? Imagine that. And DevOps was always a meeting of the development and operations, meaning everyone's unhappy. And there's a school of thought that—like, I used to think that, “Oh, this is just what we call sysadmins once they want a better title and more money, but it's still the same job.”But then I started meeting a bunch of DevOps types who had come from the exact opposite of our background, where they were software developers and then they wound up having to learn not so much how the code stuff works the way that we did, but rather how systems work, how infrastructure works. Compare and contrast those for me. Who makes, I guess, the more successful DevOps engineer when you look at it through that lens?Maish: So, I might be crucified for this on the social media from a number of people from the other side of the fence, but I have the firm belief that the people who make the best DevOps engineers—and I hate that term—but people who move DevOps initiatives or changes or transformations with organization is actually the operations people because they usually have a broader perspective of what is going on around them besides writing code. Too many times in my career, I've been burned by DNS, by a network cable, by a power outage, by somebody making a misconfiguration in the Puppet module, or whatever it might have been, somebody wrote it to deploy to 15,000 machines, whatever it may be. These are things where developers, at least my perception of what developers have been doing up until now, don't really do that. In a previous organization I used to work for, the fact was, there was a very, very clear delineation about between the operations people, and the developers who wrote the software. We had very hard times getting them into rotations for on-call, we had very hard times educating them about the fact that not every single log line has to be written to the log because it doesn't interest anybody.But from developer perspective, of course, we need that log because we need to know what's happening in the end. But there are 15, different thousand… turtles all the way down, which have implications about the number of log lines which are written into a piece of software. So, I am very much of the belief that the people that make the best DevOps engineers—if we can use that term still today—are actually people which come from an operations background because it's easier to teach them how to write code or become a programmer than the other way round of teaching a developer how to become an operations person. So, the change or the move from one direction from operations to adding the additional toil of writing software is much easier to accomplish than the other way around, from a developer learning how to run infrastructure at scale.Corey: This episode is sponsored in part 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 once believed much the same because—and it made sense coming from the background that I was in. Everyone intellectually knows that if you're having trouble with a piece of equipment, have you made sure that it's plugged in? Yes, everyone knows that intellectually. But there's something about having worked on a thing for three hours that wasn't working and only discover it wasn't plugged in, that really sears that lesson into your bones. The most confidence-inspiring thing you can ever hear from someone an operations role is, “Oh, I've seen this problem before. Here's how we fixed it.”It feels like there are no junior DevOps engineers, for lack of a better term. And for a long time, I believed that the upcoming and operational side of the world were in fact, the better DevOps types. And in the fullness of time, I think a lot of that—at least my position on it—was rooted in some level of insecurity because I didn't know how to write code and the thing that I saw happening was my job that I had done historically was eroding. Today, I don't know that it's possible to be in the operation space and not be at least basically conversant with how code works. There's a reason most of these job interviews turn into algorithm hazing.And my articulation of it was rooted, for me at least—at least in a small way—in a sense of defensiveness and wanting to validate the thing that I had done with my career that I defined myself by, I was under threat. And obviously, the thing that I do is the best thing because otherwise it's almost a tacit admission that I made poor career choices at some point. And I don't think that's true, either. But for me, at least psychologically, it was very much centered in that. And honestly, I found that the right answer for me was, in fact, neither of those two things because I have met a couple of people in my life that I would consider to be full-stack engineers.And there's a colloquialism these days, that means oh, you do front-end and back-end. Yeah. The people I'm thinking of did front-end, they did back-end, they did mobile software, they did C-level programming, they wrote their own freaking device drivers at one point. Like, they have done basically everything. And they were the sort of person you could throw any technical issue whatsoever at and get out of their way because it was going to get solved. Those people are, as it turns out, the best. Like, who does a better job developer or operations, folks? Yes. Specifically, both of those things together.Maish: Exactly.Corey: And I think that is a hard thing to talk about. I think that it's a hard—it's certainly a hard thing to find. It turns out that there's a reason that I only know two or three of those folks in the course of my entire career. They're out there, but they're really, really hard to track down.Maish: I completely agree.Corey: A challenge that I hear articulated in some cases—and while we're saying things that are going to get us yelled out on social media, let's go for the fences on this one—a concern that comes up when talking about enterprises moving to cloud is that they have a bunch of existing sysadmin types—while we're on the topic—and well, those people need to learn to work within cloud. And the reality is, in many cases that first, that's a whole new skill set that not everyone is going to be willing or able to pick up. For those who can they have just found that their market rate has effectively doubled. And that seems, on some level, to pose a significant challenge to companies undergoing this, and the larger the company, the more significant the challenge.Because it's my belief that you pay market rate for the talent you have whether you want to or not. And if companies don't increase compensation, these people will leave for things that double their income. And if they raise compensation internally, good for them, but that does have a massive drag on their budget that may not have been accounted for in a lot of the TCO analyses. How do you find that the companies you talk to wind up squaring that circle?Maish: I don't think I have a correct answer for that. I do completely agree—Corey: Oh, I'm not convinced there's a correct answer at all. I'm just trying [laugh] to figure out how to even think about it.Maish: I… have seen this as well in companies which I used to work for and companies that were customers that I have also worked with as part of my tenure in AWS. It's the fact of, when companies are trying to move to the cloud and they start upskilling their people, there's always the concern in the back of their mind of the fact, “Okay, I'm now training this person with new technology. I'm investing time, I'm investing money. And why would I do this if I know that, for example, as soon as I finish this, I'm going to have to just say, I have to pay them more because they can go somewhere else and get the same job with a better pay? So, why would we invest amount of time and resources into upscaling the people?”And these are questions which I have received and conversations which I've had with customers many times over the last two, three years. And the answer, from my perspective always, is the fact is because, number one, you're making the world a better place. Number two, you're making your employees feel more appreciated, giving them better knowledge. And if you're afraid of the fact of teaching somebody to become better is going to have negative effects on your organization then, unfortunately, you deserve to have that person leave and let them find a better job because you're not taking good care of your people. And it's sometimes hard for companies to hear that.Sometimes we get, “You know what? You're completely right.” Sometimes I don't agree with you because I need to compete there, get to the bottom line, and make sure that I stay within my budget or my TCO. But the most important thing is to have the conversation, let people hear different ideas, see how it can benefit them, not only by giving people more options to maybe leave the company, but it can actually make their whole organization a lot better in the long run.Corey: I think that you have to do right by people because reputations last a long time. Even at big companies it becomes a very slow thing to change and almost impossible to do in the short term. So, people tell stories when they feel wronged. That becomes a problem. I do want to pivot a little bit because you're not merely an EntReloper; you are an EntReloper specifically focusing on container services.Maish: Correct.Corey: Increasingly, I am viewing containers as what amounts to effectively a packaging format. That is the framework through which I am increasingly seeing. How are you seeing customers use containers? Is that directionally correct? Is it completely moonbat stuff compared to what you're seeing in the wild, or something else?Maish: I don't think it's a packaging format; I think it's more as an accelerator to enable the customers to develop in a more modern way with using twelve-factor apps with modern technology and not necessarily have their own huge, sticky, big monolith of whatever it might be, written in C# or whatever, or C++ whatever it may be, as they've been using up until now, but they now have the option and the technology and the background in order to split it up into smaller services and develop in the way that most of the modern world—or at least, the what we perceive as the modern world—is developing and creating applications today.Corey: I feel like on some level, containers were a radical change to how companies envisioned software. They definitely provide a path of modernizing things that were very tied to hardware previously. It let some companies even just leapfrog the virtualization migration that they'd been considering doing. But, on some level, I also feel like it runs counter to the ideas of DevOps, where you have development and operations working in partnership, where now it's like, welp, inside the container is a development thing and outside the container, ops problem now. It feels almost, on some level, like, it reinforces a wall. But in a lot of cultures and a lot of companies, that wall is there and there's no getting rid of it anytime soon. So, I confess that I'm conflicted on that.Maish: I think you might be right, and it depends, of course, on the company and the company culture, but what I think that companies need to do is understand that there will never be one hundred percent of people writing software that want to know one hundred percent of how the underlying infrastructure works. And the opposite direction as well: that there will never be people which maintain infrastructure and understand how computers and CPUs and memory buses and NUMA works on motherboards, that they don't need to know how to write the most beautiful enticing and wonderful software for programs, for the world. There's always going to have to be a compromise of who's going to be doing this or who's going to be doing that, and how comfortable they are with taking at least part of the responsibility of the other side into their own realm of what they should be doing. So, there's going to be a compromise on both sides, but there is some kind of divide today of separating, okay, you just write the Helm chart for your Kubernetes Pod spec, or your ECS task, or whatever task definition, whatever you would like. And don't worry about the things in the background because they're just going to magically happen in the end. But they do have to understand exactly what is happening at the background in the end because if something goes wrong, and of course, something will go wrong, eventually, one day somewhere, somehow, they're going to have to know how to take care of it.Corey: I really want to thank you for taking the time to speak with me today about, well, I guess a wide ranging variety of topics, some of which will absolutely inspire people to take to their feet—or at least their Twitter accounts—and tell us, “You know what your problem is?” And I honestly live for that. If you don't evoke that kind of reaction on some level, have you ever really had an opinion in the first place? So, I'm looking forward to that. If people want to learn more about you, your beliefs, call set beliefs misguided, et cetera, et cetera, where's the best place to find you?Maish: So, I'm on Twitter under @maishsk. I assume that will be in the [show notes 00:26:31]. I pontificate some time on technology, on cooking every now and again, on Friday before the end of the weekend, a little bit of politics, but you can find me @maishsk on Twitter. Or maishsk everywhere else social that's possible.Corey: Excellent. We will toss links to that, of course, in the [show notes 00:26:50]. Thank you so much for being so generous with your time. I appreciate it.Maish: Thank you very much, Corey. It was fun.Corey: Maish Saidel-Keesing, EntReloper of container services at AWS. 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 it, please leave a five-star review on your podcast platform of choice along with an angry comment that your 5000 enterprise developer colleagues can all pile on.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.