CrowdStrike, SolarWinds, Kaseya, Okta y Log4j: ¿estamos a un paso del colapso tecnológico? ¿cuenta su empresa con un Plan de Respuesta a Incidentes?

Imagen: Zdzisław Beksiński

Por Víctor Ruiz, fundador de SILIKN, Instructor Certificado en Ciberseguridad (CSCT™), (ISC)² Certified in Cybersecurity℠ (CC), EC-Council Ethical Hacking Essentials (EHE) Certified, EC-Council Certified Cybersecurity Technician (CCT), Ethical Hacking Certified Associate (EHCA), Cisco Ethical Hacker y líder del Capítulo Querétaro de la Fundación OWASP.

El incidente cibernético ocurrido el viernes 19 de julio de 2024, es un ejemplo de lo que puede suceder durante un ciberataque masivo. Aunque este evento, que involucró a CrowdStrike y Microsoft, no fue un ciberataque, es crucial que las empresas tomen medidas preventivas ante situaciones de esta magnitud. Se prevé que en el futuro habrá verdaderos ataques que se comportarán de manera similar al fallo que ha tenido CrowdStrike, pero con mayor frecuencia y letalidad, y esta vez coordinados por grupos de cibercriminales.

El evento de CrowdStrike nos da la oportunidad de reflexionar acerca de algunos problemas actuales como la excesiva dependencia que se tiene de sólo algunos proveedores de tecnología, así como la fragilidad de todo el sector y, además, nos permite ponerlo en perspectiva y compararlo con los ciberataques que se han presentado contra la cadena de suministro, por el tipo de daño y por la cantidad de organizaciones que se han visto afectadas con estos últimos.

Los ataques a la cadena de suministro de software son particularmente peligrosos debido a que se enfocan en las organizaciones a través de sus proveedores externos de software, hardware o servicios en cualquier fase del ciclo de vida del desarrollo. El propósito de estos ataques es obtener acceso no autorizado, llevar a cabo espionaje y facilitar actos de sabotaje.

Estos ataques pueden variar desde el uso de técnicas engañosas sencillas, como disfrazar malware como si fueran productos legítimos, hasta métodos más complejos que permiten acceder y modificar el código fuente de un programa auténtico.

Además de comprometer la infraestructura de desarrolladores y distribuidores, los atacantes pueden intentar explotar herramientas, dependencias, bibliotecas compartidas y código de terceros.

A continuación veremos algunos ejemplos:

CrowdStrike
El viernes 19 de julio de 2024, un caos informático producido por una actualización de software defectuosa de la firma CrowdStrike colapsó los sistemas de aerolíneas, hospitales, servicios de emergencia, tiendas y bancos, lo que a su vez provocó afectaciones para miles de personas alrededor del mundo. La actualización para el sensor Falcon, destinada a sistemas operativos Windows tenían un error lógico que generaba la aparición de la pantalla azul en cientos de computadoras. Después de que la empresa con oficinas centrales en Texas descubriera el error, aislaron el problema y esclarecieron que esto no se trataba de “un incidente de seguridad o ciberataque”. Sin embargo, este error dejo grandes estragos para diferentes empresas que hasta ahora siguen recuperándose. De acuerdo con Microsoft, se estima que este error afectó a 8.5 millones de dispositivos con el sistema operativo Windows, que es menos del 1% de equipos.

SolarWinds
SolarWinds se ha convertido en un nombre conocido por todas las razones equivocadas: desde 2019, esta empresa de gestión de sistemas fue el blanco de uno de los mayores ataques a la cadena de suministro de software en la historia. En diciembre de 2020, se reveló que más de 18,000 empresas públicas y privadas fueron víctimas de una campaña global de ciberespionaje. La brecha de seguridad en SolarWinds Corp. afectó al Departamento de Justicia y al Tesoro de Estados Unidos, así como a empresas como Microsoft. El malware que comprometió uno de los productos de SolarWinds permitió a los hackers acceder remotamente a las redes de las organizaciones y robar información. Aunque el impacto fue significativo, el incidente no se descubrió hasta que la reconocida empresa de ciberseguridad FireEye se dio cuenta de que también había sido hackeada.

Kaseya
En julio de 2021, Kaseya, una empresa de gestión de TI, anunció que su software VSA había sido explotado. Posteriormente, se reveló que los atacantes, conocidos como REvil, aprovecharon una vulnerabilidad en la plataforma para llevar a cabo ataques de ransomware contra varios proveedores de servicios gestionados y sus clientes. Kaseya confirmó que alrededor de 60 clientes y otras 1,500 empresas se vieron afectadas por el ataque. La empresa afirmó que no pagó ningún rescate.

Codecov
En abril de 2021, la plataforma de prueba de software Codecov, que proporciona informes y estadísticas sobre la cobertura de código, descubrió que había sido objetivo de un ataque a la cadena de suministro que manipuló los scripts de carga de Docker. El entorno de Codecov estuvo comprometido durante dos meses antes de que se detectara la intrusión de los hackers. Fue un cliente quien finalmente notó un error en el código. El daño fue considerable, dado que Codecov ofrece servicios a más de 29,000 clientes empresariales.

Okta
En 2022, Okta, un proveedor de servicios de autenticación con más de 15,000 clientes a nivel mundial, reportó tres infracciones, siendo la más reciente el compromiso de sus repositorios de GitHub. En marzo de ese año, el grupo de hackers Lapsus$ logró acceder a la red de Okta al comprometer la computadora portátil de un técnico de uno de sus proveedores externos, Sykes, que pertenece a Sitel, uno de los operadores de centros de llamadas más grandes del mundo. El ataque de Lapsus$ también afectó a varias organizaciones de atención médica. Lapsus$ es conocido por hackear y filtrar archivos robados de Samsung. Una vez dentro de la red de Okta, los hackers lograron acceder a los datos de aproximadamente el 2.5% de los clientes de la empresa.

Tokens OAuth de GitHub
En abril de 2022, GitHub, el servicio de alojamiento de repositorios, informó que un atacante había robado tokens de usuario OAuth emitidos a los integradores externos Heroku y Travis-CI. Estos tokens fueron utilizados para descargar datos de numerosos clientes de GitHub. La empresa explicó que el atacante se dirigió a organizaciones específicas y luego accedió a los repositorios privados de las cuentas de usuario de interés.

Log4j
Log4j pone de manifiesto un “potencial” de ataque más amplio, siendo un ejemplo significativo de la vulnerabilidad inherente a la cadena de suministro de software. A finales de 2021, una herramienta de registro basada en Java llamada Log4j sufrió una vulnerabilidad conocida como Log4Shell, que puso en riesgo millones de computadoras. Log4j es un software de código abierto desarrollado por la Apache Software Foundation, diseñado para registrar información de diagnóstico sobre los sistemas. Esta información ayuda a usuarios y administradores a mantener el funcionamiento adecuado de los sistemas. La vulnerabilidad Log4Shell permitía a los atacantes acceder a los sistemas, robar datos, descubrir credenciales de inicio de sesión y contraseñas, y desplegar más software malicioso. Los efectos fueron extensos debido a la amplia adopción de Log4j por numerosas personas y organizaciones.

¿Están listas las empresas para enfrentar estos desafíos?

Sin duda, el primer paso para que las empresas puedan enfrentar tanto fallos como ataques es la implementación de un plan de respuesta a incidentes. Sin esta estrategia, será difícil superar tales situaciones con éxito.

Un plan de respuesta a incidentes es un conjunto de directrices para detectar, responder y mitigar los efectos de un evento de seguridad de la información. También conocido como plan de gestión de incidentes o plan de gestión de emergencias, este plan ofrece instrucciones detalladas para enfrentar diferentes escenarios potenciales, como vulneraciones de datos, ataques DoS o DDoS, brechas en los firewalls, brotes de malware, amenazas internas, pérdida de datos y otras violaciones de seguridad.

En este sentido, los planes de respuesta a incidentes ayudan a reducir los efectos de los incidentes de seguridad y, por lo tanto, limitan el daño operativo, financiero y de reputación. También establecen las definiciones de incidentes, los requisitos de escalamiento, las responsabilidades del personal, los pasos clave a seguir y las personas a las que contactar en caso de incidente.

Un plan de respuesta a incidentes define las acciones y procedimientos recomendados para:

- Reconocer y reaccionar ante un incidente.
- Evaluar el incidente de manera rápida y efectiva.
- Notificar el incidente a las partes y organizaciones pertinentes.
- Coordinar la respuesta de la empresa.
- Escalar los esfuerzos de respuesta de la empresa según la gravedad del incidente.
- Apoyar las actividades de recuperación empresarial tras el incidente.

Un plan de respuesta a incidentes bien diseñado puede ser el factor diferenciador crucial que permita a una organización contener rápidamente el daño de un incidente y recuperar rápidamente las operaciones comerciales normales.

Las empresas que desarrollan sus planes de respuesta a incidentes deben seguir estos pasos:

1. Crear una política
2. Formar un equipo de respuesta a incidentes y definir responsabilidades
3. Desarrollar manuales de estrategias
4. Crear un plan de comunicación
5. Poner a prueba el plan
6. Identificar las lecciones aprendidas
7. Seguir probando y actualizando el plan

¿Además del plan de respuesta a incidentes qué otras acciones se deben considerar para protegerse de los ataques a la cadena de suministro de software?

Es difícil prevenir los ataques a la seguridad del software debido a la gran cantidad de proveedores en la cadena de suministro. Pero hay algunas reglas generales a seguir:

- Mantenga un inventario actualizado de todos sus activos de software.

- Proteja sus puntos finales.

- Implemente políticas sólidas de integridad de código que incluyan reglas estrictas para autorizar aplicaciones.

Para más información, visite: https://www.silikn.com/