[03/05/2021] En diciembre, el mundo se enteró de uno de los mayores y más sofisticados ataques de ciberespionaje hasta la fecha, en el que hackers rusos patrocinados por el Estado irrumpieron en las redes de agencias federales estadounidenses y de numerosas empresas. Los atacantes comprometieron a sus víctimas inyectando código malicioso en las actualizaciones de software legítimas de una popular plataforma de gestión de redes desarrollada por una empresa llamada SolarWinds.
Varios meses después, el gobierno estadounidense y la industria privada siguen trabajando para descubrir el alcance total del ataque, pero el incidente ha llamado la atención sobre un problema que los investigadores de seguridad llevan años advirtiendo: la seguridad de la cadena de suministro de software.
Mientras las empresas luchan por investigar si sus propios sistemas y datos se han visto potencialmente afectados por el incidente de SolarWinds, los ejecutivos, las juntas directivas y los clientes están descubriendo que la amenaza de los ataques a la cadena de suministro se extiende más allá de este único incidente y que la mitigación de los riesgos asociados a ellos no es sencilla. Las siguientes son las preguntas más importantes que los CISOs deben ser capaces de responder tras una violación de la cadena de suministro de software como la de SolarWinds de acuerdo con líderes y expertos en seguridad.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
¿Estamos en riesgo, aunque no utilicemos el software vulnerado?
Luego de un ataque como el de SolarWinds, los líderes empresariales preguntarán y deberán preguntar a los responsables de TI y ciberseguridad si su organización utiliza directamente el software afectado. Si la respuesta es afirmativa, se activará el plan de respuesta a incidentes de seguridad de la empresa para identificar, contener y eliminar la amenaza, y establecer el alcance del impacto a la empresa.
Si la respuesta es negativa, no significa que la organización esté segura. La pregunta de seguimiento debe ser: ¿Se ha visto comprometido alguno de nuestros socios, contratistas o proveedores? Los ataques a la cadena de suministro pueden tener un gran alcance, y las empresas suelen proporcionar a otras personas acceso a sus datos o redes y servidores.
"Nuestros clientes nos enviaban algún tipo de formulario de gestión o divulgación de riesgos y yo tenía que rellenarlo," explica Jesse Webb, responsable de tecnología y seguridad de la empresa de informática sanitaria Avalon Healthcare Solutions. Avalon no utilizaba el software, pero "casi todos mis programas de salud se pusieron en contacto conmigo inmediatamente y me preguntaron: ¿Lo está utilizando? y si lo está utilizando, deje de hacerlo e infórmenos de su investigación. Yo hice lo mismo. Me dirigí a algunos de mis principales proveedores externos, y solo había uno en mi cadena de suministro que realmente utilizaba SolarWinds. Hemos estado trabajando con ellos para que presten atención a su respuesta forense".
Es fundamental entender que los ataques a la cadena de suministro de software son muy complejos y pueden tener un gran alcance en el tiempo. Un grupo chino de espionaje cibernético conocido como Winnti, Barium o APT41 lleva realizando este tipo de ataques desde el 2017, cuando hizo un backdoor al software de gestión de servidores producido por una empresa llamada NetSarang. Ese mismo año, el grupo logró hacer un backdoor a la popular herramienta de optimización de sistemas CCleaner y mandó la actualización maliciosa a más de dos millones de ordenadores, aunque solo un número selecto de empresas del sector tecnológico fueron el objetivo de la carga dañina de la segunda fase. En el 2019, el grupo hizo un backdoor al ASUS Live Update Utility y lo realizó desde los servidores oficiales de ASUS. Los investigadores creen que todos estos ataques podrían estar interconectados y que un compromiso proporciona acceso para realizar el siguiente.
Durante una sesión informativa de la Casa Blanca en febrero, la viceconsejera de Seguridad Nacional para Tecnología Cibernética y Emergente, Anne Neuberger, reconoció esta amenaza y advirtió que el gobierno tardará meses en determinar el alcance total del ataque. "Al día de hoy, nueve agencias federales y unas 100 empresas del sector privado se han visto comprometidas", señaló. "Como saben, aproximadamente 18 mil entidades descargaron la actualización maliciosa. Por lo tanto, la escala del acceso potencial superó con creces el número de compromisos conocidos. Muchos de los comprometidos del sector privado son empresas tecnológicas, incluyendo redes de empresas cuyos productos podrían ser utilizados para lanzar más intrusiones".
Mike Raeder, un veterano del sector que ha desempeñado funciones de liderazgo en materia de seguridad cibernética en varias organizaciones y que hasta hace poco ocupaba el cargo de CISO adjunto en Northrop Grumman, considera que los consejos de administración deben estar mejor formados en los aspectos técnicos de estos ataques. Además, cree que, a largo plazo, los consejos de administración deberían diversificarse incluyendo a antiguos CIOs o CISOs.
"Asegurarnos de que nuestros consejos de administración entiendan el riesgo cibernético en su conjunto es de vital importancia, ya que entonces empezarán a hacer esas preguntas más importantes; pero incluso si no las hacen, es responsabilidad de los líderes cibernéticos hablar con los consejos de administración sobre el alcance del riesgo dentro de toda la organización", dice a CSO. "Eso no solo se refiere al pilar de TI, sino también dónde existe el riesgo cibernético más allá de eso. Cuando hablamos de las cadenas de suministro de software en particular, deberíamos preguntar a nuestros proveedores si utilizan SolarWinds o cualquier producto [comprometido]. ¿Dónde está el riesgo en su organización que podría transferirse a mi organización?"
¿Nuestro actual programa de seguridad cubre las amenazas a la cadena de suministro de software?
El principal problema de la defensa contra los ataques a la cadena de suministro de software es que abusan de una relación de confianza entre los usuarios y los proveedores, y del acceso y los privilegios legítimos que se otorgan a una pieza concreta de software para realizar su función. Desde el punto de vista del usuario, el software que descargan procede de una fuente de confianza a través del canal de distribución o actualización correcto, y está firmado digitalmente. No se puede esperar que los usuarios hagan ingeniería inversa y analicen el código de las actualizaciones de software que despliegan en su infraestructura y las empresas habituales no son proveedores de seguridad, por lo que no tienen empleados con esas habilidades.
Las organizaciones deben asumir que probablemente no podrán detectar la intrusión inicial en la cadena de suministro de software; sin embargo, pueden tomar medidas para bloquear y detectar las segundas fases del ataque. Esto incluye los intentos de descargar herramientas y cargas útiles adicionales, los intentos de comunicarse con servidores externos de mando y control, y los intentos de desplazarse lateralmente a otros sistemas.
Si el gobierno y los proveedores de seguridad como FireEye se vieron comprometidos, ¿cómo podemos protegernos nosotros mismos?
Las empresas deben centrarse en la madurez de sus programas de seguridad, señala Webb. Todo el mundo empieza por construir una sólida coraza exterior con firewalls, sistemas de detección y prevención de intrusiones, control de DNS y otras cosas que crean límites; pero no ponen mucho esfuerzo en endurecer el interior de sus entornos, añade.
Las empresas podrían detectar las actividades de movimiento lateral, como los intentos de abusar de las credenciales administrativas, pero eso suele requerir herramientas avanzadas de monitoreo y detección de comportamientos, y grandes centros de operaciones de seguridad que están fuera del rango de precios de las organizaciones pequeñas y medianas. Lo que estas pueden hacer, según Webb, es asegurarse de que cubren lo básico y de que todos los sistemas y el entorno interno están lo más reforzados posible.
Por ejemplo, en Avalon, las comunicaciones en la red interna están cifradas para que, en caso de compromiso, los atacantes no puedan extraer credenciales o información útil del tráfico, aunque puedan interceptarlo. Todo el tráfico DNS es forzado a través de un firewall y un filtro DNS, y todas las URLs a las que los servidores pueden conectarse tienen que estar en una lista blanca. Esto asegura que, si un servidor se ve comprometido, el código malicioso no pueda llegar a un servidor de comando y control para descargar herramientas o comandos adicionales.
Cuando son desplegados, todos los servidores pasan por un proceso de endurecimiento en el que todo se bloquea y se pone en la lista blanca de conexiones según sea necesario. Lo mismo ocurre con las bases de datos. Un servidor que accede a una base de datos solo puede ver lo que necesita para realizar su trabajo. Las actualizaciones solo se realizan desde un servidor interno y no directamente desde Internet, lo que impide que un servidor comprometido abra conexiones externas. Los usuarios nunca se registran con credenciales de administrador y solo pueden utilizar aplicaciones de la lista blanca. Los usuarios finales, los servidores Windows y los servidores Linux están en directorios separados, de modo que, si uno de ellos se ve comprometido, no lo esté todo el entorno.
"Hace siete años, empecé a aplicar principios del tipo de confianza cero y así es como estamos diseñados", anota Webb. "Un principio de confianza cero consiste realmente en gestionar el dispositivo solo en lo que se confía y solo en lo que se supone que es su función. Todo lo demás no es de confianza. Todo lo demás debe bloquearse. Si algo intenta violar eso, debería ser una gran alarma roja: ¿Por qué este sistema intenta hacer algo que yo no quería que hiciera?"
De hecho, FireEye, la empresa que descubrió y denunció el ataque de SolarWinds después de que su propia red fuera atacada, descubrió la intrusión porque los atacantes añadieron un dispositivo secundario a la cuenta de uno de sus empleados para saltarse la autenticación multifactor. Esto fue marcado como sospechoso y el empleado fue interrogado.
"Esa es probablemente la respuesta: confianza cero y gestión del comportamiento, y si algo viola su confianza cero, tiene que investigarlo", añade Webb.
¿Los ataques a la cadena de suministro de software deberían llevar a una revisión más detallada de los vendedores y proveedores?
Al elegir sus soluciones o servicios de software, algunas organizaciones podrían tener en cuenta las prácticas de gestión de la vulnerabilidad de un proveedor: ¿Cómo gestionan los informes de vulnerabilidad externos? ¿Con qué frecuencia publican actualizaciones de seguridad? ¿Cómo son sus comunicaciones de seguridad? ¿Publican avisos detallados? ¿Disponen de un ciclo de vida de desarrollo de software seguro destinado a reducir el número de vulnerabilidades? Algunas empresas también pueden pedir información sobre las pruebas de penetración y otros informes de cumplimiento de la seguridad.
Sin embargo, con ataques como el de SolarWinds, las organizaciones de desarrollo de software deben ir más allá e invertir en asegurar mejor su propia infraestructura y entorno de desarrollo, ya que cada vez son más un objetivo para los atacantes y pueden ser ellos mismos víctimas de ataques a la cadena de suministro de software a través de las herramientas y componentes de software que utilizan. También deben tener en cuenta los riesgos que suponen para los usuarios durante la fase de diseño de sus aplicaciones y tratar de limitar el impacto que puede tener un compromiso limitando los privilegios y el acceso que las aplicaciones necesitan para realizar su función.
"Nuestra responsabilidad va a ser presionar a la cadena de suministro: tiene que intensificar su juego. Va a tener que poner estas cosas en su sitio. Va a tener que probar y auditar su propio código, no de forma anual, pero probablemente mensual o antes de cualquier despliegue", indica Webb. "Los líderes empresariales tienen que presionar a los de TI para asegurarse de que solo están tratando/lidiando con proveedores de buena reputación y con personas que han dado el siguiente paso en la protección del código que su organización está utilizando".
Según Larry Schwarberg, vicepresidente de seguridad de la información de la Universidad de Phoenix, un primer paso en esa dirección para muchas organizaciones será identificar a todos sus proveedores de software y SaaS, y tener un proceso de incorporación claramente definido para las nuevas aplicaciones y servicios. Muchas organizaciones tienen un problema de TI en la sombra en el que diferentes equipos compran y despliegan activos de hardware y software sin que esos proveedores sean investigados por el equipo de seguridad. Esto supone un grave problema para bloquear las aplicaciones y aplicar el acceso de mínimo privilegio.
Según Schwarberg, a la hora de renovar los contratos y las suscripciones, las organizaciones deberían plantear a sus proveedores de software y servicios esas preguntas más profundas sobre el pentesting y sobre cómo están probando su software y limitando el impacto potencial.
Llevar a cabo evaluaciones exhaustivas de los proveedores de software desde la perspectiva de la seguridad de la cadena de suministro no es fácil, y requiere recursos y experiencia que muchas empresas podrían no tener, pero según Raeder, las organizaciones de auditoría probablemente usarán este evento como un catalizador para crear más capacidad en torno a esto.
"Creo que muchas organizaciones podrían hacer un cuestionario cibernético hoy y quién sabe qué se hará con esos resultados cuando los obtengan", sostiene Raeder. "Puede que se revisen o que pasen a un sistema de puntuación. En ambos lados de la ecuación, se trata de una oportunidad para mejorar el análisis de riesgos de la cadena de suministro. Las organizaciones tienen que mirar sus cadenas de suministro y averiguar quiénes son sus proveedores más críticos a los que tienen que dedicar más tiempo para analizar el riesgo y los proveedores tienen que ser capaces y estar preparados para responder a esas preguntas cibernéticas de una manera eficaz para sus clientes".
¿Este tipo de ataque solo lo utilizan los grupos APT y los estados-nación?
Muchos de los ataques a la cadena de suministro de software más destacados hasta la fecha se han atribuido a grupos APT con presuntos vínculos con gobiernos, como los ataques a SolarWinds y ShadowPad. Según un análisis del Atlantic Council de 115 ataques a la cadena de suministro de software y vulnerabilidades reveladas en los últimos 10 años, al menos 27 de ellos fueron patrocinados por Estados.
Sin embargo, los conocimientos y recursos necesarios para llevar a cabo ataques a la cadena de suministro de software no se limitan necesariamente a los grupos tradicionales de espionaje cibernético. A lo largo de los años, se han producido varios ataques con componentes de código abierto backdoored o versiones backdoored de aplicaciones legítimas realizadas desde servidores de descarga comprometidos que tenían una motivación económica y que probablemente fueron lanzados por delincuentes cibernéticos. Incluso hubo un caso relacionado con el ransomware.
En los últimos años, muchas bandas de ransomware han adoptado técnicas sofisticadas que en el pasado solo se veían en los grupos APT, incluyendo la inyección de procesos en la memoria, el reconocimiento profundo, el hacking manual y el movimiento lateral utilizando herramientas de administración de sistemas y el malware sin archivos. Algunos grupos de ransomware también han apuntado a los proveedores de servicios gestionados (MSPs) con ataques similares en concepto a los de la cadena de suministro de software: apuntan a organizaciones que pueden proporcionar acceso privilegiado a otras empresas debido a su relación comercial.
Un número cada vez mayor de grupos de mercenarios cibernéticos venden servicios de hacking tanto a gobiernos como a entidades privadas en la clandestinidad cibercriminal. A medida que más grupos comienzan a adoptar este vector de ataque, todas las organizaciones, grandes o pequeñas, independientemente de la industria en la que operan, podrían convertirse en el objetivo de un ataque de estilo APT a través de un compromiso de la cadena de suministro de software.
Basado en el artículo de Lucian Constantin (CSO) y editado por CIO Perú