Casos de estudio

 La ciberseguridad no se trata únicamente de resolver problemas cuando ya ocurrieron. En realidad, su objetivo principal es evitar que esos problemas sucedan. La ciberseguridad preventiva es el conjunto de prácticas, tecnologías y cultura organización que busca identificar vulnerabilidades antes de que un atacante las aproveche.

A diferencia del modelo reactivo tradicional, la ciberseguridad preventiva cambia el enfoque. Nos lleva del "apagar incendios" al "diseño de entornos resistentes". Esto implica auditorias continuas, escaneo de vulnerabilidades, actualizaciones periódicas, entrenamiento constante del personal y la implementación de controles de acceso y segmentación de red.

Invertir en prevención no es un gasto, es una estrategia. Según reportes de la industria, el costo promedio de una brecha de datos en 2024 superó los 4.8 millones de dólares. Las organizaciones que aplican medidas preventivas logran reducir no solo el riesgo de un ataque exitoso, sino también el impacto económico, legal y reputacional en caso de que ocurra.

A través de casos de estudio de empresas en sectores como finanzas, salud, retail y tecnología, este artículo demuestra cómo la inversión en medidas preventivas genera resultados tangibles. Analizaremos las estrategias que implementaron, los riesgos que lograron frenar y los principios que cualquier organización puede replicar sin importar su tamaño.

Imagina dos empresas. Las dos son blanco del mismo grupo criminal y reciben el mismo tipo de ataque de phishing. Una termina en los titulares de las noticias, pagando un alto precio por un rescate y notificando la fuga de datos de sus clientes. La otra ni siquiera se alcanza a enterar del intento, porque sus defensas lo bloquearon automáticamente.

Entonces, ¿cuál fue la diferencia?

La respuesta está en la prevención. En los siguientes casos veremos cómo organizaciones reales aplicaron ciberseguridad preventiva y lograron evitar incidentes que pudieron haber sido catastróficos.

Algunos casos de estudio: 

1. El caso SolarWinds: Cuando la amenaza vino de adentro

Imagina por un momento que eres el responsable de seguridad de una gran corporación. Has hecho todo bien. Tienes firewall, doble factor de autenticación, capacitas a tu equipo contra el phishing y solo trabajas con proveedores reconocidos a nivel mundial. Un día, tu plataforma de monitoreo de red, SolarWinds Orion, te avisa que hay una nueva actualización disponible. Es una herramienta crítica, la que te dice si algo anda mal en tu infraestructura, así que por supuesto le das clic a actualizar. Es lo responsable, es lo que se supone que debes hacer para estar protegido. Lo que no sabías es que acababas de abrirle la puerta principal a tu atacante.

Eso fue exactamente lo que vivieron más de dieciocho mil organizaciones en todo el mundo entre marzo y junio de 2020. Entre ellas estaban Microsoft, Intel, FireEye, el Pentágono, el Departamento de Seguridad Nacional de Estados Unidos y cientos de empresas del Fortune 500. Todas instalaron una actualización que venía firmada digitalmente, que parecía completamente legítima, pero que estaba envenenada desde su origen.

Lo que ocurrió detrás fue una de las operaciones más sofisticadas y pacientes que se han registrado. Un grupo de ciberespionaje altamente avanzado, atribuido por la comunidad de inteligencia a APT29, también conocido como Cozy Bear y vinculado al Servicio de Inteligencia Exterior de Rusia, no atacó directamente a sus víctimas finales. Entendieron que era mucho más eficiente atacar el eslabón más débil y más confiable a la vez: la cadena de suministro. Se infiltraron durante meses en el entorno de desarrollo de SolarWinds y lograron insertar un código malicioso que luego fue bautizado como SUNBURST dentro del código fuente de Orion. Cuando SolarWinds compiló su producto y lo distribuyó como una actualización oficial, estaba distribuyendo, sin saberlo, la puerta trasera de sus enemigos.

Este malware era una obra de ingeniería pensada para ser invisible. Una vez instalado, no hacía nada durante casi dos semanas. Dormía, para no levantar ninguna alarma y para desvincularse en el tiempo de la actualización que lo trajo. Después de ese periodo, comenzaba a operar con una sutileza extrema. Se comunicaba con sus servidores de comando y control imitando el tráfico legítimo de la propia plataforma de SolarWinds, robaba credenciales, leía correos y se movía lateralmente por la red. Para cualquier sistema de seguridad tradicional, parecía un usuario más con privilegios legítimos, no una amenaza. Por eso los antivirus basados en firmas nunca lo vieron. Era un archivo firmado por un proveedor de confianza haciendo lo que se suponía que debía hacer.

El descubrimiento fue casi accidental y eso es lo más inquietante. No fue SolarWinds quien se dio cuenta. Fue FireEye, una de las empresas de ciberseguridad más respetadas del mundo, cuando notó que alguien había robado sus propias herramientas de hacking internas. Al investigar su propia brecha, encontraron el hilo que los llevó hasta la actualización de Orion. Si FireEye no hubiera sido atacada y no hubiera tenido la madurez para investigarse a sí misma con total transparencia, este ataque podría haber seguido activo durante años.

Y aquí es donde el caso SolarWinds se convierte en una lección fundamental para la ciberseguridad preventiva. Nos obligó a entender que el perímetro ya no existe y que la confianza es nuestra mayor vulnerabilidad. Ya no podemos operar bajo la idea de que lo que viene de adentro o de un proveedor grande es seguro por defecto. Tenemos que adoptar una mentalidad de confianza cero incluso con quienes nos protegen. Eso significa cuestionar cada actualización, verificar cada integración y preguntarnos si realmente nuestra herramienta de monitoreo necesita tener acceso a nuestros correos de Office 365 y a nuestros controladores de dominio.

También nos enseñó que debemos dejar de buscar solo archivos maliciosos y empezar a buscar comportamientos maliciosos. La seguridad preventiva moderna no puede depender solo de si un archivo es conocido o no. Necesita entender el contexto. ¿Es normal que una herramienta de monitoreo de infraestructura de repente empiece a generar tráfico hacia un servidor externo en un país donde no operamos? ¿Es normal que cree procesos paralelos para robar tokens de autenticación? Esa es la detección que importa y que solo se logra con soluciones de monitoreo de comportamiento como EDR y XDR y con un equipo que sepa leer esas anomalías.

Finalmente, SolarWinds nos dejó claro que la segmentación de la red y tener un plan de respuesta para incidentes de terceros ya no es opcional. En muchos de los casos comprometidos, una vez que los atacantes entraron por Orion, el resto fue muy fácil porque todo estaba interconectado. Una red plana es una autopista para un atacante. Y cuando tu proveedor más crítico es comprometido, no puedes improvisar. Necesitas saber de antemano cómo aislarlo, a quién llamar, qué credenciales rotar y cómo seguir operando. Porque en la ciberseguridad actual no estás defendiendo solo tu empresa, estás defendiendo toda la cadena de confianza de la que formas parte.

2.El caso Kaseya VSA: El efecto dominó que apagó 1.500 empresas en un fin de semana

Si SolarWinds nos enseñó que podían espiarnos a través de nuestro proveedor de confianza, el caso Kaseya nos enseñó que podían secuestrar a miles de empresas a la vez usando exactamente el mismo principio. Ocurrió el 2 de julio de 2021, justo antes del fin de semana festivo del 4 de julio en Estados Unidos. No fue una fecha elegida al azar. Los atacantes saben que los viernes festivos son el momento perfecto porque los equipos de seguridad trabajan con personal mínimo y el tiempo de reacción es mucho más lento.

La víctima inicial no fue una empresa cualquiera, fue Kaseya, una compañía que provee una herramienta llamada VSA que es utilizada por los Proveedores de Servicios Administrados, los MSP. Para entender la gravedad, hay que entender qué hace un MSP. Un MSP es la empresa de TI externa que le gestiona todo a decenas o cientos de pymes que no tienen un departamento de sistemas propio. Con Kaseya VSA, ese MSP puede desde un solo panel central instalar parches, ejecutar scripts, actualizar antivirus y tomar control remoto de todos los computadores de todos sus clientes. Es una concentración absoluta de poder y de confianza.

El grupo de ciberdelincuentes REvil, un grupo de ransomware-as-a-service con origen en Rusia, descubrió varias vulnerabilidades de día cero en la versión local de Kaseya VSA. Eran fallas críticas de autenticación y de inyección de código que les permitían entrar al servidor VSA sin credenciales válidas. Una vez dentro, no necesitaron crear un malware complejo desde cero. Simplemente usaron la funcionalidad más poderosa y legítima de la propia plataforma: el sistema de distribución de actualizaciones y scripts. Desde el propio servidor de Kaseya, enviaron lo que parecía ser una actualización oficial a todos los endpoints que ese servidor gestionaba. Esa actualización era en realidad el ransomware REvil, también conocido como Sodinokibi.

El impacto fue inmediato y brutal porque era un ataque en cascada. Los MSPs fueron los primeros en ser comprometidos, pero las verdaderas víctimas fueron sus clientes. Bastó con comprometer a menos de 60 MSPs para que más de 1.500 empresas en 17 países quedaran cifradas en cuestión de horas. No eran solo empresas de tecnología. La cadena de supermercados Coop en Suecia tuvo que cerrar casi 800 tiendas porque sus cajas registradoras dejaron de funcionar. Escuelas en Nueva Zelanda, consultorios médicos, ferreterías y alcaldías en Estados Unidos se encontraron con una pantalla roja que les exigía 45.000 dólares por máquina o 70 millones de dólares por una llave universal para todos. Muchas de esas empresas ni siquiera sabían qué era Kaseya, pero su proveedor sí lo usaba, y eso fue suficiente para que cayeran.

Este caso es el ejemplo perfecto de lo que pasa cuando fallan las medidas preventivas más básicas en la cadena de suministro. Kaseya estaba en proceso de parchear esas vulnerabilidades cuando fue atacada, pero no tenía un programa de auditoría de seguridad externa continuo ni un control estricto sobre cómo su plataforma ejecutaba código con privilegios de administrador absoluto. Y del lado de los MSPs, el error fue confiar ciegamente. Permitieron que cualquier tarea enviada desde el servidor VSA se ejecutara automáticamente en todos sus clientes sin una validación manual, sin un sistema de doble aprobación y sin segmentar el acceso. Si un MSP hubiera tenido implementado el principio de privilegio mínimo, donde el servidor VSA no tiene acceso directo a toda la red del cliente, o si hubiera tenido copias de seguridad inmutables y desconectadas de la red, el ataque se hubiera contenido. Muchas empresas que tenían sus backups conectados a la misma red los perdieron también porque el ransomware los buscó y los cifró primero.

La lección que Kaseya nos deja para la ciberseguridad preventiva es aún más dura que la de SolarWinds. Ya no basta con proteger tu empresa, tienes que auditar la seguridad de quien te protege. Si trabajas con un MSP o con cualquier herramienta de gestión remota, debes exigirle autenticación multifactor obligatoria en todas sus consolas, que sus interfaces administrativas estén detrás de una VPN, que exista una lista blanca de direcciones IP que pueden comunicarse con la herramienta y, sobre todo, que cualquier despliegue masivo de software requiera una aprobación humana. Porque cuando un atacante compromete a tu proveedor de confianza, no necesita hackearte a ti, ya tiene las llaves de tu casa.

3.El caso Equifax: Cómo olvidar un parche le costó 700 millones de dólares a una de las empresas más poderosas del mundo

Si los casos de SolarWinds y Kaseya nos enseñaron que un atacante puede llegar a ti a través de tu proveedor más confiable, el caso Equifax es distinto y mucho más incómodo de contar. Aquí no hubo una operación de espionaje de un estado-nación que tardó meses infiltrándose en la cadena de desarrollo de un software. Aquí no hubo una vulnerabilidad desconocida ni un exploit de día cero que nadie había visto antes. Hubo algo mucho más humano, mucho más cotidiano y por eso mucho más peligroso: alguien simplemente no hizo su trabajo. Alguien no actualizó.

Para entender la magnitud de lo que pasó hay que entender primero qué es Equifax. No es una tienda, no es una red social, no es un banco al que puedes decidir no ir. Equifax es una de las tres agencias de crédito más grandes de Estados Unidos y opera en más de 24 países, incluido Colombia. Su negocio es recolectar y custodiar la vida financiera de las personas. Si alguna vez has pedido un crédito, una tarjeta o has sacado un plan de celular a cuotas, es casi seguro que Equifax tiene un archivo sobre ti. En ese archivo están tus nombres completos, tu dirección actual y tus direcciones anteriores, tu fecha de nacimiento, tu número de Seguro Social, que en Estados Unidos equivale a tu documento de identidad definitivo, y en muchos casos el número completo de tus tarjetas de crédito. Es literalmente la llave de tu identidad. Por eso se suponía que Equifax debía ser una fortaleza, un ejemplo de seguridad.

Todo empezó el 7 de marzo de 2017. Ese día, la Apache Software Foundation, que mantiene un framework de código abierto muy usado llamado Apache Struts 2, publicó un aviso de seguridad crítico. Habían descubierto una vulnerabilidad extremadamente grave, registrada como CVE-2017-5638. Esta falla permitía a cualquier persona en internet ejecutar comandos en el servidor simplemente enviando una petición web maliciosa con un tipo de archivo manipulado. No necesitaba usuario ni contraseña. Era ejecución remota de código en su forma más pura y peligrosa. Apache, de forma responsable, publicó el parche ese mismo día. La industria de la seguridad entró en alerta máxima. Al día siguiente, el 8 de marzo, el US-CERT, que es el centro de respuesta a emergencias del gobierno de Estados Unidos, envió un boletín a todas las empresas críticas del país diciendo que esta falla debía ser corregida de forma inmediata. En cuestión de horas, ya había código de explotación público circulando en foros de hackers. Cualquiera podía copiarlo y pegarlo.

Equifax recibió esa alerta. Internamente, el equipo de seguridad hizo lo que se supone que debe hacer en estos casos: reenvió la notificación a los administradores de aplicaciones y solicitó que se identificaran todos los sistemas que usaban Apache Struts. El 9 de marzo se envió la orden de parchear. El 15 de marzo, el equipo de seguridad hizo un escaneo con sus herramientas automáticas para confirmar que ya no quedaban sistemas vulnerables. El resultado del escaneo fue tranquilizador: no se encontró nada. El problema es que ese escaneo no servía. No estaba mirando en el lugar correcto. Equifax, como muchas grandes corporaciones con décadas de historia, tenía una infraestructura fragmentada, con sistemas nuevos y sistemas heredados que nadie quería tocar porque eran críticos y frágiles. Uno de esos sistemas era el portal de disputas de consumidores, conocido internamente como ACIS. Era una aplicación web a través de la cual los usuarios podían disputar errores en su informe de crédito. Esa aplicación había sido construida originalmente en los años setenta para cumplir con una regulación federal y había sido migrada y parcheada superficialmente durante décadas. Estaba funcionando sobre una versión vulnerable de Apache Struts y nadie la había incluido en el inventario de activos expuestos a internet. Así que el escaneo nunca la vio.

El 13 de mayo de 2017, exactamente dos meses después de que el parche estuviera disponible, un grupo de atacantes, que hasta hoy no ha sido identificado públicamente con total certeza, encontró ese portal olvidado. Bastó con una sola petición web maliciosa para entrar. No hubo una batalla épica de firewalls. Simplemente entraron. Una vez dentro, su primer movimiento fue asegurar su permanencia. Instalaron varias webshells, que son pequeños scripts maliciosos que funcionan como puertas traseras invisibles y que les permiten volver a conectarse al servidor aunque se reinicie o se cambie una contraseña. A partir de ese momento, el servidor dejó de pertenecer a Equifax y pasó a pertenecer a ellos.

Lo que siguió fueron 76 días de silencio absoluto. Desde el 13 de mayo hasta el 29 de julio, los atacantes exploraron la red interna con una calma y una paciencia que solo se puede tener cuando nadie te está mirando. Y nadie los estaba mirando por una razón que parece increíble para una empresa de ese tamaño: el dispositivo de seguridad que debía inspeccionar el tráfico de ese portal tenía el certificado digital vencido desde hacía 19 meses. Es un equipo que descifra el tráfico cifrado para buscar actividad sospechosa. Si el certificado está vencido, simplemente deja de inspeccionar y deja pasar todo. Era como tener una cámara de seguridad de última generación instalada, pero con la batería muerta desde hacía año y medio. Nadie se había dado cuenta.

Durante esos 76 días, los atacantes encontraron algo que les facilitó todo el trabajo. En uno de los servidores encontraron un archivo donde el equipo de TI había guardado, en texto plano y sin ningún tipo de cifrado, el nombre de usuario y la contraseña de administrador de varias bases de datos. Fue como encontrar la llave maestra debajo del tapete. Con esas credenciales pudieron acceder a 48 bases de datos diferentes que no tenían nada que ver con el portal de disputas. Allí estaban los datos reales. Realizaron más de 9.000 consultas, extrayendo la información en pequeños paquetes cifrados para que pareciera tráfico normal, y borrando los logs después de cada extracción para no dejar huella. Se llevaron nombres, apellidos, números de Seguro Social, fechas de nacimiento, direcciones y en más de 200.000 casos, números completos de tarjetas de crédito.

El 29 de julio de 2017, el equipo de seguridad finalmente renovó el certificado vencido del dispositivo de inspección. En cuestión de segundos, el sistema empezó a gritar. Vio gigabytes de datos saliendo hacia un servidor externo desconocido. Ahí supieron que habían sido hackeados. Aun así, Equifax tardó hasta el 7 de septiembre, seis semanas después, en hacerlo público. Seis semanas en las que 147,9 millones de estadounidenses, y miles de personas en Reino Unido y Canadá, siguieron sin saber que su identidad había sido robada.

Las consecuencias fueron históricas. El CEO, Richard Smith, renunció. El valor de la acción cayó más del 30% en días. La empresa fue demandada por casi todos los estados de http://EE.UU. y finalmente llegó a un acuerdo con la Comisión Federal de Comercio, la Oficina de Protección Financiera del Consumidor y 50 fiscales generales por un monto de hasta 700 millones de dólares para compensar a las víctimas y mejorar su seguridad. El informe final del Comité de Supervisión de la Cámara de Representantes de http://EE.UU. resumió todo en una sola línea: esta fue una brecha completamente prevenible.

Y esa es la lección más importante que nos deja Equifax para la ciberseguridad preventiva. No se trata de comprar la herramienta más cara ni de contratar al hacker más famoso. Se trata de higiene digital básica y sostenida. Se trata de tener un inventario real y actualizado de todos los activos que están expuestos a internet, especialmente los sistemas legacy que nadie quiere mirar. Se trata de tener un programa de gestión de vulnerabilidades que no dependa de un escaneo manual que se hace cuando alguien se acuerda, sino que sea automático, continuo y con responsables claros que deban confirmar con evidencia que el parche fue aplicado en menos de 72 horas cuando es crítico. Se trata de no guardar nunca credenciales en texto plano y de tener un sistema que te avise cuando un certificado de seguridad está a punto de vencer, porque un control de seguridad que no funciona es peor que no tener ningún control, porque te da una falsa sensación de seguridad. Equifax nos recuerda la verdad más dura de nuestra industria: el atacante no necesita ser un genio para ganarte, solo necesita que tú te olvides de hacer lo básico durante dos meses.

4.El caso Uber 2016: El hackeo de 57 millones de personas que se intentó tapar con 100 mil dólares

Si SolarWinds fue un ataque de un estado a la cadena de suministro y Equifax fue un caso de olvido de un parche, el caso de Uber en 2016 es el ejemplo más humano y más vergonzoso de todos. Aquí no hubo una vulnerabilidad compleja de día cero ni un grupo de inteligencia extranjera. Hubo una mala práctica que cualquier desarrollador junior sabe que no debe hacer, y luego una decisión empresarial aún peor: intentar ocultarlo.

Uber en 2016 era la startup más valiosa del mundo, valorada en casi 70 mil millones de dólares. Su lema era moverse rápido y romper cosas. Y esa cultura se notaba también en su seguridad. En octubre de 2016, dos atacantes que no eran precisamente genios de la ciberseguridad, uno de ellos un joven de 20 años de Florida, hicieron algo muy simple. Se pusieron a buscar en GitHub, que es la plataforma donde los programadores guardan su código, repositorios privados de ingenieros de Uber. No tuvieron que hackear GitHub. Simplemente encontraron lo que un ingeniero de Uber había dejado por error y por comodidad: sus credenciales de acceso a Amazon Web Services directamente escritas dentro del código fuente.

Es una de las peores prácticas en desarrollo seguro y se conoce como hardcodear secretos. Dejar una llave de acceso a tu infraestructura en la nube dentro de un archivo de código que luego se sube a un repositorio es como dejar la llave de la caja fuerte pegada con cinta adhesiva en la puerta de la oficina. Una vez que los atacantes tuvieron esas credenciales de AWS, el resto fue trivial. Entraron al bucket de Amazon S3 de Uber, que es donde se guardan archivos masivos, y encontraron un respaldo completo de la base de datos de usuarios y conductores. No estaba cifrado con una protección adicional. Era un archivo de texto gigante listo para descargar.

En ese archivo había nombres, correos electrónicos y números de teléfono de 57 millones de usuarios de Uber en todo el mundo, y nombres y números de licencia de conducir de más de 600.000 conductores en Estados Unidos. No era un muestreo, era la base de datos entera. Los atacantes la descargaron y luego, como es común en estos casos, contactaron a Uber para pedir un rescate. Le exigieron dinero a cambio de no publicar la información.

Lo que hizo Uber después es lo que convirtió un incidente grave pero manejable en un escándalo criminal. En lugar de activar su plan de respuesta a incidentes, avisar a las autoridades, avisar a los usuarios y cumplir con la ley de notificación de brechas de California, la dirección de seguridad de ese momento, liderada por su Chief Security Officer Joe Sullivan, tomó otra decisión. Decidió pagarles a los atacantes 100.000 dólares a través de su programa oficial de recompensas por encontrar vulnerabilidades en HackerOne, como si los atacantes fueran investigadores de seguridad bien intencionados. Les hicieron firmar un acuerdo de confidencialidad para que borraran los datos y se quedaran callados, y luego destruyeron toda evidencia del pago intentando hacerlo pasar por un bug bounty legítimo.

Durante un año entero, nadie fuera de un pequeño círculo en Uber supo nada. Mientras tanto, en ese mismo momento, Uber estaba siendo investigada por la Comisión Federal de Comercio de Estados Unidos, la FTC, por otra brecha anterior ocurrida en 2014. Y ante preguntas directas de la FTC sobre si habían tenido más accesos no autorizados, Uber mintió por omisión y no dijo nada. Siguió operando como si nada hubiera pasado.

Todo se derrumbó en noviembre de 2017, cuando Dara Khosrowshahi acababa de asumir como nuevo CEO después de la salida de Travis Kalanick. Su equipo de seguridad encontró rastros del pago y de la brecha durante una auditoría interna y decidió hacer lo que se debió hacer desde el principio: hacerlo público. Ese día despidieron a Joe Sullivan y a otro abogado senior de seguridad. La noticia cayó como una bomba.

Las consecuencias legales fueron históricas y son la base de por qué este caso se estudia en todas las escuelas de ciberseguridad preventiva. Uber no solo tuvo que pagar 148 millones de dólares en un acuerdo con los 50 estados de http://EE.UU. y el Distrito de Columbia por ocultar la brecha, sino que tuvo que firmar un acuerdo de 20 años de auditorías de privacidad con la FTC. En 2022, el Departamento de Justicia de http://EE.UU. llegó a un acuerdo de no enjuiciamiento con la empresa porque admitió que su personal ocultó la brecha, y en octubre de ese mismo año, Joe Sullivan se convirtió en el primer CISO en la historia en ser condenado penalmente por obstrucción a la justicia por encubrir un ciberataque. Fue sentenciado por haber intentado tapar el incidente.

Bibliografia

Instituto Nacional de Ciberseguridad de España INCIBE. (2023). Guía de ciberseguridad preventiva para empresas.

   https://www.incibe.es/empresas/guia-ciberseguridad

 Kaspersky. (2024). ¿Qué es la ciberseguridad preventiva y por qué es importante?.

   https://latam.kaspersky.com/resource-center/definitions/what-is-cyber-security

 

CCN-CERT. (2020, 14 de diciembre). _CCN-CERT AL 11/20 Campaña de ciberataques a la plataforma Orion de SolarWinds_. Centro Criptológico Nacional. https://www.ccn-cert.cni.es/avisos-al/11120-ccn-cert-al-11-20-campana-de-ciberataques-a-la-plataforma-orion-de-solarwinds

 Cybersecurity and Infrastructure Security Agency & Federal Bureau of Investigation. (2021, 4 de julio). _CISA-FBI Guidance for MSPs and their Customers Affected by the Kaseya VSA Supply-Chain Ransomware Attack_. CISA. https://www.cisa.gov/news-events/alerts/2021/07/04/cisa-fbi-guidance-msps-and-their-customers-affected-kaseya-vsa 56ac

Stellar Cyber. (2023). _2017 Equifax Breach, análisis de seguridad_. Stellar Cyber. https://stellarcyber.ai/es/blog/2017-equifax-breach-analisis-de-seguridad/ c7c9

Data Center Dynamics. (2017, 22 de noviembre). _Uber ocultó el robo masivo de datos_. DCD. https://www.datacenterdynamics.com/es/noticias/uber-oculto-el-robo-masivo-de-datos/ 72b3