1 puntos por GN⁺ 2024-07-22 | 1 comentarios | Compartir por WhatsApp

¿Qué pasó con la resiliencia digital?

  • Causa del desastre digital

    • El colapso digital que afectó el viernes a aeropuertos, hospitales y estaciones de TV fue provocado por un error en una actualización de software
    • No fue obra de fuerzas hostiles, sino un incidente que dejó al descubierto las vulnerabilidades de Estados Unidos
  • Por qué es difícil recuperarse

    • El gobierno de Biden ha estado simulando escenarios de ataques de hackers de Rusia y China
    • Pero este incidente fue causado por un simple error humano
    • En sistemas de red complejos, un pequeño error puede provocar grandes problemas
  • La reacción de los guerreros cibernéticos

    • Hubo alivio al saber que este incidente no fue un ataque a nivel estatal
    • El malware como Volt Typhoon de China es difícil de encontrar y aún más difícil de eliminar
    • Este incidente volvió a poner en evidencia los límites de la resiliencia cibernética
  • Cooperación entre gobierno y sector privado

    • En los últimos años, Estados Unidos ha empezado a tomarse en serio los problemas de ciberseguridad
    • Organismos gubernamentales como el FBI, la NSA y CISA colaboran con empresas privadas para compartir vulnerabilidades y alertar sobre hackers
    • El presidente Biden creó una Junta de Revisión de Seguridad Cibernética para analizar incidentes importantes

Resumen de GN⁺

  • Este incidente fue un colapso digital provocado por un simple error en una actualización de software
  • Dejó al descubierto la vulnerabilidad de los sistemas de red complejos y mostró los límites de la resiliencia cibernética
  • La cooperación entre el gobierno y el sector privado es clave, y se necesita un sistema para revisar incidentes importantes
  • Entre los productos o proyectos con funciones similares se encuentra software de ciberseguridad como CrowdStrike

1 comentarios

 
GN⁺ 2024-07-22
Opiniones de Hacker News
  • Me parece interesante que, entre los análisis que vi en los medios, casi nadie diga que un SO que requiere parches de seguridad frecuentes no debería usarse en infraestructura desde el principio.
    También vi una foto de una pantalla azul en el tablero de vuelos de un aeropuerto, y me pregunto por qué estas cosas no se construyen sobre Linux u OpenBSD.
    La seguridad no debería ser una función que se agrega después, sino algo incorporado desde el inicio; hoy existe toda una industria dedicada a poner una capa de seguridad encima de Windows, pero aun así no funciona bien.

    • Probablemente porque el proveedor que hizo ese software siempre lo desarrolló solo para Windows.
      En realidad, muchos casos empezaron en DOS u OS/2 y luego migraron a NT4, y ahí influyen la historia, la inercia, la familiaridad, el costo y la facilidad de soporte.
      La seguridad no es un producto, sino un proceso, y las distribuciones también requieren actualizaciones frecuentes, aunque sí se puede reducir el alcance del software instalado.
      Un dispositivo de señalización en un aeropuerto probablemente no necesite códecs como MPEG2 o VP1.
      En estos sistemas especializados también abunda el software carísimo y de mala calidad: aunque quieras SAML/OIDC, solo soportan LDAP en texto plano o, con suerte, Active Directory; aunque quieras una versión reciente de Apache Tomcat, el proveedor no sabe resolver los problemas, así que solo “soporta” una versión vulnerable de hace 3 años.
      Si es correcta la hipótesis de que la causa de la pantalla azul de CrowdStrike fue un puntero nulo, deberían haber usado un lenguaje seguro, y en ese caso creo que es fácil atribuirle la responsabilidad a CrowdStrike.
      Microsoft entregó la escopeta; no apuntarla hacia uno mismo es responsabilidad del proveedor.
    • Ahora mismo en la portada también hay una publicación que dice que CrowdStrike rompió Debian y Rocky Linux hace unos meses, pero nadie se enteró.
      https://news.ycombinator.com/item?id=41018029
    • Un “SO que recibe actualizaciones de seguridad frecuentes” es, más bien, una buena señal.
      Significa que se están planteando problemas y que se están mitigando riesgos.
      La seguridad no es una casilla de verificación; como el entorno cambia constantemente, es más bien un proceso interminable, y un SO que no recibe actualizaciones o que no se renueva con frecuencia no es mejor.
      Lo que uno quiere son actualizaciones que no vuelvan inestable al SO, y detrás de eso hay capas enormes de decisiones acumuladas por cada organización al operar estos equipos.
      La seguridad debe diseñarse en capas y venir incorporada.
      Más que “no funciona”, ha funcionado porque se mantuvo silenciosa durante mucho tiempo, y la gente solo nota los incidentes que fallan.
    • El personal del aeropuerto tiene que poder darle soporte; no puede ser algo que solo puedan manejar los típicos perfiles de HN.
      La mayoría sabe usar computadoras con Windows, el personal de soporte de TI de escritorio está acostumbrado a administrar Windows, y el equipo de instalaciones del edificio también puede ayudar hasta cierto punto.
      Microsoft facilita la administración de conjuntos de computadoras y ofrece su propia capacitación y certificaciones, además de muchísima capacitación de terceros.
      Windows es, en la práctica, la máquina estándar para uso empresarial, y la mayoría de las empresas de señalización también usa Windows.
      No es fácil encontrar gente que conozca BSD.
    • Para muchos CTO/CISO, más que un sistema estable y seguro, importa más tener un buen blanco al que trasladarle la responsabilidad cuando algo sale mal.
      Una Big Brand es un buen blanco; un proyecto open source como OpenBSD, no.
      Aunque haya pérdidas de millones de dólares, parece poco probable que despidan a un CTO por haber elegido Windows+CrowdStrike en vez de Linux/BSD.
      La frase “nadie fue despedido por comprar IBM” sigue siendo cierta, al menos en el mundo corporativo.
  • No sé si alguna vez existió la “resiliencia digital”, y si existió, me pregunto cuándo fue.
    Este caos no lo provocó un adversario, pero en la práctica proporcionó un mapa de las vulnerabilidades de Estados Unidos en un momento crítico.
    Es muy probable que quienes no están en buenos términos con Estados Unidos ya estén creando y acumulando mapas de vulnerabilidades como este.
    Sorprende, pero a la vez es evidente, que Estados Unidos y otros países mantengan una actitud tan laxa ante estas amenazas y no refuercen más sus vulnerabilidades.
    El costo es un factor, pero creo que el factor más importante es la comodidad.
    Si fortaleces los sistemas contra las vulnerabilidades, se vuelven menos cómodos y menos fáciles de usar, y la gente se resiste de inmediato.
    Cuando Microsoft lanzó Windows, especialmente Windows 95, intentó captar a usuarios no técnicos haciendo que todo fuera fácil con solo hacer clic, y la seguridad no se tuvo suficientemente en cuenta.
    Cuando los virus, las vulnerabilidades y las intrusiones se salieron de control, se introdujeron restricciones y los usuarios pasaron a disfrutar menos de la libertad a la que se habían acostumbrado.
    Microsoft acostumbró al mundo a una forma de operar laxa, y los intentos de revertirlo desde entonces han chocado continuamente con la resistencia de los usuarios.
    Estamos atrapados en un gran problema que era fácilmente previsible incluso antes del lanzamiento de Windows 95, y será extremadamente difícil corregirlo.

    • Tiene razón Charlie Munger cuando dice: “muéstrame los incentivos y te mostraré los resultados”.
      A las empresas no se les recompensa por operar sistemas informáticos seguros, redundantes y confiables; se les recompensa por lograr que la cifra final del estado de resultados supere las expectativas fijadas por un analista de Lower Manhattan 90 días antes.
      Como en Estados Unidos las empresas se encargan de gran parte del funcionamiento de la sociedad, los sistemas importantes también se diseñan así.
      Puede que esto termine en tribunales y que CrowdStrike tenga que ser adquirida para compensar a sus clientes por los daños causados desde el 19 de julio, pero eso tomará años, y los demandantes quizá solo reciban una compensación simbólica o ninguna.
      Para entonces, el mercado habrá hecho coberturas, capturado a los reguladores, recortado pérdidas y simplemente seguido adelante.
      Los activos serán comprados a precio de remate por quienes vean esto como “destrucción creativa”, sin importarles que la vida de las personas haya sido puesta en riesgo.
      Y el ciclo continuará.
    • Estudiar la experiencia de Ucrania sería muy útil, y es muy probable que ya lo haya sido.
      Casi toda su infraestructura crítica ha sufrido ciberataques durante años, y aunque los sistemas se cayeron y hubo fallas, se adaptaron.
      A veces volvieron a soluciones de baja tecnología; otras veces construyeron nuevos sistemas con resiliencia y eliminaron los antiguos.
      Cuando el problema es concreto e inmediato, también es mucho más fácil justificarlo políticamente.
      Recuerdo que una de las primeras medidas que tomó Estados Unidos cuando empezó a escalar la tensión fue enviar un equipo de expertos en ciberseguridad de la NSA para ayudar a reforzar sistemas y eliminar intrusiones.
    • Las “agencias cibernéticas” se concentran en el ataque.
      Porque es fácil sumar puntos y parecer que se está haciendo algo.
      En cambio, la defensa es un trabajo tedioso: proteger innumerables endpoints antiguos o convencer a megacorporaciones muy rentables de hacer cosas que las vuelven menos vulnerables, pero menos profitable.
    • Al menos en los 90 y principios de los 2000, si conectabas algo importante a Internet, se habrían reído de ti en la sala de juntas y te habrían despedido de inmediato.
    • Durante mucho tiempo la resiliencia fue el objetivo, y creo que antes de que el SaaS en la nube y las actualizaciones automáticas lo dominaran todo, había más resiliencia.
      La época en que las instalaciones de software estaban dentro de redes privadas, las máquinas y las topologías tenían estructuras fundamentalmente distintas, y se usaba software variado aunque fuera de menor calidad, era mucho más robusta que la de hoy.
      Ahora una sola falla de un servicio como AWS puede detener a muchas empresas, y una mala actualización como esta afecta a todos de inmediato y genera un efecto dominó.
      Antes este tipo de cosas no era común.
      Concentramos nuestra arquitectura colectiva en unas pocas herramientas de mejores prácticas, y eso se convirtió en un punto único de falla no solo frente a ataques digitales, sino también frente a configuraciones incorrectas, fallas de gestión, fracasos empresariales, ingenieros agotados y mal pagados, y optimizaciones.
      No estoy de acuerdo con que reforzar los sistemas necesariamente los haga menos cómodos.
      En la última década, la industria de la seguridad se ha movido más bien en la dirección contraria y se dio cuenta de que una seguridad demasiado rígida lleva a los usuarios a buscar atajos simples y predecibles, lo que debilita la postura de seguridad general.
      Basta ver los cambios en las recomendaciones del NIST sobre contraseñas.
      Si hay que cambiarlas cada 90 días, que sean distintas de las 10 anteriores y además cumplan requisitos de complejidad, los usuarios usan la longitud mínima con patrones predecibles y solo incrementan un número al final.
      Los hashes de contraseñas antiguas almacenados para verificar la reutilización se convierten, en caso de una brecha, en una carga que revela a los atacantes los patrones de cada usuario.
      Hoy se despliega mucha más seguridad usable, casi o totalmente transparente para el usuario final.
      Los CAPTCHA de los sitios web antiguos eran comunes y pésimos, y además fáciles de evadir, pero las soluciones CAPTCHA de Cloudflare y Google son bastante transparentes y mucho más efectivas.
      Es cierto que la laxitud general y persistente de Microsoft contribuyó a malas prácticas de seguridad, pero ese ecosistema tenía aspectos extraños por su entorno inherentemente inestable, y salvo por un breve pico, casi nunca fue la base central de la infraestructura de Internet.
      Lamentablemente sí fue central en la infraestructura corporativa, y parece que nunca recibió el memo sobre seguridad usable o transparente.
      Espero que ahora al menos estén esforzándose entre bastidores.
  • De una forma retorcida, CrowdStrike terminó haciéndole a la civilización occidental una prueba forzada de recuperación ante desastres y resiliencia
    Un ataque real no se revertiría en menos de una hora
    CrowdStrike no es la única empresa con acceso masivo a tantas compañías, gobiernos y recursos
    Si un empleado interno distribuyera un borrador de discos que destruyera no solo Windows, sino también computadoras con Linux y macOS, los sistemas afectados podrían no recuperarse en absoluto
    En ese caso, los sistemas críticos podrían tardar meses en volver a estar en línea, y la economía mundial podría paralizarse peor que durante el COVID
    El punto central también es “por qué CrowdStrike no lo hizo mejor”, pero, más ampliamente, por qué la tecnología de los sistemas críticos no es más resistente a un error o hackeo de un solo proveedor
    Por ejemplo, si en vez de un bucle de arranque un borrador de discos hubiera eliminado todos los discos de arranque, me pregunto si hay alguna razón para no tener preconfiguradas imágenes de recuperación por arranque PXE o imágenes de respaldo en servidores, ATM, kioscos, POS, etc.
    Incluso si se borraran UEFI y BIOS, no creo que sea técnicamente imposible implementar un mecanismo de recuperación automática
    Si nunca hiciste un análisis de causa raíz en respuesta a incidentes de IT o seguridad, entiendo que no pienses más a fondo, pero con ransomware, borradores de discos y riesgos de cadena de suministro generalizados desde hace más de 10 años, este es precisamente el tipo de análisis de causa raíz que faltaba
    Buscar a quién culpar y enojarse es fácil, pero no resuelve la causa raíz
    Tomar decisiones técnicas difíciles, no desperdiciar una buena crisis e impulsar inversiones en tecnología resiliente es lo que realmente aborda la causa raíz de este problema y de los problemas recurrentes

    • Si el firmware queda completamente destruido, hace falta firmware de respaldo
      En algún punto se puede hacer que estas cosas sean irrecuperables, pero ese no es el verdadero problema a resolver
      Yendo un paso más allá, el énfasis en la seguridad está sacrificando la discusión sobre resiliencia
      Especialmente desde el punto de vista financiero, la resiliencia es mucho más importante que la seguridad
  • Esto fue un secreto a voces durante décadas
    Hay apenas unos pocos proveedores importantes de sistemas operativos y navegadores, sacan parches continuamente, y la mayoría del software tiene una cadena de suministro tan enorme que auditar cualquier cosa es prácticamente imposible, y certificar que algo es realmente seguro también es difícil
    El software de “seguridad” solo amplía la superficie de ataque
    Todos en la industria lo sabían; es interesante que el NYT recién se esté poniendo al día

    • Puede ser que el NYT lo cubra por el gran incidente que ocurrió ayer, y porque es una empresa de noticias
  • Si una empresa está fuera de EE. UU., me parece una locura usar este servicio de CrowdStrike
    El FBI podría obligar a CrowdStrike, mediante una orden secreta, a inyectar una DLL en la infraestructura
    https://en.wikipedia.org/wiki/United_States_Foreign_Intelligence_Surveillance_Court

    • No estoy seguro de que eso sea correcto
      Según entiendo, el gobierno de EE. UU. puede ordenar a una empresa que entregue datos, pero no puede obligarla a hacer trabajo activo
      Ese fue también el punto central de la disputa entre el gobierno y Apple después del tiroteo de San Bernardino, y Apple tenía el derecho legal de negarse a brindar asistencia
      https://en.wikipedia.org/wiki/Apple%E2%80%93FBI_encryption_dispute
      El hecho de que la NSA y la CIA hayan llegado al punto de interceptar envíos de laptops y teléfonos para intervenirlos directamente también sugiere que no pueden obligar a ese tipo de acciones
    • En la práctica, el cumplimiento de PCI DSS es más importante que la paranoia sobre el FBI
    • Me pregunto si crees que no pueden, o que no lo harían, obligar a Microsoft a distribuir una “actualización” que haga lo mismo
  • Ayer le dije a mi familia que, si entráramos en una guerra de verdad, todo dejaría de funcionar en menos de 8 horas
    Volveríamos al efectivo y al papeleo, pero sería doloroso y lento

  • Lo que se necesita es “diversidad”, claro que no en el sentido de grupos marginados
    Si más equipos críticos ejecutaran sistemas operativos distintos, el daño habría sido limitado
    El riesgo del “monocultivo” suele mencionarse al hablar de plantas, pero el mismo riesgo aplica a la infraestructura informática

    • Eso ya ocurre en cierta medida
      El solo hecho de que la civilización no haya colapsado demuestra que hay muchísima infraestructura que no usa Windows ni CrowdStrike
    • Lo que me resulta aún más incomprensible es que los responsables de organizaciones que operan sistemas de altísima importancia hayan aceptado la idea de que un proveedor de software externo pueda enviar parches en cualquier momento
      Dicho de forma un poco cruda, creo que las empresas afectadas por CrowdStrike también comparten parte de la responsabilidad por lo ocurrido ayer
    • Aunque más equipos críticos hubieran usado otro sistema operativo, si estaban ejecutando el mismo CrowdStrike, el daño no se habría limitado
    • No necesariamente
      CrowdStrike ni siquiera es el proveedor número uno en este campo, pero esto ocurrió por los efectos de red
      La cantidad de plataformas necesaria para lograr este nivel de seguridad sería poco realista
  • A nivel mundial, hubo fallas informáticas masivas en empresas que ejecutan CrowdStrike en equipos Windows.
    CrowdStrike se vende como software contra hackeos, pero en la práctica es un software popular que usan los ejecutivos de nivel C para vigilar el comportamiento de los empleados.
    Se instala con privilegios muy elevados y, por diseño, es difícil de corregir o eliminar.
    Me pregunto si esto realmente le dejará alguna lección a alguien.

    • Creo que sí dejará una lección.
      Microsoft anunció que los equipos afectados fueron 8.5 millones, algo difícil de creer, pero al ver el esfuerzo que implicó la respuesta incluso en una organización relativamente mediana como la nuestra, surgen preguntas muy simples como: “si la mitad de los empleados trabaja de forma remota, ¿cómo diablos accedemos a estos equipos?”.
      La respuesta siempre era “cuánto cuesta hacer esto”, pero ahora también existe la cifra del otro lado: “cuánto cuesta no hacerlo”.
    • Necesito más información sobre la función de vigilancia.
      Sería bueno tener capturas de pantalla.
  • No estoy de acuerdo con la parte en la que Kent Walker, de Google, dice que “no todo está perdido” y que la IA permite avances significativos en la identificación de vulnerabilidades, el parcheo de agujeros y la mejora de la calidad del código.
    Si la única esperanza es una vaga promesa de IA, entonces creo que en realidad no hay esperanza.

    • Exacto.
      Esto es parecido a decir que la mejor forma de detener tiroteos escolares es darle armas a los maestros.
      No creo que la IA hubiera convencido mejor a la dirección de CrowdStrike de que una estrategia de despliegue gradual valía el costo.
      Problemas como este los causan las personas, no la tecnología, así que no se resuelven metiendo más tecnología.