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. 7h ago ·  Bonus

    When EV Charging Becomes a Cyber-Kinetic Risk | CUP Micro Brief

    An EV charging cable initiates a cloud-connected transaction with physical consequences. This CUP Micro Brief follows the path from complex connectivity, through unsafe input validation, to cyber-kinetic manipulation of electrical limits. Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/How-EV-Chargers-Could-Crash-the-Grid-The-Cyber-Risk-Behind-Mass-Electrification-e3lkh8c

  2. 15h ago ·  Bonus

    A Clean Backup Does Not Prove a Safe Restart | CUP Focus

    Restoring files is not the same as restoring operational confidence. This CUP Focus explains why an OT restart requires trusted control logic, known-good engineering baselines and a defensible go/no-go decision before physical production resumes. Format: CUP Focus, a self-contained section from the Cybersecurity Under Pressure archive. Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/The-Restart-Bottleneck-Is-Not-the-Backup--It-Is-the-Evidence-e3knunc

  3. 1d ago

    Detecting the Attack Is Not Proving Safety: IAM4RAIL and Railway Cybersecurity

    n a railway system, detecting malicious activity and understanding its safety consequence are two different engineering problems. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we use work developed within Europe’s Rail FP3-IAM4RAIL as a case study in one of the most important distinctions in railway cybersecurity: cybersecurity monitoring can tell us that something suspicious is happening, but it does not automatically tell us what authority the attacker has gained, which operational functions are affected or whether train safety has actually been compromised. IAM4RAIL includes an onboard cybersecurity monitoring and threat-detection capability for rolling stock. A secure edge device integrated into onboard networks continuously observes communications, telemetry and operational behaviour and can generate alerts when it identifies anomalous or suspicious activity. This provides a valuable new layer of visibility in railway environments that historically have had limited technical cybersecurity monitoring. The Technical Breakdown examines what must happen after an alert. A cyber event has to be mapped through the real architecture: from the initial entry point to the affected component, across network and system boundaries, toward the functions that carry operational authority. Detecting anomalous traffic near a critical railway subsystem is important evidence, but proximity is not the same as control. The engineering question is which boundaries the attacker can actually cross and what the compromised component is technically capable of influencing. The Operational Decisions become harder in legacy railway environments. Systems may have long service lives, strict availability requirements and safety constraints that limit how aggressively cybersecurity teams can patch, isolate or reconfigure equipment. Monitoring, segmentation and compensating controls therefore have to reduce cyber risk without creating new operational or safety hazards. Cybersecurity cannot be applied in isolation from the engineering context in which the railway must continue to operate. In The Pressure Test, you are responsible for a fleet containing legacy cyber-physical systems. Monitoring detects suspicious activity inside the onboard environment, but the evidence does not yet establish whether the attacker can reach train-control functions. Isolating everything immediately may affect availability or operational procedures. Doing nothing leaves an unresolved attack path. The decision has to be based on architecture, authority, containment and evidence — not simply on the presence of an alert. The key lesson is that detection, cybersecurity impact and safety consequence are related, but they are not interchangeable. Effective railway cybersecurity requires visibility into the attack, understanding of the affected architecture and evidence connecting cyber compromise to the physical functions that matter. An alert tells us that something may be wrong. The architecture tells us what the attacker can reach. The safety analysis tells us what that actually means for the railway. 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. 2d ago ·  Bonus

    What Actually Starts the CRA 24-Hour Clock? | CUP Micro Brief

    Not every vulnerability starts the Cyber Resilience Act reporting clock. This CUP Micro Brief explains the two triggers, why reachability and VEX matter, and how CRA product obligations differ from NIS2 operator duties. Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/The-24-Hour-Trap-Defensible-Decisions-Under-the-Cyber-Resilience-Act-e3lumm0

  5. 3d ago

    Secure Boot Is Not a Checkbox: Espressif AR2026-006 and the Limits of Firmware Trust

    Secure Boot is often represented as a simple security property: enabled or disabled. But a configuration flag does not tell us whether the complete chain used to establish trust at boot actually behaves as intended. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine Espressif security advisory AR2026-006, affecting ECDSA-based Secure Boot on specific revisions of the ESP32-H2, ESP32-C5, ESP32-C61, ESP32-P4 and ESP32-S31. The issue sits inside ROM-based ECDSA signature verification, where invalid signatures can under certain conditions be accepted as valid. The Technical Breakdown looks at what that actually means. The affected verification workflow does not sufficiently validate whether the ECDSA signature components fall within their required range. ESP32-C5 also contains an initialization issue affecting the ECDSA peripheral during the ROM verification process. If an attacker can replace the signed firmware image and manipulate its signature in external flash, the device can accept attacker-controlled firmware during boot. But the vulnerability does not eliminate the attack preconditions. Exploitation requires a path to modify external flash. That can mean supply-chain access or physical access combined with flash-write capability. Packaging, Secure UART configuration, disabled download paths and Flash Encryption can therefore materially change attack feasibility even though they do not repair the underlying ROM defect. The Operational Decisions become especially difficult because this is not simply a software patching problem. The affected behaviour exists in immutable ROM on currently affected devices. Product teams therefore need to know the exact SoC and hardware revision deployed, which Secure Boot scheme is configured, how flash is protected, which programming and service interfaces remain available, and which additional security controls surround the boot process. For new production, Espressif recommends RSA-based Secure Boot where supported. Migration of already-deployed devices depends on their existing eFuse configuration and available Secure Boot digest blocks. Another important distinction is scope. The advisory states that application-layer ECDSA verification is not affected, and the ECDSA verification path used for OTA updates is therefore separate from the vulnerable ROM-based boot verification. That distinction matters because “ECDSA is vulnerable” would be a much broader claim than the evidence supports. In The Pressure Test, imagine managing a global population of connected devices built across different hardware revisions and configurations. A Secure Boot vulnerability is disclosed, but there is no universal software fix for the affected ROM. Some devices have Flash Encryption and tightly controlled programming interfaces. Others may have different manufacturing or service paths. The decision is no longer simply whether Secure Boot is enabled. It is which deployed configurations actually expose a viable attack chain and what evidence proves that the remaining barriers still hold. The key lesson is that a security feature is not an assurance argument. Secure Boot depends on the verification implementation, key and eFuse configuration, flash integrity, programming interfaces, hardware revision and the lifecycle processes surrounding the device. “Secure Boot enabled” is configuration data. Knowing whether the complete boot chain can still be trusted is security evidence. 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

  6. 4d ago ·  Bonus

    When a License Plate Becomes a Password | CUP Micro Brief

    A public vehicle identifier became the starting point for a remote attack chain. This CUP Micro Brief connects the Kia API flaw, the disappearance of the traditional vehicle perimeter and the need for blind exploit validation. Listen to the full episode: https://podcasters.spotify.com/pod/show/toni-gonzalez-burgueo/episodes/Your-License-Plate-Is-the-Password-What-the-Kia-API-Hack-Revealed-e3lumpt

  7. 6d ago

    A Supplier List Is Not a Trust Chain: NIST IR 8536 and Verifiable Supply-Chain Traceability

    Knowing who your suppliers are is useful. Collecting SBOMs is useful. Neither, by itself, proves where a component came from, what happened to it during its lifecycle or whether the evidence describing it can still be trusted. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine NIST IR 8536, Supply Chain Traceability: Manufacturing Meta-Framework, and the problem it is trying to solve: how organizations can build verifiable provenance across increasingly complex, multi-tier supply chains without forcing every participant into the same internal system. The Technical Breakdown explores the difference between having supply-chain data and having an actual traceability chain. A supplier register, an SBOM, a certificate or a component record may each contain valuable information, but isolated artifacts do not automatically establish provenance. Traceability requires those records to be connected into a temporally ordered history in which products, components, events and transformations can be related to one another and independently verified. NIST IR 8536 approaches this through interoperable structures, linked traceability events and cryptographically verifiable relationships. The objective is not to create one enormous centralized database containing every supplier’s proprietary information. The framework supports selective disclosure, allowing organizations to provide the evidence necessary to establish provenance and integrity while protecting sensitive manufacturing and commercial data. The Operational Decisions examine what this means for organizations already collecting SBOMs, supplier declarations, certificates, manufacturing records and cybersecurity evidence. The challenge is no longer simply obtaining more documents. Teams need to determine which artifacts belong to which product configuration, which supplier or sub-tier produced them, when they were valid, what changed afterwards and whether the relationships between those records can still be demonstrated. In The Pressure Test, a critical component has passed through several suppliers, software and hardware revisions and manufacturing stages before reaching the final product. A security issue appears months later. You have supplier records, SBOMs and individual pieces of assurance evidence, but no reliable way to reconstruct the complete provenance chain. The question becomes whether you can identify the affected population, determine which evidence remains valid and prove which products actually contain the affected component or configuration. The key lesson is that supply-chain assurance depends on relationships, not inventories. A list tells you who participated. An SBOM tells you what components were declared. Traceability connects those facts to provenance, chronology, configuration and evidence throughout the lifecycle. Because a folder full of evidence is not yet a trust chain. The value appears when you can prove how the evidence connects. 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

  8. Sep 23

    Local Does Not Mean Low Impact: CVE-2026-24083 and Automotive Attack Feasibility

    A vulnerability with a local attack vector can have serious consequences. But “local” does not automatically mean remote vehicle compromise, and it certainly does not prove that an attacker can reach safety-relevant vehicle functions. In this episode of Cybersecurity Under Pressure: Real Attacks, Real Lessons, we examine CVE-2026-24083, a memory-corruption vulnerability affecting Qualcomm Snapdragon Auto platforms including QAM8295P, QCA6696 and SA8295P. The vulnerability occurs while processing IOCTL device-driver requests with invalid arguments and carries a CVSS 3.1 score of 7.8, with a local attack vector, low privileges required and no user interaction. The Technical Breakdown focuses on what “local” actually tells us. It describes where exploitation begins, not how the attacker reached that position. The initial foothold could result from physical access, a compromised application, another vulnerability, a maintenance interface or an already-established execution context. Those paths have very different levels of attack feasibility and should not be collapsed into a single vulnerability score. The next question is privilege propagation. Successful exploitation of the vulnerable component does not automatically imply control of the vehicle. The relevant engineering question is what authority that component provides and which security boundaries remain between it and vehicle-relevant assets. Can an attacker reach a more privileged service? Escape an application or virtualization boundary? Cross a hypervisor? Reach a gateway? Move toward Ethernet or CAN? Or influence an asset whose compromise could affect vehicle behaviour? The Operational Decisions translate that reasoning into automotive vulnerability management. Identifying “Snapdragon Auto” in a vehicle is not enough. The vulnerable SoC has to be mapped to the actual BSP or firmware baseline, ECU implementation, vehicle architecture and deployed population. The vulnerability then becomes an input to the ISO/SAE 21434 TARA, where each step in the attack path must be supported by explicit preconditions, controls and evidence. In The Pressure Test, the security team must decide what to do when a high-severity local vulnerability exists inside a complex vehicle architecture but the complete path to a vehicle-relevant consequence has not been demonstrated. Treating the CVSS score as proof of vehicle compromise exaggerates the evidence. Treating “local” as automatically low risk can underestimate it. The defensible decision depends on the actual attack chain and the containment mechanisms implemented in the deployed system. The key lesson is that vulnerability management cannot stop at the CVE entry. Automotive cybersecurity has to connect the initial foothold, privilege transition, architectural boundaries and vehicle consequences into one evidence-based attack path. Because “local” tells us where exploitation starts. The vehicle architecture determines how far the attacker can go. 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

See All (107)

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