POPULARITY
In this edition of Snake Oilers three vendors pitch host Patrick Gray on their tech: Pangea: Guardrails and security for AI agents and applications (https://pangea.cloud) Worried about your AI apps going rogue, being mean to your customers or even disclosing sensitive information? Pangea exists to address these risks. Fascinating stuff. Cosive: A threat intelligence company that can host your MISP server in AWS. CloudMISP! (https://www.cosive.com/snakeoilers) Are you running a MISP server on some old hardware under a desk in your SOC? There's a better way! Cosive can run it for you on AWS so you can just use it instead of wrestling with maintaining it. They also do some CTI consulting to help you get better use out of MISP. Sysdig: A Linux runtime security platform (https://sysdig.com/) The modern Windows network is an all-singing, all-dancing, perfectly orchestrated, EDR-protected ballet. The modern Linux production environment… isn't. Find out how Sysdig can help you get some visibility and control over your Linux fleet. This episode is also available on Youtube. Show notes
In this episode, we sit with security leader and venture investor Sergej Epp to discuss the Cloud-native Security Landscape. Sergej currently serves as the Global CISO and Executive at Cloud Security leader Sysdig and is a Venture Partner at Picus Capital. We will dive into some insights from Sysdig's recent "2025 Cloud-native Security and Usage Report."Big shout out to our episode sponsor, Yubico!Passwords aren't enough. Cyber threats are evolving, and attackers bypass weak authentication every day. YubiKeys provides phishing-resistant security for individuals and businesses—fast, frictionless, and passwordless.Upgrade your security:https://yubico.comSergj and I dove into a lot of great topics related to Cloud-native Security, including:Some of the key trends in the latest Sysdig 2025 Cloud-native Security Report and trends that have stayed consistent YoY. Sergj points out that while attackers have stayed consistent, organizations have and continue to make improvements to their securitySergj elaborated on his current role as Sysdig's internal CISO and his prior role as a field CISO and the differences between the two roles in terms of how you interact with your organization, customers, and the community.We unpacked the need for automated Incident Response, touching on how modern cloud-native attacks can happen in as little as 10 minutes and how organizations can and do struggle without sufficient visibility and the ability to automate their incident response.The report points out that machine identities, or Non-Human Identities (NHI), are 7.5 times riskier than human identities and that there are 40,000 times more of them to manage. This is a massive problem and gap for the industry, and Sergj and I walked through why this is a challenge and its potential risks.Vulnerability prioritization continues to be crucial, with the latest Sysdig report showing that just 6% of vulnerabilities are “in-use”, or reachable. Still, container bloat has ballooned, quintupling in the last year alone. This presents real problems as organizations continue to expand their attack surface with expanded open-source usage but struggle to determine what vulnerabilities truly present risks and need to be addressed.We covered the challenges with compliance, as organizations wrestle with multiple disparate compliance frameworks, and how compliance can drive better security but also can have inverse impacts when written poorly or not keeping pace with technologies and threats.We rounded out the conversation with discussing AI/ML packages and the fact they have grown by 500% when it comes to usage, but organizations have decreased public exposure of AI/ML workloads by 38% since the year prior, showing some improvements are being made to safeguarding AI workloads from risks as well.
Sysdig's 2025 Cloud-Native and Security Usage Report is hot off the presses, and Corey has questions. On this episode, he's joined by Crystal Morin, a Cybersecurity Strategist at Sysdig, to break down the trends of the past year. They discuss Sysdig's approach to detecting and responding to security and the success the company has seen with the rollout of Sysdig Sage (an AI product that Corey thinks is actually useful). They also chat about what's driving a spike in machine identities, practical hygiene in cloud environments, and the crucial importance of automated responses to maintain robust security in the face of increasingly sophisticated cyber threats.Show Highlights(0:00) Intro(0:39) Sysdig sponsor read(2:22) Explaining Sysdig's 5/5/5 Benchmark(4:06) What does Sysdig's work entail?(10:03) Cloud security trends that have changed over the last year(14:30) Sysdig sponsor read(15:16) How Sysdig is using AI in its security products(19:09) How many users are adopting AI tools like Sysdig Sage(25:51) The reality behind the recent spike of machine identities in security(29:24) Handling the scaling of machine identities(35:37) Where you can find Sysdig's 2025 Cloud-Native and Security Usage ReportAbout Crystal MorinCrystal Morin is a Cybersecurity Strategist with more than 10 years of experience in threat analysis and research. Crystal started her career as both a Cryptologic Language Analyst and Intelligence Analyst in the United States Air Force and as a contractor for Booz Allen Hamilton, where she helped develop and evolve their cyber threat intelligence community and threat-hunting capabilities. In 2022, Crystal joined Sysdig as a Threat Research Engineer on the Sysdig Threat Research Team, where she worked to discover and analyze cyber threat actors taking advantage of the cloud. Today, Crystal bridges the gap between business and security through cloud-focused content for leaders and practitioners alike. Crystal's thought leadership has been foundational for pieces such as the “2024 Cloud-Native Security and Usage Report” and “Cloud vs. On-Premises: Unraveling the Mystery of the Dwell Time Disparity,” among others.LinksSysdig's 2025 Cloud-Native and Security Usage Report: https://sysdig.com/2025-cloud-native-security-and-usage-report/Sysdig on LinkedIn: https://www.linkedin.com/company/sysdig/Crystal's LinkedIn: https://www.linkedin.com/in/crystal-morin/SponsorSysdig: https://sysdig.com/
This week on The Business of Open Source I had a slightly different conversation: I spoke with the CFOs of two open source companies, Sysdig and Percona, to better understand what is different (and what is not) about financial management in open source companies. Karen Walker is the CFO at Sysdig, and Eileen Doody is the CFO at Percona. They both joined me to talk about the CFO role in general and the CFO role in particular at an open source company. Why did I do this episode? Many founders I've spoken with are a bit unclear on the role of a CFO — whereas I've never spoken with a founder who had trouble understanding what their CTO does. Here's some takeaways from our conversation: Part of the CFO's role is about thinking about open source strategically, in terms of how the open source project is going to fit into the company's overall strategy.Because open source is so ingrained in the company, it doesn't fit into a single budget line item; it's impossible to break out and say ‘we spend $X on open source' because it's so integrated into everything the company doesHow do you measure your ROI on investment in open source? At Sysdig, two out of three prospects come to the company because of Falco, their open source project. We also talked about the ecosystem effects of having a huge footprint with your open source project; it's hard to measure the positive influence of having massive brand awareness, but both CFOs are convinced that it is very important to the company. Eileen says that many CIOs now have mandates to look for open source solutions when possible, which was not the case a decade ago. That's changed the dynamic for a company like Percona that's based around open source. Another reason I did this episode is because while I usually have founders on the podcast, there are some really important perspectives from other leadership team members. Part of the the role of a CEO is to understand all the other C-level leadership position's roles and responsibilities, and in my experience the CFO is one of the less well understood roles. In fact, we wrapped up the conversation by talking about how a CFO can be a real strategic partner that's forward-thinking rather than just the bean-counter that some people expect a CFO to be. A couple things to mention. First of all, if you want to learn more about my consulting work with open source companies, you can do so here. Second, if you want to chance to connect with other founders of open source companies, consider joining Open Source Founders Summit this May 19th and 20th in Paris.
Suresh Vasudevan, CEO of Sysdig, discusses the evolving challenges of cloud security incident response and the need for new approaches to mitigate organizational risk.Topics Include:Cybersecurity regulations mandate incident response reporting.Challenges of cloud breach detection and response.Complex cloud attack patterns: reconnaissance, lateral movement, exploit.Rapid exploitation - minutes vs. days for on-prem.Importance of runtime, identity, and control plane monitoring.Limitations of EDR and SIEM tools for cloud.Coordinated incident response across security, DevOps, executives.Criticality of pre-defined incident response plans.Increased CISO personal liability risk and mitigation.Documenting security team's diligence to demonstrate due care.Establishing strong partnerships with legal and audit teams.Covering defensive steps in internal communications.Sysdig's cloud-native security approach and Falco project.Balancing prevention, detection, and response capabilities.Integrating security tooling with customer workflows and SOCs.Providing 24/7 monitoring and rapid response services.Correlating workload, identity, and control plane activities.Detecting unusual reconnaissance and lateral movement behaviors.Daisy-chaining events to identify potential compromise chains.Tracking historical identity activity patterns for anomaly detection.Aligning security with business impact assessment and reporting.Adapting SOC team skills for cloud-native environments.Resource and disruption cost concerns for cloud agents.Importance of "do no harm" philosophy for response.Enhancing existing security data sources with cloud context.Challenges of post-incident forensics vs. real-time response.Bridging security, DevOps, and executive domains.Establishing pre-approved incident response stakeholder roles.Maintaining documentation to demonstrate proper investigation.Evolving CISO role and personal liability considerations.Proactive management of cyber risk at board level.Developing strong general counsel and audit relationships.Transparency in internal communications to avoid discovery risks.Security teams as business partners, not just technicians.Sysdig's cloud security expertise and open-source contributions.Participants:· Suresh Vasudevan – CEO, SysdigSee how Amazon Web Services gives you the freedom to migrate, innovate, and scale your software company at https://aws.amazon/isv/
In today's interview, Mirela Ciobanu, Lead Editor at The Paypers, talks with Sergej Epp, CISO at Sysdig, about the ever-evolving world of cybersecurity and its impact on industries worldwide.
In today's interview, Mirela Ciobanu, Lead Editor at The Paypers, talks with Sergej Epp, CISO at Sysdig, about the ever-evolving world of cybersecurity and its impact on industries worldwide.
What if sales success wasn't just about the money? Join us as we challenge this age-old myth with insights from Jim Gannon, SVP of Sales at Sysdig. Discover how autonomy, competition, and a genuine drive to impact the business play pivotal roles in achieving sales excellence. Jim reveals why curiosity and the willingness to learn from peers set top performers apart, shedding light on the motivations that propel seasoned pros and ambitious newcomers alike.The episode further unpacks the essence of team dynamics with a spotlight on recognition and accountability. By celebrating the collective efforts of everyone from sales engineers to onboarding teams, we uncover how fostering an inclusive culture strengthens team cohesion. Jim dives into the balancing act leaders face in maintaining a positive yet accountable environment, emphasizing the critical role of enablement and data-driven insights in recognizing high-performing teams.Leadership and mindset take center stage as Jim shares his experiences leading in Japan, offering valuable lessons on cultural awareness and scalable processes. Explore how a winning attitude, even against fierce competition, can be nurtured within sales teams. From strategies for private companies to tales of overcoming odds in the sports world, this conversation is your playbook for elevating sales performance and leadership prowess. Don't miss Jim's engaging stories and practical advice that promise to inspire and transform.Chapters:(00:00) Busting Sales Myths With Jim Gannon(12:08) Fostering Team Recognition and Accountability(19:05) Enhancing Sales Enablement Through Accountability(28:01) Building a Winning Mindset in Sales(33:51) Enhancing Customer Success in Sales(38:55) Casting a Leadership Shadow(42:53) Cultural Awareness and Training StoriesTakeaways:Sales Motivation Beyond Money: Jim Gannon challenges the common myth that salespeople are primarily driven by monetary incentives. He emphasizes that autonomy, competition, and the desire to impact the business are key motivators. Understanding these can help CROs better tailor their leadership and incentive structures.Curiosity as a Differentiator: Top-performing salespeople often exhibit a strong sense of curiosity and a willingness to learn. CROs should foster an environment that encourages intellectual engagement and peer learning to enhance team performance.Recognition and Accountability: Building a cohesive sales team involves recognizing contributions from all team members, not just those who close deals. CROs should focus on fostering a culture of inclusivity and accountability, which aligns with company values and encourages collective success.Sales Enablement and Data-Driven Coaching: Effective sales enablement requires moving beyond content overload to live training sessions and leveraging tools like Gong for data-driven coaching. CROs should ensure their teams have access to insights that can improve performance and identify areas for development.Building a Winning Mindset: In challenging market conditions, CROs should inspire their teams by sharing stories of underdogs who have succeeded against the odds. This helps instill confidence and drive, encouraging teams to execute the basics with excellence.Cultural Awareness in Global Leadership: For CROs overseeing international teams, understanding cultural nuances is crucial. Jim's experiences in Japan highlight the importance of cultural sensitivity and the concept of a "leadership shadow" in global contexts.Leveraging Competitive Spirit: Salespeople who thrive often enjoy the challenge of competing against larger, better-branded competitors. CROs can harness this competitive spirit by encouraging strategies that focus on differentiation and value delivery.Balancing Inspirational Leadership with Accountability: Jim emphasizes the need for CROs to balance inspirational leadership with creating a culture of accountability. This involves setting high standards while motivating teams to achieve them through clear, consistent expectations and support.Ways to Tune In:Spotify: https://open.spotify.com/show/0Yb1wPzUxyrfR0Dx35ym1A Apple Podcasts: https://podcasts.apple.com/us/podcast/coach2scale-how-modern-leaders-build-a-coaching-culture/id1699901434 Google Podcasts: https://podcasts.google.com/feed/aHR0cHM6Ly9mZWVkcy50cmFuc2lzdG9yLmZtL2NvYWNoMnNjYWxlLWhvdy1tb2Rlcm4tbGVhZGVycy1idWlsZC1hLWNvYWNoaW5nLWN1bHR1cmU Amazon Music: https://music.amazon.com/podcasts/fd188af6-7c17-4b2e-a0b2-196ecd6fdf77 Podchaser: https://www.podchaser.com/podcasts/coach2scale-how-modern-leaders-5419703 YouTube: https://www.youtube.com/@Coach2Scale CoachEm™ is the first Coaching Execution Platform that integrates deep learning technology to proactively analyze patterns, highlight the "why" behind the data with root causes, and identify the actions that will ultimately improve business results going forward. These practical coaching recommendations for managers will help their teams drive more deals, bigger deals, faster deals and loyal customers. Built with decades of go-to-market experience, world-renowned data scientists and advanced causal AI/ML technology, CoachEm™ leverages your existing tech stack to increase rep productivity, increase retention, and replicate best practices across your team.Learn more at coachem.io
In deze aflevering van de Nederlandse Kubernetes Podcast nemen Ronald Kers (CNCF Ambassador) en Jan Stomphorst (Senior Solutions Architect bij ACC ICT) je mee in de wereld van runtime container security. Samen met gast Alba Ferri, Senior Customer Solutions Engineer bij Sysdig, bespreken ze hoe tools zoals Falco en eBPF helpen om Kubernetes-clusters in real-time te beveiligen en inzicht te bieden in wat er daadwerkelijk gebeurt in je omgeving.Alba legt uit hoe Falco, een open-source tool, gebruikmaakt van eBPF om systeemaanroepen te monitoren en verdachte activiteiten te detecteren, zoals ongewenste toegang tot containers, verdacht netwerkgedrag, of pogingen om gevoelige bestanden te benaderen. Daarnaast gaat ze in op hoe organisaties Falco kunnen inzetten om niet alleen bedreigingen te voorkomen, maar ook inzicht te krijgen in het gedrag van hun containers en clusters.Belangrijke onderwerpen in deze aflevering:Wat Falco en eBPF uniek maakt in het beveiligen van containers tijdens runtime.Hoe Falco standaardregels biedt én aanpasbaar is voor specifieke omgevingen.Het verschil tussen open-source Falco en Sysdig's enterprise-oplossingen.Praktijkvoorbeelden van hoe organisaties met Falco inzicht en controle kregen over hun Kubernetes-omgevingen.Met runtime container security als essentieel onderdeel van moderne IT-beveiliging biedt deze aflevering praktische inzichten en inspiratie voor iedereen die werkt met Kubernetes. Alba's expertise maakt het onderwerp toegankelijk, van beginners tot gevorderden.-------------In this episode of the Nederlandse Kubernetes Podcast, Ronald Kers (CNCF Ambassador) and Jan Stomphorst (Senior Solutions Architect bij ACC ICT) are joined by Alba Ferri, Senior Customer Solutions Engineer at Sysdig, to explore the world of eBPF and its role in runtime container security.Alba introduces eBPF as a powerful technology that enables real-time visibility and security within Kubernetes clusters. She explains how eBPF monitors system calls and runtime behaviors, offering organizations the ability to detect suspicious activities, prevent potential threats, and gain deeper insights into their container environments.One of the key focuses of the episode is runtime container security: securing workloads during their execution rather than relying solely on pre-runtime measures. Alba shares how tools leveraging eBPF help detect unauthorized access, unusual network activity, and other anomalies in real time.Key takeaways from this episode:The power of eBPF: How eBPF optimizes monitoring, networking, and security by bypassing traditional Linux stacks.Customizable security: How runtime container security tools can be tailored to your unique environment.Proactive response: Using automated workflows to isolate suspicious containers or restart compromised workloads.From open-source to enterprise: The differences between community tools and enterprise solutions for rStuur ons een bericht.Like and subscribe! It helps out a lot.You can also find us on:De Nederlandse Kubernetes Podcast - YouTubeNederlandse Kubernetes Podcast (@k8spodcast.nl) | TikTokDe Nederlandse Kubernetes PodcastWhere can you meet us:EventsThis Podcast is powered by:ACC ICT - IT-Continuïteit voor Bedrijfskritische Applicaties | ACC ICT
In Today's episode we chat with our good friend and co-mastermind member, Jason M. Barnard. He blew our minds when it c omes to SEO, Google, Personal Branding and much more. This guy has been outsmarting Google for 20 years, and he told us everything we need to know about it. I could not stop taking notes. This conversation made us rethink a lot of what we "know" about Google and how we show up online if we really want to create a positive impact in the world. Which, I'm assuming, you want to do! We talked how this frameworks are so simple to put in place, you can do it today if you want to. We discussed modern models of AI, and how they all suck when it comes to building your brand... yes, including Chat GPT... And we wrapped up the episode with how you can get all these resources, for free! It was so good, and actionable! We can't wait to hear from you! Timestamped Overview: 00:00 Google algorithm expert with superhero alter ego. 05:26 Incredible show and valuable insights shared. 07:34 Summarizing the text in 7 words: Discussing content organization and personal branding strategies. 10:27 Jason and coach conversation on self-definition simplification. 13:27 Curiosity about unique marketing approach in SEO. 18:05 Social media algorithms keep users engaged. 21:20 Algorithms guide users through the sales journey. 24:32 Identifying content categories for efficient problem-solving. 29:31 Google search guides users through educational journey. 30:44 Sysdig engines recommend Biz Bros for B2B podcast production, guiding users through the buying process. 35:00 Focus on solving big problems through smaller tasks. 38:16 Content generating profit—pipeline platform, collaboration, tracking. 42:26 Iterative process using GPT 4 to generate answers. 46:14 Sharing knowledge freely, nature can't be changed. 48:32 Consistent red shirt creates strong professional identity. 51:15 Wearing a red shirt can make connections. 54:39 Package branded marketing for search engines effectively. Connect With Jason M. Barnard: Facebook Instagram LinkedIn Twitter Connect with FONZI: Facebook Instagram LinkedIn Twitter Connect with LUISDA: Facebook Instagram LinkedIn Twitter Subscribe to the podcast on Youtube, Apple, Spotify, Google, Stitcher, or anywhere you listen to your podcasts. You can find this episode plus all previous episodes here. If this episode was helpful, please don't forget to leave us a review by clicking here, and share it with a friend. You can go here to see the full list of episodes
How is agentic AI reshaping cloud security and what does the future hold for this transformative technology? In today's episode of Tech Talks Daily, I sit down with Loris Degioanni, the founder and CTO of Sysdig, to explore how agentic AI is driving innovation in cloud security. As the creator of Sysdig and the CNCF runtime security tool Falco, Loris brings a wealth of expertise to the conversation, having also been a key contributor to the widely-used open-source network analyzer, Wireshark. We discuss how Sysdig has pioneered the first AI-powered cloud security tool using agentic AI. This groundbreaking approach enables AI agents to function as domain-specific experts, working collaboratively to provide rapid threat detection—reducing response times to under 10 minutes in cloud environments where speed is critical. Loris shares insights into the cultural and technological factors fueling the rise of agentic AI and its potential to revolutionize cybersecurity. The conversation also delves into the promises and pitfalls of agentic AI, such as its ability to handle complex tasks in a way that mimics human teams, alongside challenges like latency and cost. Loris highlights how open-source tools like Falco and Sysdig play a crucial role in advancing AI by making domain-specific knowledge publicly accessible, empowering the broader developer community to optimize AI capabilities. Looking ahead, we explore the future of AI in enterprise and cloud security, including predictions about how conversational interfaces and agentic AI architectures will redefine how businesses interact with and manage security tools. Whether you're curious about the evolution of AI in cybersecurity or interested in learning how Sysdig is leveraging this innovation to address today's challenges, this episode offers a fascinating glimpse into the intersection of technology and security. What are your thoughts on the role of agentic AI in shaping the future of cybersecurity? Join the discussion and share your perspective!
Falco, an open-source runtime observability and security tool, was created by Sysdig founder Loris Degioanni to collect real-time system events directly from the kernel. Leveraging eBPF technology for improved safety and performance, Falco gathers data like pod names and namespaces, correlating them with customizable rules. Unlike static analysis tools, it operates in real-time, monitoring events as they occur. In this episode of The New Stack Makers, TNS Editor-in-Chief, Heather Joslyn spoke with Thomas Labarussias, Senior Developer Advocate at Sysdig, Leonardo Grasso, Open Source Tech Lead Manager at Sysdig and Luca Guerra, Sr. Open Source Engineer at Sysdig to get the latest update on Falco. Graduating from the Cloud Native Computing Foundation (CNCF) in February 2023 after entering its sandbox six years prior, Falco's maintainers have focused on technical maturity and broad usability. This includes simplifying installations across diverse environments, thanks in part to advancements from the Linux Foundation.Looking ahead, the team is enhancing core functionalities, including more customizable rules and alert formats. A key innovation is Falco Talon, introduced in September 2023, which provides a no-code response engine to link alerts with real-time remediation actions. Talon addresses a longstanding gap in automating responses within the Falco ecosystem, advancing its capabilities for runtime security.Learn more from The New Stack about Falco:Falco Is a CNCF Graduate. Now What?Falco Plugins Bring New Data Sources to Real-Time SecurityeBPF Tools: An Overview of Falco, Inspektor Gadget, Hubble and CiliumJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.
As we close the book on 2024, I want to take a moment to say THANK YOU. Whether you tuned in for one episode or all 52, you're part of a movement that believes coaching is the rocket fuel for performance. This year, Coach the Scale recorded over 65 episodes, reaching thousands of sales leaders. But this isn't about vanity metrics—this is about impact. Each episode brought lessons that slapped us in the face and whispered, "Pay attention."So, let's hit rewind on the top 10 lessons from 2024 that every sales leader needs tattooed (metaphorically) on their brain:1. Coaching isn't teaching—it's training for battle.Your reps don't learn to box by watching YouTube. It's role plays, feedback, and reps that build champions.2. High performers are your blue-chip stocks.Feed them or someone else will. Stop spending all your energy on the bottom 20%.3. Focus on behaviors, not just outcomes.Outcomes lag. Daily actions drive the engine. We are what we repeatedly do.4. Active listening is a martial art.As Colum at CoachEm says, curiosity is the currency that unlocks trust.5. Feedback is love.Frequent, honest feedback isn't a luxury—it's oxygen for growth. (Thanks to Dr. Rachel Pacheco for the unforgettable underwear analogy.
Karen Walker, CFO of Sysdig, joins Jack McCullough to discuss what it takes to lead in the dynamic world of cloud security. Karen shares her journey from global childhood experiences to leadership roles at iconic companies, such as Uber and Pandora. Together, they explore the evolving role of CFOs, the power of networking, and how technology is reshaping financial leadership. Whether you are curious about scaling fast-growing businesses or balancing passion and practicality, this conversation offers valuable insights for professionals at every stage of their careers.To book a demo with Payhawk, click here.To book a demo with Planful, click here.
Eric Carter of Sysdig joins Corey to tackle the evolving landscape of cloud security, particularly in AWS environments. As attackers leverage automation to strike within minutes, Sysdig focuses on real-time threat detection and rapid response. Tools like Runtime Insights and open-source Falco help teams identify and mitigate misconfigurations, excessive permissions, and stealthy attacks, while Kubernetes aids in limiting lateral movement. Eric introduced the “10-minute benchmark” for defense, combining automation and human oversight. Adapting to constant change, Sysdig integrates frameworks like MITRE ATT&CK to stay ahead of threats. Corey and Eric also discuss Sysdig's conversational AI security analyst, which simplifies decision-making.Show Highlights(0:00) Intro(0:32) Sysdig sponsor read(0:51) What they do at Sysdig(3:28) When you need a human in the loop vs when AI is useful(5:12) How AI may affect career progression for cloud security analysts(8:18) The importance of security for AI(12:18) Sysdig sponsor read(12:39) Security practices in AWS(15:19) How Sysdig's security reports have shaped Corey's thinking(18:10) Where the cloud security industry is headed(20:03) Cloud security increasingly feeling like an arms race between attackers and defenders(23:33) Frustrations with properly configuring leased permissions(28:17) How to keep up with Eric and SysdigAbout Eric CarterEric is an AWS Cloud Partner Advocate focused on cultivating Sysdig's technology cloud and container partner ecosystem. Eric has spearheaded marketing efforts for enterprise technology solutions across various domains, such as security, monitoring, storage, and backup. He is passionate about working with Sysdig's alliance partners, and outside of work, enjoys performing as a guitarist in local cover bands.LinksSysdig's website: https://sysdig.com/Sysdig's AWS Cloud Security: https://sysdig.com/ecosystem/aws/Sysdig's 5 Steps to Securing AWS Cloud Infrastructure: https://sysdig.com/content/c/pf-5-steps-to-securing-aws-cloud-infrastructure?x=Xx8NSJSponsorSysdig: https://www.sysdig.com
Video Episode: https://youtu.be/-fHd8wOJGHg In today’s episode, we discuss the recent surge in cyber threats, starting with the improved LightSpy spyware targeting iPhones, which enables heightened surveillance through 28 new plugins and destructive capabilities like device freezing. We also cover a critical vulnerability (CVE-2024-50550) in the LiteSpeed Cache WordPress plugin, allowing hackers to gain unauthorized admin access to over six million sites. Additionally, we examine the Phish n’ Ships campaign, which has affected over a thousand online stores, and the EmeraldWhale operation that has stolen more than 15,000 cloud credentials from exposed Git repositories, highlighting the ongoing challenges in mobile security, WordPress vulnerabilities, and credential theft. References: 1. https://thehackernews.com/2024/10/new-lightspy-spyware-version-targets.html 2. https://www.bleepingcomputer.com/news/security/litespeed-cache-wordpress-plugin-bug-lets-hackers-get-admin-access/ 3. https://www.bleepingcomputer.com/news/security/over-a-thousand-online-shops-hacked-to-show-fake-product-listings/ 4. https://www.bleepingcomputer.com/news/security/hackers-steal-15-000-cloud-credentials-from-exposed-git-config-files/ 1. What are today’s top cybersecurity news stories? 2. How does the new version of LightSpy spyware target iPhones? 3. What vulnerabilities exist in the LiteSpeed Cache WordPress plugin? 4. What is the Phish n’ Ships phishing campaign about? 5. How did hackers steal 15,000 cloud credentials from Git config files? 6. What measures can be taken to secure iPhones against spyware? 7. What are the implications of the LiteSpeed Cache privilege elevation flaw? 8. What steps should consumers take to avoid falling for phishing scams? 9. How are hackers exploiting Git configuration files for data theft? 10. What are the latest trends in mobile cybersecurity threats? LightSpy, spyware, iOS, malware, LiteSpeed Cache, vulnerability, WordPress, exploitation, Satori, phishing, vulnerabilities, counterfeit, EmeraldWhale, Git, credentials, Sysdig,
CISA spins up an election operations war room. Microsoft neglected to restrict access to gender-detecting AI. Yahoo uncovers vulnerabilities in OpenText's NetIQ iManager. QNAP issues urgent patches for its NAS devices. Sysdig uncovers Emerald Whale. A malvertising campaign exploits Meta's ad platform to spread the SYS01 infostealer. Senator Ron Wyden wants to tighten rules aimed at preventing U.S. technologies from reaching repressive regimes. Researchers use AI to uncover an IoT zero-day. Sophos reveals a five year battle with firewall hackers. Our guest is Frederico Hakamine, Technology Evangelist from Axonius, talking about how threats both overlap and differ across individuals and critical infrastructure. Be afraid of spooky data. Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Our guest is Frederico Hakamine, Technology Evangelist from Axonius, talking about how threats both overlap and differ across individuals and critical infrastructure. Selected Reading CISA Opens Election War Room to Combat Escalating Threats (GovInfo Security) Agencies face ‘inflection point' ahead of looming zero-trust deadline, CISA official says (CyberScoop) Microsoft Provided Gender Detection AI on Accident (404 Media) Yahoo Discloses NetIQ iManager Flaws Allowing Remote Code Execution (SecurityWeek) QNAP patches critical SQLi flaw (Beyond Machines) EMERALDWHALE: 15k Cloud Credentials Stolen in Operation Targeting Exposed Git Config Files (Sysdig) Fake Meta Ads Hijacking Facebook Accounts to Spread SYS01 Infostealer (Hackread) Exclusive: Senator calls on Commerce to tighten proposed rules on exporting surveillance, hacking tech to problematic nations (CyberScoop) GreyNoise Intelligence Discovers Zero-Day Vulnerabilities in Live Streaming Cameras with the Help of AI (GreyNoise) Inside Sophos' 5-Year War With the Chinese Hackers Hijacking Its Devices (WIRED) Pacific Rim: Inside the Counter-Offensive—The TTPs Used to Neutralize China-Based Threats (Sophos News) Spooky Data at a Distance (LinkedIn) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show. Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices
SecTor, Canada's largest cybersecurity conference, today announced the release of its full schedule of Summits for SecTor 2024. The live, in-person event will take place from October 22 to October 24 at the Metro Toronto Convention Centre in downtown Toronto. Summits will take place on Tuesday, October 22 and include:SecTor Executive Summit – This Summit will offer CISOs and other cybersecurity executives an opportunity to hear from industry experts helping to shape the next generation of information security strategy. Sponsors include: Armis, Sysdig, Cyera, and Trend Micro. To apply, please visit blackhat.com/sector/2024/executive-summit.html.Inaugural AI Summit at SecTor – This Summit will take place as part of The AI Summit Series, a global conference and expo series focusing on practical applications of AI technologies. This Summit will underscore the importance of artificial intelligence (AI) as an organization's newest and greatest weapon within the ever-evolving cybersecurity landscape. Passes can be purchased here: blackhat.com/sector/2024/ai-summit.html.Cloud Security Summit at SecTor – This Summit is Canada's leading cloud security event featuring keynote speakers, panel discussions, and networking opportunities, and provides an invaluable opportunity for every security professional to engage with leaders and discuss the future of cloud security. Sponsors include: CrowdStrike, Cyera, Kyndryl, Okta, OpenText, StrongDM, Sysdig, and Lookout. Passes can be purchased here: blackhat.com/sector/2024/cloud-summit.html.Note: This story contains promotional content. Learn more.ResourcesLearn more and catch more stories from SecTor Cybersecurity Conference Toronto 2024: https://www.itspmagazine.com/sector-cybersecurity-conference-2024-cybersecurity-event-coverage-in-toronto-canadaLearn more about 2 Minutes on ITSPmagazine Short Brand Story Podcasts: https://www.itspmagazine.com/purchase-programs
SecTor, Canada's largest cybersecurity conference, today announced the release of its full schedule of Summits for SecTor 2024. The live, in-person event will take place from October 22 to October 24 at the Metro Toronto Convention Centre in downtown Toronto. Summits will take place on Tuesday, October 22 and include:SecTor Executive Summit – This Summit will offer CISOs and other cybersecurity executives an opportunity to hear from industry experts helping to shape the next generation of information security strategy. Sponsors include: Armis, Sysdig, Cyera, and Trend Micro. To apply, please visit blackhat.com/sector/2024/executive-summit.html.Inaugural AI Summit at SecTor – This Summit will take place as part of The AI Summit Series, a global conference and expo series focusing on practical applications of AI technologies. This Summit will underscore the importance of artificial intelligence (AI) as an organization's newest and greatest weapon within the ever-evolving cybersecurity landscape. Passes can be purchased here: blackhat.com/sector/2024/ai-summit.html.Cloud Security Summit at SecTor – This Summit is Canada's leading cloud security event featuring keynote speakers, panel discussions, and networking opportunities, and provides an invaluable opportunity for every security professional to engage with leaders and discuss the future of cloud security. Sponsors include: CrowdStrike, Cyera, Kyndryl, Okta, OpenText, StrongDM, Sysdig, and Lookout. Passes can be purchased here: blackhat.com/sector/2024/cloud-summit.html.Note: This story contains promotional content. Learn more.ResourcesLearn more and catch more stories from SecTor Cybersecurity Conference Toronto 2024: https://www.itspmagazine.com/sector-cybersecurity-conference-2024-cybersecurity-event-coverage-in-toronto-canadaLearn more about 2 Minutes on ITSPmagazine Short Brand Story Podcasts: https://www.itspmagazine.com/purchase-programs
In this episode of Unspoken Security, host AJ Nash talks with Crystal Morin, Cybersecurity Strategist at Sysdig, about the world of threat hunting. Crystal shares her journey from military linguist to cyber defender, highlighting the skills that translate across these fields.The conversation dives into what threat hunting is and why it's crucial for proactive cybersecurity. Crystal explains how she developed a company-wide threat-hunting program at Booz Allen Hamilton, emphasizing the importance of open-source tools and training.Crystal discusses the challenges of funding proactive security measures and the need for more threat hunters in the industry. She also touches on recent discoveries, including novel cybercriminal operations and targeted attacks against large language models. The episode wraps up with insights on making threat hunting accessible to more professionals in the cybersecurity field.Send us a textSupport the show
There's a whole new dating scam that could mean you end up out of pocket (or beaten up) after a first date with a glamorous admirer, and a woman in Los Alamos uses an Air Tag to entrap a thief.Plus - don't miss our featured interview with Maya Levine of Sysdig.All this, and a very bad Cockney accent, in the latest edition of the "Smashing Security" podcast by industry veterans Graham Cluley and Carole Theriault.Warning: This podcast may contain nuts, adult themes, and rude language.Episode links:Mail Theft Suspect Apprehended Using AirTag - Santa Barbara County Sheriff's Office.Google and Apple deliver support for unwanted tracking alerts in Android and iOS - Google Security blog.Apple and Google deliver support for unwanted tracking alerts in iOS and Android - Apple.Barclays Scams Bulletin: Men more likely to fall victim to romance scams, while women lose more money - Barclays.3 men trapped by same woman: Journalist on modus operandi of dating app scams - India Today. Mumbai club under fire for 'dating scam' after man gets Rs 61,000 bill - India News.Romance scams in 2024 + online dating statistics - Norton.Tips for romance scams - Better Business Bureau.What to know about romance scams - Consumer Advice.The Godfather club dating app scam in Mumbai - YouTube.What accent does Butcher have in ‘The Boys'? - NME.Shokz bone conduction headphones - Shokz.Smashing Security merchandise (t-shirts, mugs, stickers and stuff)Sponsored by:1Password Extended Access Management - Secure every sign-in for every app on every device.Sysdig - Secure your cloud in real time. Detect, investigate, and respond to threats at cloud speed.Material Security – email security that covers the full threat landscape –
Data breaches can throw countless lives into disarray. With massive leaks and compromises happening on what feels like a daily basis, what can be done to protect people and services? On this episode, Sysdig Product Manager Maya Levine joins us for a discussion on the current state of affairs in the world of cybersecurity. Why do these attacks keep happening? Are they becoming too frequent? What can we do to prevent them? Maya has all the answers as well as tips to help keep you and your organization safe.Show Highlights:(0:00) Intro(0:37) Sysdig sponsor read(0:58) Product management at Sysdig(2:09) Are cyber attacks becoming more frequent in the cloud?(5:58) Urgency (or lack thereof) while under attack (10:37) Motives and methods in modern data breaches(15:57) Sysdig sponsor read(16:20) The cost (and necessity) of audit logging(18:46) “If breach is inevitable, what can people do?”(22:36) Maya's “I am Confused” talk(25:40) Stopping attacks before they spiral out of control(32:32) Where can find more from Maya and SysdigAbout Maya Levine:Maya Levine is a Product Manager for Sysdig. Previously she worked at Check Point Software Technologies as a Security Engineer and later a Technical Marketing Engineer, focusing on cloud security. Her earnest and concise communication style connects to both technical and business audiences. She has presented at many industry conferences, including AWS re:Invent and AnsibleFest. She has also been regularly interviewed on television news channels, written publications, and podcasts about cybersecurity.Links:Maya's LinkedIn: https://www.linkedin.com/in/maya-levine/Sysdig: https://sysdig.com/SponsorSysdig: https://sysdig.com/
Some Squarespace users see their domains hijacked. Kaspersky Lab is shutting down US operations. BackPack APKs break malware analysis tools. Hackers use 7zip files to deliver Poco RAT malware. CISA's red-teaming reveals security failings at an unnamed federal agency. Microsoft fixes an Outlook bug triggering false security alerts. Switzerland mandates open source software in the public sector. On our Industry Voices segment, N2K's Rick Howard speaks with Alex Lawrence and Matt Stamper from Sysdig about their 555 Cloud Security Benchmark. Bellingcat sleuths pinpoint an alleged cartel member. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest On our Industry Voices segment, N2K's Rick Howard speaks with Alex Lawrence and Matt Stamper from Sysdig about their 555 Cloud Security Benchmark. Learn more about the /555 benchmark. Selected Reading Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks (Krebs on Security) Kaspersky Lab Closing U.S. Division; Laying Off Workers (Zero Day) Beware of BadPack: One Weird Trick Being Used Against Android Devices (Palo Alto Networks Unit 42) New Poco RAT Weaponizing 7zip Files Using Google Drive (GB Hackers) CISA broke into a US federal agency, and no one noticed for a full 5 months (The Register) Organizations Warned of Exploited GeoServer Vulnerability (Security Week) Microsoft finally fixes Outlook alerts bug caused by December updates (Bleeping Computer) New Open Source law in Switzerland (Joinup) Exploring the Skyline: How we Located an Alleged Cartel Member in Dubai (Bellingcat) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show. Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices
AT&T wireless announces a massive data breach. NATO will build a cyber defense center in Belgium. The White House outlines cybersecurity budget priorities.A popular phone spyware app suffers a major data breach.Some Linksys routers are sending user credentials in the clear. Sysdig describes Crystalray malware. A massive phishing campaign is exploiting Microsoft SharePoint servers. Germany strips Huawei and ZTE from 5G infrastructure. Our guest is Brigid Johnson, Director of AWS Identity, on the importance of identity management. The EU tells X-Twitter to clean up its act or pay the price. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest At the recent AWS re:Inforce 2024 conference, N2K's Brandon Karpf spoke with Brigid Johnson, Director of AWS Identity, about the importance of identity and where we need to go. You can watch a replay of Brigid's session at the event, IAM policy power hour, here. Selected Reading AT&T Details Massive Breach of Customers' Call and Text Logs (Data Breach Today) NATO Set to Build New Cyber Defense Center (Infosecurity Magazine) New Presidential memorandum sets cybersecurity priorities for FY 2026, tasking OMB and ONCD to evaluate submissions (Industrial Cyber) mSpy Data Breach: Millions of Customers' Data Exposed (GB Hackers) Advance Auto Parts' Snowflake Breach Hits 2.3 Million People (Infosecurity Magazine) These Linksys routers are likely transmitting cleartext passwords (TechSpot) Known SSH-Snake bites more victims with multiple OSS exploitation (CSO Online) Beware of Phishing Attack that Abuses SharePoint Servers (Cyber Security News) Germany to Strip Huawei From Its 5G Networks (The New York Times) EU threatens Musk's X with a fine of up to 6% of global turnover (The Record) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show. Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices
In this episode from KubeCon Paris 2024, we spoke to Loris Degioanni, Co-Founder and CTO of Sysdig about Open Source Project, Falco that celebrated its graduation this year at KubeconEU, Loris shared with us this proud moment and journey from writing the 1st lines of code to its critical role in protecting Kubernetes environments, and the future roadmap post-graduation. We spoke about the gap between traditional security measures and the dynamic needs of modern infrastructures. Guest Socials: Loris's Linkedin Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security Podcast- Youtube - Cloud Security Newsletter - Cloud Security BootCamp 00:00 Introduction 01:13 A bit about Loris 01:44 What does graduation mean for Falco? 02:58 What is Falco? 04:59 eBPF and Falco 06:01 Why eBPF is secure? 07:11 Runtime Security in Kubernetes 10:32 ROI for leaders for Runtime Security Tools 12:50 Preventative Security vs Runtime Security 14:08 Runtime Security in Modern Environments 16:42 Whats the Future for Falco? 18:31 The Fun Questions
Loris Degioanni, CTO and founder of Sysdig, shares his open source story, from his work on Wireshark to pioneering cloud native security platforms with Sysdig and Falco. Sysdig is a universal system visibility tool with native support for containers, while Falco, now under the CNCF, provides real-time anomaly detection in containers and Kubernetes. We discuss the evolution of network security with the advent of containers and Kubernetes, highlighting the shift from packet-based to system call-based security through eBPF technology. He also underscores the importance of community collaboration in enhancing security measures and is optimistic about the role of open source in shaping the future of security. 00:00 Welcome and Introduction 01:34 The Evolution of Sysdig and Falco 02:37 Connecting the Dots: From Wireshark to Falco 04:37 eBPF Technology 09:18 Falco's Impact and Unexpected Uses 11:24 The Importance of Runtime Security Detection 13:11 Empowering Developers for Better Security 17:41 Excitement in the Open Source AI Ecosystem 21:04 Closing Thoughts and Future of Security Guest: Loris Degioanni (he/him) is the Chief Technology Officer and founder of Sysdig. He is also the creator of the popular open source troubleshooting tool, sysdig, and the open source container security tool Falco. Prior to founding Sysdig, Loris co-created Wireshark, the open source network analyzer, which today has 20+ million users. Loris holds a PhD in computer engineering from Politecnico di Torino and lives in Davis, California.
A supply chain attack targets python developers. Russia targets German political parties. Romanian and Spanish police dismantle a cyber-fraud gang. Pwn2Own prompts quick patches from Mozilla. President Biden nominates the first assistant secretary of defense for cyber policy at the Pentagon. An influential think tank calls for a dedicated cyber service in the US. Unit42 tracks a StrelaStealer surge. GM reverses its data sharing practice. Our guest is Anna Belak, Director of the Office of Cybersecurity Strategy at Sysdig, who shares trends in cloud-native security. And a Fordham Law School professor suggests AI creators take a page from medical doctors. Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Guest Anna Belak, Director of the Office of Cybersecurity Strategy at Sysdig, shares trends in cloud-native security. To learn more, you can check out Sysdig's 2024 Cloud-Native Security and Usage Report. Selected Reading Top Python Developers Hacked in Sophisticated Supply Chain Attack (SecurityWeek) Russian hackers target German political parties with WineLoader malware (Bleeping Computer) Police Bust Multimillion-Dollar Holiday Fraud Gang (Infosecurity Magazine) Mozilla Patches Firefox Zero-Days Exploited at Pwn2Own (SecurityWeek) Biden nominates first assistant defense secretary for cyber policy (Nextgov/FCW) Pentagon, Congress have a ‘limited window' to properly create a Cyber Force (The Record) StrelaStealer targeted over 100 organizations across the EU and US (Security Affairs) General Motors Quits Sharing Driving Behavior With Data Brokers (The New York Times) AI's Hippocratic Oath by Chinmayi Sharma (SSRN) Share your feedback. We want to ensure that you are getting the most out of the podcast. Please take a few minutes to share your thoughts with us by completing our brief listener survey as we continually work to improve the show. Want to hear your company in the show? You too can reach the most influential leaders and operators in the industry. Here's our media kit. Contact us at cyberwire@n2k.com to request more info. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © 2023 N2K Networks, Inc.
In Today's episode we chat with our good friend and co-mastermind member, Jason M. Barnard. He blew our minds when it c omes to SEO, Google, Personal Branding and much more. This guy has been outsmarting Google for 20 years, and he told us everything we need to know about it. I could not stop taking notes. This conversation made us rethink a lot of what we "know" about Google and how we show up online if we really want to create a positive impact in the world. Which, I'm assuming, you want to do! We talked how this frameworks are so simple to put in place, you can do it today if you want to. We discussed modern models of AI, and how they all suck when it comes to building your brand... yes, including Chat GPT... And we wrapped up the episode with how you can get all these resources, for free! It was so good, and actionable! We can't wait to hear from you! Timestamped Overview: 00:00 Google algorithm expert with superhero alter ego. 05:26 Incredible show and valuable insights shared. 07:34 Summarizing the text in 7 words: Discussing content organization and personal branding strategies. 10:27 Jason and coach conversation on self-definition simplification. 13:27 Curiosity about unique marketing approach in SEO. 18:05 Social media algorithms keep users engaged. 21:20 Algorithms guide users through the sales journey. 24:32 Identifying content categories for efficient problem-solving. 29:31 Google search guides users through educational journey. 30:44 Sysdig engines recommend Biz Bros for B2B podcast production, guiding users through the buying process. 35:00 Focus on solving big problems through smaller tasks. 38:16 Content generating profit—pipeline platform, collaboration, tracking. 42:26 Iterative process using GPT 4 to generate answers. 46:14 Sharing knowledge freely, nature can't be changed. 48:32 Consistent red shirt creates strong professional identity. 51:15 Wearing a red shirt can make connections. 54:39 Package branded marketing for search engines effectively. Connect With Jason M. Barnard: Facebook Instagram LinkedIn Twitter Connect with FONZI: Facebook Instagram LinkedIn Twitter Connect with LUISDA: Facebook Instagram LinkedIn Twitter Subscribe to the podcast on Youtube, Apple, Spotify, Google, Stitcher, or anywhere you listen to your podcasts. You can find this episode plus all previous episodes here. If this episode was helpful, please don't forget to leave us a review by clicking here, and share it with a friend. You can go here to see the full list of episodes
Mike Coleman is a developer advocate at Sysdig focused on open source software and spends a lot of time working on the Falco project. We'll explore how Falco enables runtime security, and celebrate its recent graduation! Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod News of the week Falco Graduation announcement Google Gemma Open Model GitOps Associate Certification (CGOA) Certified GitOps Associate (CGOA) Exam Linkerd 2.15 announcement Linkerd 2.15 stable release announcement Crossplane 1.15 announcement Open Source Summit North America Schedule Cloud Native Security Con North American Cloud Native Security Con America CFP Links from the interview Mike Coleman LinkedIn Twitter "Docker?!?! But, I'm a sysadmin" - Mike Coleman Mike Colemane and Bill Gates in an Earthquake Falco project LinkedIn Twitter Slack KubeCon NA 2019 CTF Cryptomining Detection Using Falco Navigating Open Source Project Hurdles to Achieve Community Enpowerments Aizhamal Nurmamat kyzy & Bob Killen Wrangle your alerts with open source Falco and the gcpaudit plugin Falcosidekick Practical Cloud Native Security with Falco Certified Kubernetes Security (CKS) exam
Kubernetes is designed to be highly scalable and highly dynamic… a perfect habitat for cryptominers to terminal shell into and then exploit your workload's resources to the max. And that's just one example of security threats Kubernetes users need to prepare against. Nigel Douglas from Sysdig joins Michael Levan and Kristina Devochko to give you... Read more »
Kubernetes is designed to be highly scalable and highly dynamic… a perfect habitat for cryptominers to terminal shell into and then exploit your workload's resources to the max. And that's just one example of security threats Kubernetes users need to prepare against. Nigel Douglas from Sysdig joins Michael Levan and Kristina Devochko to give you... Read more »
Kubernetes is designed to be highly scalable and highly dynamic… a perfect habitat for cryptominers to terminal shell into and then exploit your workload's resources to the max. And that's just one example of security threats Kubernetes users need to prepare against. Nigel Douglas from Sysdig joins Michael Levan and Kristina Devochko to give you... Read more »
Loris Degioanni is Founder & CTO of Sysdig, the observability and container security company behind the Falco and Sysdig open source projects. Both projects are widely adopted, with 7K GitHub Stars each. Sysdig is a $2.5B company that has raised over $700M from investors including Insight, Accel, Bain, DFJ, Goldman Sachs, Third Point & Permira. In this episode, we dig into Sysdig's roots in infrastructure and the pivotal decision to focus on security 2 years into the company journey, Sysdig's culture of experimentation (and some paranoia) that has helped make them successful, why they thought about their paid product early & much more!
Madhav Jivrajani is an engineer at VMware, a tech lead in SIG Contributor Experience and a GitHub Admin for the Kubernetes project. He also contributes to the storage layer of Kubernetes, focusing on reliability and scalability. In this episode we talked with Madhav about a recent post on social media about a very interesting stale reads issue in Kubernetes, and what the community is doing about it. Do you have something cool to share? Some questions? Let us know: - web: kubernetespodcast.com - mail: kubernetespodcast@google.com - twitter: @kubernetespod Chatter of the week Mofi Rahman co-host this episode with Kaslin Twitter/X LinkedIn Kubernetes Podcast episode 211 News of the week Google announced a new partnership with Hugging Face RedHat self-managed offering of Ansible Automation Platform on Microsoft Azure The schedule for KubeCon CloudNativeCon EU 2024 is out CNCF Ambassador applications are open The CNCF Hackathon at KubeCon CloudNativeCon EU 2024 CFP is open now The annual Cloud Native Computing Foundation report for 2023 CNCF's certification expiration period will change to 24 months starting April 1st, 2024. Sysdig 2024 Cloud Native Security and Usage Report Links from the interview Madhav Jivrajani Twitter/X LinkedIn Priyanka Saggu Interview Stale reads Twitter/X thread by Madhav "Kubernetes is vulnerable to stale reads, violating critical pod safety guarantees" - GitHub Issue tracking the stale reads CAP Theorem issue CMU Wasm Research Center "A CAP tradeoff in the wild" blog by Lindsey Kuper "Reasoning about modern datacenter infrastructures using partial histories" research paper The Kubernetes Storage Layer: Peeling the Onion Minus the Tears - Madhav Jivrajani, VMware KEP-3157: allow informers for getting a stream of data instead of chunking. KEP 2340: Consistent Reads from Cache Journey Through Time: Understanding Etcd Revisions and Resource Versions in Kubernetes - Priyanka Saggu, KubeCon NA 2023 Kubernetes API Resource Versions documentation
Cybersecurity leader Mike Isbitski explores the intricacies of cloud-native security and vulnerability management in today's technological landscape. With over 25 years of experience, he provides valuable insights into the challenges and complexities organizations face in securing ephemeral infrastructure and machine identities in the cloud. This episode also explores the cautious adoption of AI in cybersecurity, emphasizing the need for a balanced approach that maintains operational functionality while addressing evolving security concerns.Key Points with TimestampSecurity through Obscurity (00:00:00) - Mike discusses common security practices.Cloud-Native Technology Explained (00:01:30) - Unpacking the meaning of cloud-native tech.Evolving Vulnerability Management (00:03:38) - Insights on how vulnerability management has improved.AI in Cybersecurity (00:21:20) - Discussion on the slow but growing adoption of AI in cybersecurity.Challenges of Permissions and Identity (00:29:29) - The complexities of permissions in the cloud environment.Future Trends in Cybersecurity (00:34:11) - Predictions for changes and advancements in the cybersecurity landscape.About MichealMichael Isbitski is a former Gartner analyst, cybersecurity leader, and practitioner with more than 25 years of experience, specializing in application, cloud, and container security. Michael learned many hard lessons on the front lines of IT working on application security, vulnerability management, enterprise architecture, and systems engineering. He's guided countless organizations globally in their security initiatives as they support their businesses.Links Referenced:Sysdig: https://sysdig.com/Sysdig 2024 Cloud-Native Security and Usage Report: www.sysdig.com/SITC
Like many of her CFO peers, Karen Walker had an early career that was guided by abundant opportunities surrounding finance-driven decision-making within organizations. It was a path that often led Walker to engage more closely with sales and operations, as was the case at CNET Networks, where she tells us that she recognized the limitations of embracing a strictly “rules-based” approach in finance. It was at CNET that she embraced a more transformative perspective—prioritizing the customer's objectives and challenges. This shift in thinking, emphasizing a customer mind-set, would continue as she advanced in her career. At PagerDuty, the philosophy became instrumental in addressing the company's rapid growth challenges. Now, as CFO at Sysdig, Walker tell us that it's this commitment to understanding customer needs that guides the company's approach to cloud security. Her journey reflects a progressive integration of customer-centricity into financial leadership, showcasing its adaptability and efficacy in diverse business environments. Says Walker: “I think that one of the things that I have really learned over the years—and espouse as a philosophy—is that every employee—which includes, of course, finance—should really have a customer mind-set and really put the customer at the center of every decision that is made.”
Anna Belak, Director of the Office of Cybersecurity Strategy at Sysdig, joins Corey on Screaming in the Cloud to discuss the newest benchmark for responding to security threats, 5/5/5. Anna describes why it was necessary to set a new benchmark for responding to security threats in a timely manner, and how the Sysdig team did research to determine the best practices for detecting, correlating, and responding to potential attacks. Corey and Anna discuss the importance of focusing on improving your own benchmarks towards a goal, as well as how prevention and threat detection are both essential parts of a solid security program. About AnnaAnna has nearly ten years of experience researching and advising organizations on cloud adoption with a focus on security best practices. As a Gartner Analyst, Anna spent six years helping more than 500 enterprises with vulnerability management, security monitoring, and DevSecOps initiatives. Anna's research and talks have been used to transform organizations' IT strategies and her research agenda helped to shape markets. Anna is the Director of Thought Leadership at Sysdig, using her deep understanding of the security industry to help IT professionals succeed in their cloud-native journey. Anna holds a PhD in Materials Engineering from the University of Michigan, where she developed computational methods to study solar cells and rechargeable batteries.Links Referenced: Sysdig: https://sysdig.com/ Sysdig 5/5/5 Benchmark: https://sysdig.com/555 TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined again—for another time this year—on this promoted guest episode brought to us by our friends at Sysdig, returning is Anna Belak, who is their director of the Office of Cybersecurity Strategy at Sysdig. Anna, welcome back. It's been a hot second.Anna: Thank you, Corey. It's always fun to join you here.Corey: Last time we were here, we were talking about your report that you folks had come out with, the, “Cybersecurity Threat Landscape for 2022.” And when I saw you were doing another one of these to talk about something, I was briefly terrified. “Oh, wow, please tell me we haven't gone another year and the cybersecurity threat landscape is moving that quickly.” And it sort of is, sort of isn't. You're here today to talk about something different, but it also—to my understanding—distills down to just how quickly that landscape is moving. What have you got for us today?Anna: Exactly. For those of you who remember that episode, one of the key findings in the Threat Report for 2023 was that the average length of an attack in the cloud is ten minutes. To be clear, that is from when you are found by an adversary to when they have caused damage to your system. And that is really fast. Like, we talked about how that relates to on-prem attacks or other sort of averages from other organizations reporting how long it takes to attack people.And so, we went from weeks or days to minutes, potentially seconds. And so, what we've done is we looked at all that data, and then we went and talked to our amazing customers and our many friends at analyst firms and so on, to kind of get a sense for if this is real, like, if everyone is seeing this or if we're just seeing this. Because I'm always like, “Oh, God. Like, is this real? Is it just me?”And as it turns out, everyone's not only—I mean, not necessarily everyone's seeing it, right? Like, there's not really been proof until this year, I would say because there's a few reports that came out this year, but lots of people sort of anticipated this. And so, when we went to our customers, and we asked for their SLAs, for example, they were like, “Oh, yeah, my SLA for a [PCRE 00:02:27] cloud is like 10, 15 minutes.” And I was like, “Oh, okay.” So, what we set out to do is actually set a benchmark, essentially, to see how well are you doing. Like, are you equipped with your cloud security program to respond to the kind of attack that a cloud security attacker is going to—sorry, an anti-cloud security—I guess—attacker is going to perpetrate against you.And so, the benchmark is—drumroll—5/5/5. You have five seconds to detect a signal that is relevant to potentially some attack in the cloud—hopefully, more than one such signal—you have five minutes to correlate all such relevant signals to each other so that you have a high fidelity detection of this activity, and then you have five more minutes to initiate an incident response process to hopefully shut this down, or at least interrupt the kill chain before your environments experience any substantial damage.Corey: To be clear, that is from a T0, a starting point, the stopwatch begins, the clock starts when the event happens, not when an event shows up in your logs, not once someone declares an incident. From J. Random Hackerman, effectively, we're pressing the button and getting the response from your API.Anna: That's right because the attackers don't really care how long it takes you to ship logs to wherever you're mailing them to. And that's why it is such a short timeframe because we're talking about, they got in, you saw something hopefully—and it may take time, right? Like, some of the—which we'll describe a little later, some of the activities that they perform in the early stages of the attack are not necessarily detectable as malicious right away, which is why your correlation has to occur, kind of, in real time. Like, things happen, and you're immediately adding them, sort of like, to increase the risk of this detection, right, to say, “Hey, this is actually something,” as opposed to, you know, three weeks later, I'm parsing some logs and being like, “Oh, wow. Well, that's not good.” [laugh].Corey: The number five seemed familiar to me in this context, so I did a quick check, and sure enough, allow me to quote from chapter and verse from the CloudTrail documentation over an AWS-land. “CloudTrail typically delivers logs within an average of about five minutes of an API call. This time is not guaranteed.” So effectively, if you're waiting for anything that's CloudTrail-driven to tell you that you have a problem, it is almost certainly too late by the time that pops up, no matter what that notification vector is.Anna: That is, unfortunately or fortunately, true. I mean, it's kind of a fact of life. I guess there is a little bit of a veiled [unintelligible 00:04:43] at our cloud provider friends because, really, they have to do better ultimately. But the flip side to that argument is CloudTrail—or your cloud log source of choice—cannot be your only source of data for detecting security events, right? So, if you are operating purely on the basis of, “Hey, I have information in CloudTrail; that is my security information,” you are going to have a bad time, not just because it's not fast enough, but also because there's not enough data in there, right? Which is why part of the first, kind of, benchmark component is that you must have multiple data sources for the signals, and they—ideally—all will be delivered to you within five seconds of an event occurring or a signal being generated.Corey: And give me some more information on that because I have my own alerter, specifically, it's a ClickOps detector. Whenever someone in one of my accounts does something in the console, that has a write aspect to it rather than just a read component—which again, look at what you want in the console, that's fine—if you're changing things that is not being managed by code, I want to know that it's happening. It's not necessarily bad, but I want to at least have visibility into it. And that spits out the principal, the IP address it emits from, and the rest. I haven't had a whole lot where I need to correlate those between different areas. Talk to me more about the triage step.Anna: Yeah, so I believe that the correlation step is the hardest, actually.Corey: Correlation step. My apologies.Anna: Triage is fine. It's [crosstalk 00:06:06]—Corey: Triage, correlations, the words we use matter on these things.Anna: Dude, we argued about the words on this for so long, you could even imagine. Yeah, triage, correlation, detection, you name it, we are looking at multiple pieces of data, we're going to connect them to each other meaningfully, and that is going to provide us with some insight about the fact that a bad thing is happening, and we should respond to it. Perhaps automatically respond to it, but we'll get to that. So, a correlation, okay. The first thing is, like I said, you must have more than one data source because otherwise, I mean, you could correlate information from one data source; you actually should do that, but you are going to get richer information if you can correlate multiple data sources, and if you can access, for example, like through an API, some sort of enrichment for that information.Like, I'll give you an example. For SCARLETEEL, which is an attack we describe in the thread report, and we actually described before, this is—we're, like—on SCARLETEEL, I think, version three now because there's so much—this particular certain actor is very active [laugh].Corey: And they have a better versioning scheme than most companies I've spoken to, but that's neither here nor there.Anna: [laugh]. Right? So, one of the interesting things about SCARLETEEL is you could eventually detect that it had happened if you only had access to CloudTrail, but you wouldn't have the full picture ever. In our case, because we are a company that relies heavily on system calls and machine learning detections, we [are able to 00:07:19] connect the system call events to the CloudTrail events, and between those two data sources, we're able to figure out that there's something more profound going on than just what you see in the logs. And I'll actually tell you, which, for example, things are being detected.So, in SCARLETEEL, one thing that happens is there's a crypto miner. And a crypto miner is one of these events where you're, like, “Oh, this is obviously malicious,” because as we wrote, I think, two years ago, it costs $53 to mine $1 of Bitcoin in AWS, so it is very stupid for you to be mining Bitcoin in AWS, unless somebody else is—Corey: In your own accounts.Anna: —paying the cloud bill. Yeah, yeah [laugh] in someone else's account, absolutely. Yeah. So, if you are a sysadmin or a security engineer, and you find a crypto miner, you're like, “Obviously, just shut that down.” Great. What often happens is people see them, and they think, “Oh, this is a commodity attack,” like, people are just throwing crypto miners whatever, I shut it down, and I'm done.But in the case of this attack, it was actually a red herring. So, they deployed the miner to see if they could. They could, then they determined—presumably; this is me speculating—that, oh, these people don't have very good security because they let random idiots run crypto miners in their account in AWS, so they probed further. And when they probed further, what they did was some reconnaissance. So, they type in commands, listing, you know, like, list accounts or whatever. They try to list all the things they can list that are available in this account, and then they reach out to an EC2 metadata service to kind of like, see what they can do, right?And so, each of these events, like, each of the things that they do, like, reaching out to a EC2 metadata service, assuming a role, doing a recon, even lateral movement is, like, by itself, not necessarily a scary, big red flag malicious thing because there are lots of, sort of, legitimate reasons for someone to perform those actions, right? Like, reconnaissance, for one example, is you're, like, looking around the environment to see what's up, right? So, you're doing things, like, listing things, [unintelligible 00:09:03] things, whatever. But a lot of the graphical interfaces of security tools also perform those actions to show you what's, you know, there, so it looks like reconnaissance when your tool is just, like, listing all the stuff that's available to you to show it to you in the interface, right? So anyway, the point is, when you see them independently, these events are not scary. They're like, “Oh, this is useful information.”When you see them in rapid succession, right, or when you see them alongside a crypto miner, then your tooling and/or your process and/or your human being who's looking at this should be like, “Oh, wait a minute. Like, just the enumeration of things is not a big deal. The enumeration of things after I saw a miner, and you try and talk to the metadata service, suddenly I'm concerned.” And so, the point is, how can you connect those dots as quickly as possible and as automatically as possible, so a human being doesn't have to look at, like, every single event because there's an infinite number of them.Corey: I guess the challenge I've got is that in some cases, you're never going to be able to catch up with this. Because if it's an AWS call to one of the APIs that they manage for you, they explicitly state there's no guarantee of getting information on this until the show's all over, more or less. So, how is there… like, how is there hope?Anna: [laugh]. I mean, there's always a forensic analysis, I guess [laugh] for all the things that you've failed to respond to.Corey: Basically we're doing an after-action thing because humans aren't going to react that fast. We're just assuming it happened; we should know about it as soon as possible. On some level, just because something is too late doesn't necessarily mean there's not value added to it. But just trying to turn this into something other than a, “Yeah, they can move faster than you, and you will always lose. The end. Have a nice night.” Like, that tends not to be the best narrative vehicle for these things. You know, if you're trying to inspire people to change.Anna: Yeah, yeah, yeah, I mean, I think one clear point of hope here is that sometimes you can be fast enough, right? And a lot of this—I mean, first of all, you're probably not going to—sorry, cloud providers—you don't go into just the cloud provider defaults for that level of performance, you are going with some sort of third-party tool. On the, I guess, bright side, that tool can be open-source, like, there's a lot of open-source tooling available now that is fast and free. For example, is our favorite, of course, Falco, which is looking at system calls on endpoints, and containers, and can detect things within seconds of them occurring and let you know immediately. There is other EBPF-based instrumentation that you can use out there from various vendors and/or open-source providers, and there's of course, network telemetry.So, if you're into the world of service mesh, there is data you can get off the network, also very fast. So, the bad news or the flip side to that is you have to be able to manage all that information, right? So, that means—again, like I said, you're not expecting a SOC analyst to look at thousands of system calls and thousands of, you know, network packets or flow logs or whatever you're looking at, and just magically know that these things go together. You are expecting to build, or have built for you by a vendor or the open-source community, some sort of dissection content that is taking this into account and then is able to deliver that alert at the speed of 5/5/5.Corey: When you see the larger picture stories playing out, as far as what customers are seeing, what the actual impact is, what gave rise to the five-minute number around this? Just because that tends to feel like it's a… it is both too long and also too short on some level. I'm just wondering how you wound up at—what is this based on?Anna: Man, we went through so many numbers. So, we [laugh] started with larger numbers, and then we went to smaller numbers, then we went back to medium numbers. We align ourselves with the timeframes we're seeing for people. Like I said, a lot of folks have an SLA of responding to a P0 within 10 or 15 minutes because their point basically—and there's a little bit of bias here into our customer base because our customer base is, A, fairly advanced in terms of cloud adoption and in terms of security maturity, and also, they're heavily in let's say, financial industries and other industries that tend to be early adopters of new technology. So, if you are kind of a laggard, like, you probably aren't that close to meeting this benchmark as you are if you're saying financial, right? So, we asked them how they operate, and they basically pointed out to us that, like, knowing 15 minutes later is too late because I've already lost, like, some number of millions of dollars if my environment is compromised for 15 minutes, right? So, that's kind of where the ten minutes comes from. Like, we took our real threat research data, and then we went around and talked to folks to see kind of what they're experiencing and what their own expectations are for their incident response in SOC teams, and ten minutes is sort of where we landed.Corey: Got it. When you see this happening, I guess, in various customer environments, assuming someone has missed that five-minute window, is a game over effectively? How should people be thinking about this?Anna: No. So, I mean, it's never really game over, right? Like until your company is ransomed to bits, and you have to close your business, you still have many things that you can do, hopefully, to save yourself. And also, I want to be very clear that 5/5/5 as a benchmark is meant to be something aspirational, right? So, you should be able to meet this benchmark for, let's say, your top use cases if you are a fairly high maturity organization, in threat detection specifically, right?So, if you're just beginning your threat detection journey, like, tomorrow, you're not going to be close. Like, you're going to be not at all close. The point here, though, is that you should aspire to this level of greatness, and you're going to have to create new processes and adopt new tools to get there. Now, before you get there, I would argue that if you can do, like, 10-10-10 or, like, whatever number you start with, you're on a mission to make that number smaller, right? So, if today, you can detect a crypto miner in 30 minutes, that's not great because crypto miners are pretty detectable these days, but give yourself a goal of, like, getting that 30 minutes down to 20, or getting that 30 minutes down to 10, right?Because we are so obsessed with, like, measuring ourselves against our peers and all this other stuff that we sometimes lose track of what actually is improving our security program. So yes, compare it to yourself first. But ultimately, if you can meet the 5/5/5 benchmark, then you are doing great. Like, you are faster than the attackers in theory, so that's the dream.Corey: So, I have to ask, and I suspect I might know the answer to this, but given that it seems very hard to move this quickly, especially at scale, is there an argument to be made that effectively prevention obviates the need for any of this, where if you don't misconfigure things in ways that should be obvious, if you practice defense-in-depth to a point where you can effectively catch things that the first layer meets with successive layers, as opposed to, “Well, we have a firewall. Once we're inside of there, well [laugh], it's game over for us.” Is prevention sufficient in some ways to obviate this?Anna: I think there are a lot of people that would love to believe that that's true.Corey: Oh, I sure would. It's such a comforting story.Anna: And we've done, like, I think one of my opening sentences in the benchmark, kind of, description, actually, is that we've done a pretty good job of advertising prevention in Cloud as an important thing and getting people to actually, like, start configuring things more carefully, or like, checking how those things have been configured, and then changing that configuration should they discover that it is not compliant with some mundane standard that everyone should know, right? So, we've made great progress, I think, in cloud prevention, but as usual, like, prevention fails, right? Like I still have smoke detectors in my house, even though I have done everything possible to prevent it from catching fire and I don't plan to set it on fire, right? But like, threat detection is one of these things that you're always going to need because no matter what you do, A, you will make a mistake because you're a human being, and there are too many things, and you'll make a mistake, and B, the bad guys are literally in the business of figuring ways around your prevention and your protective systems.So, I am full on on defense-in-depth. I think it's a beautiful thing. We should only obviously do that. And I do think that prevention is your first step to a holistic security program—otherwise, what even is the point—but threat detection is always going to be necessary. And like I said, even if you can't go 5/5/5, you don't have threat detection at that speed, you need to at least be able to know what happened later so you can update your prevention system.Corey: This might be a dangerous question to get into, but why not, that's what I do here. This [could 00:17:27] potentially an argument against Cloud, by which I mean that if I compromise someone's Cloud account on any of the major cloud providers, once I have access of some level, I know where everything else in the environment is as a general rule. I know that you're using S3 or its equivalent, and what those APIs look like and the rest, whereas as an attacker, if I am breaking into someone's crappy data center-hosted environment, everything is going to be different. Maybe they don't have a SAN at all, for example. Maybe they have one that hasn't been patched in five years. Maybe they're just doing local disk for some reason.There's a lot of discovery that has to happen that is almost always removed from Cloud. I mean, take the open S3 bucket problem that we've seen as a scourge for 5, 6, 7 years now, where it's not that S3 itself is insecure, but once you make a configuration mistake, you are now in line with a whole bunch of other folks who may have much more valuable data living in that environment. Where do you land on that one?Anna: This is the ‘leave cloud to rely on security through obscurity' argument?Corey: Exactly. Which I'm not a fan of, but it's also hard to argue against from time-to-time.Anna: My other way of phrasing it is ‘the attackers are ripping up the stack' argument. Yeah, so—and there is some sort of truth in that, right? Part of the reason that attackers can move that fast—and I think we say this a lot when we talk about the threat report data, too, because we literally see them execute this behavior, right—is they know what the cloud looks like, right? They have access to all the API documentation, they kind of know what all the constructs are that you're all using, and so they literally can practice their attack and create all these scripts ahead of time to perform their reconnaissance because they know exactly what they're looking at, right? On-premise, you're right, like, they're going to get into—even to get through my firewall, whatever, they're getting into my data center, they don't do not know what disaster I have configured, what kinds of servers I have where, and, like, what the network looks like, they have no idea, right?In Cloud, this is kind of all gifted to them because it's so standard, which is a blessing and a curse. It's a blessing because—well for them, I mean, because they can just programmatically go through this stuff, right? It's a curse for them because it's a blessing for us in the same way, right? Like, the defenders… A, have a much easier time knowing what they even have available to them, right? Like, the days of there's a server in a closet I've never heard of are kind of gone, right? Like, you know what's in your Cloud account because, frankly, AWS tells you. So, I think there is a trade-off there.The other thing is—about the moving up the stack thing, right—like no matter what you do, they will come after you if you have something worth exploiting you for, right? So, by moving up the stack, I mean, listen, we have abstracted all the physical servers, all of the, like, stuff we used to have to manage the security of because the cloud just does that for us, right? Now, we can argue about whether or not they do a good job, but I'm going to be generous to them and say they do a better job than most companies [laugh] did before. So, in that regard, like, we say, thank you, and we move on to, like, fighting this battle at a higher level in the stack, which is now the workloads and the cloud control plane, and the you name it, whatever is going on after that. So, I don't actually think you can sort of trade apples for oranges here. It's just… bad in a different way.Corey: Do you think that this benchmark is going to be used by various companies who will learn about it? And if so, how do you see that playing out?Anna: I hope so. My hope when we created it was that it would sort of serve as a goalpost or a way to measure—Corey: Yeah, it would just be marketing words on a page and never mentioned anywhere, that's our dream here.Anna: Yeah, right. Yeah, I was bored. So, I wrote some—[laugh].Corey: I had a word minimum to get out the door, so there we are. It's how we work.Anna: Right. As you know, I used to be a Gartner analyst, and my desire is always to, like, create things that are useful for people to figure out how to do better in security. And my, kind of, tenure at the vendor is just a way to fund that [laugh] more effectively [unintelligible 00:21:08].Corey: Yeah, I keep forgetting you're ex-Gartner. Yeah, it's one of those fun areas of, “Oh, yeah, we just want to basically talk about all kinds of things because there's a—we have a chart to fill out here. Let's get after it.”Anna: I did not invent an acronym, at least. Yeah, so my goal was the following. People are always looking for a benchmark or a goal or standard to be like, “Hey, am I doing a good job?” Whether I'm, like a SOC analyst or director, and I'm just looking at my little SOC empire, or I'm a full on CSO, and I'm looking at my entire security program to kind of figure out risk, I need some way to know whether what is happening in my organization is, like, sufficient, or on par, or anything. Is it good or is it bad? Happy face? Sad face? Like, I need some benchmark, right?So normally, the Gartner answer to this, typically, is like, “You can only come up with benchmarks that are—” they're, like, “Only you know what is right for your company,” right? It's like, you know, the standard, ‘it depends' answer. Which is true, right, because I can't say that, like, oh, a huge multinational bank should follow the same benchmark as, like, a donut shop, right? Like, that's unreasonable. So, this is also why I say that our benchmark is probably more tailored to the more advanced organizations that are dealing with kind of high maturity phenomena and are more cloud-native, but the donut shops should kind of strive in this direction, right?So, I hope that people will think of it this way: that they will, kind of, look at their process and say, “Hey, like, what are the things that would be really bad if they happened to me, in terms of sort detection?” Like, “What are the threats I'm afraid of where if I saw this in my cloud environment, I would have a really bad day?” And, “Can I detect those threats in 5/5/5?” Because if I can, then I'm actually doing quite well. And if I can't, then I need to set, like, some sort of roadmap for myself on how I get from where I am now to 5/5/5 because that implies you would be doing a good job.So, that's sort of my hope for the benchmark is that people think of it as something to aspire to, and if they're already able to meet it, then that they'll tell us how exactly they're achieving it because I really want to be friends with them.Corey: Yeah, there's a definite lack of reasonable ways to think about these things, at least in ways that can be communicated to folks outside of the bounds of the security team. I think that's one of the big challenges currently facing the security industry is that it is easy to get so locked into the domain-specific acronyms, philosophies, approaches, and the rest, that even coming from, “Well, I'm a cloud engineer who ostensibly needs to know about these things.” Yeah, wander around the RSA floor with that as your background, and you get lost very quickly.Anna: Yeah, I think that's fair. I mean, it is a very, let's say, dynamic and rapidly evolving space. And by the way, like, it was really hard for me to pick these numbers, right, because I… very much am on that whole, ‘it depends' bandwagon of I don't know what the right answer is. Who knows what the right answer is [laugh]? So, I say 5/5/5 today. Like, tomorrow, the attack takes five minutes, and now it's two-and-a-half/two-and-a-half, right? Like it's whatever.You have to pick a number and go for it. So, I think, to some extent, we have to try to, like, make sense of the insanity and choose some best practices to anchor ourselves in or some, kind of like, sound logic to start with, and then go from there. So, that's sort of what I go for.Corey: So, as I think about the actual reaction times needed for 5/5/5 to actually be realistic, people can't reliably get a hold of me on the phone within five minutes, so it seems like this is not something you're going to have humans in the loop for. How does that interface with the idea of automating things versus giving automated systems too much power to take your site down as a potential failure mode?Anna: Yeah. I don't even answer the phone anymore, so that wouldn't work at all. That's a really, really good question, and probably the question that gives me the most… I don't know, I don't want to say lost sleep at night because it's actually, it's very interesting to think about, right? I don't think you can remove humans from the loop in the SOC. Like, certainly there will be things you can auto-respond to some extent, but there'd better be a human being in there because there are too many things at stake, right?Some of these actions could take your entire business down for far more hours or days than whatever the attacker was doing before. And that trade-off of, like, is my response to this attack actually hurting the business more than the attack itself is a question that's really hard to answer, especially for most of us technical folks who, like, don't necessarily know the business impact of any given thing. So, first of all, I think we have to embrace other response actions. Back to our favorite crypto miners, right? Like there is no reason to not automatically shut them down. There is no reason, right? Just build in a detection and an auto-response: every time you see a crypto miner, kill that process, kill that container, kill that node. I don't care. Kill it. Like, why is it running? This is crazy, right?I do think it gets nuanced very quickly, right? So again, in SCARLETEEL, there are essentially, like, five or six detections that occur, right? And each of them theoretically has a potential auto-response that you could have executed depending on your, sort of, appetite for that level of intervention, right? Like, when you see somebody assuming a role, that's perfectly normal activity most of the time. In this case, I believe they actually assumed a machine role, which is less normal. Like, that's kind of weird.And then what do you do? Well, you can just, like, remove the role. You can remove that person's ability to do anything, or remove that role's ability to do anything. But that could be very dangerous because we don't necessarily know what the full scope of that role is as this is happening, right? So, you could take, like, a more mitigated auto-response action and add a restrictive policy to that rule, for example, to just prevent activity from that IP address that you just saw, right, because we're not sure about this IP address, but we're sure about this role, right?So, you have to get into these, sort of, risk-tiered response actions where you say, “Okay, this is always okay to do automatically. And this is, like, sometimes, okay, and this is never okay.” And as you develop that muscle, it becomes much easier to do something rather than doing nothing and just, kind of like, analyzing it in forensics and being, like, “Oh, what an interesting attack story,” right? So, that's step one, is just start taking these different response actions.And then step two is more long-term, and it's that you have to embrace the cloud-native way of life, right? Like this immutable, ephemeral, distributed religion that we've been selling, it actually works really well if you, like, go all-in on the religion. I sound like a real cult leader [laugh]. Like, “If you just go all in, it's going to be great.” But it's true, right?So, if your workflows are immutable—that means they cannot change as they're running—then when you see them drifting from their original configuration, like, you know, that is bad. So, you can immediately know that it's safe to take an auto-respon—well, it's safe, relatively safe, take an auto-response action to kill that workload because you are, like, a hundred percent certain it is not doing the right things, right? And then furthermore, if all of your deployments are defined as code, which they should be, then it is approximately—[though not entirely 00:27:31]—trivial to get that workload back, right? Because you just push a button, and it just generates that same Kubernetes cluster with those same nodes doing all those same things, right? So, in the on-premise world where shooting a server was potentially the, you know, fireable offense because if that server was running something critical, and you couldn't get it back, you were done.In the cloud, this is much less dangerous because there's, like, an infinite quantity of servers that you could bring back and hopefully Infrastructure-as-Code and, kind of, Configuration-as-Code in some wonderful registry, version-controlled for you to rely on to rehydrate all that stuff, right? So again, to sort of TL;DR, get used to doing auto-response actions, but do this carefully. Like, define a scope for those actions that make sense and not just, like, “Something bad happened; burn it all down,” obviously. And then as you become more cloud-native—which sometimes requires refactoring of entire applications—by the way, this could take years—just embrace the joy of Everything-as-Code.Corey: That's a good way of thinking about it. I just, I wish there were an easier path to get there, for an awful lot of folks who otherwise don't find a clear way to unlock that.Anna: There is not, unfortunately [laugh]. I mean, again, the upside on that is, like, there are a lot of people that have done it successfully, I have to say. I couldn't have said that to you, like, six, seven years ago when we were just getting started on this journey, but especially for those of you who were just at KubeCon—however, long ago… before this airs—you see a pretty robust ecosystem around Kubernetes, around containers, around cloud in general, and so even if you feel like your organization's behind, there are a lot of folks you can reach out to to learn from, to get some help, to just sort of start joining the masses of cloud-native types. So, it's not nearly as hopeless as before. And also, one thing I like to say always is, almost every organization is going to have some technical debt and some legacy workload that they can't convert to the religion of cloud.And so, you're not going to have a 5/5/5 threat detection SLA on those workloads. Probably. I mean, maybe you can, but probably you're not, and you may not be able to take auto-response actions, and you may not have all the same benefits available to you, but like, that's okay. That's okay. Hopefully, whatever that thing is running is, you know, worth keeping alive, but set this new standard for your new workloads. So, when your team is building a new application, or if they're refactoring an application, can't afford the new world, set the standard on them and don't, kind of like, torment the legacy folks because it doesn't necessarily make sense. Like, they're going to have different SLAs for different workloads.Corey: I really want to thank you for taking the time to speak with me yet again about the stuff you folks are coming out with. If people want to learn more, where's the best place for them to go?Anna: Thanks, Corey. It's always a pleasure to be on your show. If you want to learn more about the 5/5/5 benchmark, you should go to sysdig.com/555.Corey: And we will, of course, put links to that in the show notes. Thank you so much for taking the time to speak with me today. As always, it's appreciated. Anna Belak, Director at the Office of Cybersecurity Strategy at Sysdig. I'm Cloud Economist Corey Quinn, and this has been a promoted guest episode brought to us by our friends at Sysdig. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that I will read nowhere even approaching within five minutes.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.
@AaronDelp and @BGracely talk about the biggest stories, trends and events of cloud in 2023, and some predictions for 2024.SHOW: 782CLOUD NEWS OF THE WEEK - http://bit.ly/cloudcast-cnotwNEW TO CLOUD? CHECK OUT - "CLOUDCAST BASICS"SHOW SPONSORS:Datadog Application Monitoring: Modern Application Performance MonitoringGet started monitoring service dependencies to eliminate latency and errors and enhance your users app experience with a free 14 day Datadog trial. Listeners of The Cloudcast will also receive a free Datadog T-shirt.CloudZero – Cloud Cost Visibility and SavingsCloudZero provides immediate and ongoing savings with 100% visibility into your total cloud spendFind "Breaking Analysis Podcast with Dave Vellante" on Apple, Google and SpotifyKeep up to data with Enterprise Tech with theCUBESHOW NOTES:All the 2023 Year In Review Show Notes2023 Year-End Mailbag2022 Year-End Mailbag2022 Year in Review and PredictionsOur 2021 PredictionsOur 2020 PredictionsTHE BASICS:Our second 2M listens show Thank you to all our sponsors throughout the year (Datadog, CloudZero, Cisco Panoptica, Section, Fix the Internet, Sysdig, DoIT, Eaton, theCUBE, CNCF, Upland Software, Equinix, Red Hat, Cloudfix, GCore, Kosli)2023 PREDICTIONS: Our 2020 PredictionsOur 2021 PredictionsOur 2022 Predictions AARON'S PREDICTIONS:A Hyperscaler that isn't 1 or 2 throws in the towel - We start to see consolidation in the categoryPlatform Engineering hits its Trough of DisillusionmentCompact, OSS, specialized AI models will become the standard for anything not in the cloud (on device, datacenter, edge)A new category emerges - AI Customization for the masses (Data Science as a Service) - intersection of ITOps and AIBRIAN'S PREDICTIONS:We'll see the 1st 500M-user AI serviceAI economics start to change (smaller models, non-GPU chips)40-50 former unicorns ($1B valuations from 2020-22) get acquired Every product adds an AI / LLM capability to simplify usageFEEDBACK?Email: show at the cloudcast dot netTwitter: @thecloudcastnet
In this episode, Host Ron Eddings, discusses new tactics of adversaries with Director of Threat Research at Sysdig, Michael Clark. Michael digs into the cloud and shares trends about the AMBERSQUID operation and how to protect yourself from potential container-based threats. Impactful Moments 00:00 - Welcome 01:20 - Introducing guest Michael Clark 03:09 - Finding AMBERSQUID 06:46 - Mining and Monitoring AWS Services 10:47 - Defending Against AMBERSQUID 14:03 - The Speed of Container-Based Threats 18:13 - The Costs of Freejacking 23:08 - Attribution & The Future Threat 26:30 - CIEMs Like You Have Secrets Links: Connect with Michael Clark: https://www.linkedin.com/in/michaelclarkinpa/ Check out Sysdig's Threat Research: https://sysdig.com/threat-research/ Join our creative mastermind and stand out as a cybersecurity professional: https://www.patreon.com/hackervalleystudio Become a sponsor of the show to amplify your brand: https://hackervalley.com/work-with-us/ Love Hacker Valley Studio? Pick up some swag: https://store.hackervalley.com Continue the conversation by joining our Discord: https://hackervalley.com/discord
All links and images for this episode can be found on CISO Series. This week's episode is hosted by me, David Spark (@dspark), producer of CISO Series and Mike Johnson, CISO, Rivian. Joining me is our guest, Suresh Vasudevan, CEO, Sysdig. In this episode: What will the employment landscape look like with Generative AI becoming the next big thing? Will we be hiring prompt engineers in a few years? Or will it become like putting "search engine proficiency" on your resume? Thanks to our podcast sponsors, Sysdig For businesses innovating in the cloud, every second counts. Sysdig strengthens cyber resilience by reducing the attack surface, detecting threats in real time, and accelerating incident response. Our platform correlates signals across cloud workloads, identities, and services to enable businesses to prioritize risks and act decisively. Sysdig. Secure every second.
All links and images for this episode can be found on CISO Series. This week's episode is hosted by me, David Spark (@dspark), producer of CISO Series and Mike Johnson, CISO, Rivian. Joining me is our guest, Kurt Sauer, CISO, Docusign. We recorded in front of a live audience at Microsoft's offices in Mountain View, CA as part of the ISSA-Silicon Valley chapter meeting. Check out all the photos from the event. In this episode: Is a high profile cyberattack the best time for salespeople to come out of the woodwork asking if the affected CISO would like to see their product, which would have helped prevent the attack? Is there any way for a vendor to positively reach out to victims after a cyberattack? Also, what could be some effective ways to invest IP with generative AI to create value for the organization? Thanks to our podcast sponsors, Veza, Sysdig, and SlashNext 75% of breaches happen because of bad permissions. The problem is that you don't know exactly WHO has access to WHAT data in your environment. For example, roles labeled as “read-only” can often edit and delete sensitive data. Veza automatically finds and fixes every bad permission—in every app—across your environment. For businesses innovating in the cloud, every second counts. Sysdig strengthens cyber resilience by reducing the attack surface, detecting threats in real time, and accelerating incident response. Our platform correlates signals across cloud workloads, identities, and services to enable businesses to prioritize risks and act decisively. Sysdig. Secure every second. SlashNext Complete delivers zero-hour protection for how people work today across email, mobile, and browser apps. With SlashNext's generative AI to defend against advanced business email compromise, smishing, spear phishing, executive impersonation, and financial fraud, your people are always protected anywhere they work. Request a demo today.
Alex Lawrence, Field CISO at Sysdig, joins Corey on Screaming in the Cloud to discuss how he went from studying bioluminescence and mycology to working in tech, and his stance on why open source is the future of cloud security. Alex draws an interesting parallel between the creative culture at companies like Pixar and the iterative and collaborative culture of open-source software development, and explains why iteration speed is crucial in cloud security. Corey and Alex also discuss the pros and cons of having so many specialized tools that tackle specific functions in cloud security, and the different postures companies take towards their cloud security practices. About AlexAlex Lawrence is a Field CISO at Sysdig. Alex has an extensive history working in the datacenter as well as with the world of DevOps. Prior to moving into a solutions role, Alex spent a majority of his time working in the world of OSS on identity, authentication, user management and security. Alex's educational background has nothing to do with his day-to-day career; however, if you'd like to have a spirited conversation on bioluminescence or fungus, he'd be happy to oblige.Links Referenced: Sysdig: https://sysdig.com/ sysdig.com/opensource: https://sysdig.com/opensource falco.org: https://falco.org TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted guest episode is brought to us by our friends over at Sysdig, and they have brought to me Alexander Lawrence, who's a principal security architect over at Sysdig. Alexander, thank you for joining me.Alex: Hey, thanks for having me, Corey.Corey: So, we all have fascinating origin stories. Invariably you talk to someone, no one in tech emerged fully-formed from the forehead of some God. Most of us wound up starting off doing this as a hobby, late at night, sitting in the dark, rarely emerging. You, on the other hand, studied mycology, so watching the rest of us sit in the dark and growing mushrooms was basically how you started, is my understanding of your origin story. Accurate, not accurate at all, or something in between?Alex: Yeah, decently accurate. So, I was in school during the wonderful tech bubble burst, right, high school era, and I always told everybody, there's no way I'm going to go into technology. There's tons of people out there looking for a job. Why would I do that? And let's face it, everybody expected me to, so being an angsty teenager, I couldn't have that. So, I went into college looking into whatever I thought was interesting, and it turned out I had a predilection to go towards fungus and plants.Corey: Then you realized some of them glow and that wound up being too bright for you, so all right, we're done with this; time to move into tech?Alex: [laugh]. Strangely enough, my thesis, my capstone, was on the coevolution of bioluminescence across aquatic and terrestrial organisms. And so, did a lot of focused work on specifically bioluminescent fungus and bioluminescing fish, like Photoblepharon palpebratus and things like that.Corey: When I talk to people who are trying to figure out, okay, I don't like what's going on in my career, I want to do something different, and their assumption is, oh, I have to start over at square one. It's no, find the job that's halfway between what you're doing now and what you want to be doing, and make lateral moves rather than starting over five years in or whatnot. But I have to wonder, how on earth did you go from A to B in this context?Alex: Yeah, so I had always done tech. My first job really was in tech at the school districts that I went to in high school. And so, I went into college doing tech. I volunteered at the ELCA and other organizations doing tech, and so it basically funded my college career. And by the time I finished up through grad school, I realized my life was going to be writing papers so that other people could do the research that I was coming up with, and I thought that sounded like a pretty miserable life.And so, it became a hobby, and the thing I had done throughout my entire college career was technology, and so that became my new career and vocation. So, I was kind of doing both, and then ended up landing in tech for the job market.Corey: And you've effectively moved through the industry to the point where you're now in security architecture over at Sysdig, which, when I first saw Sysdig launch many years ago, it was, this is an interesting tool. I can see observability stories, I can see understanding what's going on at a deep level. I liked it as a learning tool, frankly. And it makes sense, with the benefit of hindsight, that oh, yeah, I suppose it does make some sense that there are security implications thereof. But one of the things that you've said that I really want to dig into that I'm honestly in full support of because it'll irritate just the absolute worst kinds of people is—one of the core beliefs that you espouse is that security when it comes to cloud is inherently open-source-based or at least derived. I don't want to misstate your position on this. How do you view it?Alex: Yeah. Yeah, so basically, the stance I have here is that the future of security in cloud is open-source. And the reason I say that is that it's a bunch of open standards that have basically produced a lot of the technologies that we're using in that stack, right, your web servers, your automation tooling, all of your different components are built on open stacks, and people are looking to other open tools to augment those things. And the reality is, is that the security environment that we're in is changing drastically in the cloud as opposed to what it was like in the on-premises world. On-prem was great—it still is great; a lot of folks still use it and thrive on it—but as we look at the way software is built and the way we interface with infrastructure, the cloud has changed that dramatically.Basically, things are a lot faster than they used to be. The model we have to use in order to make sure our security is good has dramatically changed, right, and all that comes down to speed and how quickly things evolve. I tend to take a position that one single brain—one entity, so to speak—can't keep up with that rapid evolution of things. Like, a good example is Log4j, right? When Log4j hit this last year, that was a pretty broad attack that affected a lot of people. You saw open tooling out there, like Falco and others, they had a policy to detect and help triage that within a couple of hours of it hitting the internet. Other proprietary tooling, it took much longer than two hours.Corey: Part of me wonders what the root cause behind that delay is because it's not that the engineers working at these companies are somehow worse than folks in the open communities. In some cases, they're the same people. It feels like it's almost corporate process ossification of, “Okay, we built a thing. Now, we need to make sure it goes through branding and legal and marketing and we need to bring in 16 other teams to make this work.” Whereas in the open-source world, it feels like there's much more of a, “I push the deploy button and it's up. The end.” There is no step two.Alex: [laugh]. Yeah, so there is certainly a certain element of that. And I think it's just the way different paradigms work. There's a fantastic book out there called Creativity, Inc., and it's basically a book about how Pixar manages itself, right? How do they deal with creating movies? How do they deal with doing what they do, well?And really, what it comes down to is fostering a culture of creativity. And that typically revolves around being able to fail fast, take risks, see if it sticks, see if it works. And it's not that corporate entities don't do that. They certainly do, but again, if you think about the way the open-source world works, people are submitting, you know, PRs, pull requests, they're putting out different solutions, different fixes to problems, and the ones that end up solving it the best are often the ones that end up coming to the top, right? And so, it's just—the way you iterate is much more akin to that kind of creativity-based mindset that I think you get out of traditional organizations and corporations.Corey: There's also, I think—I don't know if this is necessarily the exact point, but it feels like it's at least aligned with it—where there was for a long time—by which I mean, pretty much 40 years at this point—a debate between open disclosure and telling people of things that you have found in vendors products versus closed disclosure; you only wind—or whatever the term is where you tell the vendor, give them time to fix it, and it gets out the door. But we've seen again and again and again, where researchers find something, report it, and then it sits there, in some cases for years, but then when it goes public and the company looks bad as a result, they scramble to fix it. I wish it were not this way, but it seems that in some cases, public shaming is the only thing that works to get companies to secure their stuff.Alex: Yeah, and I don't know if it's public shaming, per se, that does it, or it's just priorities, or it's just, you know, however it might go, there's always been this notion of, “Okay, we found a breach. Let's disclose appropriately, you know, between two entities, give time to remediate.” Because there is a potential risk that if you disclose publicly that it can be abused and used in very malicious ways—and we certainly don't want that—but there also is a certain level of onus once the disclosure happens privately that we got to go and take care of those things. And so, it's a balancing act.I don't know what the right solution is. I mean, if I did, I think everybody would benefit from things like that, but we just don't know the proper answer. The workflow is complex, it is difficult, and I think doing our due diligence to make sure that we disclose appropriately is the right path to go down. When we get those disclosures we need to take them seriously is when it comes down to.Corey: What I find interesting is your premise that the future of cloud security is open-source. Like, I could make a strong argument that today, we definitely have an open-source culture around cloud security and need to, but you're talking about that shifting along the fourth dimension. What's the change? What do you see evolving?Alex: Yeah, I think for me, it's about the collaboration. I think there are segments of industries that communicate with each other very, very well, and I think there's others who do a decent job, you know, behind closed doors, and I think there's others, again, that don't communicate at all. So, all of my background predominantly has been in higher-ed, K-12, academia, and I find that a lot of those organizations do an extremely good job of partnering together, working together to move towards, kind of, a greater good, a greater goal. An example of that would be a group out in the Pacific Northwest called NWACC—the NorthWest Academic Computing Consortium. And so, it's every university in the Northwest all come together to have CIO Summits, to have Security Summits, to trade knowledge, to work together, basically, to have a better overall security posture.And they do it pretty much out in the open and collaborating with each other, even though they are also direct competitors, right? They all want the same students. It's a little bit of a different way of thinking, and they've been doing it for years. And I'm finding that to be a trend that's happening more and more outside of just academia. And so, when I say the future is open, if you think about the tooling academia typically uses, it is very open-source-oriented, it is very collaborative.There's no specifications on things like eduPerson to be able to go and define what a user looks like. There's things like, you know, CAS and Shibboleth to do account authorization and things like that. They all collaborate on tooling in that regard. We're seeing more of that in the commercial space as well. And so, when I say the future of security in cloud is open-source, it's models like this that I think are becoming more and more effective, right?It's not just the larger entities talking to each other. It's everybody talking with each other, everybody collaborating with each other, and having an overall better security posture. The reality is, is that the folks we're defending ourselves against, they already are communicating, they already are using that model to work together to take down who they view as their targets: us, right? We need to do the same to be able to keep up. We need to be able to have those conversations openly, work together openly, and be able to set that security posture across that kind of overall space.Corey: There's definitely a concern that if okay, you have all these companies and community collaborating around security aspects in public, that well won't the bad actors be able to see what they're looking at and how they're approaching it and, in some cases, move faster than they can or, in other cases, effectively wind up polluting the conversation by claiming to be good actors when they're not. And there's so many different ways that this can manifest. It feels like fear is always the thing that stops people from going down this path, but there is some instance of validity to that I would imagine.Alex: Yeah, no. And I think that certainly is true, right? People are afraid to let go of, quote-unquote, “The keys to their kingdom,” their security posture, their things like that. And it makes sense, right? There's certain things that you would want to not necessarily talk about openly, like, specifically, you know, what Diffie–Hellman key exchange you're using or something like that, but there are ways to have these conversations about risks and posture and tooling and, you know, ways you approach it that help everybody else out, right?If someone finds a particularly novel way to do a detection with some sort of piece of tooling, they probably should be sharing that, right? Let's not keep it to ourselves. Traditionally, just because you know the tool doesn't necessarily mean that you're going to have a way in. Certainly, you know, it can give you a path or a vector to go after, but if we can at least have open standards about how we implement and how we can go about some of these different concepts, we can all gain from that, so to speak.Corey: Part of me wonders if the existing things that the large companies are collaborating on lead to a culture that specifically pushes back against this. A classic example from my misspent youth is that an awful lot of the anti-abuse departments at these large companies are in constant communication. Because if you work at Microsoft, or Google or Amazon, your adversary, as you see it, in the Trust and Safety Group is not those other companies. It's bad actors attempting to commit fraud. So, when you start seeing particular bad actors emerging from certain parts of the network, sharing that makes everything better because there's an understanding there that it's not, “Oh, Microsoft has bad security this week,” or, “Google will wind up approving fraudulent accounts that start spamming everyone.”Because the takeaway by theby the customers is not that this one company is bad; it's oh, the cloud isn't safe. We shouldn't use cloud. And that leads to worse outcomes for basically everyone. But they're als—one of the most carefully guarded secrets at all these companies is how they do fraud prevention and spam detection because if adversaries find that out, working around them becomes a heck of a lot easier. I don't know, for example, how AWS determines whether a massive account overage in a free-tier account is considered to be a bad actor or someone who made a legitimate mistake. I can guess, but the actual signal that they use is something that they would never in a million years tell me. They probably won't even tell each other specifics of that.Alex: Certainly, and I'm not advocating that they let all of the details out, per se, but I think it would be good to be able to have more of an open posture in terms of, like, you know what tooling do they use? How do they accomplish that feat? Like, are they looking at a particular metric? How do they basically handle that posture going forward? Like, what can I do to replicate a similar concept?I don't need to know all the details, but would be nice if they embrace, you know, open tooling, like say a Trivy or a Falco or whatever the thing is, right, they're using to do this process and then contribute back to that project to make it better for everybody. When you kind of keep that stuff closed-source, that's when you start running into that issue where, you know, they have that, quote-unquote, “Advantage,” that other folks aren't getting. Maybe there's something we can do better in the community, and if we can all be better, it's better for everybody.Corey: There's a constant customer pain in the fact that every cloud provider, for example, has its own security perspective—the way that identity is managed, the way that security boundaries exist, the way that telemetry from these things winds up getting represented—where a number of companies that are looking at doing things that have to work across cloud for a variety of reasons—some good, some not so good—have decided that, okay, we're just going to basically treat all these providers as, more or less, dumb pipes and dumb infrastructure. Great, we're just going to run Kubernetes on all these things, and then once it's inside of our cluster, then we'll build our own security overlay around all of these things. They shouldn't have to do that. There should be a unified set of approaches to these things. At least, I wish there were.Alex: Yeah, and I think that's where you see a lot of the open standards evolving. A lot of the different CNCF projects out there are basically built on that concept. Like, okay, we've got Kubernetes. We've got a particular pipeline, we've got a particular type of implementation of a security measure or whatever it might be. And so, there's a lot of projects built around how do we standardize those things and make them work cross-functionally, regardless of where they're running.It's actually one of the things I quite like about Kubernetes: it makes it be a little more abstract for the developers or the infrastructure folks. At one point in time, you had your on-premises stuff and you built your stuff towards how your on-prem looked. Then you went to the cloud and started building yourself to look like what that cloud look like. And then another cloud showed up and you had to go use that one. Got to go refactor your application to now work in that cloud.Kubernetes has basically become, like, this gigantic API ball to interface with the clouds, and you don't have to build an application four different ways anymore. You can build it one way and it can work on-prem, it can work in Google, Azure, IBM, Oracle, you know, whoever, Amazon, whatever it needs to be. And then that also enables us to have a standard set of tools. So, we can use things like, you know, Rego or we can use things like Falco or we can use things that allow us to build tooling to secure those things the same way everywhere we go. And the benefit of most of those tools is that they're also configured, you know, via some level of codification, and so we can have a repository that contains our posture: apply that posture to that cluster, apply it to the other cluster in the other environment. It allows us to automate these things, go quicker, build the posture at the very beginning, along with that application.Corey: One of the problems I feel as a customer is that so many of these companies have a model for interacting with security issues that's frankly obnoxious. I am exhausted by the amount of chest-thumping, you'll see on keynote stages, all of the theme, “We're the best at security.” And whenever a vulnerability researcher reports something of a wide variety of different levels of severity, it always feels like the first concern from the company is not fix the issue, but rather, control the messaging around it.Whenever there's an issue, it's very clear that they will lean on people to rephrase things, not use certain words. It's, I don't know if the words used to describe this cross-tenant vulnerability are the biggest problem you should be focusing on right now. Yes, I understand that you can walk and chew gum at the same time as a big company, but it almost feels like the researchers are first screaming into a void, and then they're finally getting attention, but from all the people they don't want to get the attention from. It feels like this is not a welcoming environment for folks to report these things in good faith.Alex: [sigh]. Yeah, it's not. And I don't know what the solution is to that particular problem. I have opinions about why that exists. I won't go into those here, but it's cumbersome. It's difficult. I don't envy a lot of those research organizations.They're fantastic people coming up with great findings, they find really interesting stuff that comes out, but when you have to report and do that due diligence, that portion is not that fun. And then doing, you know, the fallout component, right: okay, now we have this thing we have to report, we have to go do something to fix it, you're right. I mean, people do often get really spun up on the verbiage or the implications and not just go fix the problem. And so again, if you have ways to mitigate that are more standards-based, that aren't specific to a particular cloud, like, you can use an open-source tool to mitigate, that can be quite the advantage.Corey: One of the challenges that I see across a wide swath of tooling and approaches to it have been that when I was trying to get some stuff to analyze CloudTrail logs in my own environment, I was really facing a bimodal distribution of options. On one end of the spectrum, it's a bunch of crappy stuff—or good stuff; hard to say—but it's all coming off of GitHub, open-source, build it yourself, et cetera. Good luck. And that's okay, awesome, but there's business value here and I'm thrilled to pay experts to make this problem go away.The other end of the spectrum is commercial security tooling, and it is almost impossible in my experience to find anything that costs less than $1,000 a month to start providing insight from a security perspective. Now, I understand the market forces that drive this. Truly I do, and I'm sympathetic to them. It is just as easy to sell $50,000 worth of software as it is five to an awful lot of companies, so yeah, go where the money is. But it also means that the small end of the market as hobbyists, as startups are just getting started, there is a price barrier to engaging in the quote-unquote, “Proper way,” to do security.So, the posture suffers. We'll bolt security on later when it becomes important is the philosophy, and we've all seen how well that plays out in the fullness of time. How do you square that circle? I think the answer has to be open-source improving to the point where it's not just random scripts, but renowned projects.Alex: Correct, yeah, and I'd agree with that. And so, we're kind of in this interesting phase. So, if you think about, like, raw Linux applications, right, Linux, always is the tenant that you build an application to do one thing, does that one thing really, really, really well. And then you ended up with this thing called, like, you know, the Cacti monitoring stack. And so, you ended up having, like, 600 tools you strung together to get this one monitoring function done.We're kind of in a similar spot in a lot of ways right now, in the open-source security world where, like, if you want to do scanning, you can do, like, Clair or you can do Trivy or you have a couple different choices, right? If you want to do posture, you've got things like Qbench that are out there. If you want to go do runtime security stuff, you've got something like Falco. So, you've got all these tools to string together, right, to give you all of these different components. And if you want, you can build it yourself, and you can run it yourself and it can be very fun and effective.But at some point in your life, you probably don't want to be care-and-feeding your child that you built, right? It's 18 years later now, and you want to go back to having your life, and so you end up buying a tool, right? That's why Gartner made this whole CNAP category, right? It's this humongous category of products that are putting all of these different components together into one gigantic package. And the whole goal there is just to make lives a little bit easier because running all the tools yourself, it's fun, I love it, I did it myself for a long time, but eventually, you know, you want to try to work on some other stuff, too.Corey: At one point, I wound up running the numbers of all of the first-party security offerings that AWS offered, and for most use cases of significant scale, the cost for those security services was more than the cost of the theoretical breach that they'd be guarding against. And I think that there's a very dangerous incentive that arises when you start turning security observability into your own platform as a profit center. Because it's, well, we could make a lot of money if we don't actually fix the root issue and just sell tools to address and mitigate some of it—not that I think that's the intentional direction that these companies are taking these things and I don't want to ascribe malice to them, but you can feel that start to be the trend that some decisions get pushed in.Alex: Yeah, I mean, everything comes down to data, right? It has to be stored somewhere, processed somewhere, analyzed somewhere. That always has a cost with it. And so, that's always this notion of the shared security model, right? We have to have someone have ownership over that data, and most of the time, that's the end-user, right? It's their data, it's their responsibility.And so, these offerings become things that they have that you can tie into to work within the ecosystem, work within their infrastructure to get that value out of your data, right? You know, where is the security model going? Where do I have issues? Where do I have misconfigurations? But again, someone has to pay for that processing time. And so, that ends up having a pretty extreme cost to it.And so, it ends up being a hard problem to solve. And it gets even harder if you're multi-cloud, right? You can't necessarily use the tooling of AWS inside of Azure or inside of Google. And other products are trying to do that, right? They're trying to be able to let you integrate their security center with other clouds as well.And it's kind of created this really interesting dichotomy where you almost have frenemies, right, where you've got, you know, a big Azure customer who's also a big AWS customer. Well, they want to go use Defender on all of their infrastructure, and Microsoft is trying to do their best to allow you to do that. Conversely, not all clouds operate in that same capacity. And you're correct, they all come at extremely different costs, they have different price models, they have different ways of going about it. And it becomes really difficult to figure out what is the best path forward.Generally, my stance is anything is better than nothing, right? So, if your only choice is using Defender to do all your stuff and it cost you an arm or leg, unfortunate, but great; at least you got something. If the path is, you know, go use this random open-source thing, great. Go do that. Early on, when I'd been at—was at Sysdig about five years ago, my big message was, you know, I don't care what you do. At least scan your containers. If you're doing nothing else in life, use Clair; scan the darn things. Don't do nothing.That's not really a problem these days, thankfully, but now we're more to a world where it's like, well, okay, you've got your containers, you've got your applications running in production. You've scanned them, that's great, but you're doing nothing at runtime. You're doing nothing in your posture world, right? Do something about it. So, maybe that is buy the enterprise tool from the cloud you're working in, buy it from some other vendor, use the open-source tool, do something.Thankfully, we live in a world where there are plenty of open tools out there we can adopt and leverage. You used the example of CloudTrail earlier. I don't know if you saw it, but there was a really, really cool talk at SharkFest last year from Gerald Combs where they leveraged Wireshark to be able to read CloudTrail logs. Which I thought was awesome.Corey: That feels more than a little bit ridiculous, just because it's—I mean I guess you could extract the JSON object across the wire then reassemble it. But, yeah, I need to think on that one.Alex: Yeah. So, it's actually really cool. They took the plugins from Falco that exist and they rewired Wireshark to leverage those plugins to read the JSON data from the CloudTrail and then wired it into the Wireshark interface to be able to do a visual inspect of CloudTrail logs. So, just like you could do, like, a follow this IP with a PCAP, you could do the same concept inside of your cloud log. So, if you look up Logray, you'll find it on the internet out there. You'll see demos of Gerald showing it off. It was a pretty darn cool way to use a visualization, let's be honest, most security professionals already know how to use in a more modern infrastructure.Corey: One last topic that I want to go into with you before we call this an episode is something that's been bugging me more and more over the years—and it annoyed me a lot when I had to deal with this stuff as a SOC 2 control owner and it's gotten exponentially worse every time I've had to deal with it ever since—and that is the seeming view of compliance and security as being one and the same, to the point where in one of my accounts that I secured rather well, I thought, I installed security hub and finally jumped through all those hoops and paid the taxes and the rest and then waited 24 hours to gather some data, then 24 hours to gather more. Awesome. Applied the AWS-approved a foundational security benchmark to it and it started shrieking its bloody head off about all of the things that were insecure and not configured properly. One of them, okay, great, it complained that the ‘Block all S3 Public Access' setting was not turned on for the account. So, I turned that on. Great.Now, it's still complaining that I have not gone through and also enabled the ‘Block Public Access Setting' on each and every S3 bucket within it. That is not improving your security posture in any meaningful way. That is box-checking so that someone in a compliance role can check that off and move on to the next thing on the clipboard. Now, originally, they started off being good-intentioned, but the result is I'm besieged by these things that don't actually matter and that means I'm not going to have time to focus on the things that actually do. Please tell me I'm wrong on some of this.Alex: [laugh].Corey: I really need to hear that.Alex: I can't. Unfortunately, I agree with you that a lot of that seems erroneous. But let's be honest, auditors have a job for a reason.Corey: Oh, I'm not besmirching the role of the auditor. Far from it. The problem I run into is that it's the Human Nessus report that dumps out, “Here's the 700 things to go fix in your environment,” as opposed to, “Here's the five things you can do right now that will meaningfully improve your security posture.”Alex: Yeah. And so, I think that's a place we see a lot of vendors moving, and I think that is the right path forward. Because we are in a world where we generate reports that are miles and miles long, we throw them over a wall to somebody, and that person says, “Are you crazy?” Like, “You want me to go do what with my time?” Like, “No. I can't. No. This is way too much.”And so, if we can narrow these things down to what matters the most today, and then what can we get rid of tomorrow, that makes life better for everybody. There are certainly ways to accomplish that across a lot of different dimensions, be that vulnerability management, or configuration management stuff, runtime stuff, and that is certainly the way we should approach it. Unfortunately, not all frameworks allow us to look at it that way.Corey: I mean, even AWS's thing here is yelling at me for a number of services not having encryption-at-rest turned on, like CloudTrail logs, or SNS topics. It's okay, let's be very clear what that is defending against: someone stealing drives out of a data center and taking them off to view the data. Is that something that I need to worry about in a public cloud provider context? Not unless I'm the CIA or something pretty close to that. I mean, if you can get my data out of an AWS data center and survive, congratulations, I kind of feel like you've earned it at this point. But that obscures things I need to be doing that I'm not.Alex: Back in the day, I had a customer who used to have—they had storage arrays and their storage arrays' logins were the default login that they came with the array. They never changed it. You just logged in with admin and no password. And I was like, “You know, you should probably fix that.” And he sent a message back saying, “Yeah, you know, maybe I should, but my feeling is that if it got that far into my infrastructure where they can get to that interface, I'm already screwed, so it doesn't really matter to me if I set that admin password or not.”Corey: Yeah, there is a defense-in-depth argument to be made. I am not disputing that, but the Cisco world is melting down right now because of a bunch of very severe vulnerabilities that have been disclosed. But everything to exploit these things always requires, well you need access to the management interface. Back when I was a network administrator at Chapman University in 2006, even then, I knew, “Well, we certainly don't want to put the management interfaces on the same VLAN that's passing traffic.”So, is it good that there's an unpatched vulnerability there? No, but Shodan, the security vulnerability search engine shows over 80,000 instances that are affected on the public internet. It would never have occurred to me to put the management interface of important network gear on the public internet. That just is… I don't understand that.Alex: Yeah.Corey: So, on some level, I think the lesson here is that there's always someone who has something else to focus on at a given moment, and… where it's a spectrum: no one is fully secure, but ideally, you don't want to be the lowest of low-hanging fruit.Alex: Right, right. I mean, if you were fully secure, you'd just turn it off, but unfortunately, we can't do that. We have to have it be accessible because that's our jobs. And so, if we're having it be accessible, we got to do the best we can. And I think that is a good point, right? Not being the worst should be your goal, at the very, very least.Doing bare minimums, looking at those checks, deciding if they're relevant for you or not, just because it says the configuration is required, you know, is it required in your use case? Is it required for your requirements? Like, you know, are you a FedRAMP customer? Okay, yeah, it's probably a requirement because, you know, it's FedRAMP. They're going to tell you got to do it. But is it your dev environment? Is it your demo stuff? You know, where does it exist, right? There's certain areas where it makes sense to deal with it and certain areas where it makes sense to take care of it.Corey: I really want to thank you for taking the time to talk me through your thoughts on all this. If people want to learn more, where's the best place for them to find you?Alex: Yeah, so they can either go to sysdig.com/opensource. A bunch of open-source resources there. They can go to falco.org, read about the stuff on that site, as well. Lots of different ways to kind of go and get yourself educated on stuff in this space.Corey: And we will, of course, put links to that into the show notes. Thank you so much for being so generous with your time. I appreciate it.Alex: Yeah, thanks for having me. I appreciate it.Corey: Alexander Lawrence, principal security architect at Sysdig. I'm Cloud Economist Corey Quinn, and this episode has been brought to us by our friends, also at Sysdig. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an insulting comment that I will then read later when I pick it off the wire using Wireshark.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.
Threat detection is often limited to popular cloud services, so whats happening to all the "not so popular or commonly known" cloud services in your environment? We are speaking to Suresh Vasudevan, CEO of Sysdig about challenges typically companies find with this space and what should be the approach for threat detection. If you feel you are looking at threats from all cloud services you might want to hear this episode to know you actually are.Thank you to our episode sponsor Vanta and Sysdig You can find out more about Sysdig here! Find out more about Vanta here! Guest Socials: Suresh's Linkedin (@suvasudevan) Podcast Twitter - @CloudSecPod If you want to watch videos of this LIVE STREAMED episode and past episodes - Check out our other Cloud Security Social Channels: - Cloud Security Newsletter - Cloud Security BootCamp Questions asked: (00:00) Introduction (03:41) A bit about Suresh (05:14) How was threat detection done traditionally? (07:33) How does threat detection translate to cloud? (08:47) Uncommon services attack vector examples (11:00) Uncommon services explained (11:31) Problems with threat detection in cloud (16:53) How to approach prioritisation? (19:48) Bridging Cloud and Applications Resources discussed during the episode! LabRatAmberSquidScarleteelThe 2023 Global Threat Research
The Hamas-Israel war continues to be marked by hacktivism. Arid Viper's exploitation of Arabic speaker's Android devices. Iran shows improved cyberespionage capabilities. A URL shortener in the C2C market. Taking down the Mozi botnet. Ransomware in healthcare. Two are Russians arrested on treason charges, accused of hacking for Ukraine. In our sponsored Industry Voices segment, Anna Belak from Sysdig shares a new threat framework for the cloud. Rick Howard previews his new online course on cyber security first principles. And no, Russia hasn't really replaced its currency with Arctic Ocean gastropods. For links to all of today's stories check out our CyberWire daily news briefing: https://thecyberwire.com/newsletters/daily-briefing/12/209 Selected reading. ‘Hacktivists' join the front lines in Israel-Hamas war (C4ISRNet) The global cyber divide between Gaza and Israel - IT-Online (IT-Online) Arid Viper disguising mobile spyware as updates for non-malicious Android applications (Cisco Talos Blog) In Cyberattacks, Iran Shows Signs of Improved Hacking Capabilities (New York Times) FBI ‘keeping a close eye' on Iranian hackers as Israel-Hamas war intensifies (Record) Why Iran Is Gambling on Hamas (Foreign Affairs) To Aid and Abet: Prolific Puma Helps Cybercriminals Evade Detection (Infoblox Blog) Who killed Mozi? Finally putting the IoT zombie botnet in its grave (ESET) The State of Ransomware in Healthcare 2023 (Sophos) Russian security service detains two hackers allegedly working for Ukraine (Record) Pro-Ukraine group says it breached Russian card payment system (Record) Learn more about your ad choices. Visit megaphone.fm/adchoices
All links and images for this episode can be found on CISO Series. In principle, we can generally all agree that security theater is a waste of time for security teams. But the reality is that these are things that look good, so it can be hard to justify to non-technical leadership why you're eliminating something they see as secure. So how can we positively identify actual security theater practices and how do we communicate that to the rest of the organization? This week's episode is hosted by me, David Spark (@dspark), producer of CISO Series and Andy Ellis (@csoandy), operating partner, YL Ventures. Joining me is our guest, Davi Ottenheimer, vp of trust and digital ethics, Inrupt. Thanks to our podcast sponsor, Sysdig For businesses innovating in the cloud, every second counts. Sysdig strengthens cyber resilience by reducing the attack surface, detecting threats in real time, and accelerating incident response. Our platform correlates signals across cloud workloads, identities, and services to enable businesses to prioritize risks and act decisively. Sysdig. Secure every second. In this episode: Is security theater a waste of time for security teams? Why can it be hard to justify to non-technical leadership why you're eliminating something they see as secure? How can we positively identify actual security theater practices and how do we communicate that to the rest of the organization?
Sysdig's Alessandro Brucato and Michael Clark join Dave to discuss their work on "AWS's Hidden Threat: AMBERSQUID Cloud-Native Cryptojacking Operation." Attackers are targeting what are typically considered secure AWS services, like AWS Fargate and Amazon SageMaker. This means that defenders generally aren't as concerned with their security from end-to-end. The research states "The AMBERSQUID operation was able to exploit cloud services without triggering the AWS requirement for approval of more resources, as would be the case if they only spammed EC2 instances." This poses additional challenges targeting multiple services since it requires finding and killing all miners in each exploited service. The research can be found here: AWS's Hidden Threat: AMBERSQUID Cloud-Native Cryptojacking Operation Learn more about your ad choices. Visit megaphone.fm/adchoices
Dmitry Kagansky, State CTO and Deputy Executive Director for the Georgia Technology Authority, joins Corey on Screaming in the Cloud to discuss how he became the CTO for his home state and the nuances of working in the public sector. Dmitry describes his focus on security and reliability, and why they are both equally important when working with state government agencies. Corey and Dmitry describe AWS's infamous GovCloud, and Dmitry explains why he's employing a multi-cloud strategy but that it doesn't work for all government agencies. Dmitry also talks about how he's focusing on hiring and training for skills, and the collaborative approach he's taking to working with various state agencies.About DmitryMr. Kagansky joined GTA in 2021 from Amazon Web Services where he worked for over four years helping state agencies across the country in their cloud implementations and migrations.Prior to his time with AWS, he served as Executive Vice President of Development for Star2Star Communications, a cloud-based unified communications company. Previously, Mr. Kagansky was in many technical and leadership roles for different software vending companies. Most notably, he was Federal Chief Technology Officer for Quest Software, spending several years in Europe working with commercial and government customers.Mr. Kagansky holds a BBA in finance from Hofstra University and an MBA in management of information systems and operations management from the University of Georgia.Links Referenced: Twitter: https://twitter.com/dimikagi LinkedIn: https://www.linkedin.com/in/dimikagi/ GTA Website: https://gta.ga.gov TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: In the cloud, ideas turn into innovation at virtually limitless speed and scale. To secure innovation in the cloud, you need Runtime Insights to prioritize critical risks and stay ahead of unknown threats. What's Runtime Insights, you ask? Visit sysdig.com/screaming to learn more. That's S-Y-S-D-I-G.com/screaming.My thanks as well to Sysdig for sponsoring this ridiculous podcast.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Technical debt is one of those fun things that everyone gets to deal with, on some level. Today's guest apparently gets to deal with 235 years of technical debt. Dmitry Kagansky is the CTO of the state of Georgia. Dmitry, thank you for joining me.Dmitry: Corey, thank you very much for having me.Corey: So, I want to just begin here because this has caused confusion in my life; I can only imagine how much it's caused for you folks. We're talking Georgia the US state, not Georgia, the sovereign country?Dmitry: Yep. Exactly.Corey: Excellent. It's always good to triple-check those things because otherwise, I feel like the shipping costs are going to skyrocket in one way or the other. So, you have been doing a lot of very interesting things in the course of your career. You're former AWS, for example, you come from commercial life working in industry, and now it's yeah, I'm going to go work in state government. How did this happen?Dmitry: Yeah, I've actually been working with governments for quite a long time, both here and abroad. So, way back when, I've been federal CTO for software companies, I've done other work. And then even with AWS, I was working with state and local governments for about four, four-and-a-half years. But came to Georgia when the opportunity presented itself, really to try and make a difference in my own home state. You mentioned technical debt at the beginning and it's one of the things I'm hoping that helped the state pay down and get rid of some of it.Corey: It's fun because governments obviously are not thought of historically as being the early adopters, bleeding edge when it comes to technical innovation. And from where I sit, for good reason. You don't want code that got written late last night and shoved into production to control things like municipal infrastructure, for example. That stuff matters. Unlike a lot of other walks of life, you don't usually get to choose your government, and, “Oh, I don't like this one so I'm going to go for option B.”I mean you get to do at the ballot box, but that takes significant amounts of time. So, people want above all else—I suspect—their state services from an IT perspective to be stable, first and foremost. Does that align with how you think about these things? I mean, security, obviously, is a factor in that as well, but how do you see, I guess, the primary mandate of what you do?Dmitry: Yeah. I mean, security is obviously up there, but just as important is that reliance on reliability, right? People take time off of work to get driver's licenses, right, they go to different government agencies to get work done in the middle of their workday, and we've got to have systems available to them. We can't have them show up and say, “Yeah, come back in an hour because some system is rebooting.” And that's one of the things that we're trying to fix and trying to have fewer of, right?There's always going to be things that happen, but we're trying to really cut down the impact. One of the biggest things that we're doing is obviously a move to the cloud, but also segmenting out all of our agency applications so that agencies manage them separately. Today, my organization, Georgia Technology Authority—you'll hear me say GTA—we run what we call NADC, the North Atlanta Data Center, a pretty large-scale data center, lots of different agencies, app servers all sitting there running. And then a lot of times, you know, an impact to one could have an impact to many. And so, with the cloud, we get some partitioning and some segmentation where even if there is an outage—a term you'll often hear used that we can cut down on the blast radius, right, that we can limit the impact so that we affect the fewest number of constituents.Corey: So, I have to ask this question, and I understand it's loaded and people are going to have opinions with a capital O on it, but since you work for the state of Georgia, are you using GovCloud over in AWS-land?Dmitry: So… [sigh] we do have some footprint in GovCloud, but I actually spent time, even before coming to GTA, trying to talk agencies out of using it. I think there's a big misconception, right? People say, “I'm government. They called it GovCloud. Surely I need to be there.”But back when I was with AWS, you know, I would point-blank tell people that really I know it's called GovCloud, but it's just a poorly named region. There are some federal requirements that it meets; it was built around the ITAR, which is International Traffic of Arms Regulations, but states aren't in that business, right? They are dealing with HIPAA data, with various criminal justice data, and other things, but all of those things can run just fine on the commercial side. And truthfully, it's cheaper and easier to run on the commercial side. And that's one of the concerns I have is that if the commercial regions meet those requirements, is there a reason to go into GovCloud, just because you get some extra certifications? So, I still spend time trying to talk agencies out of going to GovCloud. Ultimately, the agencies with their apps make the choice of where they go, but we have been pretty good about reducing the footprint in GovCloud unless it's absolutely necessary.Corey: Has this always been the case? Because my distant recollection around all of this has been that originally when GovCloud first came out, it was a lot harder to run a whole bunch of workloads in commercial regions. And it feels like the commercial regions have really stepped up as far as what compliance boxes they check. So, is one of those stories where five or ten years ago, whenever it GovCloud first came out, there were a bunch of reasons to use it that no longer apply?Dmitry: I actually can't go past I'll say, seven or eight years, but certainly within the last eight years, there's not been a reason for state and local governments to use it. At the federal level, that's a different discussion, but for most governments that I worked with and work with now, the commercial regions have been just fine. They've met the compliance requirements, controls, and everything that's in place without having to go to the GovCloud region.Corey: Something I noticed that was strange to me about the whole GovCloud approach when I was at the most recent public sector summit that AWS threw is whenever I was talking to folks from AWS about GovCloud and adopting it and launching new workloads and the rest, unlike in almost any other scenario, they seemed that their first response—almost a knee jerk reflex—was to pass that work off to one of their partners. Now, on the commercial side, AWS will do that when it makes sense, and each one becomes a bit of a judgment call, but it just seemed like every time someone's doing something with GovCloud, “Oh, talk to Company X or Company Y.” And it wasn't just one or two companies; there were a bunch of them. Why is that?Dmitry: I think a lot of that is because of the limitations within GovCloud, right? So, when you look at anything that AWS rolls out, it almost always rolls out into either us-east-1 or us-west-2, right, one of those two regions, and it goes out worldwide. And then it comes out in GovCloud months, sometimes even years later. And in fact, sometimes there are features that never show up in GovCloud. So, there's not parity there, and I think what happens is, it's these partners that know what limitations GovCloud has and what things are missing and GovCloud they still have to work around.Like, I remember when I started with AWS back in 2016, right, there had been a new console, you know, the new skin that everyone's now familiar with. But that old console, if you remember that, that was in GovCloud for years afterwards. I mean, it took them at least two more years to get GovCloud to even look like the current commercial console that you see. So, it's things like that where I think AWS themselves want to keep moving forward and having to do anything with kind of that legacy platform that doesn't have all the bells and whistles is why they say, “Go get a partner [unintelligible 00:08:06] those things that aren't there yet.”Corey: That's it makes a fair bit of sense. What I was always wondering how much of this was tied to technical challenges working within those, and building solutions that don't depend upon things. “Oh, wait, that one's not available in GovCloud,” versus a lack of ability to navigate the acquisition process for a lot of governments natively in the same way that a lot of their customers can.Dmitry: Yeah, I don't think that's the case because even to get a GovCloud account, you have to start off with a commercial account, right? So, you actually have to go through the same purchasing steps and then essentially, click an extra button or two.Corey: Oh, I've done that myself already. I have a shitposting account and a—not kidding—Ministry of Shitposting GovCloud account. But that's also me just kicking the tires on it. As I went through the process, it really felt like everything was built around a bunch of unstated assumption—because of course you've worked within GovCloud before and you know where these things are. And I kept tripping into a variety of different aspects of that. I'm wondering how much of that is just due to the fact that partners are almost always the ones guiding customers through that.Dmitry: Yeah. It is almost always that. There's very few people, even in the AWS world, right, if you look at all the employees they have there, it's small subset that work with that environment, and probably an even smaller subset of those that understand what it's really needed for. So, this is where if there's not good understanding, you're better off handing it off to a partner. But I don't think it is the purchasing side of things. It really is the regulatory things and just having someone else sign off on a piece of paper, above and beyond just AWS themselves.Corey: I am curious, since it seems that people love to talk about multi-cloud in a variety of different ways, but I find there's a reality that, ehh, basically, on a long enough timeline, everyone uses everything, versus the idea of, “Oh, we're going to build everything so we can seamlessly flow from one provider to another.” Are you folks all in on AWS? Are you using a bunch of different cloud providers for different workloads? How are you approaching a cloud strategy?Dmitry: So, when you say ‘you guys,' I'll say—as AWS will always say—“It depends.” So, GTA is multi-cloud. We support AWS, we support OCI, we support Azure, and we are working towards getting Google in as well, GCP. However, on the agency side, I am encouraging agencies to pick a cloud. And part of that is because you do have limited staff, they are all different, right?They'll do similar things, but if it's done in a different way and you don't have people that know those little tips and tricks, kind of how to navigate certain cloud vendors, it just makes things more difficult. So, I always look at it as kind of the car analogy, right? Most people are not multi-car, right? You go you buy a car—Toyota, Ford, whatever it is—and you're committed to that thing for the next 4 or 5, 10 years, however long you own it, right? You may not like where the cupholder is or you need to get used to something, you know, being somewhere else, but you do commit to it.And I think it's the same thing with cloud that, you know, do you have to be in one cloud for the rest of your life? No, but know that you're not going to hop from cloud to cloud. No one really does. No one says, “Every six months, I'm going to go move my application from one cloud to another.” It's a pretty big lift and no one really needs to do that. Just find the one that's most comfortable for you.Corey: I assume that you have certain preferences as far as different cloud providers go. But I've found even in corporate life that, “Well, I like this company better than the other,” is generally not the best basis for making sweeping decisions around this. What frameworks do you give various departments to consider where a given workload should live? Like, how do you advise them to think about this?Dmitry: You know, it's funny, we actually had a call with an agency recently that said, “You know, we don't know cloud. What do you guys think we should do?” And it was for a very small, I don't want to call it workload; it was really for some DNS work that they wanted to do. And really came down to, for that size and scale, right, we're looking at a few dollars, maybe a month, they picked it based on the console, right? They liked one console over another.Not going to get into which cloud they picked, but we wound up them giving them a demo of here's what this looks like in these various cloud providers. And they picked that just because they liked the buttons and the layout of one console over another. Now, having said that, for obviously larger workloads, things that are more important, there is criteria. And in many cases, it's also the vendors. Probably about 60 to 70% of the applications we run are all vendor-provided in some way, and the vendors will often dictate platforms that they'll support over others, right?So, that supportability is important to us. Just like you were saying, no one wants code rolled out overnight and surprise all the constituents one day. We take our vendor relations pretty seriously and we take our cue from them. If we're buying software from someone and they say, “Look, this is better in AWS,” or, “This is better in OCI,” for whatever reasons they have, will go in that direction more often than not.Corey: I made a crack at the beginning of the episode where the state was founded 235 years ago, as of this recording. So, how accurate is that? I have to imagine that back in those days, they didn't really have a whole lot of computers, except probably something from IBM. How much technical debt are you folks actually wrestling with?Dmitry: It's pretty heavy. One of the biggest things we have is, we ourselves, in our data center, still have a mainframe. That mainframe is used for a lot of important work. Most notably, a lot of healthcare benefits are really distributed through that system. So, you're talking about federal partnerships, you're talking about, you know, insurance companies, health care providers, all somehow having—Corey: You're talking about things that absolutely, positively cannot break.Dmitry: Yep, exactly. We can't have outages, we can't have blips, and they've got to be accurate. So, even that sort of migration, right, that's not something that we can do overnight. It's something we've been working on for well over a year, and right now we're targeting probably roughly another year or so to get that fully migrated out. And even there, we're doing what would be considered a traditional lift-and-shift. We're going to mainframe emulation, we're not going cloud-native, we're not going to do a whole bunch of refactoring out of the gate. It's just picking up what's working and running and just moving it to a new venue.Corey: Did they finally build an AWS/400 that you can run that out? I didn't realize they had a mainframe emulation offering these days.Dmitry: They do. There's actually several providers that do it. And there's other agencies in the state that have made this sort of move as well, so we're also not even looking to be innovators in that respect, right? We're not going to be first movers to try that out. We'll have another agency make that move first and now we're doing this with our Department of Human Services.But yeah, a lot of technical debt around that platform. When you look at just the cost of operating these platforms, that mainframe costs the state roughly $15 million a year. We think in the cloud, it's going to wind up costing us somewhere between 3 to 4 million. Even if it's 5 million, that's still considerable savings over what we're paying for today. So, it's worth making that move, but it's still very deliberate, very slow, with a lot of testing along the way. But yeah, you're talking about that workload has been in the state, I want to say, for over 20, 25 years.Corey: So, what's the reason to move it? Because not for nothing, but there's an old—the old saw, “Well, don't fix it if it ain't broke.” Well, what's broke about it?Dmitry: Well, there's a couple of things. First off, the real estate that it takes up as an issue. It is a large machine sitting on a floor of a data center that we've got to consolidate to. We actually have some real estate constraints and we've got to cut down our footprint by next year, contractually, right? We've agreed, we're going to move into a smaller space.The other part is the technical talent. While yes, it's not broke, things are working on it, there are fewer and fewer people that can manage it. What we've found was doing a complete refactor while doing a move anywhere, is really too risky, right? Rewriting everything with a bunch of Lambdas is kind of scary, as well as moving it into another venue. So, there are mainframe emulators out there that will run in the cloud. We've gotten one and we're making this move now. So, we're going to do that lift-and-shift in and then look to refactor it piecemeal.Corey: Specifics are always going to determine, but as a general point, I felt like I am the only voice in the room sometimes advocating in favor of lift-and-shift. Because people say, “Oh, it's terrible for reasons X, Y, and Z.” It's, “Yes, all of your options are terrible and for the common case, this is the one that I have the sneaking suspicion, based upon my lived experience, is going to be the least bad have all of those various options.” Was there a thought given to doing a refactor in flight?Dmitry: So… from the time I got here, no. But I could tell you just having worked with the state even before coming in as CTO, there were constant conversations about a refactor. And the problem is, no one actually has an appetite for it. Everyone talks about it, but then when you say, “Look, there's a risk to doing this,”—right, governments are about minimizing risk—when you say, “Look, there's a risk to rewriting and moving code at the same time and it's going to take years longer,” right, that refactoring every time, I've seen an estimate, it would be as small as three years, as large as seven or eight years, depending on who was doing the estimate. Whereas the lift-and-shift, we're hoping we can get it done in two years, but even if it's two-and-a-half, it's still less than any of the estimates we've seen for a refactor and less risky. So, we're going with that model and we'll tinker and optimize later. But we just need to get out of that mainframe so that we can have more modern technology and more modern support.Corey: It seems like the right approach. I'm sorry, I didn't mean to frame that is quite as insulting as it might have come across. Like, “Did anyone consider other options just out of curi—” of course. Whenever you're making big changes, we're going to throw a dart at a whiteboard. It's not what appears to be Twitter's current product strategy we're talking about here. This is stuff that's very much measure twice, cut once.Dmitry: Yeah. Very much so. And you see that with just about everything we do here. I know, when the state, what now, three years ago, moved their tax system over to AWS, not only did they do two or three trial runs of just the data migration, we actually wound up doing six, right? You're talking about adding two months of testing just to make sure every time we did the data move, it was done correctly and all the data got moved over. I mean, government is very, very much about measure three, four times, cut once.Corey: Which is kind of the way you'd want it. One thing that I found curious whenever I've been talking to folks in the public sector space around things that they care about—and in years past, I periodically tried to, “Oh, should we look at doing some cost consulting for folks in this market?” And by and large, there have been a couple of exceptions, but—generally, in our experience with sovereign governments, more so than municipal or state ones—but saving money is not usually one of the top three things that governments care about when it comes to their AWS's state. Is cost something that's on your radar? And how do you conceptualize around this? And I should also disclose, this is not in any way, shape, or form intended to be a sales pitch.Dmitry: Yeah, no, cost actually, for GTA. Is a concern. But I think it's more around the way we're structured. I have worked with other governments where they say, “Look, we've already gotten an allotment of money. It costs whatever it costs and we're good with it.”With the way my organization is set up, though, we're not appropriated funds, meaning we're not given any tax dollars. We actually have to provide services to the agencies and they pay us for it. And so, my salary and everyone else's here, all the work that we do, is basically paid for by agencies and they do have a choice to leave. They could go find other providers. It doesn't have to be GTA always.So, cost is a consideration. But we're also finding that we can get those cost savings pretty easily with this move to the cloud because of the number of available tools that we now have available. We have—that data center I talked about, right? That data center is obviously locked down, secured, very limited access, you can't walk in, but that also prevents agencies from doing a lot of day-to-day work that now in the cloud, they can do on their own. And so, the savings are coming just from this move of not having to have as much locks away from the agency, but having more locks from the outside world as well, right? There's definitely scaling up in the number of tools that they have available to them to work around their applications that they didn't have before.Corey: It's, on some level, a capability story, I think, when it comes to cloud. But something I have heard from a number of folks is that even more so than in enterprises, budgets tend to be much more fixed things in the context of cloud in government. Often in enterprises, what you'll see is sprawl: someone leaves something running and oops, the bill wound up going up higher than we projected for this given period of time. When we start getting into the realm of government, that stops being a you broke budgeting policy and starts to resemble things that are called crimes. How do you wind up providing governance as a government around cloud usage to avoid, you know, someone going to prison over a Managed NAT Gateway?Dmitry: Yeah. So, we do have some pretty stringent monitoring. I know, even before the show, we talked about fact that we do have a separate security group. So, on that side of it, they are keeping an eye on what are people doing in the cloud. So, even though agencies now have more access to more tooling, they can do more, right, GTA hasn't stepped back from it and so, we're able to centrally manage things.We've put in a lot of controls. In fact, we're using Control Tower. We've got a lot of guardrails put in, even basic things like you can't run things outside of the US, right? We don't want you running things in the India region or anywhere in South America. Like, that's not even allowed, so we're able to block that off.And then we've got some pretty tight financial controls where we're watching the spend on a regular basis, agency by agency. Not enforcing any of it, obviously, agencies know what they're doing and it's their apps, but we do warn them of, “Hey, we're seeing this trend or that trend.” We've been at this now for about a year-and-a-half, and so agencies are starting to see that we provide more oversight and a lot less pressure, but at the same time, there's definitely a lot more collaboration assistance with one another.Corey: It really feels like the entire procurement model is shifted massively. As opposed to going out for a bunch of bids and doing all these other things, it's consumption-based. And that has been—I know for enterprises—a difficult pill for a lot of their procurement teams to wind up wrapping their heads around. I can only imagine what that must be like for things that are enshrined in law.Dmitry: Yeah, there's definitely been a shift, although it's not as big as you would think on that side because you do have cloud but then you also have managed services around cloud, right? So, you look at AWS, OCI, Azure, no one's out there putting a credit card down to open an environment anymore, you know, a tenant or an account. It is done through procurement rules. Like, we don't actually buy AWS directly from AWS; we go through a reseller, right, so there's some controls there as well from the procurement side. So, there's still a lot of oversight.But it is scary to some of our procurement people. Like, AWS Marketplace is a very, very scary place for them, right? The fact that you can go and—you can hire people at Marketplace, you could buy things with a single button-click. So, we've gone out of our way, in my agency, to go through and lock that down to make sure that before anyone clicks one of those purchase buttons, that we at least know about it, they've made the request, and we have to go in and unlock that button for that purchase. So, we've got to put in more controls in some cases. But in other cases, it has made things easier.Corey: As you look across the landscape of effectively, what you're doing is uprooting an awful lot of technical systems that have been in place for decades at this point. And we look at cloud and I'm not saying it's not stable—far from it—but it also feels a little strange to be, effectively, making a similar timespan of commitment—because functionally a lot of us are—when we look at these platforms. Was that something that had already been a pre-existing appetite for when you started the role or is that something that you've found that you've had to socialize in the last couple years?Dmitry: It's a little bit of both. It's been lumpy, agency by agency, I'll say. There are some agencies that are raring to go, they want to make some changes, do a lot of good, so to speak, by upgrading their infrastructure. There are others that will sit and say, “Hey, I've been doing this for 20, 30 years. It's been fine.” That whole, “If it ain't broke, don't fix it,” mindset.So, for them, there's definitely been, you know, a lot more friction to get them going in that direction. But what I'm also finding is the people with their hands on the keyboards, right, the ones that are doing the work, are excited by this. This is something new for them. In addition to actually going to cloud, the other thing we've been doing is providing a lot of different training options. And so, that's something that's perked people up and definitely made them much more excited to come into work.I know, down at the, you know, the operator level, the administrators, the managers, all of those folks, are pretty pleased with the moves we're making. You do get some of the folks in upper management in the agencies that do say, “Look, this is a risk.” We're saying, “Look, it's a risk not to do this.” Right? You've also got to think about staffing and what people are willing to work on. Things like the mainframe, you know, you're not going to be able to hire those people much longer. They're going to be fewer and far between. So, you have to retool. I do tell people that, you know, if you don't like change, IT is probably not the industry to be in, even in government. You probably want to go somewhere else, then.Corey: That is sort of the next topic I want to get into, where companies across the board are finding it challenging to locate and source talent to work in their environments. How has the process of recruiting cloud talent gone for you?Dmitry: It's difficult. Not going to sugarcoat that. It's, it's—Corey: [laugh]. I'm not sure anyone would say otherwise, no matter where you are. You can pay absolutely insane, top-of-market money and still have that exact same response. No one says, “Oh, it's super easy.” Everyone finds it hard. But please continue [laugh].Dmitry: Yeah, but it's also not a problem that we can even afford to throw money at, right? So, that's not something that we'd ever do. But what I have found is that there's actually a lot of people, really, that I'll say are tech adjacent, that are interested in making that move. And so, for us, having a mentoring and training program that bring people in and get them comfortable with it is probably more important than finding the talent exactly as it is, right? If you look at our job descriptions that we put out there, we do want things like cloud certs and certain experience, but we'll drop off things like certain college requirements. Say, “Look, do you really need a college degree if you know what you're doing in the cloud or if you know what you're doing with a database and you can prove that?”So, it's re-evaluating who we're bringing in. And in some cases, can we also train someone, right, bring someone in for a lower rate, but willing to learn and then give them the experience, knowing that they may not be here for 15, 20 years and that's okay. But we've got to retool that model to say, we expect some attrition, but they walk away with some valuable skills and while they're here, they learn those skills, right? So, that's the payoff for them.Corey: I think that there's a lot of folks exploring that where there are people who have the interest and the aptitude that are looking to transition in. So, much of the discussion points around filling the talent pipeline have come from a place of, oh, we're just going to talk to all the schools and make sure that they're teaching people the right way. And well, colleges aren't really aimed at being vocational institutions most of the time. And maybe you want people who can bring an understanding of various aspects of business, of workplace dynamics, et cetera, and even the organization themselves, you can transition them in. I've always been a big fan of helping people lateral from one part of an organization to another. It's nice to see that there's actual formal processes around that for you, folks.Dmitry: Yeah, we're trying to do that and we're also working across agencies, right, where we might pull someone in from another agency that's got that aptitude and willingness, especially if it's someone that already has government experience, right, they know how to work within the system that we have here, it certainly makes things easier. It's less of a learning curve for them on that side. We think, you know, in some cases, the technical skills, we can teach you those, but just operating in this environment is just as important to understand the soft side of it.Corey: No, I hear you. One thing that I've picked up from doing this show and talking to people in the different places that you all tend to come from, has been that everyone's working with really hard problems and there's a whole universe of various constraints that everyone's wrestling with. The biggest lie in our industry across the board that I'm coming to realize is any whiteboard architecture diagram. Full stop. The real world is messy.Nothing is ever quite like it looks like in that sterile environment where you're just designing and throwing things up there. The world is built on constraints and trade-offs. I'm glad to see that you're able to bring people into your organization. I think it gives an awful lot of folks hope when they despair about seeing what some of the job prospects are for folks in the tech industry, depending on what direction they want to go in.Dmitry: Yeah. I mean, I think we've got the same challenge as everyone else does, right? It is messy. The one thing that I think is also interesting is that we also have to have transparency but to some degree—and I'll shift; I know this wasn't meant to kind of go off into the security side of things, but I think one of the things that's most interesting is trying to balance a security mindset with that transparency, right?You have private corporations, other organizations that they do whatever they do, they're not going to talk about it, you don't need to know about it. In our case, I think we've got even more of a challenge because on the one hand, we do want to lock things down, make sure they're secure and we protect not just the data, but how we do things, right, some are mechanisms and methods. But same time, we've got a responsibility to be transparent to our constituents. They've got to be able to see what we're doing, what are we spending money on? And so, to me, that's also one of the biggest challenges we have is how do we make sure we balance that out, that we can provide people and even our vendors, right, a lot of times our vendors [will 00:30:40] say, “How are you doing something? We want to know so that we can help you better in some areas.” And it's really become a real challenge for us.Corey: I really want to thank you for taking the time to speak with me about what you're doing. If people want to learn more, where's the best place for them to find you?Dmitry: I guess now it's no longer called Twitter, but really just about anywhere. Twitter, Instagram—I'm not a big Instagram user—LinkedIn, Dmitry Kagansky, there's not a whole lot of us out there; pretty easy to do a search. But also you'll see there's my contact info, I believe, on the GTA website, just gta.ga.gov.Corey: Excellent. We will, of course, put links to that in the [show notes 00:31:20]. Thank you so much for being so generous with your time. I really appreciate it.Dmitry: Thank you, Corey. I really appreciate it as well.Corey: Dmitry Kagansky, CTO for the state of Georgia. 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 telling me that I've got it all wrong and mainframes will in fact rise again.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.
AI news is bad news, an online service to catch your cheating partner, and an IoT-enabled dick cage fails to keep a grip on its own security.All this and much much more is discussed in the latest edition of the "Smashing Security" podcast by cybersecurity veterans Graham Cluley and Carole Theriault, joined this week by Mark Stockley.Plus don't miss our featured interview with Alex Lawrence, principal security architect at Sysdig.Warning: This podcast may contain nuts, adult themes, and rude language. May? Who are we kidding...Episode links:199: A few tech cock-ups, and one cock lock-up - Smashing Security.Smart male chastity lock cock-up - Pen Test Partners.“My sexual urges are so out of control I'm considering buying a chastity cage” - Dear Deidre, The Sun.Maker of ‘smart' chastity cage left users' emails, passwords, and locations exposed - TechCrunch.Dispatch pauses AI sports writing program - Axios.Would Your Partner Cheat? These ‘Testers' Will Give You an Answer - The New York Times.Loyalty Test.Nitpick: Why don't induction hobs have knobs?Longevity… simplified - book by Dr Howard J Luks.Oxford Art Society Open Exhibition 2023.Carole Theriault art website.Smashing Security merchandise (t-shirts, mugs, stickers and stuff)Sponsored by:Kolide – Kolide ensures that if your device isn't secure it can't access your cloud apps. It's Device Trust for Okta. Watch the demo today!Sysdig – Is your cloud secure? Not without runtime insights! Sysdig delivers the industry's ONLY complete, consolidated Cloud-Native Application Protection Platform (CNAPP) – powered by runtime insights – to prioritize critical risks and stay ahead of unknown threats. Learn how runtime insights reduces fatigue so developers can focus on delivering software and your security teams can focus on other demands.ClearVPN – Hide your IP address, browse without geo-restrictions, and stay private online with a 30 day free trial of its premium plan.SUPPORT THE SHOW:Tell your friends and colleagues about “Smashing Security”, and leave us a review on Apple Podcasts or
AI chatbots are under fire in Las Vegas, the secrets of hackers' passwords are put under the microscope, and Graham reveals (possibly) the greatest TV programme of all time.All this and more is discussed in the latest edition of the "Smashing Security" podcast by cybersecurity veterans Graham Cluley and Carole Theriault.Warning: This podcast may contain nuts, adult themes, and rude language.Episode links:100,000 Hackers Exposed from Top Cybercrime Forums - Hudson Rock.Prominent Threat Actor Accidentally Infects Own Computer with Info-Stealer - Hudson Rock.People coaxed AI into saying 9+10=21 and giving instructions for spying — it shows how these systems are prone to flaws and bias - Business Insider.These Women Tried to Warn Us About AI - Rolling Stone.Chatbots: Why does White House want hackers to trick AI? - BBC News.I, Claudius - BBC iPlayer.Drama Connections: I, Claudius - BBC documentary from 2005, on YouTube.'Painkiller' Review: Netflix Series Fails To Capture Opioid Crisis - Variety.”Painkiller” trailer - YouTube.Smashing Security merchandise (t-shirts, mugs, stickers and stuff)Sponsored by:Kolide – Kolide ensures that if your device isn't secure it can't access your cloud apps. It's Device Trust for Okta. Watch the demo today!Sysdig – Is your cloud secure? Not without runtime insights! Sysdig delivers the industry's ONLY complete, consolidated Cloud-Native Application Protection Platform (CNAPP) – powered by runtime insights – to prioritize critical risks and stay ahead of unknown threats. Learn how runtime insights reduces fatigue so developers can focus on delivering software and your security teams can focus on other demands.Beyond Identity - Enables companies with the ability to completely eliminate reliance on passwords and protect against password-based breaches, fraud, and ransomware attacks. Get a free demo.SUPPORT THE SHOW:Tell your friends and colleagues about “Smashing Security”, and leave us a review on Apple Podcasts or
Michael Clark from Sysdig joins with Dave to discuss their research on SCARLETEEL 2.0: Fargate, Kubernetes, and Crypto. New research from Sysdig threat researchers found that the group continues to thrive with improved tactics. Most recently, they gained access to AWS Fargate, a more sophisticated environment to breach, thanks to their upgraded attack tools. The research states "In their most recent activities, we saw a similar strategy to what was reported in the previous blog: compromise AWS accounts through exploiting vulnerable compute services, gain persistence, and attempt to make money using cryptominers." Had Sysdig not thwarted SCARLETEEL's attack, they estimated that they would have mined $4,000 per day until they were stopped. The research can be found here: SCARLETEEL 2.0: Fargate,Kubernetes, and Crypto