Podcasts about msrc

In this episode of The BlueHat Podcast, host Nic Fillingham and Wendy Zenone are joined by Dhiral Patel, Senior Security Engineer at ZoomInfo and one of MSRC's Most Valuable Researchers (MVR). Dhiral shares how a hacked Facebook account sparked his passion for ethical hacking. From web development to penetration testing, Dhiral has become a top bug hunter, landing multiple spots on the MSRC leaderboards. Dhiral reflects on his early MSRC submissions and lessons learned. He also discusses the importance of mastering web security basics, practicing on platforms like TryHackMe and Hack the Box, and staying connected with the bug bounty community.  In This Episode You Will Learn:  The importance of mastering web security basics before diving into bug bounty hunting Why hands-on platforms like TryHackMe and Hack the Box are perfect for beginners Dhiral's journey from blogging to freelancing and security research Some Questions We Ask: How do you balance competition and collaboration in the bug bounty community? Can you explain what clickjacking is and if it still works today? Why did you start with Power BI, and how did it lead to your journey in security?    Resources:      View Dhiral Patel on LinkedIn   View Wendy Zenone on LinkedIn   View Nic Fillingham on LinkedIn    Related Microsoft Podcasts:     Microsoft Threat Intelligence Podcast   Afternoon Cyber Tea with Ann Johnson   Uncovering Hidden Risks   Discover and follow other Microsoft podcasts at microsoft.com/podcasts   The BlueHat Podcast is produced by Microsoft and distributed as part of N2K media network. 

In this episode of The BlueHat Podcast, hosts Nic Fillingham and Wendy Zenone are joined by Jason Geffner, Principal Security Architect at Microsoft, to discuss his groundbreaking work on scaling and automating Dynamic Application Security Testing (DAST). Following on from his BlueHat 2024 session, and outlined in this MSRC blog post, Jason explains the key differences between DAST, SAST, and IAST, and dives into the challenges of scaling DAST at Microsoft's enterprise level, detailing how automation eliminates manual configuration and improves efficiency for web service testing.     In This Episode You Will Learn:     Overcoming the challenges of authenticated requests for DAST tools  The importance of API specs for DAST and how automation streamlines the process  Insights into how Microsoft uses DAST to protect its vast array of web services    Some Questions We Ask:    What's a lesson from this work that you can share with those without Microsoft's resources?  Can you explain what the transparent auth protocol is that you mentioned in the blog post?  How is your work reducing the manual effort needed to configure DAST system services?     Resources:       View Jason Geffner on LinkedIn    View Wendy Zenone on LinkedIn    View Nic Fillingham on LinkedIn     Related Blog Post: Scaling Dynamic Application Security Testing (DAST) | MSRC Blog  Related BlueHat Session Recording: BlueHat 2024: S10: How Microsoft is Scaling DAST     Related Microsoft Podcasts:       Microsoft Threat Intelligence Podcast    Afternoon Cyber Tea with Ann Johnson    Uncovering Hidden Risks          Discover and follow other Microsoft podcasts at microsoft.com/podcasts   

While we are on our winter publishing break, please enjoy an episode of our N2K CyberWire network show, The BlueHat Podcast by Microsoft and MSRC. See you in 2025! Yonatan Zunger, CVP of AI Safety & Security at Microsoft joins Nic Fillingham and Wendy Zenone on this week's episode of The BlueHat Podcast. Yonatan explains the distinction between generative and predictive AI, noting that while predictive AI excels in classification and recommendation, generative AI focuses on summarizing and role-playing. He highlights how generative AI's ability to process natural language and role-play has vast potential, though its applications are still emerging. He contrasts this with predictive AI's strength in handling large datasets for specific tasks. Yonatan emphasizes the importance of ethical considerations in AI development, stressing the need for continuous safety engineering and diverse perspectives to anticipate and mitigate potential failures. He provides examples of AI's positive and negative uses, illustrating the importance of designing systems that account for various scenarios and potential misuses.      In This Episode You Will Learn:       How predictive AI anticipates outcomes based on historical data  The difficulties and strategies involved in making AI systems safe and secure from misuse  How role-playing exercises help developers understand the behavior of AI systems    Some Questions We Ask:        What distinguishes predictive AI from generative AI?  Can generative AI be used to improve decision-making processes?  What is the role of unit testing and test cases in policy and AI system development?    Resources:   View Yonatan Zunger on LinkedIn      View Wendy Zenone on LinkedIn   View Nic Fillingham on LinkedIn    Related Microsoft Podcasts:     Microsoft Threat Intelligence Podcast   Afternoon Cyber Tea with Ann Johnson   Uncovering Hidden Risks       Discover and follow other Microsoft podcasts at microsoft.com/podcasts   Learn more about your ad choices. Visit megaphone.fm/adchoices

Jim Hull, Program Manager at MSRC joins Nic Fillingham and Wendy Zenone on this week's episode of The BlueHat Podcast to share insights into his role in reviewing vulnerability reports and managing cases. They dive into the submission process, detailing the types of reports accepted by MSRC and what happens after a researcher submits a potential vulnerability. The conversation also highlights the accessibility of the portal for anyone interested in identifying security issues, whether they are professionals or hobbyists. Jim explains the importance of providing clear proof of concept when submitting a vulnerability and walks through the steps MSRC takes to triage, reproduce, and resolve reports.    In This Episode You Will Learn:       Why a detailed proof of concept is essential when submitting a vulnerability  How the MSRC collaborates with engineers at Microsoft to resolve vulnerabilities  The importance of including video or image documentation to support reports    Some Questions We Ask:        What is the vulnerability triage process at MSRC?  How long does it take to fix a vulnerability after it's been reported?  Why is it important to use the researcher portal instead of email or social media?     Resources:   Microsoft Security Response Center     View Wendy Zenone on LinkedIn   View Nic Fillingham on LinkedIn    Related Microsoft Podcasts:     Microsoft Threat Intelligence Podcast   Afternoon Cyber Tea with Ann Johnson   Uncovering Hidden Risks       Discover and follow other Microsoft podcasts at microsoft.com/podcasts     The BlueHat Podcast is produced by Microsoft and distributed as part of N2K media network. 

Tom Gallagher, VP of Engineering and head of MSRC, joins Wendy Zenone and Nic Fillingham on this week's episode of The BlueHat Podcast. After nearly 25 years at Microsoft, Tom reflects on his early days at the company, where he started as a penetration tester on SharePoint, offering insights into the evolving landscape of cybersecurity since 1999. Tom shares a few different experiences from his journey, including auditing a local ISP's security in exchange for a job, and his transition from an intern working on Internet Explorer's rendering engine to key roles in Office and eventually MSRC. Through Tom's experiences, you'll gain a unique perspective on Microsoft's cybersecurity evolution and the broader industry landscape. In This Episode You Will Learn: A Clippy vulnerability that exemplifies the importance of external insights How you can support teams when they find vulnerabilities in their code Tom's experiences attending early Black Hat and DEFCON conferences Some Questions We Ask: How does your experience as a bug hunter influence your role at MSRC? Can you elaborate on the process of mitigating vulnerabilities quickly within SFI? Will you explain Trustworthy Computing and its significance in Microsoft's history? Resources: View Tom Gallagher on LinkedIn View Wendy Zenone on LinkedIn View Nic Fillingham on LinkedIn Related Microsoft Podcasts: Microsoft Threat Intelligence Podcast Afternoon Cyber Tea with Ann Johnson Uncovering Hidden Risks Discover and follow other Microsoft podcasts at microsoft.com/podcasts Hosted on Acast. See acast.com/privacy for more information.

In this episode of the Blue Security Podcast, Andy and Adam discuss two important topics: Microsoft's pledge for greater transparency in identifying and determining root causes for security vulnerabilities, and the increasing sophistication of USB malware attacks in industrial organizations. They provide insights into Microsoft's Secure Future Initiative and the importance of security in the OT and IoT networks. They also offer practical tips for strengthening USB security and data exfiltration prevention. Takeaways -Microsoft is pledging greater transparency in identifying and determining root causes for security vulnerabilities in their products and services. -The Secure Future Initiative aims to transform software development, implement new identity protections, and improve transparency and vulnerability responses. -USB malware attacks in industrial organizations are increasing in sophistication, with attackers using USB devices to establish silent residency in industrial control systems. -Organizations should strengthen USB security by blocking or allowing USB devices based on an allow list, scanning USB devices for malicious processes or files, and implementing attack surface reduction rules. -Data exfiltration prevention is crucial, and organizations should consider implementing full disk encryption, data loss prevention (DLP) rules, and sensitivity labeling to protect sensitive data. -Visibility and inventory of OT and IoT devices are essential for developing a security strategy, and solutions like Defender for IoT and OT can provide network-based security and inventory management. ----------------------------------------------------------- YouTube Video Link:⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ https://youtu.be/aveWb4fjOek⁠ ----------------------------------------------------------- Documentation: https://msrc.microsoft.com/blog/2024/04/toward-greater-transparency-adopting-the-cwe-standard-for-microsoft-cves/ https://www.honeywell.com/us/en/news/2024/04/cybersecurity-in-2024-usb-devices-continue-to-pose-major-threat https://learn.microsoft.com/en-us/defender-endpoint/configure-real-time-protection-microsoft-defender-antivirus https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction ----------------------------------------------------------- Contact Us: Website: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://bluesecuritypod.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Twitter: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/bluesecuritypod⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Linkedin: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/company/bluesecpod⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Youtube: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.youtube.com/c/BlueSecurityPodcast⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ----------------------------------------------------------- Andy Jaw Twitter: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/ajawzero⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/andyjaw/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Email: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠andy@bluesecuritypod.com⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ----------------------------------------------------------- Adam Brewer Twitter: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://twitter.com/ajbrewer⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ LinkedIn: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/adamjbrewer/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Email: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠adam@bluesecuritypod.com --- Send in a voice message: https://podcasters.spotify.com/pod/show/blue-security-podcast/message

Last week in security news: PR pushback from Microsoft, AWS Cloud Companion Guide for the CSA Cyber Trust Mark, and more!Links: My intense 2am conversation with MSRC a week before BlackHat AWS announces Cloud Companion Guide for the CSA Cyber Trust mark Securing generative AI: An introduction to the Generative AI Security Scoping Matrix

Episode sponsors: Binarly (https://binarly.io) FwHunt (https://fwhunt.run) Product security executive Kymberlee Price joins the show to gab about life in the trenches at the Microsoft Security Response Center (MSRC), the challenges of maintaining healthy hacker/vendor relationships, the harsh realities of bug-bounty programs, and thoughts on the cybersecurity job market.

Cameron Vincent, a security researcher at Microsoft, joins Nic Fillingham and Wendy Zenone on this week's episode of The BlueHat Podcast. Cameron has been one of the top researchers for both Microsoft and Google programs numerous times. He now works on the V&M team within the MSRC side, dealing with security issues internally. Cameron discusses with Nic and Wendy the importance of understanding your role and responsibilities in the workplace, the first bug he ever submitted, and his time presenting at BlueHat 2023. In This Episode You Will Learn: The benefits of face-to-face communication and how to balance it with technology. Why you should build a supportive culture of communication How to get involved in the world of bug bounty hunting Some Questions We Ask: How do you manage and deal with stress and burnout from your work? What are some practical ways to provide feedback to team members? How can we improve communication in a remote work environment? Resources: Follow Cameron Vincent on Twitter Watch Cameron speak at BlueHat 2023 View Nic Fillingham on LinkedIn View Wendy Zenone on LinkedIn Send us feedback: bluehat@microsoft.comFollow us on Twitter: @MSFTBlueHat Discover and follow other Microsoft podcasts at microsoft.com/podcasts Hosted on Acast. See acast.com/privacy for more information.

James Forshaw, a security researcher at Google's Project Zero, joins Nic Fillingham and Wendy Zenone on this week's episode of The BlueHat Podcast. James has been involved with computer hardware and software security for over ten years and has been listed as the number one researcher for MSRC, as well as being a Pwn2Own and Microsoft Mitigation Bypass bounty winner. James is also the author of the book "Attacking Network Protocols" which is available from NoStarch Press. James discusses going after logic-based bugs, his time at BlueHat 2023, and how creativity and intuition help him while hunting for new bugs. In This Episode You Will Learn: Values and benefits of writing your own tooling Why James decided on a high-level, call-to-action presentation for BlueHat 2023 The inspiration behind his new book “Attacking Network Protocols” Some Questions We Ask: Is there a sequence of events you follow when hunting for a logic vulnerability? When should someone consider writing their own tools? What advantages come to mind when writing your tooling for a new project? Resources: Watch James Forshaw at BlueHat 2023 View James Forshaw on LinkedIn View Nic Fillingham on LinkedIn View Wendy Zenone on LinkedIn Send us feedback: bluehat@microsoft.comFollow us on Twitter: @MSFTBlueHatDiscover and follow other Microsoft podcasts at microsoft.com/podcasts Hosted on Acast. See acast.com/privacy for more information.

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.

Featured Guest: Theresa Griego, MSRC, RRT-RCP To Celebrate Respiratory Care Week- October 23-30 Respiratory Care Week highlights the information we need to keep us breathing well so we can enjoy a great quality of life.   On this edition of Exhale we talked Theresa Griego who has a passionate look at Respiratory Care.  A Respiratory Professor at Tarrant County College in Fort Worth, Tx. Theresa a respiratory therapy instructor discusses heroic work on the front lines of respiratory care. Growing threats to respiratory health like COVID-19 - amid the struggle to care for an aging U.S. population. Be sure to check out her video. RT OUTLOUD Twitter- https://mobile.twitter.com/outloudrt LinkedIn-   https://www.linkedin.com/in/theresagriegomsrc/ Instagram- https://www.instagram.com/rtoutloud/?fbclid=IwAR1flpfWzyKJoZDC9cGif2rXlE-s7rPOwdyRCz2bTEccoUKex6_y383Nli4

In this AARC Perspectives episode, we talk with JJ Valdez, MSRC, RRT, RRT-ACCS, a collegiate educator with the goal of inspiring the next generation of clinicians to elevate the standard of health care. He discusses the value of using social media to engage with colleagues and help grow the profession. He also shares his tips on strengthening your social media presence.

Allen: All right, everybody, welcome passive traders. I have one of my good friends with me today, Denny is going to be here. He's going to be talking about trading life in general, and everything that he's learned along the way. Denny, you know, we've, you've been in our programs for a little bit now we've seen your success. And I'm, we're friends on Facebook. So I see you with your posts from Hawaii, sitting on a beach house and all that and we're on the coaching calls, you're always you know, you're always making me jealous. You're always like, "well, I'm going to Hawaii next week, or I'm going on vacation. I'm going golfing". I'm like, Come on, man. So I'm glad that we finally got to talk, you know, thank you for thank you for taking the time to be out here and talk with us. And I can't wait to learn from you. Denny: Okay. Well, the way I you know, the way I originally got hooked up with you is I saw one of your marketing deals on the internet. And I thought, you know, well, you know, let's give this a look. And so I talked with Cory and and I said to her, hey, look, you know, I've got I said, I'd like an honest answer that if I come in and buy the program and everything, and I've got $10,000. Is it possible for me to make $2,000 a month on the $10,000? And she said, Well, we've got people doing it. She was very honest. You know, and then so so I got in on the oil deal. One. I think it's blank check trading is that was the oil is. And boy, I learned a whole lot. The first year, I was just sailing along making money hand over fist. And that was when oil was not very volatile. And it was just making, you know, moving sideways, which is perfect for if you want to trade oil futures, you know, it's perfect. Allen: Yeah. Yeah. All markets are our friend.  Denny: And, and then all of a sudden, oil shot up. And I think it was November two years ago might have been three. Now I know I've been doing it quite a while. All of a sudden, I went in. And I looked and the market had dropped. And I and I was in a position where I was going to end up getting a margin call. So I liquidated my position was $4,700 that day, and I'll be damned the next day, boom, it pops right back up. And that was the day after Thanksgiving. And then on the next call, you talked about the Friday after Thanksgiving is not a very high volume deal. And so one big guy in there can make the market he can make it drop, you can make it rise, and I fell prey to that because I didn't know but you know, you can learn from your mistakes. And I made made plenty of them. But now I make money every month. Allen: That 4700, did that wipe you out? Denny: Out? No, no, I had 10 Okay. Okay, so I started all back over. And it took me it took me damn near a year to get it to get it back. And in the meantime, you had your program on stocks. Okay, so I signed up for that. And I fooled around with the stocks for a while and I went back to oil because to me, it's a little more passive where I can put a trade on and I will look at it once a week you know, and I feel comfortable with it. But then what happened is we got get them the next chapter Benny Alan COVID here. And my advertising agency that I own I do direct mail advertising for automotive industry. And I don't know if you've been reading but the car dealers don't have any new cars. Allen: Yeah, they don't need advertising. Denny: So, I my business the first year of COVID was down 2,000,400 and some $1,000 Right now, the second year is about 2.8 million and now we're into the third year of the car shortage and so far this year I'm down $1,976,000 From where my normal years would be so I went from a mid six figure income guaranteed down I collected my Social Security check with my wife, okay. And so I go okay, let's start fooling around with your knowledge with oil and with stock options and get yourself a little income so I took $25,000 out of our savings account and put it into my tasty works account and I make on an average trading two ETFs and oil and I just started doing spreads on weekly options in oil and that I've been doing okay on it but you got to watch that a little quicker because you'll, you can get caught up in a margin call on everything pretty quick on that. But since I have no other job, okay, I can watch it. You know, I just make sure that that when I go to the golf course on my daily trip I've got my phone with me. And I can hop in on the tasty works phone app and protect myself if I need to. But what I learned most from you was paid.. Allen: So how are you doing there? So you're like, Okay, so you Alright, so I'm following the story. Right? So you were you were learning like, you've been in our program, I think two years. So three, three, okay, three. So you learn how to do the oil you were doing great. And then you had one bad day where it crashed and you basically went back to zero and you had to start over? Right so that at least you didn't lose it you had you know you get back your gains then you know COVID hit so you had to basically all hands on deck for the business trying to figure that out. Now you're at the point where like, okay, you know what, I got this stuff that I know how to do let me see if I can make some money on the side. So you've been trading oil you've been doing you said you doing 2 ETFs. So what are you doing on? Yeah, what type I do? I do SPX and (inaudible). So what strategy are you doing on those? Okay, well, Denny: Let's go back to my educational background. Okay. Okay. I have a master's degree in Environmental Engineering. My master's thesis was the statistical modeling of dam failures due to excess runoff. Okay, so I'm a numbers guy, a numbers game, I understand standard deviations, regression lines, Bayesian coordinates, you know, all of this fancy mathematics that all of these indicators that when they write them, you know, I know how they get there. So I started looking at the stuff and I started looking for patterns, because standard deviation and stuff like that is nothing other than patterns, okay, that create a probability statement of the same thing occurring, okay. So, I started looking and I found the correlation between the VIX that, you know, on the CMOE, right, the VIX, right? And what happens with it? And so, I take the VIX and say it was it traded at 2588 and open this morning at 2588. I can't I can't remember exactly what it is. I go in, and I divide the VIX by 16. Now, why do I divide by 16? Allen: I have no idea. Denny: There are 256 trading days in the market. Right? The square root of 256 is 16. Okay. So I take the 68 divided by 16. And that gives me a percentage that's 87% accurate as to the upward or downward movement of SPX or rut on a daily basis. From what it opens that not what it closed that yesterday. But when the opening bell dings like, this morning, yesterday, right? Close to 1806. Okay. But this morning, when the bell rang, it was 1843 just for a short period of time until the CPI stuff caught up in the rear end dropped out of it. Okay, right. But so what I do is I go in and take what it opens at, and take the percentage and what it opens at, say it's one point it was 1.61 today, so you take 1.61% of the opening bell, and you subtract that from what it opened that and you add it to what it opened that and you gives you a high and a low rate. Okay? Allen: Say that again, do make doing so. Okay. The VIX divided by 16. Okay, then what do you do that? Denny: Okay, you multiply that the 1.61% Okay? Times when it opened that, okay, and that comes out to roughly what, close to 30 bucks. I don't have my calculator here. Okay. So you would take, you would take it and if it opened at 1843, you take the 30 off of that, that would be 1813. And then you take the 1843 and add the 32, which would be 1873. So that means that you've got an 87 point something percent chance that the right is going to close somewhere between the 1813 and 1873. Okay, okay, so now, we wait until the Between 1030 and 11 o'clock central time, okay. And the reason that I wait until then, is if you look, the market goes in and opens it bounces up and down. And if it's on the way up between 1030 and 11 o'clock you have what what usually happens and happens most days is a mid morning reversal of some sort where people are in taking profits or, or getting rid of losses. So okay. And at that point, it gives you a direction of the momentum of the market for the rest of the day. And the rest of the day barring no news or anything, it pretty much goes sideways or slightly up or slightly down. And I go in and sell a put put spread or a call spread at the bottom or the top that was ranges away from the way the momentum of the markets going. And I do that on a daily basis. Allen: So if you think is going down you sell calls if you think it's going up you sell puts at the end of that range. So is that like you said 87% So what is that like as like one and a half standard deviation?  Denny: One and a half standard deviations?  Allen: Okay. All right. But but why do you do the VIX because what does the VIX have to do with the rut? The VIX is based on the VIX, SPX the VIX Denny: Gives you the volatility, the market as a whole. Allen: Right. But it has to do with the volatility of the SPX, the RUT has its own.. Denny: Okay, okay. But the RUT is based on 2000 stocks, okay. And vix takes into account the volatility of what's happening in the 2000 stocks, the Dow Jones and the standards and poors. The way they calculate the bets, Allen: Okay, because I thought the VIX was just only on the SPX the 500. The large ones. Denny: Yeah, yeah. Well, but it is, but they just weren't right. There's yeah, there's a there's a correlation between what's happening in SPX and what happens in RUT. Okay. Allen: Yeah, they're, yeah, okay. Right. They are correlated. So it just it just happened correlated workout, right?  Denny: And it's just and it's just like if you want to see what's going on with gonna happen for disaster time, with the SPX. Go in and look at what's going on with QQQ. If QQQ is dropping, you better watch yourself on the SPX, with about, I forget what percentage of the SPX is Fang stocks now? Right? Yeah. Okay. Allen: So how long? How long have you been doing this? Denny: I've been doing for about four months. Allen: Four months. Okay. And you back tested it? Denny: Yeah. Oh, yeah. I spent a couple, couple $100 and got some good back testing software and back tested it. And if you go through the thing and wins about 80 some percent of the time, okay. Allen: And how much are you trying to make on each trade? Denny: Okay, I'm trying to make 4% Three and a half to 4% on a trade, okay. Allen: And these are weekly trades or daily trades daily. So you want the SPX, Denny: The SPX, the SPX has a closing every day. Okay, Allen: So these are at the close. Yes. Okay. Denny: And the rut has Monday, Wednesday and Friday. So I only trade the rut on Monday, Wednesday and Friday. Allen: Cool. So now your results been so far? Denny: That I'm doubling my money every month. Allen: Wow. 100% every month? Denny:  When Putin cut the pipeline off, okay. And the market and the rear end fell out of the market that day. I was at my computer when it started happening. And I closed everything out. If if I hadn't closed it out, I probably would have lost about three or 4000 that day, but I don't you know, what I do, Allen is I take a future value calculator, okay. And if this month, I want to make $10,000. I plug in $10,000. And I put three and a half percent of $10,000 times 21 or 22 trading days. And I print it out. And it tells me how much I need to make each day in order for that to occur. And then I keep a spreadsheet that I'm plus or minus off of the predicted number that I was supposed to be asked. And I adjust my trading from there now like right now for this month. So far. I'm up 900 bucks as a closing day. So I'm actually today is the 13th. Yeah, and I'm actually to where the tweet where I should be on the 20th of them. month. Okay, so if I think the markets going to be a little volatile or, or there might be some bad news coming, I can lay off, okay, and skip a day and see what's happening. Okay. That's where what you taught me is the patience. Is that it? You don't have to do it every day. Allen: Right? Right. So okay, so you're saying that you're doubling to 25? Every every month or no, Denny: Not doubling how much I want to make God, I got 25 in there, but you're trying to make you want to make if I want to make 10 This month, I put 10 up. And with the whole idea that I'm could lose all 10,000 of it. Allen: Okay so you're only using 10. Denny: Yeah, but I'm only using 10. If I lose, I lose the 10 then, you know, I'm a big boy. You know, we try again next month. Allen: So like, today's the 13th, you're only up 900. So you still got a ways to go before you get to the goal. Denny: No, no, I'm up 900 over how much I should be up. Allen: So you've already made the 10. And you made another 900? Denny: No, no, no, no. Oh, hold on a second. Okay. Okay, I started out, okay, with 10,000 in the account, okay. And I go to a future value calculator and I plug in, say three and a half percent. Okay. And I plug in 21 days, okay. Yeah. Well, that'll, at the end of the month, if I do that I shouldn't have around $21,000. Okay. And what the future value calculator says is that on day two, I should have 10,300 and some dollars on it. Okay, and then day three, I should have close to 10 Seven. Okay. So I go down what the day is what it says where I should be to achieve the deal. And I'm up 900 Okay, over that. Allen: I say okay, okay. Okay, so you're on pace. You're better you're better than doing on pace to double Denny: Yeah, right. I'm, yeah, I do what's called a phase and betting deal. Okay. Yeah. And so.. Allen: So that's what you're doing on the SPX on the RUT, and you're also doing oil. So how do you put in oil? Denny: I don't know oil, I buy maybe two to three contracts okay of the weeklies now, okay, and do a credit spread on them and try to make, you know, 4 or 500 bucks on the credit spreads and let them expire worthless. Okay. And, and then and the only and I'm only trying that because I know how to make money doing the monthlies and, and getting in at 45 days and, and monitoring it. So I'm a natural born tanker. Okay. Right. And, and, and it can cost me money at times. Okay. But, you know, I guess I'm fortunate that I'm not looking where my next meal is coming from. Allen: Right. Cool. So like today, you know, we have SPX is down 4.3% Today, big moves, they move down. So I'm assuming based on what you said, when you got in on SPX had already started moving down, so you sold calls today? Denny: Yeah, I sold calls I sold about 4090 and 4095. Allen: Okay, and then basically, you didn't have any trouble today? Denny: No and yesterday, yesterday went up. Okay. But when I went when I entered it, it was going sideways. And it was more advantageous on the calls yesterday. So I sold 4185 and 4190 yesterday, okay. And, you know, they they expired worthless okay. Allen: And is there any time you do both puts and calls? Denny: Yes. Yep. It looks like it's going absolutely sideways. Like I say, enter my trade between 1030 and 11. And I usually go to the golf course about one o'clock. But before I go to the golf course, I pull my account up and I look at it and the pit looks like it's going sideways. Then I create an iron condor and I go in and sell puts. Allen: And then what about a stoploss you have any? Denny: Yeah, I put stop losses in on everything. Allen: What percent? Like how do you know when to get out? Denny: I put 40% Okay. Allen: So 40% loss. Denny: Yeah. Allen: Okay. Cool. And so you're pretty happy with that? Denny: Yeah, you know, until it burns me I guess I will you know, I'm waiting. I'm waiting for it. I'm you know, I've done this long enough now that I know that nothing is failsafe. Allen: No, but you're doing this in a time that it is pretty volatile. You know? I mean vix today was at 27. But yeah, even so the VIX is kind of low for what's going on and all the stuff that's happening with the Fed. And, you know, we're still in a bear market. So we're still getting these wild bull market, not not a bull market rally, but a, like a whipsaw rally to go up, and then we, we hit back down on a dime. And so it still it has been very up in Downy and so well, having a you know, the strategy that you're just like, hey, I'm not gonna, I'm just gonna play day by day and not worry about at night. I think that makes a lot of sense. Denny: Yeah. You know, and, you know, I am a very, very avid reader. Okay, so I read Barron's, I read the bestsellers, Business Daily, and stuff like that, not because I think that they are going to enlighten me on anything. But what I have read is, there's a lot of guys in there that tell us about the history of the market. Okay. And for every bear market, you know, usually lasts nine to 18 months. And there's usually four to five mini rallies in there that everyone is calling the bottom of the bear market, and then it drops again, you know, and so, if we understand that, you don't get too overly enthused with the rising SPX or a Dow. Allen: Yeah, yeah. It's, I mean, that comes with experience or like you said, you know, learning and education. Cool. So what do you see going forward? Like, what's, what's next for you? Denny: Man? You know, I just enjoy doing this stuff. You know, I mean, you know, I'm in the twilight twilight of my life. You know, I'm 76 years old. Man. I'm a real young 76. I mean, I'm very mobile. I play, play golf every day. Right now, while we're speaking. I'm in Duncanville, Texas at my grandson's tennis match. He just, he just won his doubles match. And so about a half hour he'll start playing singles. So we'll watch that but.. Allen: Yeah it's a little how, I tell you that. Denny: Yeah, 95 right now here but you know, my normal week is yesterday was Monday I was in junior high volleyball and Flower Mound, which is 30 miles away from where we live. But today I'm at varsity tennis in Duncanville. That's not bad. That's close to where I live. Tomorrow. I got off then Thursday. I got junior varsity tennis. That's a home meet. And then Friday night, I've got got varsity football and Flower Mound. Okay. That's almost every day of the week. I'm doing something with the grandkids. Allen: You're going golfing every day and you're still trading every day? Denny: Yeah, and I'm trading every day. No, and you know, thanks to you. You've shown me ways that I don't have to sit there and stare at a computer. To make money. Allen: Yeah, yeah. Yeah. No, that's not the I really like what you're doing. I like your style. You know, it's like, okay, you know, put a trade on, let it work, and then go enjoy my life. Denny: Yeah. Doesn't work. So what, you know, there's another day. Allen: Yeah, but the return is good enough that, you know, you get compensated, even if there are losses, the you're, you're playing with bigger numbers. So it's like, hey, if I can make 100%, then yeah, I can lose 20, 30, 40%. That's okay. Yes. Because I can still make much more than that, you know, in the stock market. They're like, Oh, wait, you know, you shouldn't lose more than five or 10% of your account? Well, you're only making 10% a year. So obviously, you don't want to lose more than that. But if the numbers are bigger than you can take bigger, bigger, bigger bumps, so.. Denny: And I'll tell you, I'll tell you what I use I still I still use your option trading Google Spreadsheet. Allen: For the credit spreads, yeah. Denny: Yeah, I use it every day. Allen: Yep, makes it simple, right? Just calculate Yeah. Denny: The only thing is I went in and change changed the 25% to 40%. Allen: But I like it because it's like simple, you know, and I'm sure people listening to this. They're gonna be like, Okay, what do I do again? So it's like, just gonna recap. You know, you wake up in the morning, you see where the SPX and the RUT are opening, right? Yeah, take a look at the VIX. You divided by 16 and then you add that.. Denny: That's your that's your percentage movement in the ETL. Okay, that's Allen: A percentage move of the SPS. Okay. So you multiply that percentage by the open. By the Open, and then that you find your range. Denny: That will give you the that'll give you the movement, which, so say it's 1843 and say, say your your divide by say, say it's say VIX is 32. Okay, okay. Okay, you divide by 16. That's two to 2%. Okay, so say.. Allen: Okay that's percentage. Okay, yeah. Denny: 2%. So say right, opened at 1800. Today, you take 2%, that's $36. So then you take 36 off of 1800. Okay. And, you know, that puts you down to 1764. And then you add 36 to the 1800. And that gives you 1836 yeah. Allen: We have a 87% probability of this range working out for the day, it's not for the month, whatever it is for the day. And that works out to be about 1.5 standard deviations. So we've got the range, that's about one and a half standard deviations, that's 87% probability about that. And for you, it's been working pretty good. And you set it at a 40% stop loss. Oh, and then the other thing is that you get into the trade about an hour and a half an hour, hour and a half after the market opens. And so.. Denny: And the reason of the hour, hour and a half is it took me a while to realize this, the market tends to at times gap up or gap down. Okay. And then about an hour to an hour and a half later, it kind of self corrects itself. Allen: Sometimes that Yeah, yeah. But they say, you know, the opening bell is usually amateur hour. And so yeah, I mean, I could have told you that I don't trade the first hour of the day, you know, markets open markets open about 8:30 here Central time, so I don't trade before 10 o'clock, which is exactly an hour and a half. So I do that.. Denny: Yeah, that's when I'm looking at the momentum indicators and everything.  Allen: And then you let your trades expire? Denny: Yes. Allen: Okay. So you got that going on. And then.. Denny: Well the good thing about it is trades good, you can't get out of it anyway, because you've made all your money by about two o'clock and go in and try to close the trades. It says that say you get the message just some of the bid ask or zero. Allen: So, okay, so you got that going on. And you got the oil, weeklies gone. So that keeps you busy. That keeps you diversified. You're making decent amount. You're happy. That's awesome. I love it. That's that's what this is all about, you know, Denny: Keeps going to Hawaii. Yeah. You know, Allen: Yeah life is good, right? You're hanging out with grandkids you got you still have the house in Hawaii, you go on vacations, everyone, wherever you feel like it. So I like it.. Denny: In two weeks. I'll be in New York City. Allen: That's great. Cool.  Denny: Going to see Billy Joel at Madison Square Garden. Allen: Very nice. So did you do any kind of trading before you came across us? Denny: Yes. And I lost my rear end. Allen: Oh, no, that's not good. Yeah. Denny: I was way too aggressive. Okay, and not patient. And that's when I was gonna get out of the equity market completely. When I saw your oil deal, okay. And, you know, and I figured I had a better chance at oil, because it's something that we all need. And it's something that's not going out of style. Even if we go to all electric cars. What people don't understand is that two thirds of the pharmaceuticals and all of the plastic comes tomorrow. And that's none that's going away. Nope. There's going to be a demand. Allen: Yeah. In fact, you know, even with everything with the more solar and the more wind power they bring on, the world is still using more oil now than we have, like 10 years ago, the demand continues to increase, just goes up and up and up every year. So yeah, it's not going anywhere, anytime soon. So we're going to continue to trade even if demand starts going down. It's such a big market that we'll be trading oil for, you know, for the next 20-30 years.  Denny: Yeah Allen: That's, I mean, it's a different so basically, the you are trading equities but then when you found out and you learn about how we sell options, that kind of really flipped the switch?  Denny: Yeah that intrigued me. Okay. First of all well, my background before I got into the advertising thing was I owned a car dealership. Okay, I owned a Ford dealership. If you know anything about car, guys, we're super aggressive and we love leverage. And when I saw options, and I saw the leverage available, I said, this is my ticket. Allen: So then, why are we still at 25,000? Why don't we go more? Denny: You know, I've got a, I've got a wife. Okay, that funny story, okay? All donations came in and bought me out. I guess it's 28 years ago now. And I got a very sizable check. And the day I got that check, my wife reached over and she grabbed that check. And she said, seed money only comes once in a lifetime. And this is going for our old age and for fun. I go, Okay. Well, one of the ways that I've stayed married 52 years, is that I always get the last word. "Yes, dear". So, she, in the money, she basically watches it, okay. And, and she thinks that, you know, a lot of what I'm doing, although I'm making money and stuff like that, on on a basis is a little bit too risky for her, her deal. And so that, you know, that's what she has given me to play with. Okay. Consequently, I have pointed out to her recently, that because of that money, she's not had to buy any groceries out of her retirement account. For her Social Security check. I played for all the plane tickets wherever we go. This trip to New York. I've got $1,000 in Hamilton tickets invested. And she didn't have to pay for any of that. So don't you think it's about time that we started looking at adding more to that, you know, so that I think by the end of the year, she might, you know, lead me forward a little bit more. Allen: Do you have other investments and stuff elsewhere? Yeah, yeah, money's coming in. So it's not like you need this to live off of   Denny: No, no, no, no. Man, like, it's like I said that when my COVID that stopped an annual mid six figure income. I mean, on a normal week, before COVID. I was, well, on a normal month, I was doing 800,000 to 1 million pieces of direct mail a month. But that so you know, it's a good sized business, okay. With annual revenues, anywhere from two and a half to three $3 million. And, and I'm a one man show. I have no employees in that business. You know.   Allen: So it's still running, you still run that business? Yeah.   Denny: Yeah. In fact, I just got a job today. I mean, you know, they're, they're doing  infrequent, you know, I mean, you know, I might have made 30,000 bucks for the whole year doing that, you know, which, you know, that used to be a week sometimes, you know,   Allen: You know, so let me ask you this. Are we going to see below MSRP prices anytime soon?   Denny: No, no, no.   Allen: How about MSRC? Like, I'm seeing prices that are like way above like, double MSRP. Yeah, I'm not paying.   Denny: As soon as the chip shortage is alleviated, and they start to get inventory sometime in the next 18 to 24 months. They'll have inventory again. Oh, wow. But I don't know if you've seen what's happened to the used car market?   Allen: No, it's taken off like crazy.    Denny: Yeah, I mean, you know, my wife has macular degeneration now. And so, leasing a car is unless you have a business purpose. leasing a car is a bad investment. Okay. My wife had macular degeneration, we didn't know if she was going to, they were going to be able to get it stopped and whether she was going to be able to continue to drive. So the car that I'm sitting in right now is her car. Okay. And we leased it, and it had a $21,000 residual on it at the end of the lease period. And we were, you know, we were gonna turn it in. And then I pulled up what the value on it was, the retail value on this car was 31,000. So I went down to the Ford dealership, and broken but check for the car. And they can't want me to lease another one. I know. Thank you, you know, and so and that's happened all throughout the industry. And it's consequently forced the US car prices way up. And so what's going to happen two fold things going to happen. Matt, real quick, I know that you know, either way saw your day on this, but this is interesting. Once the inventory, get levels get up, all these car dealers that have these massive use car inventories are going to have so much water in their inventory. And water is excess pricing to what the current market book value on the vehicles is. In other words, if you can't sell it for what you own it for, you're gonna lose money. Right? And, and a lot of these big-- you live in Houston, I live in Dallas, a lot of these big dealerships that have two and 300 guards in the ground, are going to have a million and a half to $2 million in water in their inventory. And they're going to have to get rid of them. Okay. And so the rear end will fall out of the used car market. And you know, so right now consumers are getting screwed on automobiles. But the dealer has his day of reckoning coming due.   Allen: Yeah, but if you need a car now, you're screwed.   Denny: You need a car now you're in trouble. A buddy of mine went looked at a Subaru Outback with 19,000 miles on it, that it was a year and a half old. And they wanted $35,000 for it.  Allen: Yeah, yeah, don't get in a wreck. I mean, my car I've been thinking about my wife is like, can you just get a new car, please? I'm like, No, I like it. You know, I'm trying to get it up to 200,000. You know, miles on it. Yeah, trying to get there. I mean, it's fine. It works. You know? It's comfortable. It looks fine. From the outside. Everything is comfortable. It works. You know, it's nice Toyota keeps running. But she's like, can you get some bigger? I'm like, Alright, so we looked around, and I'm like, Man, I don't want to pay this stuff. You know, it's not even. It's not like we can't afford the payment or anything. It's just from where it used to be to where it is. Now. There's no difference. The car is the same. You just charged me a whole lot more for no reason. Just because yeah, there's a you can. So yeah, yeah, no, I don't want to play that. Denny: Yeah, their day of reckoning is coming.  Allen: We'll be alright. Well, do you have any advice for our listeners, people that are learning and trying to figure out like you found your way, right, you found your niche in trading, and it took you I don't know how many years you were trading for two years. But how many years? Were you looking before? Before that? Denny: Oh five years, I probably probably five years before I found you. Okay. And two years, two years of.. Allen: Learning and testing Denny: Not doing what you told me to do. And getting and getting burned, to realize, to realize that the things that you teach patients, you know, just the little thing and Think or Swim your standard deviation deal, you know, saying, Oh, you've got a red line there. That's not good. You know, just those little things, you know. So the biggest advice, the best advice I could give to an individual, be patient. Don't try to hit homeruns. You know, the age old adage, pigs get fat, hogs get slaughtered, is so true. It's like one of my rules on the SPX. You know, a $5 spread. Okay, a $5 spreads on the SPX is 500 bucks. Okay. So if I'm trying to make 4% to 5% a day, that means I'm looking to get 20 cents. On my credit spread. That's it 20 cents. Okay. And if you look at what the delta is on that, it's usually 12 to 13, which puts me in a real advantageous position. You know, so don't get greedy. Just let time be. let time be your friend. Allen: Right? Yep. And that actually might be a shortcut for you. So you don't even have to worry about the VIX. You just go in to get the 12 Delta.  Denny: I'm in the process of doing about a year study on this, okay. Because I back tested it using the Delta. Okay. And some wild market swings, it comes out that it doesn't work out. Right. Okay. Yeah. Allen: But the thing is, it's hard to back test it because you're saying that you go in after looking at it visually and being like, Okay, I want to be on this side or I want to be on that side. You can't do that. Unless you do it manually yourself with a like a software that I like the one I use where you got to go in day by day by day. If you're one of those programs where you just put in the numbers and you Just let it run, it doesn't work. Denny: You've got to plug them in yourself. Yeah. And it's time consuming. Especially if you're doing dailies. Yeah. Because you got you got 256 for every year. Allen: Yeah. And I mean, like, you know, when we when we back test a new strategy, it's like I want to I want you know, a good 10 years of data, you know, I want to see the the ups and the downs and the flats and the recessions and the bulls market and everything. I want to know that it's going to work long term, not just for a couple because I've been burned on that too. You know, I, I back tested different strategies like the butterfly on McDonald's and a butterfly on a Walmart and they worked great for five years. For five years, they made money. I went in there with guns blazing. You know, I took like every money out of money I had at the time at $25,000 on one trade, just want Dre put it all and boom, blew up. And I'm like, what happened? Oh, my God, man. It was a fluke. I'm gonna do it again. Next month, next month, boom, blew up again. You know.. Denny: Those butterflies and iron condors look great. You sit there and you look at the leverage you've got on that you go, Whoa, you know, but you know, you got to think, why isn't everyone doing it? There's a reason. Allen: So, there's lots of little tweaks behind it. Yeah, yeah. This has been fun. Denny, I'm gonna let you go. I appreciate you. And if there's anything you need, please reach out to us. We're always here for you. And thank you for sharing your wisdom. Denny: Okay, well, you know, I mean, I just want to tell you and your listeners that your program has definitely taught me a lot and made me a lot successful. Faster than I ever would have been. Allen: That's awesome. That's good to hear. Make my day. I love it. I love it. JOIN OUR FREE PRIVATE FACEBOOK GROUP: https://optiongenius.com/alliance  Like our show? Please leave us a review here - even one sentence helps. Thank you!

There is no one bigger game changer in the world than technology and its uptake in every aspect of our lives including our collective future. Cybersecurity has become the top priority across the board. There is need for informed cybersecurity investments that consider sustainability, responsible data usage, being prepared for any crisis and being resilient. We have to enable a culture of responsible innovation that takes holistic considerations for the people, process and technologies and drive a responsible mindset. We will talk about boundary considerations when it comes to data use, adversary threats, impact on environment, user behaviors and how we can help as cybersecurity professionals. The goal is to build the highways for the future with a holistic approach and principles that enables fearless harnessing of the global compute platform, enabling profound technological growth for the next generation. About the speaker: Abhilasha Bhargav-Spantzel is a Partner Security Architect at Microsoft. She is responsible for monitoring and coverage architecture for Microsoft Security Response Center (MSRC). MSRC is the front-line defense for millions of customers around the world who use Microsoft platforms and products. Previously she was at Intel for 14 years, focusing on hardware-based security product architecture. She completed her doctorate from Purdue University, which focused on identity and privacy protection using cryptography and biometrics. Abhilasha drives thought leadership and the future evolution of cybersecurity platforms through innovation, architecture, and education. She has given numerous talks at conferences and universities as part of distinguished lecture series and workshops. She has written 5 book chapters and 30+ ACM and IEEE articles and has 35+ patents. Abhilasha leads multiple D&I and actively drives the retention and development of women in technology. She is passionate about STEM K-12 cybersecurity education initiatives, as well as co-organizes regular camps and workshops for the same. Sonnie Ebikwo is a Principal Program Manager at Microsoft where he works on strategies to deliver a high bar of security capabilities and productivity for Microsoft and Stakeholders. He is a highly knowledgeable professional, credited with over 27-years of progressive experiences in both the private and public sectors where he developed strong functional background in various industries ranging from Cybersecurity, Telecom, US Government, Real Estate, Transportation and the Service Industry. Prior to joining Microsoft, he served as a Senior Technical Program Manager and Availability Zone Owner of the largest cluster of Data Centers with the largest customer base within the AWS Data Center Supply Delivery Infrastructure. In this role, he led complex cross functional teams to deliver data center supply through shell, room and infill opportunities including direct responsibility for overall short- and longer-term health of the AZ. Sonnie holds a distinguished formal and extensive education with a master's in planning from the University of Texas at Arlington and completed the senior executive leadership development training at the UChicago Booth School of Business in 2013. He is a certified Project Management Professional (PMP-2003), Certified Scrum Master and a Certified Scrum Product Owner.

About ShirShir Tamari is the Head of Research of Wiz, the cloud security company. He is an experienced security and technology researcher specializing in vulnerability research and practical hacking. In the past, he served as a consultant to a variety of security companies in the fields of research, development and product.About SagiSagi Tzadik is a security researcher in the Wiz Research Team. Sagi specializes in research and exploitation of web applications vulnerabilities, as well as network security and protocols. He is also a Game-Hacking and Reverse-Engineering enthusiast.About NirNir Ohfeld is a security researcher from Israel. Nir currently does cloud-related security research at Wiz. Nir specializes in the exploitation of web applications, application security and in finding vulnerabilities in complex high-level systems.Links: Wiz: https://www.wiz.io Cloud CVE Slack channel: https://cloud-cve-db.slack.com/join/shared_invite/zt-y38smqmo-V~d4hEr_stQErVCNx1OkMA Wiz Blog: https://wiz.io/blog Twitter: https://twitter.com/wiz_io TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Redis, the company behind the incredibly popular open source database that is not the bind DNS server. If you're tired of managing open source Redis on your own, or you're using one of the vanilla cloud caching services, these folks have you covered with the go to manage Redis service for global caching and primary database capabilities; Redis Enterprise. To learn more and deploy not only a cache but a single operational data platform for one Redis experience, visit redis.com/hero. Thats r-e-d-i-s.com/hero. And my thanks to my friends at Redis for sponsoring my ridiculous non-sense.  Corey: This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So, the idea being that you can run stateless things without having to worry about scaling, placement, et cetera, and the rest. They claim significant cost savings, and they're able to wind up taking what you're running as it is in AWS with no changes, and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them, so that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem and they get out there in public and say, “We're solving a problem,” it's very hard to snark about that. Multus Medical, Construx.ai and Stax have seen significant results by using them. And it's worth exploring. So, if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or batch, consider checking them out. Visit risingcloud.com/benefits. That's risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. One of the joyful parts of working with cloud computing is that you get to put a whole lot of things you don't want to deal with onto the shoulders of the cloud provider you're doing business with—or cloud providers as the case may be, if you fallen down the multi-cloud well. One of those things is often significant aspects of security. And that's great, right, until it isn't. Today, I'm joined by not one guest, but rather three coming to us from Wiz, which I originally started off believing was, oh, it's a small cybersecurity research group. But they're far more than that. Thank you for joining me, and could you please introduce yourself?Shir: Yes, thank you, Corey. My name is Shir, Shir Tamari. I lead the security research team at Wiz. I working in the company for the past year. I'm working with these two nice teammates.Nir: Hi, my name is Nir Ohfield,. I'm a security researcher at the Wiz research team. I've also been working for the Wiz research team for the last year. And yeah.Sagi: I'm Sagi, Sagi Tzadik. I also work for the Wiz research team for the last six months.Corey: I want to thank you for joining me. You folks really burst onto the scene earlier this year, when I suddenly started seeing your name come up an awful lot. And it brought me back to my childhood where there was an electronics store called Nobody Beats the Wiz. It was more or less a version of Fry's on a different coast, and they went out of business and oh, good. We're going back in time. And suddenly it felt like I was going back in time in a different light because you had a number of high profile vulnerabilities that you had discovered, specifically in the realm of Microsoft Azure. The two that leap to mind the most readily for me are ChaosDB and the OMIGOD exploits. There was a third as well, but why don't you tell me, in your own words, what it is that you discovered and how that played out?Shir: We, sort of, found the vulnerabilities in Microsoft Azure. We did report multiple vulnerabilities also in GCP, and AWS. We had multiple vulnerabilities in AWS [unintelligible 00:02:42] cross-account. It was a cross-account access to other tenants; it just was much less severe than the ChaosDB vulnerability that we will speak on more later. And a both we've present in Blackhat in Vegas in [unintelligible 00:02:56]. So, we do a lot of research. You mentioned that we have a third one. Which one did you refer to?Corey: That's a good question because you had the I want to say it was called as Azurescape, and you're doing a fantastic job with branding a number of your different vulnerabilities, but there's also, once you started reporting this, a lot of other research started coming out as well from other folks. And I confess, a lot of it sort of flowed together and been very hard to disambiguate, is this a systemic problem; is this, effectively, a whole bunch of people piling on now that their attention is being drawn somewhere; or something else? Because you've come out with an awful lot of research in a short period of time.Shir: Yeah, we had a lot of good research in the past year. It's a [unintelligible 00:03:36] mention Azurecape was actually found by a very good researcher in Palo Also. And… do you remember his name?Sagi: No, I can't recall his name is.Corey: Yeah, they came out of unit 42 as I recall, their cybersecurity division. Every tech company out there seems to have some sort of security research division these days. What I think is, sort of, interesting is that to my understanding, you were founded, first and foremost, as a security company. You're not doing this as an ancillary to selling something else like a firewall, or, effectively, you're an ad comp—an ad tech company like Google, we you're launching Project Zero. You are first and foremost aimed at this type of problem.Shir: Yes. Wiz is not just a small research company. It's actually pretty big company with over 200 employees. And the purpose of this product is a cloud security suite that provides [unintelligible 00:04:26] scanning capabilities in order to find risks in cloud environments. And the research team is a very small group. We are [unintelligible 00:04:35] researchers.We have multiple responsibilities. Our first responsibility is to find risks in cloud environments: It could be misconfigurations, it could be vulnerabilities in libraries, in software, and we add those findings and the patterns we discover to the product in order to protect our customers, and to allow them for new risks. Our second responsibility is also to do a community research where we research everyone vulnerabilities in public products and cloud providers, and we share our findings with the cloud providers, then also with the community to make the cloud more secure.Corey: I can't shake the feeling that if there weren't folks doing this sort of research and shining a light on what it is that the cloud providers are doing, if they were to discover these things at all, they would very quietly, effectively, fix it in the background and never breathe a word of it in public. I like the approach that you're taking as far as dragging it, kicking and screaming, into the daylight, but I also have to imagine that probably doesn't win you a whole lot of friends at the company that you're focusing on at any given point in time. Because whenever you talk to a company about a security issue, it seems like the first thing they're concerned about is, “Okay, how do we wind up spinning this or making sure that we minimize the reputational damage?” And then there's a secondary reaction of, “Oh, and how do we protect our customers? But mostly, how do we avoid looking bad as a result?” And I feel like that's an artifact of corporate culture these days. But it feels like the relationship has got to be somewhat interesting to navigate from your perspective.Shir: So, once we found a vulnerability and we discuss it with the vendor, okay, first, I will mention that most cloud providers have a bug bounty program where they encourage researchers to find vulnerabilities and to discover new security threats. And all of them, as a public disclosure, [unintelligible 00:06:29] program will researchers are welcome and get safe harbor, you know, where the disclosure vulnerabilities. And I think it's, like, common interest, both for customers, but for researchers, and the cloud providers to know about those vulnerabilities, to mitigate it down. And we do believe that sometimes cloud providors does resolve and mitigate vulnerabilities behind the scenes, and we know—we don't know for sure, but—I don't know about everything, but just by the vulnerabilities that we find, we assume that there is much more of them that we never heard about. And this is something that we believe needs to be changed in the industry.Cloud providers should be more transparent, they should show more information about the result vulnerabilities. Definitely when a customer data was accessible, or where it was at risk, or at possible risk. And this is actually—it's something that we actually trying to change in the industry. We have a community and, like, innovative community. It's like an initiative that we try to collect, we opened a Slack channel called the Cloud CVE, and we try to invite as much people as we can that concern about cloud's vulnerabilities, in order to make a change in the industry, and to assist cloud providers, or to convince cloud providers to be more transparent, to enumerate cloud vulnerabilities so they have an identifier just, like cloud CVE, like a CVE, and to make the cloud more protected and more transparent customers.Corey: The thing that really took me aback by so much of what you found is that we've become relatively accustomed to a few patterns over the past 15 to 20 years. For example, we're used to, “Oh, this piece of software you run on your desktop has a horrible flaw. Great.” Or this thing you run in your data center, same story; patch, patch, patch, patch patch. That's great.But there was always the sense that these were the sorts of things that were sort of normal, but the cloud providers were on top of things, where they were effectively living up to their side of the shared responsibility bargain. And that whenever you wound up getting breached, for whatever reason—like in the AWS world, where oh, you wound up losing a bunch of customer data because you had an open S3 bucket? Well, yeah, that's not really something you can hang super effectively around the neck of the cloud provider, given that you're the one that misconfigured that. But what was so striking about what you found with both of the vulnerabilities that we're talking about today, the customer could have done everything absolutely correctly from the beginning and still had their data exposed. And that feels like it's something relatively new in the world of cloud service providers.Is this something that's been going on for a while and we're just now shining a light on it? Have I just missed a bunch of interesting news stories where the clouds have—“Oh, yeah, by the way, people, we periodically have to go in and drag people out of our cloud control plane because oops-a-doozy, someone got in there again with the squirrels,” or is this something that is new?Shir: So, we do see an history other cases where probability [unintelligible 00:09:31] has disclosed vulnerabilities in the cloud infrastructure itself. There was only few, and usually, it was—the research was conducted by independent researchers. And I don't think it had such an impact, like ChaosDB, which allowed [cross-system 00:09:51] access to databases of other customers, which was a huge case. And so if it wasn't a big story, so most people will not hear about it. And also, independent researchers usually don't have the back that we have here in Wiz.We have a funding, we have the marketing division that help us to get coverage with reporters, who make sure to make—if it's a big story, we make sure that other people will hear about it. And I believe that in most bug bounty programs where independent researchers find vulnerabilities, usually they more care about the bounty than the aftereffect of stopping the vulnerability, sharing it with the community. Usually also, independent [unintelligible 00:10:32] usually share the findings with the research community. And the research community is relatively small to the IT community. So, it is new, but it's not that new.There was some events back in history, [unintelligible 00:10:46] similar vulnerabilities. So, I think that one of the points here is that everyone makes a mistake. You can find bugs which affected mostly, as you mentioned previously, this software that you installed on your desktop has bugs and you need to patch it, but in the case of cloud providers, when they make mistakes, when they introduce bugs to the service, it affects all of their customers. And this is something that we should think about. So, mistakes that are being made by cloud providers have a lot of impact regarding their customers.Corey: Yeah. It's not a story of you misconfigured, your company's SAN, so you're the one that was responsible for a data breach. It's suddenly, you're misconfiguring everyone's SAN simultaneously. It's the sheer scale and scope of what it is that they've done. And—Shir: Yeah, exactly.Corey: —I'm definitely on board with that. But the stuff I've seen in the past, from cloud providers—AWS, primarily, since that is admittedly where I tend to focus most of my time and energy—has been privilege escalation style stuff, where, okay, if you assign some users at your company—or wherever—access to this managed IAM policy, well, they'll have suddenly have access to things that go beyond the scope of that. And that's not good, let's be very clear on that, but it is a bit different between that and oh, by the way, suddenly, someone in another company that has no relationship established with you at all can suddenly rummage through your data that you're storing in Cosmos DB, their managed database offering. That's the thing to me that I think was the big head-turning aspect of this, not just for me, but for a number of folks I've spoken to, in financial services, in government, in a bunch of environments where data privacy is not optional in the same way that it is when, you know, you're running a social media for pets app.Nir: [laugh]. Yeah, but the thing is, that until the publication of ChaosDB, no one ever heard about the [unintelligible 00:12:40] data tampering in any cloud providers. Meaning maybe in six months, you can see a similar vulnerabilities in other cloud providers that maybe other security research groups find. So yeah, so Azure was maybe the first, but we don't think they will be the last.Shir: Yes. And also, when we do the community research, it is very important to us to take big targets. We enjoy the research. One day, the research will be challenging and we want to do something that it was new and great, so we always put a very big targets. To actually find vulnerability in the infrastructure of the cloud provider, it was very challenging for us.When didn't came ChaosDB by that; we actually found it by mistake. But now we think actively that this is our next goal is to find vulnerabilities in the infrastructure and not just vulnerabilities that affect only the—vulnerabilities within the account itself, like [unintelligible 00:13:32] or bad scoped policies that affects only one account.Corey: That seems to be the transformative angle that you don't see nearly as much in existing studies around vulnerabilities in this space. It's always the, “Oh, no. We could have gotten breached by those people across the hallway from us in our company,” as opposed to folks on the other side of the planet. And that is, I guess, sort of the scary thing. What has also been interesting to me, and you obviously have more experience with this than I do, but I have a hard time envisioning that, for example, AWS, having a vulnerability like this and not immediately swinging into disaster firefighting mode, sending their security execs on a six month speaking tour to explain what happened, how it got there, all of the steps that they're taking to remediate this, but Azure published a blog post explaining this in relatively minor detail: Here are the mitigations you need to take, and as far as I can tell, then they sort of washed their hands of the whole thing and have enthusiastically begun saying absolutely nothing since.And that I have learned is sort of fairly typical for Microsoft, and has been for a while, where they just don't talk about these things when it arises. Does that match your experience? Is this something that you find that is common when a large company winds up being, effectively, embarrassed about their security architecture, or is this something that is unique to Microsoft tends to approach these things?Shir: I would say in general, we really like the Microsoft MSRC team. The group in Microsoft that's responsible for handling vulnerabilities, and I think it's like the security division inside Microsoft, MSRC. So, we have a really good relationship and we had really good time working with them. They're real professionals, they take our findings very seriously. I can tell that in the ChaosDB incident, they didn't plan to publish a blog post, and they did that after the story got a lot of attention.So, I'm looking at a PR team, and I have no idea out there decide stuff and what is their strategy, but as I mentioned earlier, we believe that there is much more cloud vulnerabilities that we never heard of, and it should change; they should publish more.Nir: It's also worth mentioning that Microsoft acted really quick on this vulnerability and took it very seriously. They issued the fix in less than 48 hours. They were very transparent in the entire procedure, and we had multiple teams meeting with them. The entire experience was pretty positive with each of the vulnerability we've ever reported to Microsoft.Sagi: So, it's really nice working with the guys that are responsible for security, but regarding PR, I agree that they should have posted more information regarding this incident.Corey: The thing that I found interesting about this, and I've seen aspects of it before, but never this strongly is, I was watching for, I guess, what I would call just general shittiness, for lack of a better term, from the other providers doing a happy dance of, “Aha, we're better than you are,” and I saw none of that. Because when I started talking to people in some depth at this at other companies, the immediate response—not just AWS, to be clear—has been no, no, you have to understand, this is not good for anyone because this effectively winds up giving fuel to the slow-burning fire of folks who are pulling the, “See, I told you the cloud wasn't secure.” And now the enterprise groundhog sees that shadow and we get six more years of building data centers instead of going to the cloud. So, there's no one in the cloud space who's happy with this kind of revelation and this type of vulnerability. My question for you is given that you are security researchers, which means you are generally cynical and pessimistic about almost everything technological, if you're like most of the folks in that space that I've spent time with, is going with cloud the wrong answer? Should people be building their own data centers out? Should they continue to be going on this full cloud direction? I mean, what can they do if everything's on fire and terrible all the time?Shir: So, I think that there is a trade-off when you embrace the cloud. On one hand, you get the fastest deployment times, and a good scalability regarding your infrastructure, but on the other end, when there is a security vulnerability in the cloud provider, you are immediately affected. But it is worth mentioning that the security teams or the cloud providers are doing extremely good job. Most likely, they are going to patch the vulnerability faster than it would have been patched in on-premise environment. And it's good that you have them working for you.And once the vulnerability is mitigated—depends on the vulnerability but in the case of ChaosDB—when the vulnerability was mitigated on Microsoft's end, and it was mitigated completely. No one else could have exploited after the mitigated it once. Yes, it's also good to mention that the cloud provides organization and companies a lot of security features, [unintelligible 00:18:34] I want to say security features, I would say, it provides a lot of tooling that helps security. The option to have one interface, like one API to control all of my devices, to get visibility to all of my servers, to enforce policies very easily, it's much more secure than on-premise environments, where there is usually a big mess, a lot of vendors.Because the power was in the on-prem, the power was on the user, so the user had a lot of options. Usually used many types of software, many types of hardware, it's really hard to mitigate the software vulnerability in on-prem environments. It's really helped to get the visibility. And the cloud provides a lot of security, like, a good aspects, and in my opinion, moving to the cloud for most organization would be a more secure choice than remain on-premise, unless you have a very, very small on-prem environment.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense.Corey: The challenge I keep running into is that—and this is sort of probably the worst of all possible reasons to go with cloud, but let's face it, when us-east-1 recently took an outage and basically broke a decent swath of the internet, a lot of companies were impacted, but they didn't see their names in the headlines; it was all about Amazon's outage. There's a certain value when a cloud provider takes an outage or a security breach, that the headlines screaming about it are about the provider, not about you and your company as a customer of that provider. Is that something that you're seeing manifest across the industry? Is that an unhealthy way to think about it? Because it feels almost like it's cheating in a way. It's, “Yeah, we had a security problem, but so did the entire internet, so it's okay.”Nir: So, I think that if there would be evidence that these kind of vulnerabilities were exploited while disclosure, then you wouldn't see headlines of companies, shouting in the headlines. But in the case of the us reporting the vulnerabilities prior to anyone exploiting them, results in nowhere a company showing up in the headlines. I think it's a slightly different situation than an outage.Shir: Yeah, but also, when one big provider have an outage or a breach, so usually, the customers will think it's out of my responsibility. I mean, it's bad; my data has been leaked, but what can I do? I think it's very easy for most people to forgive companies [unintelligible 00:21:11]. I mean, you know what, it's just not my area. So, maybe I'm not answer that into that. [laugh].Corey: No, no, it's very fair. The challenge I have, as a customer of all of these providers, to be honest, is that a lot of the ways that the breach investigations are worded of, “We have seen no evidence that this has been exploited.” Okay, that simultaneously covers the two very different use cases of, “We have pored through our exhaustive audit logs and validated that no one has done this particular thing in this particular way,” but it also covers the use case, “Of, hey, we learned we should probably be logging things, but we have no evidence that anything was exploited.” Having worked with these providers at scale, my gut impression is that they do in fact, have fairly detailed logs of who's doing what and where. Would you agree with that assessment, or do you find that you tend to encounter logging and analysis gaps as you find these exploits?Shir: We don't really know. Usually when—I mean, ChaosDB scenario, we got access to a Jupyter Notebook. And from the Jupyter Notebook, we continued to another internal services. And we—nobody stopped us. Nobody—we expected an email, like—Corey: “Whatcha doing over there, buddy?”Shir: Yeah. “Please stop doing that, and we're investigating you.” And we didn't get any. And also, we don't really know if they monitor it or not. I can tell from my technical background that logging so many environments, it's hard.And when you do decide to log all these events, you need to decide what to log. For example, if I have a database, a managed database, do I log all the queries that customers run? It's too much. If I have an HTTP application—a managed HTTP application—do I save all the access logs, like all the requests? And if so, what will be the retention time? For how long?We believe that it's very challenging on the cloud provider side, but it just an assumption. And doing the discussion with Microsoft, the didn't disclose any, like, scenarios they had with logging. They do mention that they're [unintelligible 00:23:26] viewing the logs and searching to see if someone exploited this vulnerability before we disclosed it. Maybe someone discovered before we did. But they told us they didn't find anything.Corey: One last area I'd love to discuss with you before we call it an episode is that it's easy to view Wiz through the lens of, “Oh, we just go out and find vulnerabilities here and there, and we make companies feel embarrassed—rightfully so—for the things that they do.” But a little digging shows that you've been around for a little over a year as a publicly known entity, and during that time, you've raised $600 million in funding, which is basically like what in the world is your pitch deck where you show up to investors and your slides are just, like, copies of their emails, and you read them to them?[laugh]I mean, on some level, it seems like that is a… as-, astounding amount of money to raise in a short period of time. But I've also done a little bit of digging, and to be clear, I do not believe that you have an extortion-based business model, which is a good thing. You're building something very interesting that does in-depth analysis of cloud workloads, and I think it's got an awful lot of promise. How does the vulnerability research that you do tie into that larger platform, other than, let's be honest, some spectacularly effective marketing.Sagi: Specifically in the ChaosDB vulnerability, we were actually not looking for a vulnerability in the cloud service providers. We were originally looking for common misconfigurations that our customers can make when they set up their Cosmos DB accounts, so that our product will be able to alert our customers regarding such misconfigurations. And then we went to the Azure portal and started to enable all of the features that Cosmos DB has to offer, and when we enabled enough features, we noticed some feature that could be vulnerable, and we started digging into it. And we ended up finding ChaosDB.But our original work was to try and find misconfigurations that our customers can make in order to protect them and not to find a vulnerability in the [CSP 00:25:31]. This was just, like, a byproduct of this research.Shir: Yes. There is, as I mentioned earlier, our main responsibility is to add a little security rist content to the product, to help customers to find new security risks in their environment. As you mentioned, like, the escalation possibilities within cloud accounts, and bad scoped policies, and many other security risks that are in the cloud area. And also, we are a very small team inside a big company, so most of the company, they are doing heavy [unintelligible 00:26:06] and talk with customers, they understand the risks, they understand the market, what the needs for tomorrow, and maybe we are well known for our vulnerabilities, but it just a very small part of the company.Corey: On some level, it says wonderful things about your product, and also terrifying things from different perspectives of, “Oh, yeah, we found one of the worst cloud breaches in years by accident,” as opposed to actively going in trying to find the thing that has basically put you on the global map of awareness around these things. Because there a lot of security companies out there doing different things. In fact, go to RSA, and you'll see basically 12 companies that just repeated over and over and over with different names and different brandings, and they're all selling some kind of firewall. This is something actively different because everyone can tell beautiful pictures with slides and whatnot, and the corporate buzzwords. You're one of those companies that actually did something meaningful, and it felt almost like a proof of concept. On some level, the fact that you weren't actively looking for it is kind of an amazing testament for the product itself.Shir: Yeah. We actually used the product in the beginning, in order to overview our own environment, and what is the most common services we use. In order—and we usually we mix this information with our product managers, know to understand what customers use and what products and services we need to research in order to bring value to the product.Sagi: Yeah, so the reason we chose to research Cosmos DB was that, we found that a lot of our Azure customers are using Cosmos DB on their production environments, and we wanted to add mitigations for common misconfigurations to our product in order to protect our customers.Nir: Yeah, the same goes with our other research, like OMIGOD, where we've seen that there is a excessive amount of [unintelligible 00:27:56] installations in an Azure environment, and it raised our [laugh] it raised our attention, and then found this vulnerability. It's mostly, like, popularity-guided research. [laugh].Shir: Yeah. And also [unintelligible 00:28:11] mention that maybe we find vulnerabilities by accident, but the service, we are doing vulnerability itself for the past ten years, and even more. So, we are very professional and this is what we do, and this is what we like to do. And we came skilled to the [crosstalk 00:28:25].Corey: It really is neat to see, just because every other security tool that I've looked at in recent memory tells you the same stuff. It's the same problem you see in the AWS billing space that I live in. Everyone says, “Oh, we can find these inactive instances that could be right-sized.” Great, because everyone's dealing with the same data. It's the security stuff is no different. “Hey, this S3 bucket is open.” Yes, it's a public web server. Please stop waking me up at two in the morning about it. It's there by design.But it goes back and forth with the same stuff just presented differently. This is one of the first truly novel things I've seen in ages. If nothing else, you convince me to kick the tires on it, and see what kind of horrifying things I can learn about my own environments with it.Shir: Yeah, you should. [laugh]. Let's poke [unintelligible 00:29:13].[laugh].Corey: I want to thank you so much for taking the time to speak with me today. If people want to learn more about the research you're up to and the things that you find interesting, where can they find you all?Shir: Most of our publication—I mean, all of our publications are under the Wiz, which is wiz.io/blog, and people can read all of our research. Just today we are announcing a new one, so feel free to go and read there. And they also feel free to approach us on Twitter, the service, we have a Twitter account. We are open for, like, messages. Just send us a message.Corey: And we will certainly put links to all of that in the [show notes 00:29:49]. Shir, Sagi, Nir, thank you so much for joining me today. I really appreciate your time.Shir: Thank you.Sagi: Thank you.Nir: Thank you much.Shir: It was very fun. Yeah.Corey: This has been Screaming in the Cloud. I'm Cloud Economist Corey Quinn and thank you for listening. 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 from someone else's account.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.

In this episode of AARC Perspectives, we talk with Krystal Craddock, MSRC, RRT, RRT-ACCS, RRT-NPS, AE-C, CCM, and dive into how her team celebrates RC week. She gives helpful ideas to managers and discusses why it's important to celebrate year-round.

Episode 7 – Kelly Todd of the CVE Program speaks with Lisa Olson of Microsoft about managing the modernization and automation changes currently underway in the CVE Program. Topics include the efforts of the newly formed CVE Transition Working Group (Lisa, a CVE Board member, is co-chair); automation of CVE ID assignment and CVE Record publishing for CVE Numbering Authorities (CNAs), including the availability of free APIs and other improvements on the way; the upcoming new version release of JSON for the CVE Record format to enhance the data associated with a record; the upcoming availability of program metrics for the CVE community, as well as customized dashboards for use by CNAs; the upcoming launch of a new and more modern CVE website using a new url, cve.org; among other program improvements. In addition, Lisa discusses the benefits of partnering with the CVE Program as a CNA and of being a member of the global CNA community.CVE® - https://cve.mitre.org/Microsoft - https://www.microsoft.com/MSRC - https://microsoft.com/msrcCVE Working Groups - https://cve.mitre.org/working_groups.htmlHow to become a CNA - https://cve.mitre.org/cve/cna.html#become_a_cna

About NickNick Frichette is a Penetration Tester and Team Lead for State Farm. Outside of work he does vulnerability research. His current primary focus is developing techniques for AWS exploitation. Additionally he is the founder of hackingthe.cloud which is an open source encyclopedia of the attacks and techniques you can perform in cloud environments.Links: Hacking the Cloud: https://hackingthe.cloud/ Determine the account ID that owned an S3 bucket vulnerability: https://hackingthe.cloud/aws/enumeration/account_id_from_s3_bucket/ Twitter: https://twitter.com/frichette_n Personal website:https://frichetten.com TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached, the hard way. Take a look at this. It's one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That's canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I'm a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications. It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself; make one of them go away. To learn more, visit lumigo.io.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I spend a lot of time throwing things at AWS in varying capacities. One area I don't spend a lot of time giving them grief is in the InfoSec world because as it turns out, they—and almost everyone else—doesn't have much of a sense of humor around things like security. My guest today is Nick Frechette, who's a penetration tester and team lead for State Farm. Nick, thanks for joining me.Nick: Hey, thank you for inviting me on.Corey: So, like most folks in InfoSec, you tend to have a bunch of different, I guess, titles or roles that hang on signs around someone's neck. And it all sort of distills down, on some level—in your case, at least, and please correct me if I'm wrong—to ‘cloud security researcher.' Is that roughly correct? Or am I missing something fundamental?Nick: Yeah. So, for my day job, I do penetration testing, and that kind of puts me up against a variety of things, from web applications, to client-side applications, to sometimes the cloud. In my free time, though, I like to spend a lot of time on security research, and most recently been focusing pretty heavily on AWS.Corey: So, let's start at the very beginning. What is a cloud security researcher? “What is it you'd say it is you do here?” For lack of a better phrasing?Nick: Well, to be honest, the phrase ‘security researcher' or ‘cloud security researcher' has been, kind of… I guess watered down in recent years; everybody likes to call themselves a researcher in some way or another. You have some folks who participate in the bug bounty programs. So, for example, GCP, and Azure have their own bug bounties. AWS does not, and too sure why. And so they want to find vulnerabilities with the intention of getting cash compensation for it.You have other folks who are interested in doing security research to try and better improve defenses and alerting and monitoring so that when the next major breach happens, they're prepared or they'll be able to stop it ahead of time. From what I do, I'm very interested in offensive security research. So, how can I as, a penetration tester, or red teamer or, I guess, an actual criminal, [laugh] how can I take advantage of AWS, or try to avoid detection from services like GuardDuty and CloudTrail?Corey: So, let's break that down a little bit further. I've heard the term of ‘red team versus blue team' used before. Red team—presumably—is the offensive security folks—and yes, some of those people are, in fact, quite offensive—and blue team is the defense side. In other words, keeping folks out. Is that a reasonable summation of the state of the world?Nick: It can be, yeah, especially when it comes to security. One of the nice parts about the whole InfoSec field—I know a lot of folks tend to kind of just say, “Oh, they're there to prevent the next breach,” but in reality, InfoSec has a ton of different niches and different job specialties. “Blue teamers,” quote-unquote, tend to be the defense side working on ensuring that we can alert and monitor potential attacks, whereas red teamers—or penetration testers—tend to be the folks who are trying to do the actual exploitation or develop techniques to do that in the future.Corey: So, you talk a bit about what you do for work, obviously, but what really drew my notice was stuff you do that isn't part of your core job, as best I understand it. You're focused on vulnerability research, specifically with a strong emphasis on cloud exploitation, as you said—AWS in particular—and you're the founder of Hacking the Cloud, which is an open-source encyclopedia of various attacks and techniques you can perform in cloud environments. Tell me about that.Nick: Yeah, so Hacking the Cloud came out of a frustration I had when I was first getting into AWS, that there didn't seem to be a ton of good resources for offensive security professionals to get engaged in the cloud. By comparison, if you wanted to learn about web application hacking, or attacking Active Directory, or reverse engineering, if you have a credit card, I can point you in the right direction. But there just didn't seem to be a good course or introduction to how you, as a penetration tester, should attack AWS. There's things like, you know, open S3 buckets are a nightmare, or that server-side request forgery on an EC2 instance can result in your organization being fined very, very heavily. I kind of wanted to go deeper with that.And with Hacking the Cloud, I've tried to gather a bunch of offensive security research from various blog posts and conference talks into a single location, so that both the offense side and the defense side can kind of learn from it and leverage that to either improve defenses or look for things that they can attack.Corey: It seems to me that doing things like that is not likely to wind up making a whole heck of a lot of friends over on the cloud provider side. Can you talk a little bit about how what you do is perceived by the companies you're focusing on?Nick: Yeah. So, in terms of relationship, I don't really have too much of an idea of what they think. I have done some research and written on my blog, as well as published to Hacking the Cloud, some techniques for doing things like abusing the SSM agent, as well as abusing the AWS API to enumerate permissions without logging into CloudTrail. And ironically, through the power of IP addresses, I can see when folks from the Amazon corporate IP address space look at my blog, and that's always fun, especially when there's, like, four in the course of a couple of minutes, or five or six. But I don't really know too much about what they—or how they view it, or if they think it's valuable at all. I hope they do, but really not too sure.Corey: I would imagine that they do, on some level, but I guess the big question is, you know that someone doesn't like what you're doing when they send, you know, cease and desist notices, or have the police knock on your door. I feel like at most levels, we're past that in an InfoSec level, at least I'd like to believe we are. We don't hear about that happening all too often anymore. But what's your take on it?Nick: Yeah, I definitely agree. I definitely think we are beyond that. Most companies these days know that vulnerabilities are going to happen, no matter how hard you try and how much money you spend, and so it's better to be accepting of that and open to it. And especially because the InfoSec community can be so, say, noisy at times, it's definitely worth it to pay attention, definitely be appreciative of the information that may come out. AWS is pretty awesome to work with, having disclosed to them a couple times, now.They have a safe harbor provision, which essentially says that so long as you're operating in good faith, you are allowed to do security testing. They do have some rules around that, but they are pretty clear in terms of if you were operating in good faith, you wouldn't be doing anything like that. It tends to be pretty obviously malicious things that they'll ask you to stop.Corey: So, talk to me a little bit about what you've found lately, and been public about. There have been a number of examples that have come up whenever people start googling your name or looking at things you've done. But what's happening lately? What have you found that's interesting?Nick: Yeah. So, I think most recently, the thing that's kind of gotten the most attention has been a really interesting bug I found in the AWS API. Essentially, kind of the core of it is that when you are interacting with the API, obviously that gets logged to CloudTrail, so long as it's compatible. So, if you are successful, say you want to do, like, Secrets Manager, ListSecrets, that shows up in CloudTrail. And similarly, if you do not have that permission on a role or user and you try to do it, that access denied also gets logged to CloudTrail.Something kind of interesting that I found is that by manually modifying a request, or mal-forming them, what we can do is we can modify the content-type header, and as a result when you do that—and you can provide literally gibberish. I think I have VS Code window here somewhere with a content-type of ‘meow'—when you do that, the AWS API knows the action that you're trying to call because of that messed up content type, it doesn't know exactly what you're trying to do and as a result, it doesn't get logged to CloudTrail. Now, while that may seem kind of weirdly specific and not really, like, a concern, the nice part of it though is that for some API actions—somewhere in the neighborhood of 600. I say ‘in the neighborhood of' just because it fluctuates over time—as a result of that, you can tell if you have that permission, or if you don't without that being logged to CloudTrail. And so we can do this enumeration of permissions without somebody in the defense side seeing us do it. Which is pretty awesome from a offensive security perspective.Corey: On some level, it would be easy to say, “Well, just not showing up in the logs isn't really a security problem at all.” I guess that you disagree?Nick: I do, yeah. So, let's sort of look at it from a real-world perspective. Let's say, Corey, you're tired of saving people money on their AWS bill, you'd instead maybe want to make a little money on the side and you're okay with perhaps, you know, committing some crimes to do it. Through some means you get access to a company's AWS credentials for some particular role, whether that's through remote code execution on an EC2 instance, or maybe find them in an open location like an S3 bucket or a Git repository, or maybe you phish a developer, through some means, you have an access key and a secret access key. The new problem that you have is that you don't know what those credentials are associated with, or what permissions they have.They could be the root account keys, or they could be literally locked down to a single S3 bucket to read from. It all just kind of depends. Now, historically, your options for figuring that out are kind of limited. Your best bet would be to brute-force the AWS API using a tool like Pacu, or my personal favorite, which is enumerate-iam by Andres Riancho. And what that does is it just tries a bunch of API calls and sees which one works and which one doesn't.And if it works, you clearly know that you have that permission. Now, the problem with that, though, is that if you were to do that, that's going to light up CloudTrail like a Christmas tree. It's going to start showing all these access denieds for these various API calls that you've tried. And obviously, any defender who's paying attention is going to look at that and go, “Okay. That's, uh, that's suspicious,” and you're going to get shut down pretty quickly.What's nice about this bug that I found is that instead of having to litter CloudTrail with all these logs, we can just do this enumeration for roughly 600-ish API actions across roughly 40 AWS services, and nobody is the wiser. You can enumerate those permissions, and if they work fantastic, and you can then use them, and if you come to find you don't have any of those 600 permissions, okay, then you can decide on where to go from there, or maybe try to risk things showing up in CloudTrail.Corey: CloudTrail is one of those services that I find incredibly useful, or at least I do in theory. In practice, it seems that things don't show up there, and you don't realize that those types of activities are not being recorded until one day there's an announcement of, “Hey, that type of activity is now recorded.” As of the time of this recording, the most recent example that in memory is data plane requests to DynamoDB. It's, “Wait a minute. You mean that wasn't being recorded previously? Huh. I guess it makes sense, but oh, dear.”And that causes a reevaluation of what's happening in the—from a security policy and posture perspective for some clients. There's also, of course, the challenge of CloudTrail logs take a significant amount of time to show up. It used to be over 20 minutes, I believe now it's closer to 15—but don't quote me on that, obviously. Run your own tests—which seems awfully slow for anything that's going to be looking at those in an automated fashion and taking a reactive or remediation approach to things that show up there. Am I missing something key?Nick: No, I think that is pretty spot on. And believe me, [laugh] I am fully aware at how long CloudTrail takes to populate, especially with doing a bunch of research on what is and what is not logged to CloudTrail. I know that there are some operations that can be logged more quickly than the 15-minute average. Off the top of my head, though, I actually don't quite remember what those are. But you're right, in general, the majority at least do take quite a while.And that's definitely time in which an adversary or someone like me, could maybe take advantage of that 15-minute window to try and brute force those permissions, see what we have access to, and then try to operate and get out with whatever goodies we've managed to steal.Corey: Let's say that you're doing the thing that you do, however that comes to be—and I am curious—actually, we'll start there. I am curious; how do you discover these things? Is it looking at what is presented and then figuring out, “Huh, how can I wind up subverting the system it's based on?” And, similar to the way that I take a look at any random AWS services and try and figure out how to use it as a database? How do you find these things?Nick: Yeah, so to be honest, it all kind of depends. Sometimes it's completely by accident. So, for example, the API bug I described about not logging to CloudTrail, I actually found that due to [laugh] copy and pasting code from AWS's website, and I didn't change the content-type header. And as a result, I happened to notice this weird behavior, and kind of took advantage of it. Other times, it's thinking a little bit about how something is implemented and the security ramifications of it.So, for example, the SSM agent—which is a phenomenal tool in order to do remote access on your EC2 instances—I was sitting there one day and just kind of thought, “Hey, how does that authenticate exactly? And what can I do with it?” Sure enough, it authenticates the exact same way that the AWS API does, that being the metadata service on the EC2 instance. And so what I figured out pretty quickly is if you can get access to an EC2 instance, even as a low-privilege user or you can do server-side request forgery to get the keys, or if you just have sufficient permissions within the account, you can potentially intercept SSM messages from, like, a session and provide your own results. And so in effect, if you've compromised an EC2 instance, and the only way, say, incident response has into that box is SSM, you can effectively lock them out of it and, kind of, do whatever you want in the meantime.Corey: That seems like it's something of a problem.Nick: It definitely can be. But it is a lot of fun to play keep-away with incident response. [laugh].Corey: I'd like to reiterate that this is all in environments you control and have permissions to be operating within. It is not recommended that people pursue things like this in other people's cloud environments without permissions. I don't want to find us sued for giving crap advice, and I don't want to find listeners getting arrested because they didn't understand the nuances of what we're talking about.Nick: Yes, absolutely. Getting legal approval is really important for any kind of penetration testing or red teaming. I know some folks sometimes might get carried away, but definitely be sure to get approval before you do any kind of testing.Corey: So, how does someone report a vulnerability to a company like AWS?Nick: So AWS, at least publicly, doesn't have any kind of bug bounty program. But what they do have is a vulnerability disclosure program. And that is essentially an email address that you can contact and send information to, and that'll act as your point of contact with AWS while they investigate the issue. And at the end of their investigation, they can report back with their findings, whether they agree with you and they are working to get that patched or fixed immediately, or if they disagree with you and think that everything is hunky-dory, or if you may be mistaken.Corey: I saw a tweet the other day that I would love to get your thoughts on, which said effectively, that if you don't have a public bug bounty program, then any way that a researcher chooses to disclose the vulnerability is definitionally responsible on their part because they don't owe you any particular duty of care. Responsible disclosure, of course, is also referred to as, “Coordinated vulnerability disclosure” because we're always trying to reinvent terminology in this space. What do you think about that? Is there a duty of care from security researchers to responsibly disclose the vulnerabilities they find, or coordinate those vulnerabilities with vendors in the absence of a public bounty program on turning those things in?Nick: Yeah, you know, I think that's a really difficult question to answer. From my own personal perspective, I always think it's best to contact the developers, or the company, or whoever maintains whatever you found a vulnerability in, give them the best shot to have it fixed or repaired. Obviously, sometimes that works great, and the company is super receptive, and they're willing to patch it immediately. And other times, they just don't respond, or sometimes they respond harshly, and so depending on the situation, it may be better for you to release it publicly with the intention that you're informing folks that this particular company or this particular project may have an issue. On the flip side, I can kind of understand—although I don't necessarily condone it—why folks pursue things like exploit brokers, for example.So, if a company doesn't have a bug bounty program, and the researcher isn't expecting any kind of, like, cash compensation, I can understand why they may spend tens of hours, maybe hundreds of hours chasing down a particularly impactful vulnerability, only to maybe write a blog post about it or get a little head pat and say, “Thanks, nice work.” And so I can see why they may pursue things like selling to an exploit broker who may pay them hefty sum, if it is a—Corey: Orders of magnitude more. It's, “Oh, good. You found a way to remotely execute code across all of EC2 in every region”—that is a hypothetical; don't email me—have a t-shirt. It seems like you could basically buy all the t-shirts for [laugh] what that is worth on the export market.Nick: Yes, absolutely. And I do know from some experience that folks will reach out to you and are interested in, particularly, some cloud exploits. Nothing, like, minor, like some of the things that I've found, but more thinking more of, like, accessing resources without anybody knowing or accessing resources cross-account; that could go for quite a hefty sum.Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn't translate well to cloud or multi-cloud environments, and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.Corey: It always feels squicky, on some level, to discover something like this that's kind of neat, and wind up selling it to basically some arguably terrible people. Maybe. We don't know who's buying these things from the exploit broker. Counterpoint, having reported a few security problems myself to various providers, you get an autoresponder, then you get a thank you email that goes into a bit more detail—for the well-run programs, at least—and invariably, the company's position is, is whatever you found is not as big of a deal as you think it is, and therefore they see no reason to publish it or go loud with it. Wouldn't you agree?Because, on some level, their entire position is, please don't talk about any security shortcomings that you may have discovered in our system. And I get why they don't want that going loud, but by the same token, security researchers need a reputation to continue operating on some level in the market as security researchers, especially independents, especially people who are trying to make names for themselves in the first place.Nick: Yeah.Corey: How do you resolve that dichotomy yourself?Nick: Yeah, so, from my perspective, I totally understand why a company or project wouldn't want you to publicly disclose an issue. Everybody wants to look good, and nobody wants to be called out for any kind of issue that may have been unintentionally introduced. I think the thing at the end of the day, though, from my perspective, if I, as some random guy in the middle of nowhere Illinois finds a bug, or to be frank, if anybody out there finds a vulnerability in something, then a much more sophisticated adversary is equally capable of finding such a thing. And so it's better to have these things out in the open and discussed, rather than hidden away, so that we have the best chance of anybody being able to defend against it or develop detections for it, rather than just kind of being like, “Okay, the vendor didn't like what I had to say, I guess I'll go back to doing whatever [laugh] things I normally do.”Corey: You've obviously been doing this for a while. And I'm going to guess that your entire security researcher career has not been focused on cloud environments in general and AWS in particular.Nick: Yes, I've done some other stuff in relation to abusing GitLab Runners. I also happen to find a pretty neat RCE and privilege escalation in the very popular open-source project. Pi-hole. Not sure if you have any experience with that.Corey: Oh, I run it myself all the time for various DNS blocking purposes and other sundry bits of nonsense. Oh, yes, good. But what I'm trying to establish here is that this is not just one or two companies that you've worked with. You've done this across the board, which means I can ask a question without naming and shaming anyone, even implicitly. What differentiates good vulnerability disclosure programs from terrible ones?Nick: Yeah, I think the major differentiator is the reactivity of the project, as in how quickly they respond to you. There are some programs I've worked with where you disclose something, maybe even that might be of a high severity, and you might not hear back four weeks at a time, whereas there are other programs, particularly the MSRC—which is a part of Microsoft—or with AWS's disclosure program, where within the hour, I had a receipt of, “Hey, we received this, we're looking into it.” And then within a couple hours after that, “Yep, we verified it. We see what you're seeing, and we're going to look at it right away.” I think that's definitely one of the major differentiators for programs.Corey: Are there any companies you'd like to call out in either direction—and, “No,” is a perfectly valid [laugh] answer to this one—for having excellent disclosure programs versus terrible ones?Nick: I don't know if I'd like to call anybody out negatively. But in support, I have definitely appreciated working with both AWS's and the MSRC—Microsoft's—I think both of them have done a pretty fantastic job. And they definitely know what they're doing at this point.Corey: Yeah, I must say that I primarily focus on AWS and have for a while, which should be blindingly obvious to anyone who's listened to me talk about computers for more than three and a half minutes. But my experiences with the security folks at AWS have been uniformly positive, even when I find things that they don't want me talking about, that I will be talking about regardless, they've always been extremely respectful, and I have never walked away from the conversation thinking that I was somehow cheated by the experience. In fact, a couple of years ago at the last in-person re:Invent, I got to give a talk around something I reported specifically about how AWS runs its vulnerability disclosure program with one of their security engineers, Zach Glick, and he was phenomenally transparent around how a lot of these things work, and what they care about, and how they view these things, and what their incentives are. And obviously being empathetic to people reporting things in with the understanding that there is no duty of care that when security researchers discover something, they then must immediately go and report it in return for a pat on the head and a thank you. It was really neat being able to see both sides simultaneously around a particular issue. I'd recommend it to other folks, except I don't know how you make that lightning strike twice.Nick: It's very, very wise. Yes.Corey: Thank you. I do my best. So, what's next for you? You've obviously found a number of interesting vulnerabilities around information disclosure. One of the more recent things that I found that was sort of neat as I trolled the internet—I don't believe it was yours, but there was a ability to determine the account ID that owned an S3 bucket by enumerating by a binary search. Did you catch that at all?Nick: I did. That was by Ben Bridts, which is—it's pretty awesome technique, and that's been something I've been kind of interested in for a while. There is an ability to enumerate users' roles and service-linked roles inside an account, so long as the account ID. The problem, of course, is getting the account ID. So, when Ben put that out there I was super stoked about being able to leverage that now for enumeration and maybe some fun phishing tricks with that.Corey: I love the idea. I love seeing that sort of thing being conducted. And AWS's official policy as best I remember when I looked at this once, account IDs are not considered confidential. Do you agree with that?Nick: Yep. That is my understanding of how AWS views it. From my perspective, having an account ID can be beneficial. I mentioned that you can enumerate users' roles and service-linked roles with it, and that can be super useful from a phishing perspective. The average phishing email looks like, “Oh, you won an iPad,” or, “Oh, you're the 100th visitor of some website,” or something like that.But imagine getting an email that looks like it's from something like AWS developer support, or from some research program that they're doing, and they can say to you, like, “Hey, we see that you have these roles in your account with account ID such-and-such, and we know that you're using EKS, and you're using ECS,” that phishing email becomes a lot more believable when suddenly this outside party seemingly knows so much about your account. And that might be something that you would think, “Oh, well only a real AWS employee or AWS would know that.” So, from my perspective, I think it's best to try and keep your account ID secret. I actually redact it from every screenshot that I publish, or at the very least, I try to. At the same time, though, it's not the kind of thing that's going to get somebody in your account in a single step, so I can totally see why some folks aren't too concerned about it.Corey: I feel like we also got a bit of a red herring coming from AWS blog posts themselves, where they always will give screenshots explaining what they do, and redact the account ID in every case. And the reason that I was told at one point was, “Oh, we have an internal provisioning system that's different. It looks different, and I don't want to confuse people whenever I wind up doing a screenshot.” And that's great, and I appreciate that. And part of me wonders on one level how accurate is that?Because sure, I understand that you don't necessarily want to distract people with something that looks different, but then I found out that the system is called Isengard and, yeah, it's great. They've mentioned it periodically in blog posts, and talks, and the rest. And part of me now wonders, oh, wait a minute. Is it actually because they don't want to disclose the differences between those systems, or is it because they don't have license rights publicly to use the word Isengard and don't want to get sued by whoever owns the rights to the Lord of the Rings trilogy. So, one wonders what the real incentives are in different cases. But I've always viewed account IDs as being the sort of thing that eh, you probably want to share them around all the time, but it also doesn't necessarily hurt.Nick: Exactly, yeah. It's not the kind of thing you want to share with the world immediately, but it doesn't really hurt in the end.Corey: There was an early time when the partner network was effectively determining tiers of partner by how much spend they influenced, and the way that you've demonstrated that was by giving account IDs for your client accounts. The only verification at the time, to my understanding was that, “Yep, that mapped to the client you said it did.” And that was it. So, I can understand back in those days not wanting to muddy those waters. But those days are also long passed.So, I get it. I'm not going to be the first person to advertise mine, but if you can discover my account ID by looking at a bucket, it doesn't really keep me up at night.So, all of those things considered, we've had a pretty wide-ranging conversation here about a variety of things. What's next? What interests you as far as where you're going to start looking and exploring—and exploiting as the case may be—various cloud services? hackthe.cloud—which there is the dot in there, which also turns it into a domain; excellent choice—is absolutely going to be a great collection for a lot of what you find and for other people to contribute and learn from one another. But where are you aimed at? What's next?Nick: Yeah, so one thing I've been really interested in has been fuzzing the AWS API. As anyone who's ever used AWS before knows, there are hundreds of services with thousands of potential API endpoints. And so from a fuzzing perspective, there is a wide variety of things for us to potentially affect or potentially find vulnerabilities in. I'm currently working on a library that will allow me to make that fuzzing a lot easier. You could use things like botocore, Boto3, like, some of the AWS SDKs.The problem though, is that those are designed for, sort of like, the happy path where you can format your request the way Amazon wants. As a security researcher or as someone doing fuzzing, I kind of want to send random gibberish sometimes, or I want to malform my requests. And so that library is still in production, but it has already resulted in a bug. While I was fuzzing part of the AWS API, I happened to notice that I broke Elastic Beanstalk—quite literally—when [laugh] when I was going through the AWS console, I got the big red error message of, “[unintelligible 00:29:35] that request parameter is null.” And I was like, “Huh. Well, why is it null?”And come to find out as a result of that, there is a HTML injection vulnerability in the Elastic—well, there was a HTML injection vulnerability in the Elastic Beanstalk, for the AWS console. Pivoting from there, the Elastic Beanstalk uses Angular 1.8.1, or at least it did when I found it. As a result of that, we can modify that HTML injection to do template injection. And for the AngularJS crowd, template injection is basically cross-site scripting [laugh] because there is no sandbox anymore, at least in that version. And so as a result of that, I was able to get cross-site scripting in the AWS console, which is pretty exciting. That doesn't tend to happen too frequently.Corey: No that is not a typical issue that winds up getting disclosed very often.Nick: Definitely, yeah. And so I was excited about it, and considering the fact that my library for fuzzing is literally, like, not even halfway done, or is barely halfway done, I'm looking forward to what other things I can find with it.Corey: I look forward to reading more. And at the time of this recording, I should point out that this has not been finalized or made public, so I'll be keeping my eyes open to see what happens with this. And hopefully, this will be old news by the time this episode drops. If not, well, [laugh] this might be an interesting episode once it goes out.Nick: Yeah. I hope they'd have it fixed by then. They haven't responded to it yet other than the, “Hi, we've received your email. Thanks for checking in.” But we'll see how that goes.Corey: Watching news as it breaks is always exciting. If people want to learn more about what you're up to, and how you go about things, where can they find you?Nick: Yeah, so you can find me at a couple different places. On Twitter I'm @frichette_n. I also write a blog where I contribute a lot of my research at frechetten.com as well as Hacking the Cloud. I contribute a lot of the AWS stuff that gets thrown on there. And it's also open-source, so if anyone else would like to contribute or share their knowledge, you're absolutely welcome to do so. Pull requests are open and excited for anyone to contribute.Corey: Excellent. And we will of course include links to that in the [show notes 00:31:42]. Thank you so much for taking the time to speak with me. I really appreciate it.Nick: Yeah, thank you so much for inviting me on. I had a great time.Corey: Nick Frechette, penetration tester and team lead for State Farm. 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 a comment telling me why none of these things are actually vulnerabilities, but simultaneously should not be discussed in public, ever.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.

Prior to the pandemic, workdays used to look a whole lot different. If you had a break, you could take a walk to stretch your legs, shake the hands of your co-workers, or get some 1-on-1 face time with the boss. Ahh... those were the days. That close contact we once had is now something that many of us yearn for as we've had to abruptly lift and shift from living in our office to working from our home. But communicating and socializing aren't the only things that were easier back then. The walls of your office have expanded, and with them, the boundaries of your security protocols. Small in-office tasks like patching a server have now become multi-step processes that require remote management, remote updates, and remote administrative control. With that comes the prioritization of resilience and what it means for enterprises, customers, and security teams alike. That's where remote enterprise resiliency comes into play.   Today on the pod, we explore the final chapter of the MDDR. Irfan Mirza, Director of Enterprise Continuity and Resilience at Microsoft, wraps up the observations from the report by giving hosts Nic Fillingham and Natalya Godyla the rundown on enterprise resiliency and discusses how we can ensure the highest levels of security while working from home. Irfan explains the Zero trust model and how Microsoft is working to extend security benefits to your kitchen or home office, or...  that make-shift workspace in your closet.   In the second segment, Andrew Paverd, Senior Researcher on the Microsoft Security Response Center Team and jack of all trades, stops by… and we're not convinced he's fully human. He's here to tell us about the many hats he wears, from safe systems programming to leveraging AI to help with processes within the MSRC, and shares how he has to think like a hacker to prevent attacks. Spoiler alert: he's a big follower of Murphy's Law.    In This Episode, You Will Learn:   How classical security models are being challenged  What the Zero Trust Model is and how it works   The three critical areas of resilience: extending the enterprise boundary, prioritizing resilient performance, and validating the resilience of our human infrastructure.   How hackers approach our systems and technologies    Some Questions We Ask:  How has security changed as a product of the pandemic?  Do we feel like we have secured the remote workforce?  What frameworks exist to put a metric around where an organization is in terms of its resiliency?  What is Control Flow Guard (CFG) and Control-Flow Integrity?  What's the next stage for the Rust programming language?   Resources:  Microsoft Digital Defense Report Irfan's LinkedIn Andrew's LinkedIn Microsoft Security Blog Nic's LinkedIn Natalia's LinkedIn Related: Listen to: Afternoon Cyber Tea with Ann Johnson Listen to: Security Unlocked: CISO Series with Bret Arsenault  Security Unlocked is produced by Microsoft and distributed as part of The CyberWire Network. 

On PopHealth Week our guest is Marino A. Bruce, PhD, MSRC, MDiv. Dr. Bruce Directs the Program for Research on Faith, Health & Justice in the Department of Population Health Science at University of Mississippi Medical Center. He is a social and behavioral scientist with interests in the integration of the full range of health determinants specifically for young African American males and their risk factors for chronic kidney disease and cardiovascular disease. His current research explores the intersection of race, gender, spirituality, religiosity, and behavior and their implications for social and health outcomes among African-American male boys, adolescents and emerging adults. Dr. Bruce is also a Certified Rehabilitation Counselor and an ordained Baptist Minister and leverages the strengths of research-, community-, and faith-based communities toward efforts to improve the health of disadvantaged and disenfranchised males, their families, and their communities. Enjoy! ==##==  

On PopHealth Week our guest is Marino A. Bruce, PhD, MSRC, MDiv. Dr. Bruce Directs the Program for Research on Faith, Health & Justice in the Department of Population Health Science at University of Mississippi Medical Center. He is a social and behavioral scientist with interests in the integration of the full range of health determinants specifically for young African American males and their risk factors for chronic kidney disease and cardiovascular disease. His current research explores the intersection of race, gender, spirituality, religiosity, and behavior and their implications for social and health outcomes among African-American male boys, adolescents and emerging adults. Dr. Bruce is also a Certified Rehabilitation Counselor and an ordained Baptist Minister and leverages the strengths of research-, community-, and faith-based communities toward efforts to improve the health of disadvantaged and disenfranchised males, their families, and their communities. Enjoy! ==##==      

This episode we speak with Cecilia Gaposchkin and Anne Lester, editors of our exciting new series Medieval Societies, Religions, and Cultures: https://www.cornellpress.cornell.edu/series/medieval-societies-religions-and-cultures/ Sign up here to get updates on new books in this series and all of our new books in medieval studies: https://www.cornellpress.cornell.edu/sign-up/ M. Cecilia Gaposchkin is Professor of History at Dartmouth College. She is the author of The Making of Saint Louis: Kingship, Sanctiity, and Crusade in the Later Middle Ages and Invisible Weapons: Liturgy and the Making of Crusade Ideology, among others. Anne E. Lester holds the John W. Baldwin and Jenny Jochens Associate Chair in Medieval History at Johns Hopkins University. She is the author of Creating Cistercian Nuns: The Women's Religious Movement and Its Reform in Thirteenth-Century Champagne.

  Log-MD story     SeaSec East meetup     Gabe (county Infosec guy) https://www.sammamish.us/government/departments/information-technology/ransomware-attack-information-hub/ New Slack Moderator (@cherokeeJB) Shoutout to “Jerry G”   Mike P on Slack: https://www.eventbrite.com/e/adversary-tactics-red-team-operations-training-course-dc-april-2019-tickets-54735183407 www.Workshopcon.com/events and that we're looking for BlueTeam trainers please   Any chance you can tag @workshopcon. SpecterOps and lanmaster53 when you post on Twitter and we'll retweet   Noid - @_noid_ noid23@gmail.com   Bsides Talk (MP3) - https://github.com/noid23/Presentations/blob/master/BSides_2019/Noid_Seattle_Bsides.mp3 Slides (PDF) https://github.com/noid23/Presentations/blob/master/BSides_2019/Its%20Not%20a%20Bug%20Its%20a%20Feature%20-%20Seattle%20BSides%202019.pdf   Security view was a bit myopic? “What do we win by playing?” Cultivating relationships (buy lunch, donuts, etc) Writing reports Communicating findings that resonate with developers and management     Often pentest reports are seen by various facets of folks     Many levels of competency (incompetent -> super dev/sec) Communicating risk? Making bugs make sense to everyone… The three types of power: https://www.manager-tools.com/2018/03/three-types-power-and-one-rule-them-part-1 (yas!)   Check out our Store on Teepub! https://brakesec.com/store Join us on our #Slack Channel! Send a request to @brakesec on Twitter or email bds.podcast@gmail.com #Brakesec Store!:https://www.teepublic.com/user/bdspodcast #Spotify: https://brakesec.com/spotifyBDS #RSS: https://brakesec.com/BrakesecRSS #Youtube Channel:  http://www.youtube.com/c/BDSPodcast #iTunes Store Link: https://brakesec.com/BDSiTunes #Google Play Store: https://brakesec.com/BDS-GooglePlay Our main site:  https://brakesec.com/bdswebsite #iHeartRadio App:  https://brakesec.com/iHeartBrakesec #SoundCloud: https://brakesec.com/SoundcloudBrakesec Comments, Questions, Feedback: bds.podcast@gmail.com Support Brakeing Down Security Podcast by using our #Paypal: https://brakesec.com/PaypalBDS OR our #Patreon https://brakesec.com/BDSPatreon #Twitter: @brakesec @boettcherpwned @bryanbrake @infosystir #Player.FM : https://brakesec.com/BDS-PlayerFM #Stitcher Network: https://brakesec.com/BrakeSecStitcher #TuneIn Radio App: https://brakesec.com/TuneInBrakesec Transcription (courtesy of otter.ai, and modified for readability by Bryan Brake) Bryan Brake 0:13 Hello everybody this is Bryan from Brakeing Down Security this week you're gonna hear part two of our interview with Noid, we did a lot of interesting discussions with him and it went so well that we needed the second week so for those of you here just catching this now Part One was last week so you can just go back and download that one. We're going to start leading in with the "one of us" story because one of the one of the slides he talked about was how you know he you know learned how to be one with his dev team and one of the last topics we had was kind of personal to me I do a lot of pentest writing for reports and stuff at my organization "Leviathan" and and you know, we talked about you know What makes a good report how to write reports for all kinds of people, whether it be a manager that you're giving it to, from an engagement for a customer, or, you know, the technical people who might be fixing the bugs that an engagement person might find, or a pen tester might find in this case. So, yeah, we're we're going to go ahead and lead in with that. Before we go though, SpectreOps is looking for people to go to their classes. They're learning adversary tactics and red team Operations Training course in Tysons Corner, Virginia. It's currently $4,000 to us and it's from April 23, April 26 of this year 2019. That doesn't include also airfare and hotel, so you're gonna have to find your way to Tysons Corner the Hyatt Regency there's a link in the show notes of course to the to the class if you'd like to go You'll learn things like designing and deploying sophisticated resilient covert attack infrastructure, gaining initial access footholds on systems using client side attacks, and real world scenarios cutting edge lateral movement methods to move through the enterprise and a bunch of other cool things... so yeah if you're interested in and hooking that up you can you there's still you still got more than a month to sign up for it it looks like there might still be tickets so knock yourselves out they're also looking for blue team people. "Mike P" on our Slack channel, which will tell you about the end of the show here on how to join if you'd like, he said http://www.workshopcon.com/events they're looking for blue team trainers... you can hang out with folks like you know, SpecterOps and Tim Tomes (LanMaster53) as well there when you you know we can you sign up for the blue team stuff and yeah http://www.workshopcon.com/events and then you can you know learn to be a blue team trainer or actually give blue team training if you so choose. So that said it's pretty awesome. Alright, so without further ado, we're going to get started with part two of our interview with Noid here, hope you have a great week. And here we go. Okay. So I think we've gotten down to like the "one of us" story. So we're in our hero finally starts to get it and begins to bridge the gap. Some of the things some of the points are the lessons learned in this story. And you can tell us about story was that language makes all the difference in the world. This is what got me on to the part about the reporting, which we'll talk about a little while, but maybe you could fill us in on this discovery, this the story that got you to these points. Brian "Noid" Harden 3:37 Okay, so the team I'm working on I get asked the the thing in question is it was a pretty massive product and it had never had any threat modeling done, Bryan Brake 3:50 okay. Brian "Noid" Harden 3:51 So had never had any threat modeling done and this this particular product was made up of tons of little sub products. So what I did is I sat there first in a kind of a complete panic going, this is overwhelming. I don't have nearly enough time or resources to be able to do this. But you know how to eat the elephant, right? The small pieces and get at it. So I had one dev lead, who I know, had worked previously on a security product. And he was a nice guy. So I sat down with them and basically said, "Hey, could you walk me through visually diagramming how your service works, building that data flow diagram, and then we're going to talk about it from a security perspective". And he was sort of like, oh, that'd be fun. Yeah, let's do that. And so we sat there and he diagrammed and the whole time he's diagramming, he'd stop and erase things and go, Wait, no, no, we were going to do it that way. But we didn't. And then oh, and we stopped doing it this way, because we added this other thing and we had to be able to break communication out number channels and then he stopped at one point and was like, get a picture of this was like I think this is probably the most accurate diagram of our service we've ever had. And then when we started doing the threat modeling side of it, like, you know, talking about trust boundaries and you know, it's like all right, so what makes sure that you know data from point A to point B and it's not filled with that kind of thing? And I'm saying okay well, could you could you you know, do this over HTTPS rather than just regular HTTP Bryan Brake 5:29 right Brian "Noid" Harden 5:31 you know you get non repudiation you know, and it's like, not talking about even the security value of it, but talking more about the you know, you the integrity be there and then at one point, he stops and he looks at me and he says, Man, I never had a threat modeling would generate so much feature work. And in my mind, I was like, talking about feature work like, these are bugs you need to fix. Now, all of a sudden, it was like, Oh, crap, I've been approaching this entirely the wrong way my entire career. Devs look at things that have looked at depth look at things from bug fixing, and feature development. And as a security person, what i, every time I'd been bringing up stuff they needed to do in my mind, it was implied it was feature development. But they saw this bug fixing, because in the "dev world" security fixes or bug fixes. He saw the value here and went, Oh, this is going to generate a ton of feature work. And it's like, oh, so I gotta stop calling the security work. I've got to start calling this feature work. And sure enough, not only if you start calling it feature work. And of course now once you're talking about feature work, you can start talking about the drivers. Why are we building a feature because you know, you don't build features nobody wants. Unless you're certain software companies. But yeah, but you build.. you build features that come out of customer requests, you know, you get features that hey, you know, I look at things like say Microsoft Office, how that's evolved over the years. And that's because people who use Office come back and say, you know, this is really cool. But I'd really like it if when I'm giving my PowerPoint presentation, I had a timer on the screen. So I know I'm on mark, you know, and Okay, that's a feature requests. And so that's how these things evolve. And so once I started talking about security work from the perspective of feature development you know, we have existing features that need to be worked on to give them new functionality in order to be able to pick up new customers and we have new features that we need to build that will also help because the other thing too I also noticed is that well... well I care about things like confidentiality and integrity. Devs care about things like availability and performance, right, these two these two things can kind of be almost used interchangeably, depending on the circumstance, so when, when devs are talking about stability, I'm thinking about integrity. When I'm when I'm talking about availability, they're, they're thinking about performance. And so all of a sudden, I'm now giving them ideas for like new proof counters, basically, like new metrics to check the health of the thing that we're building. And the way I looked at it was almost... Yeah, this is what this is the business driver for the, you know, customer X wants it customer Y needs it, you know, and here's the benefit, you know, the product gets out of it. Here's the benefit that developers get out of it. And what a security get out of it? Hey, don't worry about it. Purely, purely any value I derived from this work is purely coincidental. Brian Boettcher 8:57 *Chuckles* Brian "Noid" Harden 9:00 And that, in turn, helps start driving the conversation a lot better. Because the other value I got out of it, too is by having somebody on the development side of the house who had a name and had some, you know, reputation behind him, he was able to go to his respective peers and say, Man, I did this thing with Noid and it was really valuable. And we got a lot of cool stuff out of it. So he's gonna hit you up about it. And I totally recommend doing Bryan Brake 9:27 right Brian "Noid" Harden 9:28 and at which point because because some of the folks I worked with were either indifferent towards me, they were just busy. I did have some folks that I work with, though, that were just flat out adversarial towards me. They frankly they didn't want me doing what I was doing. They didn't really want me parking and poking around like the dark corners of the product. You know, because it was going to make work, but having somebody on their side say, No, I actually got value out of this. Okay, well, I'll give it a try. Holy crap, I got value out of this, too. So that was that was where I suddenly realized that my languagein my mind, I'm not saying anything differently. But yet, it turns out that when it comes to the words coming out of my mouth and how they were being received, it radically changed how I was expressing myself to people. And it totally changed the response I got. Brian Boettcher 10:26 So maybe we need a new "CIA" triad that has the other words on it, you know, the, the translated words for development and product teams, Brian "Noid" Harden 10:35 possibly! Bryan Brake 10:36 performance... integrity is stability. Brian "Noid" Harden 10:43 Yeah, stability. availability... Bryan Brake 10:48 What's confidentiality then? what does the other bit that they talk about or worry about? Brian "Noid" Harden 10:52 I don't know if only we had a dev lead on this call. Brian Boettcher 10:55 *chuckles* Bryan Brake 10:56 Yeah. Do you know one? *laughs*. So, so the lessons learned, you said, language makes all the difference. You know the way you speak is like, you know, if you're, if you only know English, like most Americans and go over to France, speaking louder in English to somebody who only speaks French is not going to help here to help you so "look for the helpers" So let's say you don't, let's say we're not lucky enough to have somebody like the person you found in your organization is is it it's going to take a little bit longer maybe to get them onto your side to you know, poke at him like that or, you know, maybe grease the wheels with some donuts or you know, maybe take them to lunch or something. Would that be helpful at all? Brian "Noid" Harden 11:35 Well, first off Yes, you'd be amazed at how much showing up with donuts Bryan Brake 11:48 Oh, I know Brian "Noid" Harden 11:49 Oh yeah. No, actually actually it's funny too because I actually just a couple of weeks ago and other team at my company came over and gave my team donuts They gave my team the IT team and the tech team donuts because of all the work we've been putting in form... as far as I'm concerned. Yeah, I'll march directly into hell for those people right now, because they gave me donuts... Bryan Brake 11:56 niiiice. they better be Top Pot donuts or something legit not like... Brian "Noid" Harden 12:13 Oh, yeah, they were. They were Top Pot donuts. But yeah, so part of its that something else, too is doing some of the work yourself. So, in addition to all this work I'm doing I'm also managing the development of security features. And I had gone over the product spec for one of these security features. And I built a data flow diagram. And then during one of my little weekly Scrum meetings where I sit down with my devs. I showed it to them. and I remember one of them to and he immediately stopped and was like, "What is this?" He's like, "what is this doesn't make sense", Bryan Brake 12:53 This is forbidden knowledge This is your thing. Brian "Noid" Harden 12:56 Yeah, you wrote this. Okay, you wrote this, this is just a visual representation of the thing that you wrote. And once I explained it him, sort of the steps one through eleventy, you know, and showed him what had happened. He was sort of like a "Oh, that's interesting". Still somewhat dismissive of it, but it was still kind of a file. So in addition to, you know, buttering people up with donuts, and lunch and things like that, but also sometimes you gotta just buckle down and do it yourself, and then show the value. And I mean, I'll be blunt. That's how I've gone by through most of my career is when I can't get traction. I'll go do it. And then pop up and go. Hey, guys, check this thing out. Oh, wow. That's really neat. How do you do that? Where did you do that? It's like oh, you can do it too. Right now I can show you how I can work with you on it. I'm certainly not going to tell you to RTFM and walk out of the room. So part of it is it also shows a little bit of commitment on your part, sort of one of the things I've picked up that security, not even in the equation here. But just having worked in a lot of software development organizations with the devs and the PMs is the devs is frequently see the PM is not doing anything of value except for when you are. So when you are willing to put that kind of effort into deliver something like that, like, Hey, I thought modeled our service,it sort of shows this, "oh, I take it back. All those things I said about you know, you're not worthless after all." So there's definitely some value there too, because a lot of times too people are willing to say because it's easy to stand back and issue edicts, it's easy to stand back and just, you know, get up on your soapbox and tell everybody else what to do. But when you're when you show you're willing to eat your own dog food. That really gets people's attention because it's like, "Okay, this dude clearly cares about this a lot" And now that he's done it, I see what he's talking about. Yeah. You know, like we should do that there's value here. Bryan Brake 15:11 So very cool. Yeah. So when you on the last slide here, when you wrapped it all up, you said engage early and often... Does it have to be so when we're talking about communication, open communication, trying to, you know, some of its, you know, cultivating relationships. So, you kind of need to, you know, if you're introverted, you kind of need to step out of your shell a little bit and go and talk to people, get out of your cubes for once a while. Turn on the lights, that kind of thing. How often did you talk with these teams to help build this relationship after a while, because obviously there had to be some team building there? Brian "Noid" Harden 15:48 Yeah, so in my case, since I was in the team, we thought weekly, okay, weekly, and sometimes daily because they were literally down the hall from me, right, but in terms of where I've had to work in other organizations Where I've been in back in a centralized organization and having to work with remote teams or work with teams that I'm telling them to do things but I'm not in their org... like a weekly basis okay like we're going to meet up this weekbecause like for example like when I was a back when I was at Microsoft I worked in the MSRC before I left yeah and I was handling me and another guy we're handling all the (Internet Explorer)IE cases. Okay. That was a lot of cases because there's a lot of versions i right. So we would go meet with those cats once a week. And we would sit down with them and say, Okay, here's here's the queue. Here's what's new from last time. You know, here's sort of what we think is the priority for fixing things you know, what do you think about it, but it's it's that you always want them to know who you are, and you want them to know that you're just as busy as they are, and that you end that you're also respectful of their time, right? You know, so we'd make the meeting short... personal pet peeve of mine are people that set meetings deliberately long with the expectation of all just go ahead and give everybody 30 minutes. I'll give everybody 30 minutes back, right? Like, well thanks jerk. Like how about you could have just made a 30 minute meeting in the first place? You know it just tells that that that tells me you're not that doesn't tell me you're a magnanimous person that tells me you can't manage your time, you know. So I try to be really concise. Like, I'm going to set up a meeting with these devs. I'm going to include them agenda in the meeting invite. I'm going to set it for exactly how long I think it's like we're going to 30 minute meeting, you know, 30 minute meeting to go over the bugs that are in the queue. There's four new ones from last week one of them's really nasty, you know, that probably is probably going to be a non negotiable.. You know, but the other three are up for negotiation and you show up you sit down with them you know some pleasantries and then you just, you get to work and then you get them back out doing their thing and you get back to your thing. And that really flows well... It really flows well because, you know, none of us like meetings. And the closer you are to touching computers, the more meetings disrupt your flow the more they just disrupt your life and the thing that you're effectively getting usually paid a lot of money for.And so by kind of doing it that way, you keep that cadence up to keep that that sort of friendship and that that rapport up but the other thing too is a another point I wanted to make, but I'm getting tired... but yeah, but but along those lines to Yeah, yo get that rapport there. You're respectful of their time and then you... I can't remember what I was going to say next. Bryan Brake 19:20 So the last bit was, let's see, don't talk about securities, talk about feature development. We talked about that threat modeling your developers, you and Dr. Cowan, my, my car pool buddy, you and Crispin need to you know get get together and talk about the the threat modeling he's doing... he doesn't do trust boundaries so much, one of the talk he gave at SeaSec East was about how we do threat modeling in our organization but a lot of companies are starting to see value in that before we do engagements because we can prioritize what's the more important thing to test versus just testing all the things in the environment Brian "Noid" Harden 19:42 Threat modeling and software development is huge too, like that was one of the one of the things I think a lot of my developers I've done this with over the years have taken away from it is one you have to make it fun... You can't make a complete slog. But one of the nice things about threat modeling, is when you're visually looking at the thing you're going to build, that's when you make the realization that like, Oh, hey, my post office has no door... You know, and it's like the best time to figure that out. Then you always like, I always tell people that. Yeah, the best time to fix a bug is an alpha before you write anything... And the next best time to fix it is before it goes into production. And the worst possible time to fix a bug is after I've been in prod for 10 years, and it's a it's a load bearing bug at this point. It has dependencies on it Bryan Brake 20:30 you know what, it's funny you mentioned that I've been seeing some like Linux kernel bugs they said there was one in there for like 15 years old at affected all of like 2.6.x to up to the latest version. It was a use after free bug, you know that I don't know if they found the bug 15 years ago and just never fixed it but yeah, bugs like that sit in there because people don't don't check for that kind of stuff... Brian "Noid" Harden 20:51 that happens sometimes those the well I mean, God remember that. Remember the whole SYN flood thing in the 90s? Yeah, I mean it was it was it was in the RFC... One of those like, like, Oh, we found the bug. It's like what? You read the RFC. And just finally understood it. You know, so it's, it's that stuff. And there was an SSH bug that popped up recently. Yep. It was the same thing. It wasn't a terribly nasty critical bug. But it was, in a piece of code that had been in SSH for ever. Bryan Brake 21:26 Yeah. I seem to remember that one, too. Yeah. I'll have to find a link to that one. So I know you're getting tired. I have one other topic I'd like to discuss because I do a lot of report writing. Well, I I probably should do a lot of report writing but at Leviathan we you know we're the PM grease the wheels we you know, work with a relationship with the the status meetings, we do the executive summary and such and I could be better writing reports some of our testers are way better at it than I am... You know, taking the taking the whole idea of the language and where where things go with this, when we, when we put findings out, we've won, we call them bugs where we call them findings, not necessarily bugs. But what I'm trying to figure out is how we can better communicate our reporting, when we're doing things like readouts, to you know, kind of resonate with both developers and management because the idea is the executive summary is supposed to be for the "managers" or senior folk and then we have like, you know, components that drill down and talk about specifics and be more technical, but, you know, often we find ourselves and I find myself because I come from a more technical background writing more technical to the executives and my question was, Is there ways of communicating risk to both the developers and the managers in the, you know, using using somewhat the same language? Or should we call the bugnot bugs or not findings. We call them, you know, hey, here's a feature you guys should implement, which would be, you know, HTTP or, you know, you must have seen a few pen test reports in your time. And I mean, what is what is your opinion of pen test reports? Brian "Noid" Harden 23:13 So, my opinion, the most pen test reports, is that their garbage... Well, they're usually written to, they're usually written to one extreme or the other. So unfortunately, I have yet to find any really good language that appeases everybody. Brian Boettcher 23:30 So what's the one extreme or the other? Brian "Noid" Harden 23:32 What are the two extremes they're either hyper technical, the sort of stuff that like any of the three of us would probably look at and go, Okay, I get it, right. I understand the value here or there so high level that if I'm a business person, I might be sitting there going, Hey, okay, you know,you've you've reached out you've touched my heart. I understand that this this is a critical like this is a big issue we need to get fixed. But there's not enough meat there that if I took that report and handed it off to my dev lead and said, go fix this. The dev lead is going to sit there and go... Brian Boettcher 24:09 Are you kidding me? Brian "Noid" Harden 24:10 Yeah. Like, I don't know what to fix, according to this report says bad things can happen on the network. Are you telling me to go prevent bad things from happening on the network? So that's the thing. I find that Yeah, they either overwhelm you with details or there's not enough substance to them. Okay, so every once in a while, you get a really good one though, you get a you get a you get a really good one. If I could look at just a shout out to CoalFire actually, like their reports. Unknown 24:39 I mean, okay, So, What is a happy medium type report for you? One that would satisfy the manager folks but also get with, you know, be technical enough. What kind of things would you like to see in reports that you get from them and feel free to you know, talk about the Coalfire thing I guess Brian "Noid" Harden 25:02 *Chuckles* Bryan Brake 25:06 *Chuckles* We're always trying to improve our reports that Leviathan we've gone through and done things like test evaluations and you know things like that and no it's fine you know they're they're cool with me doing my podcast on the side so but if you had when you get reports... the good ones... What do they look like well I mean what what kind of things that you're looking for and and and in a pen a proper pentest report? Brian "Noid" Harden 25:30 Well for me being a technical person one of the things... the biggest thing I'm looking for in a report repro steps, right? If you haven't given me clear repo steps, then you have given me a useless report and that's the thing I've seen reports were basically it's... you know, hey man, we all we popped your domain controller you know, we did this we did that. Look at all freaking awesome we are... And you're like, Okay, I didn't hire you guys to be a circus sideshow. I hired you guys to show me where my risk is, and so I can focus my I know where to focus my efforts. And so those types of so those types of like, "look at how badass I am" reports don't do anything for me... what I do like there were reports that say hey you know we found a cross site scripting vulnerability on this particular product in this particular area. And here is not only screenshots of the cross site scripting vulnerability happening, but here's the repro steps because what's going to happen is, for example, you know, I see something like that and I go, Well, we got to fix that. I'm going to go to my developers. And the first thing my developers are going to ask me is, can you repro it? Can I read through it because one of the things they're going to do is after they fix it, they're going to validate the fix if they don't know how it was exploited in the first place. They're not going to know how to validate the fix. So being able to provide that information... down is is huge for me. Um, but then again, I'm also not, you know the business guy, I'm not the big money guy, I'm I want my report to be technical right so would the executives of my company get the same value out of the report? I probably not... you know when you're talking to the much higher level non technical people what you need to be doing is you need to be making sure you're talking in terms of risk. Sure, you know, you're talking in terms of risk and you're talking in terms of a not technical risk... You know, at the end of the day, the CEO of the company doesn't give a damn that SMBv1 is still on the network, right? They might not even know what that is, right? odds are I'm gonna I'm gonna go out and say they probably don't know what that is. Um, and even in that doesn't mean explain to them what it is because they're not going to care so first. We're going to go from not knowing what it is to not caring what it is. But if you express things in terms of risk of that, you know, the current network architecture, as it stands is very fragile and could be easily brought down, you know, through almost potentially accidental behavior, let alone. malicious behavior. You know, resulting in outages and SLA violations right now, you got their attention, because what they hear there is also if I don't fix this, it might cost me money. Brian Boettcher 28:36 profit loss. Brian "Noid" Harden 28:37 Yeah, and that's the thing. It's the, you know, depending on where they're at, in the org structure, you know, I've been in I've been in plenty of organizations before where downtime... downtime is bad... downtime is just, I mean, downtime is never good. But I mean, I've been in organizations where it's like, okay, so I just got promoted to like, super uber director guy. 48 hours into the gig. You know, we had like, a two hour outage,... I'm done. Bryan Brake 29:08 Busted that SLA, big money... Brian "Noid" Harden 29:10 even though even though I had nothing to do with it, I'm the accountable one. So, yeah, you have, you know, you need to be able to express things in terms that they translates to, you know, finding out like, like one of the things I back when I used to be a consultant, one of the things I always ask the executive types I'd meet on jobs is what keeps you up at night. You know, what keeps you up at night? Like what you know, don't don't worry about what I'm concerned about, what are you concerned about? Because they might be the same thing. I'm just going to talk to you about it using again, using the words that you care for and understand because I see a lot of technical people try to describe risk to non technical people and they do it by being highly technical and when it's not being understood. They fall back to being even more they take the approach of being in France... not speaking French. So I'm going to speak slower and louder, right? And, and at the end of the day, they're just going to keep shaking their heads going, Man, this guy really wants to express something to make. Bryan Brake 30:18 Yeah, something must be really important... Brian "Noid" Harden 30:20 ...to agitated by it. I don't know what it is... Bryan Brake 30:23 Great, now it's blue monkey poo. I don't know what's going on. Brian "Noid" Harden 30:26 Yeah, so that's, that's it. So yeah. When you're when you're talking to leadership, expressing things in terms of the contract violations, SLA violations, financial financial impact, right? You know, like, like, one of the things I liked when PCI came out and they had like these ridiculous up to $10,000 per bit of PII that gets disclosed and then you explain to a room full of high level people that and if blank were to happen 40,000 bits of PII .would be exposed a you knnow and I'm not so good at math but my calculator here tells me at $10,000 a pop and you watch people in the room real quiet... Bryan Brake 31:10 oh yeah no that now you know the thing is you just haven't seen a Leviathan one yet so you know if you want to you know reach out to us we'll do a pentest for you we when we don't mind coming out and hanging out doing pen tests for you so Brian "Noid" Harden 31:24 Frank's a good friend, solid solid human being Bryan Brake 31:26 no I mean will take your money and will give you a good will give you good drubbing. You will not get up and down left and right. You'll make it hurt. So anyway, actually, yeah, we we actually might need to talk about that a little bit later. I would not hate on that. I get money when people come in its new business. So yeah, I wouldn't hate on that at all. Brian Boettcher 31:47 I like in in your last phrase or last sentence in your presentation. If you can, avoid even using the word security. I think that's a good summary of what we talked about. Bryan Brake 32:00 Yeah, that got me too. I was like, Wow. Okay. So it's like, it's like the buzzword you're not supposed to say or, you know, like, you get a shock.. Brian "Noid" Harden 32:08 Treat it like a game. Yeah. Yeah, you got it like a game. But you you'd be amazed it works Bryan Brake 32:16 hundred percent of the time. It works every time? Brian "Noid" Harden 32:18 Yeah, hundred percent of the works every time. But, ya know, it it it definitely works because there are people too because there's conditioning, right. The history between security people and software developers is deep and it goes back Bryan Brake 32:33 it's contentious Brian "Noid" Harden 32:34 it's contentious at times. And, you know, obviously, you know, you try to try to try to be a good human being, trying to better the world around you. You know, try to,when you whenever you go somewhere, try to leave it in a better condition than you found it. But also understand that the person who may have been there for you may have just straight up just f the place up Brian Boettcher 32:58 scorched earth Brian "Noid" Harden 32:59 Yep, yeah. so and so. Yeah. And sometimes, because, I mean, I've got, I've rolled into organizations before where it's like, Why are these people so mad at me? I just got here... And it's like, oh, because the guy you replaced was just got off. And then and it sucks because it's not fair that you have to rebuild those damaged relationships because you didn't damage them. but life ain't fair? Bryan Brake 33:22 Yep. Well, you know, what, the, the, the whole, you know, DevOps and those things, that was the, you know, the Elysian Fields for developers like, Oh, I can go do anything and enjoy everything, and then it's like, you know, we're, the "no" department where the, we're the where the ones are going to put manacles on them. So, you know, security folks have have got to learn to be flexible, compliance folks can't wield their hammer anymore, like they, they should, if they want to, you know, play with the developers in the devops and the management folks, we talked about this with Liz rice couple weeks ago about getting, you know, security into the devops area and it's like one we got it we gotta learn to be flexible we've got to help them understand that now yeah the bug feature stuff if I'd heard this when we were talking to her I'm almost certain she would agree with us on the fact that you know we can't treat security like security we have treated as feature enhancement in this case Brian "Noid" Harden 34:16 it is a feature, you know it is a feature and increase the stability of the product that can get increases the customer base of the product it's right it has all the same things to it that any other feature would, but yeah but as far as the security being the note apartment thing to something else is like I still run into security people that they look at themselves as the "No" department that kind of pride themselves on Yeah, and when you find those people just call them out. I mean, just just tell them like, Look, man, that doesn't work. It's never work. Stop it now. Because when you're viewed as the "no" department, no one will ever want to work with you. Why would you want to? Bryan Brake 34:57 Yep... you're a non-starter Brian "Noid" Harden 34:59 Yeah, what's go because that was a bit of career advice I got at one point was that basically be solutions focused. You know, nobody wants to basically you're not going to go anywhere if you're the person who's calling out the problem and you might be calling out the problem more articulately than anybody else in the room, you might have a better understanding of the scope of them the depth of the problem, but there is a whole class of manager out there that will just be like, Man, that Noid guy, nothing but problems. Whereas if you instead say, you know, you kind of focus on the sort of the not really the problem, but rather you focus on the solution... "be solutions oriented" to sound like a business guy for a second. And it's like, yeah, you'd be that solutions oriented person, and especially if you can do it with a sort of positive spin, like I had a boss at one point I would stop in his office pissed off every once in a while, and I just be like this is screwed up and that screwed up and blah, blah blah. And he stopped and go "leave my office now and come back in and restate everything you just said. But in a positive way." I don't even know how it will then go sit in the hallway for a few minutes she would come back and I'd be like, okay,we have an opportunity for us. And I tell you I hated them for it. But name if it didn't work. Bryan Brake 36:32 Oh god. Yeah, that would make complete sense. Yeah, coming in with a positive instead of negative. Brian "Noid" Harden 36:40 So that's the thing. It's like yeah, even when your negativity is spot on and accurate. There's a lot of people that are like.. "ugh the person is always negative" And then sure enough, yeah, you start focusing on like, oh, you're the positive solutions oriented guy. Even while you're telling them that it's all basically like we're all going to Hell, but I'm doing it in a positive solutions oriented manner, and you'd be amazed how much traction I get you. Bryan Brake 37:06 Mr. Boettcher, do you have any other thoughts or questions? I want to let Mr.Noid go, cuz he's getting a little ty ty, he's a bit sleepy and he needs to go to bed... Brian Boettcher 37:15 There's a lot of great tidbits in here. I'm gonna have to listen to it again, and get all of them. And, and again, there's a lot of manager tools references here and, and manager tools, if you're not a manager, that's okay. It's not for managers, all that stuff they talk about is is really valuable to all employees. Brian "Noid" Harden 37:39 What's it called, the manager tools podcast? Bryan Brake 37:42 Yep.It's been going on for 12 years. Brian Boettcher 37:45 Since 2006 Bryan Brake 37:46 Yeah, something like that. It's it's very big. We put a link to the three powers three types of power and one to rule them all in the in the show notes as well. So yeah, go listen to that. I listened to that it's it's one of my regular non-info sec podcast that I listened to, so I listen to it every Monday morning, and when I'm on the treadmill at the gym, so yeah, really, really excellent stuff. If you're, you're out there and, you know, yeah, I mean, it'll help you kind of understand, but if you're out there and you're not a manager yet, it might help you understand where your managers coming from, too. All right. Mr. Noid how would people get a hold of you if they wanted to maybe have you for more podcasts appearances or, you know, speaking engagements or whatever? Are you going to be speaking anywhere soon? Brian "Noid" Harden 38:39 Am I I don't know. No, I don't think I am right. Sorry. Are you going anywhere? So question? I am there you go. I am speaking soon. Yeah, I'm, I'm speaking at the NCC group. Open Forum. Oh, that's right. That's next weekend. I don't think it's actually been announced yet. Okay. It's I mean, it's cool for me to talk about it. But yes, it's... Bryan Brake 39:02 the 12 (of March) yeah it is the 12th in Fremont, so if you're outside of the Seattle area you're going to be SOL.. yeah they don't record that Brian "Noid" Harden 39:15 but but I'm going to be giving basically the abbreviated version of my besides talk. they had they had an empty slot they needed to fill up... and they basically said could you do it I said sure and then they said it's 30 minutes long and I'm like well my talks an hour, but how will will make it work... they're I think they're a Tableau up in Fremont... Bryan Brake 39:37 yeah I'm on that list and yeah I know Miss Crowell over there who's one of the senior managers at NCC she's great lady... she's actually not running she used to run it and and gave somebody else but she still helps out a when she can but yeah, really, really great quarterly open forum that NCC group puts out. Plus they put out a nice spread for dinner certainly good Brian "Noid" Harden 40:00 I haven't been the one in a while, but they usually a lot of fun. I wouldn't last one of those I went to was a TLS 1.3 Bryan Brake 40:09 I was at that one too. Brian "Noid" Harden 40:10 That worked out great. Because literally the following weekend, I spoke at DC 206 nice about TLS 1.2 right? and ended up getting Joe to come along and speak about TLS 1.3 and a much more authoritative manner than I could have. It's bad ass. Bryan Brake 40:24 Yeah, Joe. Joe was on the steering committee for that. Brian "Noid" Harden 40:28 Yep. Yeah, I think but yeah, that was also nice. He kept me honest. While I was given my talk. I periodically just look at them any kind of nod. I'm not going into the weeds yet. But yeah, as far as getting a hold of me goes the best way to do it is I'm on Twitter @_noid_ or you can email me at noid23@gmail.com Bryan Brake 40:52 Yeah so yeah if you're in the Seattle area and the downtown Seattle area or Fremont area that's really nice place I think parking I think was at a premium The last time we were there Brian "Noid" Harden 40:52 It's Fremont, parking is always at a premium Bryan Brake 40:52 they're dodging bikes or whatever like motorized bicycles or whatever so you know Brian Boettcher 40:52 scooters now Bryan Brake 40:52 yeah I mean Fremont area they're really weird about their bicycle laws and stuff up there so Brian "Noid" Harden 41:07 ...and zoned parking so watch for your park too Bryan Brake 41:32 I'm going to get Miss Berlin because you know she's got a lot going on she's you know heading up the mental health hackers group.. you can find her was it hacker... god I hate this, um... she's @infosystir on Twitter. hackers mental health is her nonprofit. She's running that and you can find that @hackershealth on Twitter, she will come to your convention or conference and do a village. And and, you know it's a nice chill area you can go to, if you're interested in doing that Brian "Noid" Harden 42:12 is truly doing the Lord's work too. Bryan Brake 42:14 Yes she is. And we're very proud of her for all that she's doing. So yeah, her and Megan Roddy who's also one of our slack slack moderators... So speaking of our slack we have a very active slack community we just like I said we have "JB" who was promoted to moderator because it's been far too long and he's been doing the the European and Asia book club and he should have been a moderator for a while so did that today gave him access to our secret moderator channel and such and but yeah we have a social contract you can join us by emailing bds.podcast@gmail.com or hitting our Twitter which is the the podcast Twitter @brakesec and you can follow me on Twitter.@bryanbrake. Mr. Boettcher, you got a lot going on to sir how would people find you if we wanted to talk about the log MD stuff? Brian Boettcher 43:10 yeah you just go to log-MD.com... Don't forget the dash right otherwise you'll you'll get some well nevermind... Bryan Brake 43:20 Is it like WhiteHouse.com *laughs* that's an old joke kids! Brian Boettcher 43:26 I'd like to say though if you if you do go by your developers donuts or whoever don't eat any between the pickup and drop off right because then you'll show up with four donuts and they'll be like oh thanks great there's 10 of us and you bring us for Donuts Bryan Brake 43:41 {imitating Forrest Gump]"I had some sorry" Don't do that yeah yea buy 13 donuts and then eat one for yourself and then say you got it doesn't you go yeah so you're making an appearance you're going to be Bsides Austin at the end of the month along with Ms. Berlin's going to be that one as well. I think? Brian Boettcher 44:00 I am... Megan's going to be there I'm not sure. Very cool as her home base so we'll see. Nice. Yeah and the classes are cheap. I don't know if they're sold out yet but it's like $100 bucks. Bryan Brake 44:13 Okay, awesome. Cool. Before we go, we have a store. If you want to go buy a T shirt for the Brakeing Down Security logo, you know, you can definitely go do that or get one with Miss Berlin's face on it. Which is very weird but it's still very cool I'm going to probably by pink one here in the next few weeks and thank you to our patrons people who help support the podcast but donating some money helps pay for hosting pays for the time that we're doing this also we're looking into adding some possible transcription services we've gotten a couple emails from people who are saying they want to get transcriptions of us saying "uh, um, ah" lot so I actually actually it was a gentleman by the name of Willie I think was said head hearing difficulties so he wanted to know if we had a transcription of the podcast and I feel really bad because I'm like I don't know how to reply to him and say I you know we're just a little mom and pop shop here so we're looking at transcription services maybe something like Mechanical Turk or there was one called otter.ai that we're we're looking at to maybe kind of make it better for people to hear these things Brian "Noid" Harden 45:26 I'm actually actually suffer from degenerative hearing loss. I'm slowly going deaf myself Bryan Brake 45:31 I've got tinnitus is from the Navy Brian "Noid" Harden 45:32 same here. It's permanent and ongoing. And just yeah, it's like I feel for him. Yep. And hopefully transcriptions will be a thing at some point. Yeah, god's I hope so. Yeah, I mean, other than the US and about 800 times during podcast I apologize for that. But yeah, so we're, we're trying to look into that if if we can make it work we will we will do our utmost to make the podcast as available as possible to everybody. So in end up to be we have to hire somebody, he'll do it for us. So that that may be another thing, which means will need more pot Patreon money, you know that kind of thing. So if you're interested in getting full transcripts we may make that possible if we can get another maybe 20 to 30 people a 20-30 bucks a month. So but we do appreciate that the tips the you know we call them tips because you're helping to support the podcast and helping us get this out. And yeah, so for Miss Berlin who's not here sadly. And she's going to be kicking yourself because this was a really awesome podcast and Mr. Boettcher. This is Brakeing Down Security from a world headquarters here in Seattle. Have a great week. Be nice to another. Please take care of yourselves because you're the only you have and we'll talk again soon. Brian Boettcher 46:45 Bye bye Brian "Noid" Harden 46:46 Bye Internet people. Transcribed by https://otter.ai

In this episode... James and I host legitimate Polynesian royalty (a princess....) really! Katie gives us the skinny on Microsoft's 10 year progression to get to a bug bounty program We discuss the merits of bug bounties and execution in a very large enterprise Katie gives us as many details as she can about the recent $100,000 payout Much... much ... more! Guest Katie Moussouris ( @k8em0 ) - Katie runs the Security Community Outreach and Strategy team for Microsoft as part of the Microsoft Security Response Center (MSRC) team to help drive crucial elements of our security community strategy effort. She is a Senior Security Strategist Lead, and let's not sell her short - she is royalty!She created and drove the first ever Microsoft security bounty programs (www.microsoft.com/bountyprograms). Which received 18 vulnerabilities and a new attack technique that will help Microsoft build stronger defenses that will protect the entire platform from this new class of attack.She serves as lead subject matter expert in the US National Body for the ISO work item 29147 "Vulnerability Disclosure", scheduled for publication in 2013, and does countless other efforts associated with the ISO standards body and various other industry groups. 

TMT: Fitness Part 3 of 5.

TMT: Fitness Part 2 of 5.

TMT: Fitness Part 1 of 5.

TMT: Administration.

TMT: Goals.

TMT: Introduction and Background.

Two Minute Tips Pilot Episode.

Greg Wroblewski has a Ph.D. in Computer Science and over 15 years of software industry experience. At Microsoft he is a member of a team of security researchers that investigate vulnerabilities and security threats as part of the Microsoft Security Response Center (MSRC). The team works on every MSRC case to help improve the guidance and protection we provide to customers through our security updates and bulletins by discovering additional attack vectors, new exploitation techniques and adapting quickly to stay ahead of the ever evolving security ecosystem. This team also provides forward looking security guidance to product teams within Microsoft, impacting products that have and have not shipped and ultimately helping to protect Microsoft customers from getting their systems compromised by building more resilient software. During past few years he has worked on some of the high profile security flaws, overseeing investigation, production and release of up to 20 Microsoft's security bulletins per year. Prior to joining Microsoft he was doing academic research in reverse engineering and code obfuscation techniques.

Greg Wroblewski has a Ph.D. in Computer Science and over 15 years of software industry experience. At Microsoft he is a member of a team of security researchers that investigate vulnerabilities and security threats as part of the Microsoft Security Response Center (MSRC). The team works on every MSRC case to help improve the guidance and protection we provide to customers through our security updates and bulletins by discovering additional attack vectors, new exploitation techniques and adapting quickly to stay ahead of the ever evolving security ecosystem. This team also provides forward looking security guidance to product teams within Microsoft, impacting products that have and have not shipped and ultimately helping to protect Microsoft customers from getting their systems compromised by building more resilient software. During past few years he has worked on some of the high profile security flaws, overseeing investigation, production and release of up to 20 Microsoft's security bulletins per year. Prior to joining Microsoft he was doing academic research in reverse engineering and code obfuscation techniques.