En la entrega anterior (https://shorturl.at/jFoRP) referimos el caso de la organización estadounidense privada “Colonial Pipeline”, quien fue víctima de un severo ataque de “Ransonmare como Servicio (RaaS)” en el año 2021. Un incidente que costó un rescate aproximado de US$4.4 millones, además de pérdidas por más de una semana de operaciones, impactadas perjudicialmente, lo que incluyó 6 días únicamente para restaurar la automatización total del oleoducto, apagado en forma preventiva. El 19 de Mayo de ese mismo año, el Director Ejecutivo (CEO) de esa empresa estadounidense, declaró que reconocía lo controversial de haber pagado el rescate pero que ello se había hecho, por ser lo más beneficioso para el país. Más tarde el FBI declaró haber recuperado 3.2 millones de dólares del pago pero los delincuentes, no fueron atrapados y se quedaron con más de un millón de dólares.
Ahora bien, fuera de los señalamientos técnicos que reflejan que el personal de ciberseguridad pudo haber hecho más para prevenir el ataque, dado que se sostuvieron en la defensa preventiva de un perímetro con controles clásicos, existe una cruda verdad en materia de tecnología, que a menudo no se discute. Esta se relaciona con la verdadera capacidad de protección de nuestros sistemas tecnológicos modernos, que además resultan ser críticos para la infraestructura nacional. Eso significa responder ¿cuán verdaderamente seguros pueden estar nuestras infraestructuras críticas automatizadas en su control y manejo?. La idea no es responder con esperanzas, promociones o mercadeo, el asunto es descubrir la realidad aunque sea desagradable. Tomar hechos ciertos y reconocer los límites de nuestra ciencia actual, para poder planificar sobre un piso sólido.
Entonces, lo primero que hay que señalar es que la infraestructura crítica de las naciones resulta apetecible, como objetivo de perjuicio, para muchos actores. En 2019, Edward Cartwright, Julio Castro y Ana Cartwright escribieron en el Journal de Ciberseguridad, que la única forma de disuadir a los criminales de lanzar ataques “ransomware”, es que estos perciban que las medidas de protección de su potencial víctima son “casi perfectas”. Más también añadieron “lo cual es improbable”. De manera que usted puede asumir que en algún momento será la presa y por ello, debe prepararse para ello. Pero no únicamente a modo preventivo, debe además presumir que hay alta probabilidad de que logren atravesar las protecciones más externas de su infraestructura crítica y deba responder al ataque en forma dinámica. Es decir, que deba reaccionar con algo más que murallas y puertas cerradas, que son mecanismos de seguridad estáticos. Ese nivel de protección fue sobreestimado por el personal de Colonial Pipeline.
¿Y porqué uno debería asumir un escenario tan negativo como es tener su plataforma invadida y su primera línea de defensa sobrepasada? Hay tres razones principales, la primera se vincula con la naturaleza del código seguro. Este es una entelequia, no tenemos forma científica para validar la seguridad de un programa. De lo que disponemos son buenos mecanismos de pruebas de cumplimiento y resistencia, ante casos posibles. Eso es diferente y hay que añadir que los sistemas de software industrial de nuestros días, tienen millones de líneas de código. A menudo con programas de más de una casa desarrolladora profesional. Cosa que complica considerablemente su calidad. Ahora bien, con frecuencia ese riesgo es minimizado por la industria de software, a razón de satisfacer ajustados cronogramas comerciales de desarrollo. Y es que examinar exhaustivamente la confiabilidad del código toma tiempo y genera costos. Adicionalmente, la competencia con tus rivales industriales impone plazos que dejan poco margen de maniobra. Por eso, se ha adoptado la aproximación de liberar los sistemas para su uso y usar “parches de software”, como mecanismo reactivo, ante el descubrimiento de fallas o ajustes. Eso resulta mejor para la industria y además traslada algo de la responsabilidad del fabricante sobre el cliente. Si este último no monta la actualización a tiempo, cualquier reclamo que haga será desestimado.
De modo que todo sistema está destinado a tener que incorporar parches correctivos. Pero eso también acarrea otros riesgos, ya que la acumulación de parches de software a la larga, aumenta la probabilidad de que surjan efectos colaterales, desconocidos y nuevos efectos emergen dentro del sistema. Hay numerosos ejemplos de reconocidos fabricantes, que distribuyeron un parche y luego se vieron obligados con urgencia, a entregar otro parche para corregir fallas que no esperaron surgirían al aplicar el primero. La carrera de tiempo por proveer parches efectivos, antes que los programas que explotarían la debilidad (“exploits”) surgida, inunden los sistemas de los clientes es un trabajo exigente y retador.
La segunda razón se vincula con el diseño actual de muchos sistemas industriales, esto ha cambiado significativamente en las 4 últimas décadas. En sus inicios las plantas industriales, oleoductos, aeropuertos, hospitales y otras áreas críticas, operaban aisladas de las redes de computadoras. Pero el cambio ha sido vertiginoso y rápido, el tráfico de datos, telefonía y vídeo que en los 90’s se separaba, hoy viaja integrado en paquetes del Protocolo de Internet (IP). Algo parecido ocurrió con plataformas industriales que estaban físicamente separadas; se automatizaron y posteriormente se integraron con las redes de datos. Se separaron lógicamente a través de “Firewalls”, dominios segmentados y dispositivos conmutadores, pero este tipo de mecanismos hoy también se controlan por software y ello los coloca en el espacio de los elementos vulnerables. Entonces, si usted se apropia de uno de ellos, puede ordenarle que lo deje entrar y eso lo hemos discutidos en escritos previos. Ese fue el caso de la VPN de Colonial Pipeline.
Para poner las cosas aún más color de hormiga, los diseñadores de algunos sistemas de control y adquisición de datos industriales que antes usaban sus propios protocolos de intercambios, como es el caso de Mobdus y sus derivados, cambiaron la naturaleza de la red por la que el mismo viaja ahora y adoptaron el mundo IP. Esto es bueno para los fabricantes dado que disminuye costos, pero hace que las debilidades del TCP/IP se hereden en las redes industriales. Claro, facilita la actualización de software con el esquema de parches distribuidos por Internet y hasta habilita el mantenimiento en línea, que como un servicio adicional rápidamente puede proveer el mismo fabricante, pero eso mismo medio puede ser subvertido por causa ajena a la plataforma industrial y llevarse todo como un efecto de piezas de dominó juntas donde la primera empuja al resto.
Cada entrada remota de su red hecha para sus proveedores o fabricantes, son una puerta al exterior y las credenciales actuales son un mecanismo muy débil para asegurar que no puedan caer en manos contrarias. A Colonial Pipeline también le pasó eso y la historia esta llena de errores o debilidades de diseño, que obligan a aplicar con urgencia montañas de paños calientes que poco pueden hacer, dado que la falla es estructural. Irán, Stuxnet y los SCADA de Siemens®, operando sobre Microsoft® Windows es únicamente un ejemplo conocido de esto. No es lo mismo proteger una casa con una puerta, que otra que tenga, además entradas para un anexo y hasta una puerta al jardín. Abandone la idea de que al cumplir altos estándares de seguridad eso le otorga seguridad plena de protección; eso es tan válido como creer que por ser deportista no se puede sufrir un infarto. Esto es un asunto de probabilidades e interdependencia de sistemas, no de prejuicios.
En la próxima parte expondremos el resto de las causas y apuntaremos cuál camino recorrer para poder resistir ante estas dificultades. Por ahora concluimos citando al investigador y gerente en seguridad, John McManus, quien ocupó un alto cargo gerencial en la NASA y en 2009 escribió: “Me preocupa profundamente el enfoque rápido y directo que todavía veo que se aplica a la seguridad. Parece que no aprendimos las lecciones de finales de los 90 y la crisis de las puntocom. Documentamos las lecciones y las guardamos en carpetas, en un estante, para que acumularan polvo.
Como dije antes, tenemos lecciones anotadas, más no aprendidas. No basta con recopilar las lecciones; debemos aplicarlas para mejorar. No estamos desarrollando programas de seguridad basados en riesgos, que aborden la seguridad durante todas las fases del ciclo de vida del desarrollo del sistema. Hasta que no hagamos esa transición, nuestro éxito será limitado”.
Autor: Miguel Torrealba Sánchez.
Universidad Simón Bolívar
Departamento de Computación y Tecnología de la Información
mtorrealba@usb.ve
