Las infraestructuras críticas dependen de la conectividad, pero cada conexión crea una vía potencial de ataque. A la luz de los recientes ataques, de las lecciones extraídas de mi nueva serie documental *Into the Breach: Breaking the Firewall * y de la evolución de las tecnologías de aislamiento, como los diodos de datos, debemos replantearnos cómo se diseñan nuestros sistemas más críticos y analizar por qué tanto los gobiernos como las empresas deberían partir de una pregunta sencilla: ¿Es realmente necesaria esta conexión?
1. Por qué creé «Into the Breach»
Este fin de semana hemos estrenado «Into the Breach: Breaking the Firewall », el primer episodio que he producido a través de Cyber King Productions, presentado por Kari Byron, de «MythBusters».
¿Por qué decidí producir un programa sobre ciberseguridad?
Durante años he intentado explicar en qué consiste la ciberseguridad de las infraestructuras críticas a clientes, funcionarios públicos, periodistas, socios, amigos y, a veces, incluso a mi propia familia.
Normalmente no tarda mucho en salir a colación el tema de los cortafuegos, los «air gaps», los PLC, las tecnologías de la información (TI), las tecnologías operativas (TO), la segmentación, el modelo «Zero Trust», los diodos de datos, el malware y las vulnerabilidades.
Y me doy cuenta de cuándo empiezo a perder a la gente.
En algún momento me di cuenta de que quizá el problema no era el público.
Quizá el sector de la ciberseguridad se haya vuelto muy malo a la hora de contar su propia historia.
Piensa en a qué se enfrenta este sector: atacantes que actúan en nombre de Estados, centrales eléctricas, redes de abastecimiento de agua, satélites, fábricas, inteligencia artificial, ordenadores cuánticos y ataques que pueden acarrear consecuencias físicas reales.
Sin embargo, por alguna razón, seguimos explicando todo esto con otra presentación de PowerPoint.
Quería hacer algo diferente.
Elige un tema que la gente crea entender. Diseña un experimento real en torno a él. Analízalo a fondo. Pónlo a prueba. Recurre a expertos que conozcan la tecnología. Hazlo visual. Hazlo entretenido. Y, lo más importante, cuestiona las suposiciones que el sector de la ciberseguridad lleva años repitiendo sin cuestionarlas lo suficiente.
De ahí surgió «Into the Breach». La serie combina ciberataques reales, experimentos prácticos, entrevistas a expertos y demostraciones para hacer que la ciberseguridad resulte tangible y comprensible.
Para el episodio n.º 1, quería empezar con una de las suposiciones más importantes de todas:
«Si lo pones detrás de un cortafuegos, estará protegido».
Entonces, casi coincidiendo a la perfección con el estreno del episodio, lo que estaba ocurriendo en Minnesota acaparó la actualidad informativa.
2. Cuando la ciberseguridad empieza a mover aguas
Los días 26 y 27 de julio, un ciberataque coordinado tuvo como objetivo la tecnología operativa de más de 30 sistemas comunitarios de abastecimiento de agua en Minnesota. Minnesota activó su plan de respuesta estatal en materia de ciberseguridad para investigar los ataques y prestar apoyo a las comunidades afectadas.
Dos días después, el FBI y la EPA emitieron una advertencia más amplia. Desde el 27 de julio, las empresas de suministro de agua y de tratamiento de aguas residuales de al menos siete estados habían notificado incidentes relacionados con controladores lógicos programables (PLC) conectados a Internet.
Los atacantes accedieron de forma remota a los dispositivos, modificaron las direcciones IP y las contraseñas, y provocaron que los operadores perdieran la supervisión y el control. El FBI informó de consecuencias operativas, entre ellas la pérdida de presión y las inundaciones. También detectó configuraciones de red de terceros similares en varias de las víctimas, lo que podría haber permitido a los atacantes repetir el mismo éxito.
Párate a pensarlo un momento.
Estamos hablando de ordenadores que controlan el agua.
No se trata de que alguien robe un número de tarjeta de crédito. Tampoco se trata únicamente de que un programa de ransomware cifre el portátil de un empleado.
Cuando un atacante puede interferir en una bomba, una válvula, un interruptor eléctrico, una tubería, una línea de producción u otro proceso físico, la ciberseguridad adquiere una dimensión mucho mayor.
Se convierte en un problema de seguridad pública.
Y Minnesota no es la primera señal de alarma.
3. Ya hemos visto esto antes
El Volt Typhoon es uno de los ejemplos más claros.
Las agencias de ciberseguridad de EE. UU. y de sus aliados han documentado que agentes chinos patrocinados por el Estado han conseguido establecer un acceso persistente a organizaciones de infraestructuras críticas en los sectores de las comunicaciones, la energía, el transporte, el agua y otros.
En un caso confirmado de intrusión, es probable que los atacantes obtuvieran acceso inicial aprovechando la vulnerabilidad CVE-2022-42475 en un cortafuegos perimetral FortiGate 300D sin parches.
Piensa en lo que pasó allí.
El dispositivo instalado para proteger el perímetro se convirtió en la vía de acceso a través del mismo.
Eso no es una crítica a Fortinet.
Cualquier plataforma de software sofisticada puede acabar teniendo vulnerabilidades. Los cortafuegos necesitan parches. Las VPN necesitan parches. Los sistemas operativos necesitan parches. Las credenciales pueden ser robadas. Las configuraciones pueden ser erróneas. Los administradores cometen errores. Se producen vulnerabilidades de día cero.
Esa es la realidad del software.
Ucrania puso de manifiesto las consecuencias físicas de forma aún más dramática. En diciembre de 2015, unos atacantes se hicieron con el control de tres empresas de distribución eléctrica. Pasaron de los sistemas informáticos a los sistemas operativos, accedieron al entorno de los sistemas de control industrial (ICS) a través de la infraestructura VPN, accionaron interruptores eléctricos y provocaron cortes de suministro que afectaron a unos 225 000 clientes.
Hay una gran diferencia entre que un atacante acceda a uno de tus ordenadores y que acceda al ordenador que controla tu suministro eléctrico.
Las consecuencias pueden ir más allá de la pantalla.
4. No estoy en contra de los cortafuegos
Voy a dejarlo muy claro.
Necesitamos cortafuegos.
OPSWAT Los utiliza. Nuestros clientes los utilizan. Casi todas las redes modernas dependen de ellos.
Lo que cuestiono es la idea de que un cortafuegos equivalga a aislamiento.
Para mí, un cortafuegos es como un guardia de seguridad muy inteligente que está de pie delante de una puerta. El guardia conoce miles de reglas. Comprueba las credenciales. Examina el tráfico. Decide qué puede entrar y qué puede salir.
Eso tiene un valor incalculable.
Pero aún queda una puerta.
Si alguien roba las credenciales adecuadas, encuentra una vulnerabilidad, se aprovecha de un error de configuración o compromete la propia tecnología de seguridad, la vía de acceso sigue existiendo.
Así que empecé a plantearme otra pregunta:
¿Y si, en realidad, nadie tiene que entrar por la puerta?
¿Por qué gastar tanto dinero en hacer que la puerta sea más inteligente si, para empezar, las necesidades de la empresa ni siquiera requieren una puerta?
Ahí es donde un diodo de datos marca una diferencia fundamental.
Un diodo de datos no es un cortafuegos más eficaz.
Resuelve un problema distinto.
En lugar de basarse únicamente en reglas de software para decidir qué tráfico se permite, un diodo de datos puede controlar la dirección de la comunicación a nivel de hardware.
El NIST ha demostrado precisamente este tipo de arquitectura en un diseño de referencia para empresas de suministro eléctrico. Los datos de supervisión operativa se transmiten hacia el exterior a través de una pasarela unidireccional, y la arquitectura impide que los datos vuelvan a entrar por esa misma conexión en el entorno industrial protegido.
Se trata de una propiedad de seguridad fundamentalmente diferente.
5. Sin ruta de retorno innecesaria
Creo que el principio es tan sencillo que se merece un nombre sencillo:
Sin ruta de retorno innecesaria
Es posible que una empresa de suministro de agua tenga que enviar alertas.
Es posible que una central eléctrica tenga que enviar datos de telemetría.
Es posible que una fábrica necesite exportar información del sistema de registro histórico.
Es posible que un operador de un gasoducto necesite un sistema de supervisión centralizado.
Es posible que un entorno de defensa necesite exportar registros.
Toda esa información puede salir de la red protegida.
Pero si no hay ninguna razón operativa para que la comunicación vuelva a pasar por ese mismo límite:
¿Por qué crear la ruta de retorno?
Sé que no todos los entornos pueden funcionar así. Existen razones legítimas para el mantenimiento remoto, el control remoto, las actualizaciones de software, las confirmaciones y otros procesos bidireccionales.
Si necesitas esa conexión, defiéndela con todas tus fuerzas.
Las últimas directrices del FBI para el sector del agua indican a los operadores que deben evitar que los PLC estén expuestos directamente a Internet, canalizar el acceso remoto a través de pasarelas seguras, restringir el acceso, validar los archivos de proyecto de los PLC, proteger la conectividad móvil y mantener la capacidad de operar manualmente tras un incidente.
Estoy de acuerdo con todo eso.
Pero creo que tenemos la configuración predeterminada al revés.
Hoy en día, con demasiada frecuencia empezamos por la conectividad y luego le pedimos al equipo de ciberseguridad que la proteja.
En el caso de nuestros sistemas más importantes, deberíamos empezar por el aislamiento y preguntarnos:
¿Por qué hay que abrir el camino?
6. Un solo sentido no es suficiente, y además tiene que ser limpio.
Hay un aspecto importante de este debate que a veces se pasa por alto.
Un diodo de datos resuelve el problema de la dirección.
No resuelve automáticamente el problema del contenido.
Aunque se permita que un archivo malicioso se desplace en la dirección autorizada, sigue siendo malicioso.
Si una actualización de software comprometida atraviesa el diodo, sigue estando comprometida.
Si alguien introduce un documento malicioso en un entorno aislado, el mero hecho de que esté aislado no garantiza que el documento sea seguro.
Por eso creo que la próxima generación de esta arquitectura debe ser:
Solo de ida y limpio
Utiliza el diodo para controlar la dirección.
A continuación, comprueba qué se permite pasar.
Esto implica combinar la comunicación unidireccional garantizada por el hardware con tecnologías como « Multiscanning », la depuración de datos y la tecnología Deep CDR™, el entorno aislado (sandboxing), la prevención de fugas de datos (DLP), la inspección de contenidos basada en inteligencia artificial, la validación de archivos y la aplicación de políticas.
OPSWATLa arquitectura actual de MetaDefender ya combina la tecnología Deep CDR™, Metascan™ Multiscanning, el entorno de pruebas (sandboxing) Proactive DLP y la inspección basada en IA en flujos de trabajo de archivos controlados, y nuestros productos multidominio combinan estas tecnologías de prevención con arquitecturas de transferencia segura. MetaDefender™ Core puede utilizar más de 30 motores antimalware en paralelo como parte de estos flujos de trabajo.
El objetivo no debería ser simplemente:
¿Se pueden transferir estos datos de A a B?
Las preguntas deberían ser:
¿Debería avanzar en esta dirección, para empezar?
...o mejor aún...
¿Debería permitirse este contenido en absoluto?
Esa es la diferencia entre limitarse a crear un «air gap» y establecer un proceso seguro para transferir información a través de él.
7. My Desafío a la CISA
Quiero poner a prueba a la CISA, pero también quiero reconocer su mérito.
La situación está cambiando.
Una nueva guía de 2026 sobre el aislamiento de infraestructuras críticas establece que los operadores deben ser capaces de aislar los sistemas OT vitales del resto de redes, describe el aislamiento físico como la forma más eficaz de protección y reconoce específicamente que los diodos de datos y las soluciones entre dominios ofrecen una mayor garantía que las arquitecturas estándar de pasarela de red cuando se implementan correctamente.
Es un avance importante.
My El reto al que se enfrenta la CISA es el siguiente:
No convirtamos el aislamiento en algo que solo nos preparamos para hacer durante una crisis. Hagamos que forme parte del diseño de las infraestructuras críticas desde el principio.
Antes de preguntarte cómo protegemos el acceso remoto, pregúntate si realmente es necesario ese acceso.
Si la respuesta es sí, asegúralo.
Si la respuesta es «no»:
Elimina la ruta.
8. La normativa debería plantear una pregunta más acertada
Esta reflexión trasciende las fronteras de Estados Unidos. El marco NIS2 de Europa establece ahora un marco común de ciberseguridad que abarca 18 sectores críticos, entre los que se incluyen la energía, el transporte, la sanidad, el agua potable, las aguas residuales, la infraestructura digital, la industria manufacturera, la administración pública y el sector espacial.
Los gobiernos de todo el mundo están endureciendo los requisitos en materia de evaluación de riesgos, autenticación, notificación de incidentes, aplicación de parches, supervisión, detección y recuperación.
Todo eso es importante.
Pero creo que las autoridades reguladoras deberían plantear más preguntas:
¿Por qué existe esta relación?
¿Cómo proteges la conexión?
¿Es realmente necesario que exista esa conexión?
Estas preguntas deben plantearse en todos los lugares donde operen infraestructuras críticas.
9. Estados Unidos debería liderar
Dicho todo esto, creo que Estados Unidos debería dar el primer paso.
Pido que se promulgue un decreto presidencial de EE. UU. basado en un principio muy sencillo:
Sin ruta de retorno innecesaria.
En el caso de nuestras infraestructuras más críticas, todo se reduce a cinco conceptos:
- Ningún controlador crítico debe estar expuesto directamente a Internet.
- Si los datos solo tienen que salir, establece una conexión unidireccional y asegúrate de que los datos estén limpios. Utiliza una comunicación unidireccional controlada por hardware, junto con medidas de seguridad de contenidos, análisis múltiple, depuración de datos y la tecnología Deep CDR™, para que la información que cruza el perímetro sea inspeccionada y depurada.
- El control remoto debería ser una excepción. Si realmente es necesario, hay que protegerlo, restringirlo, supervisarlo, auditarlo y asegurarse de que los operadores puedan recuperarse de forma segura.
- Ayudar a las empresas de servicios públicos más pequeñas a modernizarse. No se debe esperar que una pequeña red de abastecimiento de agua pueda defenderse por sí sola frente a ciberdelincuentes sofisticados con los recursos de una empresa de servicios públicos nacional.
- Estableced los requisitos de seguridad, no el proveedor. Los gobiernos deberían definir el resultado y dejar que el sector compita para ofrecer la mejor solución.
El principio es sencillo:
Si no es necesario que el tráfico vuelva, elimina la ruta de retorno. Y todo lo que cruce el límite debe estar limpio.
Estados Unidos puede marcar el camino, pero animaría a los gobiernos de todo el mundo a que adoptaran el mismo principio.
10. La física cuántica nos está enseñando la misma lección
Hay otra razón por la que creo que deberíamos actuar antes de que se produzca la próxima crisis.
El 22 de junio de 2026, la Casa Blanca promulgó el Decreto Ejecutivo n.º 14412, titulado «Protección de la nación frente a ataques criptográficos avanzados». En él se reconoce la amenaza futura que suponen los ordenadores cuánticos a gran escala para la criptografía de uso generalizado, se acelera la transición federal hacia la criptografía poscuántica aprobada por el NIST y se ordena a los organismos que ayuden a los propietarios de infraestructuras críticas a prepararse para su propia migración.
Me gusta esta lógica.
Actúa antes de que se produzca la crisis.
Eso es prevención.
Creo que esa misma filosofía debería aplicarse a la arquitectura de las infraestructuras críticas.
Además, existe una conexión interesante entre los diodos de datos y la era cuántica.
Para que quede claro, un diodo de datos no hace que la criptografía actual sea resistente a la computación cuántica. La criptografía poscuántica resuelve ese problema matemático.
Pero las claves de cifrado siguen estando almacenadas en algún sitio.
Se generan en algún sitio. Se almacenan en algún sitio. Se utilizan en algún sitio.
Los HSM, los sistemas de gestión de claves, la infraestructura de computación cuántica y las futuras redes cuánticas seguirán requiriendo hardware, software, operadores y conexiones de red.
Seguirán teniendo superficies de ataque.
Imagina un entorno criptográfico de alta sensibilidad que necesita enviar al exterior datos de telemetría, información de auditoría, incidentes de seguridad o resultados computacionales validados, pero en el que no hay motivo para que una red empresarial convencional inicie una comunicación de vuelta hacia los sistemas que protegen esas claves.
Creo que esta es una aplicación futura importante para el aislamiento garantizado por hardware. Se trata de una inferencia arquitectónica, no de un sustituto de la criptografía poscuántica. Las arquitecturas unidireccionales del NIST muestran cómo las rutas unidireccionales pueden reducir la accesibilidad de la red, mientras que la nueva política federal sobre cuántica pone de manifiesto la importancia que está adquiriendo la protección de los futuros sistemas criptográficos.
My La idea es sencilla:
La criptografía poscuántica protege los fundamentos matemáticos.
Hardware-El aislamiento forzado puede proteger la ruta hacia las máquinas al proteger los cálculos matemáticos.
En el caso de nuestros entornos más sensibles, creo que necesitaremos ambas cosas.
11. Hemos apostado por esta convicción
Debería dejar claro lo que es obvio.
OPSWAT vende diodos de datos.
Pero no descubrimos esta arquitectura de repente porque Minnesota sufriera un ataque el mes pasado, ni entramos en el mercado porque yo decidiera producir un programa sobre ciberseguridad.
Hicimos esta apuesta hace años.
Durante años, OPSWAT ha integrado nuestras tecnologías con las de proveedores de diodos en entornos sensibles de la administración pública, la defensa, la energía y la industria. Cuanto más tiempo pasaba con estos clientes, más convencido estaba de que, si nuestra misión era realmente proteger las infraestructuras críticas del mundo, necesitábamos contar con una mayor parte de esta tecnología en nuestras propias manos.
Hicimos algo que no era lo más lógico para una empresa conocida tradicionalmente por su software.
Hemos comprado dos empresas de ferretería.
En 2021, OPSWAT adquirió los activos de Bayshore Networks, lo que permitió a la empresa incorporar capacidades en materia de seguridad industrial, OT, ICS y transferencia segura de datos.
En 2024, adquirimos Fend, lo que nos permitió ampliar nuestras capacidades en materia de diodos de datos y nos proporcionó otra arquitectura especialmente adecuada para infraestructuras distribuidas y remotas, como las empresas de suministro de agua.
Y la adquisición de esas empresas no fue más que el principio.
Hemos triplicado los recursos de I+D destinados a este ámbito.
También tomamos otra decisión.
Si vamos a fabricar hardware del que dependen los gobiernos y los operadores de infraestructuras críticas, quiero saber de dónde procede ese hardware, quién lo ha montado, qué componentes se han utilizado, cómo se ha probado y cómo controlamos su calidad.
Así pues, hemos acercado mucho más la producción a nosotros.
En noviembre de 2025, OPSWAT inauguró una planta de producción en Tampa (Florida), lo que nos permitió internalizar la fabricación de hardware y aumentar nuestro control sobre la calidad, el cumplimiento normativo, el desarrollo de productos y la integridad de la cadena de suministro.
Y Tampa no es el final de esta estrategia.
Estamos desarrollando nuevas capacidades regionales y centros de operaciones en Europa y Asia, ya que a los gobiernos les preocupa cada vez más no solo lo que hace la tecnología de ciberseguridad, sino también dónde se fabrica y quién controla la cadena de suministro.
Esto no es un proyecto secundario.
Se trata de una apuesta a largo plazo sobre la dirección que, en nuestra opinión, debe tomar la seguridad de las infraestructuras críticas.
12. «La prevención es lo primero»
Todo esto nos lleva de nuevo al argumento que expuse en mi libro, «Cybersecurity Upside Down».
Nuestro sector se ha vuelto increíblemente eficaz a la hora de detectar problemas, una vez que ya hemos permitido que esos problemas lleguen al medio ambiente.
Necesitamos, sin lugar a dudas, sistemas de detección. Necesitamos centros de operaciones de seguridad (SOC), inteligencia sobre amenazas, supervisión y respuesta ante incidentes.
Pero la prevención debe ser lo primero.
Si puedes eliminar el contenido malicioso antes de que se ejecute, hazlo.
Si puedes eliminar un privilegio innecesario, elimínalo.
Si puedes aislar el entorno crítico, hazlo.
Y si un sistema crítico no necesita una ruta de red de entrada:
Elimina la ruta.
Esa es la ciberseguridad basada en la prevención ante todo.
13. Por qué creé CyberKing Productions
Y esto me lleva de vuelta al punto de partida de esta historia.
«Into the Breach » no es simplemente otro vídeo promocional de « OPSWAT ».
Creé Cyber King Productions porque creo que la ciberseguridad necesita una forma totalmente diferente de comunicarse con el mundo.
No quiero hacer anuncios publicitarios para empresas.
Quiero contar historias sobre ciberseguridad que la gente realmente quiera ver.
Elige algo que todo el mundo crea entender. Descubre la suposición que hay detrás. Diseña un experimento en torno a ello. Pruébalo. Ponlo a prueba. Quizá lo desmontes. Quizá hagas estallar algo. Después, invita a expertos y explícales lo que ha ocurrido realmente.
Eso es lo que intentamos hacer con el primer episodio de *Into the Breach*, «Breaking the Firewall ».
Antes del estreno oficial, el episodio ya se había empezado a emitir en United Airlines. Luego, en Black Hat, ocurrió algo que me hizo especial ilusión: la gente se acercaba al stand de OPSWAT después de haber visto el episodio durante el vuelo, y algunos querían hablar con nosotros sobre los diodos de datos.
Piénsalo.
Alguien vio un programa sobre ciberseguridad en un avión, llegó a Black Hat, se acercó a nuestro stand y quería saber cómo proteger mejor una red crítica.
Eso es exactamente lo que esperaba que pudiera hacer Cyber King.
14. Las personas que hay detrás de Cyber King
Tener una idea es fácil. Llevarla a cabo, no tanto.
Soy el creador y productor ejecutivo, pero tuve la suerte de contar con un equipo increíble para el primer episodio:
- Kari Byron fue presentadora y productora ejecutiva
- Berry Blanton fue director y productor
- Jason Richard fue productor y editor
- Linda Wolkovitch fue la productora
- Erik Weinbrecht fue guionista
- Joanna Shemesh fue productora asociada
- Scott Sorensen fue director de fotografía
- Shannon Wilkerson se encargó del diseño 3D y del diseño de movimiento
- Christopher Gore Gammon fue redactor adjunto
- El equipo de producción también contó con Jesús «Chuy» Valadez, Mahlik Hailu, Jan Reichle, Christina Robles, Jesús Ocejo y Román Molla.
...y, por supuesto, Maxx, el perro robot, interpretó su propio papel.
Quiero dar las gracias de forma muy especial a Kari, Berry, Jason, Erik y a todos los que han contribuido a que esta idea se haya hecho realidad.
15. Esto es solo el principio
El episodio n.º 1 trataba sobre los cortafuegos.
Pero no nos vamos a quedar ahí.
El episodio n.º 2 está en fase de producción en estos momentos, y ya tengo guiones e ideas para muchos más episodios.
No faltan supuestos sobre ciberseguridad que merezcan ser cuestionados. Aislamientos físicos, soportes extraíbles, inteligencia artificial, ransomware, cadenas de suministro, seguridad en la nube, depuración de datos, modelo «Zero Trust», infraestructuras críticas, computación cuántica y muchos más.
Pero tampoco quiero que «Cyber King» se centre únicamente en « OPSWAT ».
Quiero que participen otras personas del sector.
Si eres socio tecnológico o socio de canal actual de OPSWAT y tienes una tecnología, un caso de éxito de un cliente, una hipótesis sobre ciberseguridad o un experimento que crees que merece ser grabado en vídeo, ponte en contacto conmigo directamente.
Quizá probemos algo juntos. Quizá nos lancemos a por ello. Quizá demostremos que funciona. Quizá descubramos que la idea generalizada es errónea.
¿Al final? Quizás hagamos un episodio juntos.
Envíame un mensaje privado por LinkedIn o Facebook.
Lo digo en serio.
En el ámbito de la ciberseguridad ya hay suficientes seminarios web y presentaciones de PowerPoint.
Quiero conseguir que la ciberseguridad sea algo que la gente realmente quiera ver.
Mira «Into the Breach: Breaking the Firewall ». Compártelo. Desafía a la CISA. Desafía a los reguladores. Desafía a OPSWAT. Desafíame a mí.
Pero lo más importante es que vuelvas a la arquitectura que protege tus propios sistemas críticos y te hagas una pregunta muy sencilla:
¿De verdad es necesario que vuelva el tráfico?
Si la respuesta es «sí», protege esa conexión como si el funcionamiento de tu empresa dependiera de ello.
¿Y si la respuesta es «no»?
Elimina la ruta.
Y asegúrate de que todo lo que dejes pasar esté limpio.
Mira «Into the Breach: Breaking the Firewall », episodio n.º 1:
El episodio n.º 2 se está grabando en estos momentos. Si eres socio actual de « OPSWAT » y crees que deberíamos grabar un episodio juntos, envíame un mensaje.
