Cybersecurity Under Pressure. Real Attacks, Real Lessons

Antonio González
  • 0.0 (0)
  • Technology
  • Updated Weekly

This podcast breaks down real cybersecurity incidents to understand what actually went wrong, not in theory, but in practice. Each episode analyzes a recent attack, explains the technical mechanics in clear language, and translates them into concrete lessons for security, engineering, and business teams. Topics covered: OT security, ICS cybersecurity, industrial control systems, critical infrastructure protection, NIS2 compliance, Zero Trust architecture, operational technology resilience, railway cybersecurity, automotive security, and cyber-physical systems.

  1. 3h ago

    Authenticated but Wrong: When Railway APIs Contradict Physical Reality

    A railway API can be correctly authenticated, protected by strong cryptography and accepted by every security control in the chain — while still delivering operationally wrong data. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a critical limitation of digital trust in interconnected railway environments: authentication can prove where data came from, but it cannot prove that the data still reflects physical reality. The Technical Breakdown explores the security assumptions behind trusted interfaces and industrial data exchange. Certificates, identities and secure communication channels can confirm that a recognised system sent a message. They do not automatically establish that the information is current, physically plausible or safe to use in an operational decision. That distinction matters in railway systems, where data may cross multiple platforms, suppliers and organisational boundaries before reaching the people and systems expected to act on it. The problem becomes urgent when authenticated information conflicts with what operators, sensors or the physical infrastructure appear to be showing. At that point, the issue is no longer an abstract architectural debate. It becomes a real-time crisis involving operations, engineering, cybersecurity, legal, compliance and business leadership. In The Pressure Test, it is 3:00 a.m. on a Friday and you are responsible for a major central railway node. The data has passed its security checks, but something does not align with operational reality. You must decide what can still be trusted, how much evidence is enough and whether acting on authenticated but questionable information creates more risk than rejecting it. The key lesson is that cryptographic authentication proves identity, not operational truth. Railway resilience therefore requires more than securing APIs and communication channels. It requires mechanisms that validate data against context, system state and physical behaviour before that data is allowed to drive critical decisions. Because trusted data is not defined only by who sent it. It is defined by whether it is still true. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders. Explore all episodes and resources: https://cybersecurityunderpressure.com/episodes

  2. 2d ago

    Trusted Software, Wrong Weld: Why OT Integrity Is Not Process Integrity

    A welding robot can execute trusted software, accept authorized commands and still produce the wrong physical result. That distinction sits at the heart of this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons. We examine a fundamental problem in industrial cybersecurity: the difference between proving that software and commands are legitimate and proving that the physical process is still doing what engineering intended. The Technical Breakdown separates logical intent from authorized operation. A valid command can be authenticated. Software can remain trusted. Access controls can work as designed. And yet the resulting action can still be wrong for the process. That changes the security question. Instead of asking only, “Was this command authorized?”, industrial defenders also need to ask whether the resulting physical behaviour remains within the expected engineering envelope. The challenge becomes even harder in brownfield environments, where legacy controllers, operational constraints and existing industrial architectures limit how easily new security controls can be introduced. In The Pressure Test, you take the role of engineering and security leadership at a Tier-1 automotive supplier producing structural chassis components. The problem is no longer theoretical: you have to decide how much assurance is enough when production, legacy technology and the physical consequences of a wrong decision all matter. The episode concludes with a practical principle: selective assurance. Not every signal requires the same level of validation, but the parameters and actions capable of changing the physical process deserve stronger scrutiny than simple software trust can provide. Because in OT, trusted software does not automatically mean a trusted outcome. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders. Explore all episodes and resources: https://cybersecurityunderpressure.com/episodes

  3. 4d ago

    Bendix EC80 Brake Recall: When Safety Urgency Meets Cybersecurity Controls

    A brake recall is first and foremost a physical safety issue. But what happens when the pressure to act quickly collides with the security controls protecting a critical vehicle system? In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we use the Bendix EC80 brake recall to examine a difficult product cybersecurity problem: how to preserve cyber resilience when safety-critical engineering decisions have to move fast. The Technical Breakdown starts with the asset itself, examining the hardware and the trust boundary around a critical braking system. From there, the discussion moves beyond architecture and into the environments where remediation actually has to work. The factory floor. The service bay. The engineering sprint cycle. These are the places where cybersecurity requirements meet operational reality, and where a control that looks straightforward on paper can become much harder to enforce under safety, production and time pressure. In The Pressure Test, the evidence is incomplete but the clock is already running. Production schedules, physical highway safety, product availability and regulatory obligations all compete for attention. The challenge is not simply deciding whether security or safety comes first, but determining how to protect both when delaying action also carries risk. The key lesson is that safety and cybersecurity cannot be engineered as separate lifecycle problems. Safety-critical remediation needs security mechanisms and operational processes designed to remain effective even when the organisation is under pressure to act quickly. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders. Explore all episodes and resources: https://cybersecurityunderpressure.com/episodes

  4. Aug 14

    Railway AI at Risk: When Subcontractor Leaks Break the Trust Chain

    Your railway systems may be secure. Your AI environment may be protected. But what happens when sensitive information escapes through a subcontractor? In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine a growing challenge for railway cybersecurity: protecting sensitive AI and engineering assets across a supply chain that extends far beyond the organisation itself. We trace how information can move through subcontractors and suppliers, how seemingly isolated leaks can expose a much wider technical and operational picture, and why securing the primary organisation is no longer enough when critical knowledge is distributed across the engineering ecosystem. The discussion then moves from technical exposure to the harder questions. What are the business and regulatory consequences when sensitive railway information crosses the expected trust boundary? How should organisations manage subcontractors that are essential to engineering and innovation while also expanding the attack and exposure surface? In The Pressure Test, you step into the role of the CISO or incident commander and face the decisions that follow a serious third-party exposure: contain the incident, determine what has actually been compromised, preserve operations and decide what can still be trusted. The key lesson is clear: AI security cannot stop at your organisational boundary. In complex railway ecosystems, trust has to be engineered, governed and continuously verified across the entire supply chain. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders. Explore all episodes and resources: https://cybersecurityunderpressure.com/episodes

  5. Aug 12

    Why Signed Firmware Is Still Vulnerable: The Trust Chain Behind the Signature

    A valid digital signature tells you that firmware was signed by a trusted key. It does not necessarily tell you that everything behind that signature can still be trusted. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine one of the most dangerous assumptions in product cybersecurity: that signed firmware automatically means secure firmware. We trace the problem back through the engineering and software supply chain, exploring how a securely designed product can still inherit compromise from the systems, processes and trust relationships used to build and release its software. The discussion then moves from architecture to operational reality. What happens when strong security controls collide with availability, lifecycle constraints and incident response? How should organisations decide whether firmware can still be trusted when the cryptography works but the surrounding chain of trust is in question? The Pressure Test puts those decisions into a realistic incident scenario, where technical certainty is limited and the consequences of the wrong call are significant. The key lesson is simple: code signing is an essential control, but it is not the end of firmware security. Trust has to extend across the entire lifecycle behind the signature. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and practical lessons for cybersecurity leaders.

  6. Aug 10

    Minnesota Water Cyberattacks: When OT Security Meets Physical Risk

    What happens when a cyberattack moves beyond IT systems and begins to threaten the physical processes communities depend on? In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine the cyberattacks targeting water systems in Minnesota and the deeper OT security lessons behind them. We break down how attackers can exploit weaknesses around industrial environments, use detailed engineering knowledge against defenders, and turn access to PLCs and operational systems into a potential physical consequence. But the technical compromise is only part of the problem. The harder question is what operators do next. How do you contain an incident without disrupting essential services? When does isolation create more operational risk than it removes? And how should an incident commander respond when the evidence is incomplete but the consequences of waiting could be significant? The episode closes with a practical lesson for security, risk and business leaders: protecting critical infrastructure requires more than defending the network perimeter. It requires understanding the physical process, the engineering ecosystem and the decisions that must still work when the organisation is under pressure. Thanks for listening to Cybersecurity Under Pressure. Follow the show for more real attacks, technical breakdowns and lessons for cybersecurity leaders.

  7. Aug 7

    Aftermarket Car Alarms: The Answer Is Not to Make Vehicles Impossible to Modify

    A dealer-installed anti-theft device should make a vehicle safer. But what happens when that device introduces a new wireless path into the vehicle itself? Researchers identified serious Bluetooth weaknesses in KARR and SWDS aftermarket alarm systems installed in approximately 2.2 million vehicles. From close range, an attacker could potentially unlock doors, control the alarm and activate the immobiliser, preventing the vehicle’s next engine start. That distinction matters. The research does not demonstrate that an attacker can stop a moving vehicle, take control of its steering or manipulate its brakes. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine how a dealer-installed device can cross the trust boundary between the retail supply chain and the vehicle’s internal architecture. We separate the confirmed findings from claims about AI-assisted malware and adaptive exploitation. There is no public evidence that Dolphin X, autonomous malware or a coordinated campaign has targeted these vehicles. The episode then places the listener inside a hypothetical fleet-response scenario. Vehicle inventories are incomplete, service capacity is limited and thousands of cars cannot be remediated at once. The decision must therefore be immediate, traceable and based on risk. The conclusion is not to make vehicles impossible to modify. Openness and cybersecurity can coexist, but any third-party device with privileged access to vehicle functions requires explicit trust boundaries, secure integration and lifecycle governance. Thank you for listening. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.

  8. Aug 5

    Why Patching Windchill Is Not Enough: Restoring Trust in the Digital Thread

    A critical vulnerability in PTC Windchill and FlexPLM exposed more than an enterprise server. It placed the integrity of the digital thread at risk. Patching the vulnerability closes the original entry point. It does not prove that engineering files, source code, approval workflows, test evidence or supplier copies remained untouched while the system was exposed. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine why a compromised Product Lifecycle Management platform must be treated as a potential product-integrity incident, not merely an IT security event. We trace critical engineering data from the controlled PLM environment through Tier 1 contractors, lower-tier suppliers, exported STEP files, unmanaged endpoints and factory systems. At each boundary, visibility declines while the risk of theft, manipulation and loss of traceability increases. The episode then places the listener inside a high-pressure automotive scenario. A safety-critical ECU release passed through a compromised Windchill workflow, forensic logs are incomplete, a supplier controls part of the build process and production must continue within days. The response cannot be limited to patching and IOC hunting. It requires evidence preservation, targeted containment, independent signatures, focused artifact reconciliation, supplier assurance and predefined escalation criteria. The central lesson is clear: organisations do not need to revalidate every engineering asset with the same intensity. They must identify their crown jewels, apply rigorous verification to safety-critical artifacts and govern operational exceptions throughout the supply chain. A patch restores the platform. Evidence restores trust in the product. Thank you for listening to Cybersecurity Under Pressure: Real Attacks, Real Lessons. Follow the show for more real incidents, difficult decisions and practical cybersecurity lessons.

See All (86)

About

This podcast breaks down real cybersecurity incidents to understand what actually went wrong, not in theory, but in practice. Each episode analyzes a recent attack, explains the technical mechanics in clear language, and translates them into concrete lessons for security, engineering, and business teams. Topics covered: OT security, ICS cybersecurity, industrial control systems, critical infrastructure protection, NIS2 compliance, Zero Trust architecture, operational technology resilience, railway cybersecurity, automotive security, and cyber-physical systems.

Information