En diciembre del 2020 una noticia nos cimbró fuertemente a nivel mundial: el director general o CEO de Fire Eye, Kevin Mandian, anunciaba al mundo que ellos -una de las empresas líderes en ciberseguridad y con uno de los equipos de especialistas más avanzados en manejo de cíberincidentes- habían sido víctimas de un hackeo, y los atacantes habían estado dentro de sus redes y sistemas por… varias semanas.

Desde el primer anuncio, Fire Eye compartió globalmente la información de los ataques, incluyendo los llamados “indicadores de compromiso” (IOC), de los que hablaremos más adelante. Curiosamente, en las siguientes semanas el precio de la acción de Fire-Eye subió a un nivel que no había logrado en los últimos 6 años. Muchos analistas lo atribuyen a que Kevin Mandian hizo un excelente manejo de esta crisis para darle la vuelta al problema: de ser una empresa de ciberseguridad que fue hackeada, a ser la primera empresa en el mundo en descubrir e informar sobre el que se ha denominado “el mayor ciberataque en la historia”.

En las siguientes semanas fueron apareciendo diversas noticias y análisis para entender mejor la situación. Supimos que el principal vector de ataque, parece que no fue el único, fue a través de insertar código malicioso en un software muy popular para gestionar redes. Concretamente, los atacantes fueron capaces, desde fines de 2019, de insertar código malicioso (una puerta trasera o back door) en las versiones Orion de SolarWinds. De esta forma 18 mil empresas que descargaron legalmente este software están teóricamente vulnerables, y así ha ido apareciendo la lista de víctimas, incluyendo empresas tan importantes como Microsoft, Cisco o Intel, y agencias del gobierno americano como los departamentos de Comercio, del Tesoro y de Energía. En la última cuenta a febrero de 2021 había más de 100 organizaciones privadas y 9 públicas.

Los investigadores, como es normal, le pusieron nombre al ataque: Sunburst o Solorigate,  empezaron a hablar de que fue un ataque a la cadena de suministro (supply chain) y surgieron muchas preguntas: ¿es un nuevo tipo de ataque?, ¿infectaron también a otros paquetes de software?, ¿qué instituciones han resultado infectadas y, sobre todo, en cuáles se ha robado información? En mi empresa tenemos SolarWinds, ¿estoy en problemas?, ¿cómo sé si en mi empresa existe otro paquete de software que está infectado? y, en todo caso, ¿qué debo hacer?

Aunque todas las preguntas anteriores son relevantes, las dos últimas son, en mi opinión, las más importantes. Por una parte, si usted utiliza SolarWinds póngase en contacto con su proveedor y visite la página del fabricante. Con estas dos acciones podrá tener un panorama claro de lo que tiene qué hacer. También puede visitar las páginas Web de Fire Eye y de Microsoft,  entre otras fuentes calificadas, en las que podrá encontrar mucha información de cómo detectar si están infectados sus sistemas y qué acciones tomar.

Dedicaremos el resto de este artículo, entonces, a apoyarlo en contestar la última pregunta: ¿cómo puedo saber si estoy siendo víctima de un ataque de cadena de suministro y qué puedo hacer?

Muchas personas escucharon por primera vez el término “ataque a la cadena de suministro” y supusieron que era un nuevo tipo de ataque. Eso no es totalmente correcto, ya se había visto antes, pero varios elementos que se utilizaron en esta ocasión sí son verdaderamente novedosos y avanzados, por lo que es muy probable que el atacante sea un país “hostil” (técnicamente llamado estado-nación). Varios investigadores han señalado a Rusia como el responsable, pero, como siempre ocurre, el gobierno de ese país niega los cargos.

Antes de contestar qué podemos hacer para detectar y prevenir este tipo de ataques, entendamos un poco más sobre su modus operandi.

Un poco de historia antigua sobre ataques en la cadena de suministro

Voy a mencionarles un par de ejemplos de la historia y mitología antiguas para intentar demostrar que los ataques a la cadena de suministro tienen miles de años de existir.

Una reina egipcia que está tratando de esconderse de su esposo (y a la vez hermano) para evitar la muerte, necesita ver urgentemente al César para jugarse su última carta: convencerlo de que la restaure en el trono y, de paso, ponga en su lugar a su hermano. Y se le ocurre esconderse en una alfombra enrollada, que una de sus sirvientas llevará al palacio donde se encuentra el César. Seguramente ya saben que estoy hablando de Cleopatra y la famosa historia de la alfombra que, de acuerdo a los historiadores, es muy factible, de haber sido cierta. Lo que sí es un hecho es que Cleopatra fue capaz de recuperar su reino y pasó a la historia como una mujer sumamente inteligente y preparada, además de muy bella.

Un tocayo mío de la antigüedad fue el famoso Ulises de la Ilíada y la Odisea (bueno, el nombre original era “Odysseus”, pero con el tiempo y un poco de transliteraciones, quedó en español como Ulises). Aparece en la Ilíada como uno de los reyes aqueos que luchaban para recuperar a la hermosa Helena que había sido raptada por París y que era retenida en Troya. Homero nos cuenta en la Ilíada que fue a Ulises a quién se le ocurrió la idea de crear en madera un caballo enorme que los aqueos “regalarían” a los troyanos, como un presente por su aparente derrota. El desenlace ya lo sabemos.

Quizás es menos conocido otro episodio de Ulises que el mismo Homero nos relata en su otro libro, la Odisea. Me refiero a la historia en la cual aquel y sus hombres son retenidos en una cueva del gigante cíclope Polifemo. Al tratar de escapar, logran dejar ciego al cíclope, pero este, enojado, decide bloquear con una enorme roca el acceso a la cueva y solo dejar salir a sus ovejas, tentándolas con sus enormes manos (pues ya estaba ciego y no veía quién intentaba salir). En una variante de lo que ya había hecho con el Caballo de Troya, Ulises instruye a sus hombres para que se amarren al estómago de las ovejas y puedan salir sin ser detectados por el tacto del gigante.

¿Pero qué tienen que ver estas historias con lo que sucedió con SolarWinds y los ataques de cadena de suministro? Resulta que, en todos los casos, el modus operandi es el mismo: la víctima permite el paso de “algo” que no debería permitir (la alfombra, una versión de software, un caballo de madera o una oveja). En otras palabras, la víctima lo permitió sin darse cuenta del verdadero contenido del “paquete” y, por tanto, sin saber las verdaderas consecuencias.

Si pensamos en la alfombra de Cleopatra, en el Caballo de Troya o en las ovejas del cíclope, la solución parece simple: tengamos más cuidado con “el paquete” que permitimos entrar o salir de nuestro sistema.

En otras palabras, ni los guardias egipcios pensaban que dentro de la alfombra venía Cleopatra (un “paquete prohibido”) ni Polifemo, el cíclope, pensó que abajo del estómago de las ovejas estaban escondidos Ulises y sus soldados (otros “paquetes” que tenían prohibida la salida) ni los troyanos pensaron en que adentro del caballo venían guerreros aqueos (otro caso de paquetes peligrosos) ni Microsoft, Fire Eye y 18 mil clientes de SolarWinds pensaron que la versión Orion que estaban descargando del sitio oficial traía “gratis” una puerta trasera para el ataque Solarigate (por supuesto estoy siendo irónico).

Pero también, en todos los casos, no es nada sencillo identificar el paquete y frenar su acceso. Centremos nuestra atención en un ciberataque de cadena de suministro del cual queremos proteger nuestros sistemas informáticos. En estos casos el reto tiene, al menos, dos grandes dificultades:

  1. De todas las “cosas” que cruzan nuestros sistemas, ¿de cuáles debemos cuidarnos?
  2. ¿Cómo identificar esas “cosas” para no dejarlas entrar o, si ya están adentro, sacarlas?

No podemos decir que Fire-Eye, Microsoft o varias de las agencias del gobierno americano que fueron vulneradas no hayan tenido diversos controles y realizado inversiones importantes para contar con una ciberseguridad madura. De cualquier forma, el ataque prosperó y los atacantes (¿el gobierno ruso?) estuvieron dentro de esos ambientes por varios meses. Entonces, ¿qué podemos hacer las organizaciones que no tenemos ese tamaño y no es factible invertir las cantidades que ellos han invertido?

Sin tratar de ofender a nadie, voy a enumerar algunas medidas que podemos tomar, tanto en forma correctiva, es decir, cuando nos enteramos de una organización importante que ha sido vulnerada, como en forma preventiva, para lo cual expondré algunos controles que podríamos estar olvidando y que nos ayudan a mejorar nuestra postura de ciberseguridad.

Reaccionar más rápido (controles correctivos)

A nivel mundial, desde hace algunos años empezó a cambiar el enfoque en la estrategia de ciberseguridad de las organizaciones. Pasamos de proteger solamente (e implementar fundamentalmente controles preventivos) a repartir los esfuerzos de protección con los de detección, respuesta y evolución de nuestra ciberseguridad. En este sentido, y dado el nivel creciente de sofisticación de los ataques y los atacantes, es difícil pensar que nuestras medidas de ciberdefensa van a ser suficientes, pero también es lógico, y válido, pensar en que es altamente probable que, si surgen nuevos ataques, se den primero en otras organizaciones y no en la nuestra.

Lo anterior nos lleva a recomendar tres líneas de acción muy concretas:

  1. Revisar continuamente los foros especializados para obtener información sobre nuevos ataques.
  2. Contratar una o más empresas que nos brinden, en forma continua, información de inteligencia de amenazas (intelligence feeds). Es decir, información de nuevos ataques en formas más digeribles y lista para que actuemos.

Si la información de un nuevo ataque nos llega junto con los llamados IOC (de las siglas en inglés de Indicators of Compromise, indicadores de compromiso) y con recomendaciones específicas de qué tipo de filtros hay que implementar en firewalls y preventores de intrusos (IPS), es mucho más probable que ejecutemos rápidamente esas acciones de protección.

  1. Ligar las dos actividades anteriores con el proceso de control de cambios y de gestión de parches y actualizaciones. De nada sirve entender la forma en que trabaja un nuevo ciberataque si no actualizamos, rápida y ordenadamente, nuestros sistemas para hacernos menos vulnerables. Por ejemplo, ¿estamos seguros de que en nuestros ambientes no hay versiones “viejitas” y vulnerables de SMB, Windows, Google Chrome o Microsoft Internet Explorer? Asociados con estos programas y protocolos, existen un sinfín de ataques que explotan vulnerabilidades conocidas en los mismos. ¿La solución?: Actualizar a las últimas versiones[1].

Prevenir y detectar (en la medida de lo posible) los ataques de cadena de suministro

Muchas de las medidas de seguridad que menciono a continuación debieran ser ya parte de los controles de nuestro programa de ciberseguridad; por desgracia no son tan comunes como debieran. La lista de controles de seguridad que sugiero no pretende ser exhaustiva, más bien me he enfocado en varias medidas que considero muy útiles y -por desgracia- poco comunes.

  • Mayor conciencia de los altos ejecutivos. Ellos deben involucrarse activamente en entender los distintos ciberriesgos y el impacto que pueden causar al negocio si se materializan. Tienen que determinar el “apetito de riesgo” que tendrá su organización, los controles que será necesario implementar (en las distintas dimensiones y a lo largo de las diferentes áreas de la empresa), los costos e inversiones requeridas y, finalmente, el nivel de riesgo residual que tendrán. Si ya lo están haciendo, de verdad los felicito. Si no, la alta dirección debe entender que no están siendo diligentes y por ello han ido apareciendo, en distintos países, regulaciones en las que las penalizaciones también los incluyen.
  • Hacer análisis de riesgos con un enfoque moderno. En mi opinión, es necesario incorporar prácticas que nos permitan identificar las distintas cadenas de aliados y proveedores que tenemos y establecer mecanismos viables para gestionar las vulnerabilidades en toda la cadena de aliados y proveedores, así como incorporar a los distintos involucrados en la cadena de responsabilidades. También debemos diagnosticar en profundidad qué prácticas de desarrollo de software seguro ya están implementadas y cuáles faltan (véase más adelante).
  • Evolucionar hacia un desarrollo de software seguro. Si bien muchas empresas medianas y grandes han incorporado algunos controles para desarrollar software seguro (típicamente el uso de herramientas de análisis automatizado de vulnerabilidades, tanto estáticas como dinámicas), falta mucho para que las medidas abarquen el ciclo completo de desarrollo: desde el diseño, programación y pruebas hasta la liberación.

No importa si usa métodos tradicionales en cascada, o si ha migrado a modelos ágiles e incluso a DevOps, es necesario incorporar diversos controles para lograr tener un desarrollo seguro. Mencionaré algunos ejemplos:

  • Realizar modelado de amenazas y desarrollo de casos de abuso en la etapa de diseño de la aplicación.
  • Establecimiento de políticas y criterios claros y por escrito para contar con una codificación segura.
  • Uso de herramientas para detectar vulnerabilidades en las librerías de terceros.
  • Realización de revisiones manuales de las aplicaciones y módulos críticos, para detectar vulnerabilidades que -todavía hoy en día- no logran detectar las herramientas automatizadas.
  • Incorporar un conjunto de pruebas de seguridad completas, incluyendo probar los casos de abuso, el uso de herramientas de fuzzing, además de realizar pruebas de ataques volumétricos y pruebas profundas de hacking ético, que incluyan escenarios completos de ataque (a veces llamado red teaming) para probar las aplicaciones y todo su ambiente operativo.
  • Inventariar y probar el software que adquirimos. Esta labor puede ser titánica, por lo que recomendamos empezar con los más críticos y acelerar la siguiente recomendación.
  • Habilitar el control aplicativo y por usuario que permiten los firewalls de nueva generación. De acuerdo con lo que he observado en Latinoamérica, muchos usuarios no explotan todas las funcionalidades que tienen los firewalls de nueva generación, incluyendo la granularidad para controlar los flujos aplicativos que cruzan nuestras redes y salen a Internet. Es urgente que lo hagan.
  • Incorporar mayores exigencias a nuestros proveedores de software. Sean paquetes comerciales o sistemas desarrollados a la medida por terceros, es un hecho que la mayoría de las organizaciones no han sabido exigir lo suficiente a sus proveedores. Empecemos a negociar la compra o actualización del software, sujeto a que nos brinden mayor información del tipo de controles que están implementando en su proceso, continuemos entonces poniendo cláusulas de responsabilidad y penalizaciones por incumplimiento. Si son desarrolladores de software a la medida, incluyamos el derecho a auditarlos. Este camino no será sencillo, pero debemos exigir más, sumarnos a otras empresas usuarias del producto y presionar a los proveedores.
  • Habilitar servicios de detección de anomalías y sondas de engaño. Ayuda mucho el incorporar tecnologías de analítica del comportamiento de usuarios y entidades (UBA y UEBA: User Behavior Analytics y User and Entity Behavior Analytics), así como sondas que simulan ser un equipo cualquiera y que pueden engañar a un atacante (genéricamente se les ha llamado tecnologías de engaño o deception), pero siempre es necesario que un especialista, ya sea de la organización o de un proveedor confiable, realice el monitoreo para detectar posibles anomalías, investigar y, si resulta un incidente, disparar el proceso respectivo.
  • Evolucionar nuestro sistema de manejo y respuesta a incidentes. Históricamente las empresas han activado el proceso de manejo de incidentes cuando existe una alarma clara originada de alguna consola o bitácora. Pero en la evolución de este proceso deben considerar que el disparador puede ser un equipo de “caza de amenazas” (threat hunting), que está revisando la infraestructura buscando indicadores de compromiso (IOC) y señales de que la organización pudo haber sido penetrada y no nos hemos dado cuenta.

Por último, cada vez es más necesario estar segmentando el tráfico de las aplicaciones e, idealmente, lograr que cada componente de nuestro sistema (sea una rutina o microservicio aplicativo del software, un dispositivo de hardware o una persona) se autentique con todos aquellos con los que requiere tener comunicación, y que todas las comunicaciones sean cifradas. En otras palabras, que nadie confíe en nadie.

En palabras sencillas, requerimos ir evolucionando nuestros ambientes informáticos hacia una arquitectura de “cero confianza” (zero trust). Este gran objetivo no será ni tan sencillo ni tan barato, pero tal parece que será necesario en casi todas las organizaciones.

Espero les hayan servido las ideas y consejos de este artículo. La ciberseguridad se ve muy retadora, pero no menos emocionante que en los últimos 25 años.

[email protected]

[1] Es curioso y preocupante darnos cuenta de que, por ejemplo, hay empresas importantes que siguen teniendo algunos servidores -o incluso cajeros automáticos (ATM)- con versiones antiguas de Windows (Windows 7 e incluso Windows XP).