Ivanti Blog: Seguridad

ITAM se cruza con CAASM: por qué la gestión de activos de TI es un requisito previo para su estrategia de CAASM

Wed, 01 Jul 2026 15:00:14 Z

La gestión de la superficie de ataque de activos cibernéticos (CAASM) es un enfoque emergente para una pieza fundamental de su estrategia de ciberseguridad: contar con una visión completa de sus activos cibernéticos para poder identificar vulnerabilidades que agentes malintencionados podrían explotar.

Para el personal de operaciones de TI, CAASM probablemente sonará muy similar a la gestión de activos de TI (ITAM). Esto se debe a que ambas disciplinas están estrechamente relacionadas, lo que subraya claramente cómo seguridad y operaciones de TI pueden y deben apoyarse en herramientas y procesos compartidos.

ITAM frente a CAASM: ¿cuál es la diferencia?

ITAM es un conjunto de procesos y herramientas para gestionar todos los activos de TI, incluidos hardware y software, durante todo su ciclo de vida. Normalmente incluye una amplia variedad de flujos de trabajo, como descubrimiento de activos, gestión de inventario, mapeo de servicios, seguimiento y supervisión de activos, y gestión del ciclo de vida de los activos.

CAASM amplía el alcance de ITAM al identificar y mitigar posibles vulnerabilidades y amenazas para los sistemas, redes y aplicaciones de su organización. El proceso suele implicar identificar todos los activos de su entorno de TI, mapear las interdependencias entre estos activos y evaluar el impacto potencial de una brecha.

El objetivo es ofrecer a su organización una comprensión clara de su posible superficie de ataque y priorizar las iniciativas de corrección en función de los riesgos más significativos. Sin duda, los equipos lo consideran necesario: el 44 % de los equipos de ciberseguridad considera que la información sobre activos es fundamental para identificar y proteger las superficies de ataque.

Los beneficios de ITAM para la seguridad

La importancia de ITAM para la seguridad no es ninguna novedad para los líderes de TI. Una encuesta de EMA a líderes de TI realizada en 2022 reveló que casi la mitad mide el éxito de su programa de ITAM por la reducción de los riesgos de seguridad. Analizar ITAM desde la perspectiva de la seguridad muestra una serie de beneficios directamente relacionados con CAASM:

Identificación de activos

Una solución ITAM completamente implementada permite a su organización identificar y realizar el seguimiento de todos sus activos de TI. Saber qué activos hay en el entorno es el primer paso para identificar posibles vulnerabilidades y amenazas.

Gestión de vulnerabilidades

Sin un inventario completo de activos de TI, su organización encontrará lagunas al intentar realizar evaluaciones periódicas de vulnerabilidades, identificar posibles vulnerabilidades y abordarlas de forma proactiva.

Priorización de las medidas de seguridad

Saber cuáles son todas las piezas y dónde se encuentran es un gran comienzo, pero asignar recursos de forma eficaz para gestionar el riesgo implica saber qué activos son los más críticos. Un conjunto bien definido de procesos ITAM y sistemas ITAM eficaces proporciona a su organización la información que necesita para priorizar las medidas de seguridad.

Al clasificar los activos por tipo, los equipos de ciberseguridad pueden centrarse más en los activos de mayor riesgo, como la nube y SaaS, manteniendo al mismo tiempo un control adecuado sobre activos de riesgo relativamente menor, como los dispositivos perimetrales.

Y aunque estén menos directamente conectados con CAASM, ITAM también desempeña un papel en el refuerzo de la seguridad en otras áreas:

Cumplimiento normativo

Existe un amplio conjunto de normativas —CCPA, RGPD, POPI, Castle y otras— que exigen a las empresas mantener un inventario preciso de sus activos de TI y demostrar el cumplimiento de diversos estándares de seguridad.

Ahorro de costes

En lo que respecta a los activos de TI, gestionar los costes está estrechamente relacionado con gestionar el uso. Por ejemplo, casi un tercio de los líderes de TI encuestados cree que está desperdiciando presupuesto en recursos en la nube no utilizados o infrautilizados. Un gasto mal gestionado supone un riesgo para las organizaciones de TI por sí mismo, y agrava los problemas de ciberseguridad al limitar los recursos disponibles para abordar cuestiones de seguridad.

Creación de una solución CAASM que garantice la seguridad de los activos

Al fusionar ITAM con la gestión de riesgos de activos cibernéticos, una solución CAASM puede proteger tanto los activos individuales como toda la superficie de activos cibernéticos frente a una amplia variedad de amenazas y vulnerabilidades. Analicemos con más detalle los componentes que conforman una pila de soluciones CAASM eficaz:

Descubrimiento y gestión de activos

Ya hemos visto que ITAM es un componente crítico de la solución CAASM. La implementación correcta de ITAM requiere herramientas de descubrimiento que analicen la red para identificar todos los dispositivos conectados, incluidos aquellos que puedan estar ocultos o ser desconocidos.

La base de datos de activos de la solución ITAM, a menudo asociada a la CMDB (véase más abajo), puede proporcionar entonces un repositorio central para gestionar toda la información de los activos, incluidos atributos de activos, configuraciones y mapeo de relaciones y dependencias.

Gestión de vulnerabilidades

La gestión de vulnerabilidades incluye herramientas y tecnologías que permiten a su organización identificar y priorizar vulnerabilidades en sus activos de TI. Las herramientas de análisis de vulnerabilidades realizan análisis periódicos de su entorno para identificar posibles vulnerabilidades en hardware, software y configuraciones. A continuación, estas herramientas priorizan las vulnerabilidades en función de su gravedad y proporcionan recomendaciones de corrección para abordarlas de forma proactiva.

Inteligencia de amenazas

La inteligencia de amenazas incluye herramientas y tecnologías que proporcionan información en tiempo real sobre amenazas y tendencias emergentes. Estas herramientas supervisan una amplia variedad de fuentes, incluidos feeds públicos y privados, redes sociales y foros de la dark web, para identificar posibles amenazas y vectores de ataque. Puede utilizar esta información para priorizar las medidas de seguridad y abordar de forma proactiva posibles amenazas.

Base de datos de gestión de la configuración (CMDB)

La CMDB es un repositorio central de todos los servicios, activos y otros elementos de configuración dentro del entorno de TI. Incluye tanto un inventario de estos elementos como sus relaciones y dependencias. La CMDB permite a su empresa realizar el seguimiento y gestionar todos los cambios en los activos, garantizando que los cambios se realicen de forma controlada y documentada.

Al integrar la CMDB con herramientas de gestión de vulnerabilidades e inteligencia de amenazas, las empresas pueden priorizar las medidas de seguridad en función de la criticidad de los activos y sus relaciones.

La pila de soluciones CAASM es un conjunto completo de herramientas y tecnologías que permiten a las empresas identificar y mitigar de forma proactiva posibles vulnerabilidades en sus activos de TI. Al combinar descubrimiento y gestión de inventario de activos, gestión de vulnerabilidades, inteligencia de amenazas y CMDB, su empresa puede anticiparse a posibles ciberamenazas y mantener protegidos sus activos de TI críticos.

Cómo la IA agéntica permite una respuesta autónoma frente a amenazas a velocidad de máquina

Mon, 29 Jun 2026 14:00:03 Z

¿Por qué el 40 % de las alertas que reciben los equipos de seguridad quedan hoy completamente sin investigar? No se debe a una falta de preocupación, sino a que las ventanas de ataque son cada vez más breves y a una proliferación tecnológica abrumadora.

Los equipos de seguridad actuales operan en un panorama de amenazas definido por ataques en aumento, presupuestos más ajustados y una fatiga por alertas cada vez mayor. Las organizaciones procesan una media de 960 alertas de seguridad al día, y las grandes empresas gestionan más de 3000 alertas diarias en unas 30 herramientas. Eso suma 36 000 amenazas potenciales al mes que podrían pasar desapercibidas. La asimetría es abrumadora: a los atacantes les basta con una brecha con éxito, mientras que los defensores deben acertar siempre.

Esta brecha crítica para las organizaciones es un problema de arquitectura. El mayor reto en la respuesta frente a amenazas no es lo que se detecta, sino lo que ocurre después de que salta la alerta.

¿La buena noticia? La IA agéntica cambia esa arquitectura. No sustituyendo las herramientas existentes, sino cerrando la brecha operativa entre la detección y la acción.

El problema de la velocidad en la seguridad

Las herramientas que ha implementado (SIEM, EDR, escáneres de vulnerabilidades, plataformas SOAR) son excepcionales en la detección. Sacan a la luz las amenazas, catalogan los riesgos y envían las alertas. Pero la detección sin una respuesta eficaz no es más que documentación costosa. El verdadero cuello de botella pasa a ser solucionar los problemas con la rapidez necesaria para que importe, no simplemente saber qué falla.

Más información:Por qué la gestión tradicional de vulnerabilidades se está resquebrajando ante el descubrimiento impulsado por IA

Las operaciones de seguridad tradicionales siguen una secuencia conocida: salta una alerta, un analista investiga, se toma una decisión, se programa la remediación, se aprueba el cambio… y solo entonces se actúa. Cada paso tiene sentido por separado, pero juntos obligan a los equipos a trabajar a velocidad humana mientras las amenazas se mueven de forma autónoma. Para cuando la investigación ha concluido, el adversario ya se ha movido lateralmente. Y, para cuando se implementa un parche, se han divulgado tres CVE críticas más.

La brecha temporal es evidente. Según el Informe de investigaciones sobre brechas de datos de Verizon 2025, las organizaciones tardan una mediana de 32 días en remediar vulnerabilidades en dispositivos perimetrales, mientras que los actores de amenazas explotan esas mismas vulnerabilidades en el momento de su divulgación pública o incluso antes, operando en la práctica con plazos de día cero. Esa brecha se está acelerando: el informe M-Trends 2026 de Mandiant revela que el tiempo entre el acceso inicial y el traspaso a un grupo de amenazas secundario se ha reducido de más de ocho horas en 2022 a solo 22 segundos en 2025.

Un modelo de seguridad eficaz requiere que la detección desencadene una acción inmediata e inteligente. Las capacidades existentes, como la evaluación de vulnerabilidades , la gestión de endpoints , la implementación de parches y los controles de acceso siguen vigentes, pero operan con mayor rapidez y autonomía. El resultado son operaciones de seguridad que funcionan a velocidad de máquina, no a velocidad humana.

Cómo es realmente la seguridad agéntica

En seguridad, la IA agéntica hace referencia a sistemas autónomos que ejecutan flujos de trabajo de seguridad de extremo a extremo. Pasan de la detección a la decisión y a la acción sin detenerse para obtener aprobación manual en cada paso.

La IA agéntica debería operar en toda la superficie de ataque, coordinando la detección, la decisión y la respuesta como un único sistema.

Remediación autónoma de vulnerabilidades

Cuando se divulga una CVE crítica, los agentes evalúan de inmediato la exposición en todo el entorno. Priorizan el riesgo en función de la explotabilidad y del contexto empresarial, implementan parches en los endpoints afectados y verifican la remediación. Todo esto ocurre antes de que un analista abra un ticket. La supervisión humana se mantiene, pero se elimina el retraso que generan los traspasos manuales.

Más información:Informe sobre priorización de parches basada en riesgos

Respuesta inteligente frente a amenazas

Cuando un endpoint muestra un comportamiento sospechoso, los agentes correlacionan señales de EDR, telemetría de red e inventario de activos. Los dispositivos afectados se aíslan; las sesiones activas se revocan; las pruebas forenses se capturan y se alerta al SOC con todo el contexto. La amenaza se contiene antes de propagarse, lo que permite a los analistas investigar un incidente neutralizado en lugar de una brecha activa.

Postura de cumplimiento continuo

Los agentes supervisan continuamente endpoints y servidores para detectar desviaciones de configuración. Cuando un dispositivo deja de cumplir las políticas, por ejemplo, si se desactiva un firewall, se apaga el cifrado o se instala software no autorizado, la remediación se produce automáticamente. La configuración se corrige, el evento se registra y se verifica el cumplimiento. El cumplimiento se convierte en un estado continuo, no en un ejercicio trimestral.

Mitigación del riesgo de acceso

Los agentes detectan patrones de acceso anómalos, como geolocalizaciones inesperadas, intentos de escalada de privilegios y accesos inusuales a datos. Las sesiones sospechosas se terminan; se aplica la autenticación multifactor y el acceso se reduce hasta que se complete la verificación. Los usuarios legítimos siguen trabajando mientras el movimiento lateral se detiene en tiempo real.

Estos agentes trabajan en toda la pila de seguridad existente, incluidos SIEM, EDR, gestión de vulnerabilidades , sistemas de identidad y gestión de parches. Cada herramienta se vuelve más rápida y eficaz como parte de un sistema coordinado. El objetivo no es sustituir las operaciones de seguridad, sino permitir que operen a la velocidad a la que ya lo hacen los adversarios.

Más información:Cómo la IA agéntica está transformando la infraestructura y las operaciones

De la detección a la acción: la arquitectura de la velocidad

El cambio fundamental que permite la IA agéntica es la toma de decisiones en el punto de detección. En lugar de separar la percepción de la acción, los flujos de trabajo de seguridad se diseñan para evaluar el riesgo y responder de inmediato a medida que surgen las amenazas.

Cuando se identifica una vulnerabilidad crítica, el agente no genera un ticket para revisarlo más adelante. Evalúa los mismos factores que tendría en cuenta un arquitecto de seguridad:

¿El sistema está expuesto a Internet?
¿A qué datos accede?
¿Existe un exploit conocido en circulación?
¿Cuál es el impacto empresarial de aplicar el parche frente a retrasarlo?

Esa decisión se toma en milisegundos, no en días. Y lograr este resultado requiere algo más que scripts de automatización: requiere sistemas capaces de razonar sobre el contexto y las consecuencias.

Puntuación de riesgo con contexto empresarial

No todas las vulnerabilidades críticas tienen la misma urgencia. Los agentes evalúan conjuntamente la explotabilidad, la exposición y el impacto empresarial. Una vulnerabilidad en un servidor de pruebas interno se gestiona de forma distinta que el mismo problema en un sistema de producción orientado al cliente. La priorización se realiza automáticamente, y la justificación es clara y defendible.

Umbrales de respuesta adaptativos

Los agentes aprenden de los resultados con el tiempo. Cuando determinadas acciones generan falsos positivos de forma recurrente, los umbrales se ajustan. Cuando surgen nuevos patrones de ataque, aumenta la sensibilidad. El sistema mejora con el uso, en lugar de volverse más frágil a medida que cambian las condiciones.

Escalación con preservación del contexto

Cuando un agente alcanza el límite de su autonomía, la escalación incluye el razonamiento, no solo una alerta. Qué se detectó, qué señales se evaluaron, por qué la decisión no pudo completarse de forma autónoma y qué acción se recomendó se transmiten al analista. La intervención humana se centra en las decisiones que importan, no en el triaje.

Auditabilidad integrada

Cada acción se registra con todo el contexto, incluido el desencadenante, los datos evaluados, la decisión tomada y el resultado. El cumplimiento se integra directamente en el flujo de trabajo en lugar de reconstruirse a posteriori.

El impacto en los equipos de seguridad es medible. La Encuesta SANS de detección y respuesta 2025 reveló que el 73 % de las organizaciones cita los falsos positivos como su principal reto de detección, y el 76 % señala la fatiga por alertas como una preocupación principal del SOC. No se trata solo de un problema de eficiencia. Cuando los analistas dedican la mayor parte de su tiempo a separar el ruido de lo relevante, los programas de seguridad siguen siendo reactivos por diseño.

El resultado es una realidad operativa diferente. La detección conduce a la resolución. Las alertas se abordan a medida que aparecen, en lugar de acumularse en colas. Los equipos de seguridad dedican menos tiempo a responder a los incidentes de ayer y más a prevenir el siguiente.

Qué cambia en la práctica

Cuando la IA agéntica se implementa en entornos de seguridad de producción, el impacto se manifiesta menos como logros aislados y más como un cambio estructural. Los equipos observan cambios constantes en la forma en que se estructuran los flujos de trabajo, en la rapidez con que se reduce el riesgo y en dónde se aplica el esfuerzo humano.

1. El tiempo hasta la acción se reduce drásticamente

La detección y la respuesta se fusionan en un único movimiento. Las vulnerabilidades que antes esperaban días para el triaje y la programación se evalúan, priorizan y remedian automáticamente cuando se cumplen los umbrales de riesgo. Las amenazas que antes se movían lateralmente durante la investigación se contienen en el punto de detección. El resultado medible es un menor tiempo de permanencia y una reducción del riesgo más rápida, no solo alertas más rápidas.

2. Disminuye la sobrecarga operativa

El trabajo de seguridad rutinario que antes consumía tiempo de los analistas, como la remediación de desviaciones de cumplimiento, la coordinación de parches y las correcciones de acceso, pasa a ejecutarse de forma continua en segundo plano. Los informes se convierten en un subproducto de las operaciones normales, no en una carrera periódica contra el reloj. Los equipos de seguridad dedican menos tiempo a gestionar procesos y más a aplicar criterio.

3. La calidad de la respuesta se vuelve más uniforme

Cuando las decisiones se toman utilizando siempre las mismas entradas contextuales, el comportamiento de respuesta se estabiliza. Riesgos similares se gestionan de formas similares, independientemente de cuándo se produzcan o de quién esté de guardia. Esta consistencia reduce la variabilidad, limita el error humano y facilita explicar los resultados a auditores, directivos y reguladores.

4. La atención humana se desplaza hacia trabajo de mayor valor

Los analistas ya no se ven arrastrados a cada alerta o problema menor de configuración. Intervienen cuando la escalación está justificada y cuando las decisiones afectan de forma material al riesgo empresarial. El resultado es menos fatiga por alertas, menos falsos positivos y más tiempo dedicado a búsqueda de amenazas, análisis de incidentes y mejora estratégica.

El impacto empresarial de este cambio se refleja en los datos del sector. Según el informe Cost of a Data Breach 2025 de IBM, las organizaciones que utilizan IA y automatización de forma extensiva ahorraron una media de 1,9 millones de dólares por brecha y redujeron el ciclo de vida de la brecha en ochenta días. Con un ciclo de vida medio global de las brechas de 241 días en 2025, el más bajo en nueve años, incluso las mejoras incrementales en velocidad se traducen en una reducción significativa del riesgo y los costes.

El patrón es constante. Los equipos de seguridad dejan de reaccionar a los atrasos acumulados y empiezan a operar al ritmo de la propia amenaza.

Por qué avanzar despacio es el mayor riesgo

La cautela en torno a la IA en seguridad es comprensible. Los sistemas de seguridad afectan a infraestructuras críticas. Los errores son muy visibles, y las consecuencias de un fallo son reales. Esperar a contar con casos de uso más claros, una gobernanza más sólida y controles probados puede parecer la opción responsable.

El reto es que el entorno de riesgo subyacente ha cambiado. Los atacantes ya operan a velocidad de máquina, mientras que la mayoría de los programas de seguridad siguen respondiendo a velocidad humana. Cada semana dedicada a retrasar una autonomía significativa amplía esa brecha. La exposición se acumula de forma silenciosa, no porque falle la detección, sino porque la acción no puede seguir el ritmo.

La mayoría de las organizaciones ya disponen de las señales necesarias. SIEM, EDR, gestión de vulnerabilidades y los sistemas de aplicación de parches generan detección y contexto de alta calidad. La limitación está en la ejecución. Las alertas se acumulan. Los tickets esperan. Las decisiones se estancan. La IA agéntica aborda esa limitación reduciendo la distancia entre detección y respuesta. Cuanto más tiempo permanezca esa distancia, más se alejará la postura de seguridad de la realidad de las amenazas modernas.

En la práctica, la resistencia a la seguridad agéntica suele ser más organizativa que técnica. La propiedad de los resultados impulsados por IA puede no estar clara. Los incentivos pueden premiar el cumplimiento del proceso por encima de la reducción del riesgo. Los equipos pueden ver la automatización como una amenaza para su relevancia, en lugar de como una extensión de sus capacidades.

Desde el punto de vista operativo, suele ocurrir lo contrario. A medida que aumenta la autonomía, el trabajo de los analistas se vuelve más enfocado y más valioso. Se amplían las actividades de búsqueda de amenazas, análisis de incidentes, investigación de adversarios y mejora arquitectónica. El triaje manual, la coordinación de parches y la investigación repetitiva retroceden. La experiencia humana se aplica donde más importa el criterio.

Las organizaciones que retrasan la adopción de la seguridad agéntica no se quedan quietas. Están eligiendo operar con un modelo de respuesta que no puede igualar el ritmo de los ataques modernos. Con el tiempo, ese desajuste se convierte en la principal fuente de riesgo.

El cambio ya está en marcha

Las operaciones de seguridad se están alejando de los modelos reactivos en los que la detección genera trabajo pendiente, las alertas crean tareas y los plazos de respuesta se alargan durante días. Los programas líderes se están reorganizando en torno a la ejecución proactiva, donde los sistemas perciben las condiciones, evalúan el riesgo y actúan de forma continua. Los agentes autónomos absorben el volumen y la variabilidad. Los equipos humanos se centran en la estrategia, la investigación y la mejora.

Este cambio refleja una transformación en la forma en que debe operar la seguridad moderna. Los adversarios ya automatizan el reconocimiento, el desarrollo de exploits y el movimiento lateral. Los ataques avanzan sin esperar a que los tickets se sometan a triaje o a que se programen aprobaciones. Los programas de seguridad que siguen ligados a flujos de trabajo a velocidad humana tienen dificultades para cerrar esa brecha.

Lo que distingue a las organizaciones más eficaces es su disposición a operar de otra manera. Diseñan para la ejecución además de para la detección. Gobiernan la autonomía de forma deliberada. Miden resultados en lugar de actividad. Con el tiempo, este modelo operativo amplifica su ventaja porque la respuesta mejora a medida que los sistemas aprenden y los equipos se reenfocan.

La pregunta a la que se enfrentan los líderes de seguridad ya no es si la autonomía tiene cabida en las operaciones de seguridad. Es si su organización está preparada para ejecutar la seguridad al ritmo que exige ahora el entorno.

¿Preparado para cerrar la brecha de velocidad en la seguridad?

Descubra cómo Ivanti Neurons for ITSM permite flujos de trabajo de seguridad autónomos que pasan de la detección a la resolución con rapidez y control.

Estamos en un apocalipsis de los parches. Eso significa que estas tres excusas de TI ya no sirven.

Wed, 29 Apr 2026 14:00:07 Z

El 7 de abril, Anthropic anunció que su modelo Claude Mythos Preview había identificado de forma autónoma miles de vulnerabilidades zero-day de gravedad alta y crítica en todos los principales sistemas operativos y navegadores web. Más del 99 % de ellas seguían sin parchear el día de su divulgación.

Dos semanas después, el 21 de abril, Mozilla afirmó que había utilizado el mismo modelo para encontrar y parchear 271 vulnerabilidades en la versión más reciente de Firefox. La propia evaluación de Mozilla: «Hasta ahora no hemos encontrado ninguna categoría ni complejidad de vulnerabilidad que los humanos puedan encontrar y este modelo no».

271 es la primera oleada. Chrome, Edge, Windows, macOS, Linux, FreeBSD: el fallo de ejecución remota de código de 17 años de antigüedad en FreeBSD que divulgó el equipo rojo de Anthropic (CVE-2026-4747) es un ejemplo temprano de lo que está por venir. Todos los proveedores bajo el paraguas del Project Glasswing de Anthropic están en disposición de publicar correcciones a un ritmo que el sector no había visto antes. Todas esas correcciones se convierten en CVE públicas con parches disponibles, que acaban en el mismo lugar: su entorno.

La historia de la contención también presenta una grieta. El 21 de abril, Bloomberg informó de que un grupo vinculado a Discord obtuvo acceso no autorizado a Mythos a través del entorno de un proveedor externo. Anthropic afirma que la actividad no fue más allá de ese proveedor. Independientemente de que una capacidad similar esté ya en manos de atacantes o no, el margen defensivo es más corto de lo que sugería el anuncio del 7 de abril.

Mythos llegó a un mundo que ya avanzaba en esa dirección. El informe Global Threat Report 2026 de CrowdStrike documentó un aumento interanual del 89 % en los ataques habilitados por IA en 2025. Esa tendencia es anterior a Mythos.

Llamémoslo apocalipsis de los parches. Un apocalipsis operativo en sentido estricto, en el que el volumen y la cadencia de CVE públicas con parches disponibles están a punto de superar la forma en que trabajan actualmente la mayoría de los equipos de TI y seguridad.

NIST ya está notando los efectos del apocalipsis de los parches. En abril, la agencia anunció un cambio importante en las operaciones de la National Vulnerability Database (NVD) en respuesta a un aumento del 263 % en las solicitudes. NIST dejará de proporcionar enriquecimiento detallado para todas las vulnerabilidades enviadas y, en su lugar, solo lo hará para las vulnerabilidades que cumplan criterios de alto riesgo, como las incluidas en el catálogo Known Exploited Vulnerabilities de CISA o las que afecten a software gubernamental crítico. NIST se apoyará en las CVE Numbering Authorities (CNA), como Ivanti, en lugar de realizar su propia evaluación independiente.

Desde el anuncio, he escuchado tres versiones de la misma respuesta por parte de clientes y colegas. Las tres son variaciones de un programa diseñado para un mundo que avanzaba más despacio.

«Tenemos un escáner de vulnerabilidades»

Qualys, Rapid7 y Tenable realizan bien el descubrimiento de vulnerabilidades. Los escáneres encuentran, señalan, puntúan y enumeran. El despliegue, la verificación, la gestión de reinicios y la reversión quedan fuera de su alcance. Ese trabajo sigue teniendo que realizarse en algún lugar. En la mayoría de los programas, se lleva a cabo en una herramienta distinta, con un equipo distinto y a una cadencia distinta.

Con la ventana de explotación reducida ahora a horas y la cola de Glasswing a punto de duplicar el backlog, un escáner que genera 587 vulnerabilidades críticas y entrega la lista a un equipo humano es un lastre. La medida práctica es conectar el escáner que ya tiene a un motor de remediación que pueda actuar automáticamente sobre sus hallazgos. Una plataforma de gestión autónoma de endpoints (AEM), con despliegue por anillos y reversión, e inteligencia de vulnerabilidades para aportar contexto basado en el riesgo a decisiones de remediación eficientes, de modo que la lista se reduzca sin que una persona tenga que tomar cada decisión.

«Gestionamos las aprobaciones a través de nuestro sistema de tickets»

Hablando de personas que tienen que tomar decisiones… Los procesos de aprobación largos y lineales van a ralentizar considerablemente el proceso de remediación. ¿Cuándo fue la última vez que tuvo que decidir si iba a desplegar la última actualización del sistema operativo o del navegador?

Las organizaciones ya saben que van a desplegar estas actualizaciones. A menudo, el proceso de aprobación se debe a políticas internas complejas y a una falta de alineación en torno a los resultados de seguridad. ¿El resultado? Un proceso muy lineal que requiere el escáner de vulnerabilidades mencionado anteriormente, un analista que apruebe lo que ya se sabe que debe hacerse, tickets enviados a los responsables de negocio para su aprobación y acumulados en bandejas de entrada a la espera de aprobación y, en última instancia, tiempo valioso desperdiciado en una decisión que, en esencia, ya estaba bien entendida y no era necesario tomar.

El cambio del mercado hacia la gestión de la exposición aborda este proceso de forma muy distinta, centrándose en definir el apetito de riesgo de una organización y supervisar su postura de riesgo. La próxima vez que se publique una actualización del sistema operativo Windows, ya sabrá que la desplegará, el calendario en que lo hará y los SLA y métricas de cumplimiento con los que medirá el éxito. Lo que realmente quiere saber es:

1. ¿Debemos avanzar más rápido porque la actualización incluye vulnerabilidades explotadas conocidas?

2. ¿La actualización está afectando a las operaciones y debemos ralentizar el ritmo (afortunadamente, la plataforma de gestión autónoma de endpoints incluye despliegue por anillos con reversión)?

«Tenemos Intune»

Microsoft Intune tiene dos límites de alcance que importan en este contexto.

En primer lugar, solo gestiona los dispositivos inscritos en él. Los endpoints no inscritos y no gestionados —servidores, portátiles de contratistas, TI en la sombra, dispositivos perimetrales desatendidos— quedan completamente fuera de su visibilidad. Durante periodos de mayor volumen de vulnerabilidades, esos puntos ciegos se multiplican más rápido de lo que los equipos pueden gestionar manualmente.

En segundo lugar, aunque Intune simplifica el despliegue y las actualizaciones de aplicaciones, su cobertura de aplicaciones de terceros y su profundidad de priorización son más limitadas de lo que la mayoría de los administradores cree. Intune puede indicarle qué está desactualizado, pero no qué aumenta realmente su exposición––lo que obliga a los equipos a parchearlo todo de forma reactiva o a basarse en conjeturas cuando el tiempo escasea.

La mayoría de los entornos empresariales no son exclusivamente Windows, no están plenamente inscritos ni ejecutan una pila de aplicaciones pequeña y homogénea. Cuando se disparan las divulgaciones de vulnerabilidades, canalizar así la aplicación de parches deja brechas y se convierte en un riesgo sistémico.

Mantenga Intune. Combínelo con una capa de descubrimiento y remediación que encuentre los activos que Intune no puede ver, priorice las vulnerabilidades más importantes y aplique parches con confianza en las aplicaciones que Intune no cubre.

Qué hacer al respecto

La automatización es el modelo operativo. Debe estar integrada en el flujo de trabajo.

Los profesionales conocen el principio desde hace tiempo. Se manifiesta en tres ámbitos:

Triaje continuo. Las vulnerabilidades explotadas conocidas pueden seguir una vía de respuesta a zero-days, especialmente en las partes menos seguras de la organización, como los sistemas de usuario final. Además, establezca y defina aplicaciones concretas, como navegadores y aplicaciones de telecomunicaciones, para que se actualicen por una vía prioritaria que se revise semanalmente o incluso a diario. Todo lo demás puede esperar a la ventana de mantenimiento habitual.
Despliegue por anillos con reversión automatizada. Anillo de pruebas, anillo de primeros usuarios, producción amplia, misión crítica. La secuencia es poco llamativa, pero funciona para la mayoría de las tareas de mantenimiento. Lo que ha cambiado es que determinadas actualizaciones tendrán que comprimirse para ajustarse a la ventana de explotación, en lugar de esperar al mantenimiento mensual. El anillo de pruebas debe estar automatizado e instrumentado; una lista de comprobación manual no puede moverse a esa velocidad.
Verificación de ciclo cerrado. El parche no se considera desplegado hasta que se verifica su instalación en el endpoint, y la CVE no se cierra hasta que un nuevo análisis lo confirma. La mayoría de los equipos se saltan ese paso, por eso las evidencias de cumplimiento se convierten en una urgencia la semana anterior a la auditoría. Por eso esta semana hemos lanzado el cumplimiento continuo en nuestra plataforma: para que las evidencias de cumplimiento se generen de forma continua y automática a medida que se despliegan los parches, con la automatización encargándose de las decisiones de priorización para las que la mayoría de los equipos no tiene capacidad.

Las 271 vulnerabilidades de Firefox de Mozilla son un anticipo. Todos los grandes proveedores de software bajo Glasswing están a punto de empezar a corregir más vulnerabilidades y a un ritmo acelerado, y los atacantes con la misma clase de capacidad buscarán exactamente esas brechas siempre que obtengan acceso a un modelo similar. La carrera armamentística de IA resultante tendrá un efecto directo en el número y la frecuencia de las actualizaciones que las organizaciones tendrán que remediar, y a un ritmo acelerado. La automatización es lo que permite sostener un programa. A los equipos que todavía se limitan a aplicar parches mensualmente les espera una etapa complicada.

Si dirige un programa de TI o seguridad, merece la pena realizar la autoevaluación ahora. Tome el último parche crítico que desplegó. Mejor aún: si se publicara un zero-day un viernes, ¿podría remediarlo antes del lunes? Mida el tiempo desde la publicación de la CVE hasta la instalación verificada en el último endpoint. Si esa cifra se mide en semanas, el apocalipsis de los parches va a alcanzarle.

Soberanía digital y nube soberana: protección de los datos en la nube de la UE para la resiliencia operativa

Fri, 17 Apr 2026 12:30:01 Z

La protección de datos tradicional seguía un principio sencillo: los datos almacenados en el país A están protegidos por las leyes del país A; los datos almacenados en el país B están protegidos por las leyes del país B. Sin embargo, en la economía global actual, el lugar donde residen físicamente sus datos ya no determina qué gobiernos pueden exigir acceso a ellos.

La infraestructura en la nube ha introducido una nueva complejidad jurisdiccional. La ubicación física de los centros de datos, la nacionalidad de la sede del proveedor de nube y la entidad que controla las operaciones pueden generar reclamaciones jurisdiccionales contrapuestas, lo que podría permitir que varios gobiernos exijan acceso a los mismos datos.

¿Qué es la soberanía digital?

Este desafío tiene un nombre: soberanía digital. La soberanía digital es el principio según el cual las organizaciones mantienen el control total de sus datos dentro del marco legal de su jurisdicción de origen. Esta idea se ha convertido en una necesidad para la resiliencia organizativa, ya que las empresas operan en un mundo geopolítico más fragmentado y con menor confianza. Las organizaciones públicas y privadas necesitan acceso seguro a plataformas basadas en la nube que cumplan los requisitos normativos locales y estén protegidas frente a los riesgos geopolíticos, conocidos o desconocidos, a los que se enfrenta su región.

Cómo afecta la Ley CLOUD de EE. UU. a la residencia de los datos de la UE

La Ley CLOUD de EE. UU. de 2018 (Clarifying Lawful Overseas Use of Data Act) reforzó aún más estas preocupaciones para las organizaciones de la UE. Esta ley faculta a las fuerzas de seguridad de EE. UU. para obligar a cualquier proveedor de nube con sede en EE. UU. a entregar datos almacenados en cualquier lugar del mundo, con independencia de la ubicación física de los datos o de la nacionalidad del cliente.

Tanto la Ley CLOUD de EE. UU. como la Foreign Intelligence Surveillance Act (FISA) han generado motivos de preocupación para las empresas de la Unión Europea. A través de estas dos políticas, las autoridades estadounidenses podrían acceder a los datos contenidos en plataformas en la nube de cualquier organización con sede central en EE. UU., incluso cuando el centro de datos en la nube esté situado en otro país.

Para las empresas con sede en la UE, el uso de herramientas con sede en EE. UU. conlleva obligaciones específicas del RGPD porque los datos personales salen de la UE. Y desde que se invalidó el Escudo de Privacidad UE-EE. UU. (conocido como «Schrems II»), las empresas de la UE necesitan otras protecciones. Las cláusulas contractuales tipo (CCT) siguen siendo válidas, pero son condicionales y complejas, ya que requieren una revisión caso por caso.

Desde entonces se ha introducido un Marco de Privacidad de Datos posterior, pero la confianza subyacente entre los países implicados tiene sus límites. Estas dinámicas aumentaron la presión para garantizar la protección de los datos, por lo que se hicieron necesarias soluciones de nube soberana para garantizar la resiliencia operativa.

Ivanti Neurons for MDM – Sovereign Edition: diseñada para la soberanía en la nube de la UE

Para nuestros partners y clientes de la UE, Ivanti Neurons for MDM Sovereign Edition aborda estos requisitos mediante una arquitectura y unas operaciones fundamentalmente diferentes. Ubicada en Alemania y operada de forma independiente, esta solución se diseñó para alinearse con el Marco de Soberanía en la Nube de la Comisión Europea y ha sido evaluada por el prestigioso cyberintelligence.institute, cuya evaluación experta explica:

«Ivanti Sovereign Cloud demuestra un alto nivel de control europeo en las áreas de tratamiento de datos, seguridad y gobierno del cumplimiento. En su configuración actual, Ivanti Sovereign Cloud alcanza al menos la certificación SEAL 2, lo que significa que la soberanía de los datos está garantizada en todas las áreas. Además, Ivanti Sovereign Cloud cumple los requisitos de la certificación SEAL 3 en muchas áreas relevantes, logrando así resiliencia digital».

Puede leer la evaluación técnica completa para obtener más información.

Lograr el cumplimiento de la soberanía de los datos con confianza

Neurons for MDM – Sovereign Edition – EU proporciona a las empresas europeas una base estratégica para su plataforma de TI y seguridad de la mano de un líder de confianza, al tiempo que mantiene las protecciones jurisdiccionales locales para la gestión del riesgo. Esto significa que las entidades públicas y privadas pueden continuar su transformación digital con la confianza de que sus datos en la nube seguirán estando seguros mientras sus operaciones ganan resiliencia.

¿Cuáles son los próximos pasos? Lea nuestro informe técnico La nube soberana como necesidad estratégica para las organizaciones europeas, para descubrir cómo Ivanti Neurons for MDM Sovereign Edition alcanza y supera la certificación SEAL 2, y proporciona la arquitectura de nube soberana que las organizaciones europeas necesitan para mantener la soberanía de los datos y, al mismo tiempo, hacer posible una transformación digital segura.

Trusted Ownership: cómo Ivanti Application Control escala más allá de las listas de permitidos

Wed, 25 Feb 2026 14:25:15 Z

El control de aplicaciones es uno de esos temas de seguridad sobre los que muchas personas siguen teniendo ideas preconcebidas. Las listas de permitidos tradicionales parecen seguras, pero se convierten rápidamente en una carga de mantenimiento. Las listas de bloqueados resultan reactivas e incompletas. Y, aunque herramientas como Microsoft AppLocker llevaron a muchos a pensar que las listas de permitidos estrictas eran el estándar de referencia, los ataques modernos han demostrado lo contrario. Los atacantes recurren cada vez más a herramientas legítimas y firmadas —utilizadas en el contexto incorrecto— para eludir por completo los controles basados en listas.

Por eso, cuando las organizaciones evalúan Ivanti Application Control o Ivanti Neurons for App Control y se encuentran con Trusted Ownership, al principio puede parecerse a las listas de bloqueados porque permite bloqueos explícitos. En realidad, Trusted Ownership es un modelo de aplicación de políticas basado en la procedencia mucho más amplio y mucho más ligero desde el punto de vista operativo, que controla la ejecución en función del origen, no solo de la identidad.

En lugar de gestionar listas cada vez más extensas, aplica la seguridad en función de quién ha colocado el software en el sistema, alineándose de forma clara con las prácticas modernas de distribución de software y los principios de zero trust. La mejor forma de entenderlo no es como otro mecanismo de listas, sino como un modelo de aplicación de políticas basado en la procedencia que controla la ejecución en función del origen, no solo de la identidad.

Ese cambio de enfoque conduce a una pregunta más adecuada para el control de aplicaciones moderno: no solo qué es un archivo, sino cómo ha llegado hasta ahí.

Más allá de las listas: por qué el control de procedencia es ahora importante

La pregunta de cómo llegó un archivo al sistema está en el centro del control de procedencia. En lugar de confiar en los archivos basándose únicamente en el editor, la ruta o el hash, el control de procedencia evalúa el origen y el proceso que los introdujeron. ¿Quién escribió el archivo en el disco? ¿A través de qué mecanismo? ¿La instalación siguió un flujo de trabajo de TI controlado? Esta evaluación desplaza el control de aplicaciones de la confianza en el objeto a la confianza en el proceso, creando un límite de seguridad mucho más sólido.

En Ivanti Application Control, el control de procedencia se implementa como Trusted Ownership. Se permite cualquier archivo colocado por un propietario de confianza; todo lo introducido por un usuario se deniega de forma predeterminada. Esto se aplica de forma coherente a ejecutables, DLL, instaladores y scripts. Como identidades como SYSTEM, TrustedInstaller y Administrators son de confianza de forma predeterminada, el software entregado a través de canales de implementación estándar como MS Intune, MECM, Ivanti Endpoint Manager (EPM) u otras herramientas empresariales se ejecuta de inmediato sin mantenimiento de reglas ni excepciones.

Esto marca una ruptura fundamental con las listas de permitidos clásicas. Las reglas de AppLocker dependen por completo de definiciones exactas de editor, ruta o hash. No evalúa el origen de la instalación ni confía automáticamente en sus mecanismos de implementación. El software entregado por Intune sigue requiriendo una regla de permiso preexistente, a menudo basada en valores predeterminados amplios que permiten los directorios Program Files o Windows.

Esa distinción es importante porque los ataques modernos convierten cada vez más herramientas legítimas en armas en contextos inadecuados. El control de procedencia neutraliza gran parte de ese riesgo al exigir confianza en cómo llega el software, no solo en qué es. Se alinea con los principios de zero trust, reduce la exposición de la cadena de suministro y limita drásticamente, de forma predeterminada, las oportunidades de abuso mediante Living off the Land (LotL).

Una vez que se comprende la importancia del origen, la siguiente pregunta es: ¿cómo se aplica a escala?

La respuesta: aplicar la procedencia de forma coherente a todas las formas en que el software se ejecuta y se entrega.

Más allá de las listas de bloqueados: cobertura amplia diseñada para la implementación moderna de software

El control de procedencia desplaza la seguridad de las aplicaciones de la gestión de listas interminables a la validación del proceso por el que el software llega al sistema. Una vez adoptada esta perspectiva, queda claro que Trusted Ownership no es un enfoque de listas de bloqueados. Es un límite de confianza basado en el origen que se comporta de forma muy distinta a las listas de permitidos tradicionales.

Un error habitual es pensar que Trusted Ownership se parece a las listas de bloqueados porque los administradores a veces añaden reglas de denegación específicas para herramientas conocidas de Windows. En la práctica, estas reglas de denegación son medidas de refuerzo defensivo frente a técnicas Living off the Land. Todo método serio de control de aplicaciones utiliza este tipo de restricciones específicas. El núcleo de Trusted Ownership es lo contrario de las listas de bloqueados. El software entregado mediante un proceso controlado y de confianza se permite de forma predeterminada, mientras que el contenido introducido por el usuario se deniega de forma predeterminada.

Un diferenciador más importante es la cobertura. Muchas organizaciones que dependen de listas de permitidos clásicas acaban centrándose casi exclusivamente en archivos ejecutables. A menudo evitan aplicar el mismo cumplimiento a DLL, scripts y paquetes MSI porque estos tipos de archivo complican mucho más el mantenimiento de reglas. Esto crea brechas que los atacantes modernos explotan con frecuencia.

Trusted Ownership evita estas brechas aplicando el mismo cumplimiento basado en el origen a toda la cadena de ejecución. Ejecutables, DLL, scripts, instaladores MSI y componentes relacionados se evalúan mediante el mismo modelo de confianza. Como la confianza viene determinada por quién introdujo el archivo, no hacen falta políticas independientes para cada tipo de archivo. Un script en la carpeta Descargas, una DLL creada en un directorio de compilación temporal o un EXE ejecutado desde un perfil de usuario reciben el mismo tratamiento de denegación predeterminada cuando se originan fuera de un proceso de instalación controlado.

Este modelo de confianza también se alinea de forma natural con la manera en que las plataformas modernas de gestión de endpoints entregan software. Soluciones como Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager y sistemas similares suelen instalar aplicaciones utilizando la identidad SYSTEM u otra cuenta de servicio de confianza.

Como estas identidades ya son propietarios de confianza, el software implementado a través de estos canales se ejecuta de inmediato sin crear reglas de permiso, mantener rutas de archivo ni actualizar políticas. Solo cuando se utilizan de forma intencionada cuentas de instalación alternativas, como agentes DevOps personalizados o instalaciones mediante scripts en contexto de usuario, es necesario identificar esa identidad como propietario de confianza.

El resultado es un modelo con una cobertura amplia y coherente en todos los tipos de archivo relevantes. Funciona sin fisuras con las distribuciones modernas de software y evita la sobrecarga operativa asociada a las listas de permitidos clásicas, que se centran principalmente en archivos ejecutables.

Trusted Ownership deposita la confianza no en objetos individuales, sino en los procesos controlados mediante los que se entrega el software, creando un enfoque más escalable y más seguro para el control de aplicaciones.

Dónde encaja WDAC (App Control for Business)

Microsoft mantiene dos tecnologías de control de aplicaciones: AppLocker y App Control for Business (anteriormente WDAC). Aunque ambas siguen existiendo, Microsoft es clara sobre sus funciones. AppLocker ayuda a impedir que los usuarios ejecuten aplicaciones no aprobadas, pero no cumple los criterios de mantenimiento de las características de seguridad modernas y, por tanto, se clasifica como un mecanismo de defensa en profundidad, no como un control de seguridad estratégico.

La vía de futuro de Microsoft para el control de aplicaciones es App Control for Business, y la compañía indica explícitamente que AppLocker tiene las funciones completas y ya no está en desarrollo activo, más allá de las actualizaciones de seguridad esenciales. Esto significa que todas las nuevas capacidades se entregan solo en WDAC y no en AppLocker.

App Control for Business introduce el concepto de Managed Installer. Esto permite que Windows confíe automáticamente en las aplicaciones instaladas a través de plataformas de implementación designadas, como Intune o MECM. La confianza se deriva del canal de distribución y no de archivos individuales, lo que reduce significativamente el mantenimiento de reglas.

Esto se alinea estrechamente con el modelo Trusted Ownership de Ivanti Application Control. Ambos enfoques confían en el software en función del proceso controlado que lo instaló, en lugar de basarse en atributos de archivo discretos. Sin embargo, Trusted Ownership aplica este concepto de una forma más sencilla y accesible desde el punto de vista operativo. Ivanti confía en identidades como SYSTEM y cuentas de servicio designadas sin requerir capas de políticas complejas, definiciones XML ni conocimientos profundos de WDAC.

Ivanti escucha a muchas organizaciones que tienen dificultades para poner WDAC en funcionamiento. Las políticas de WDAC requieren un diseño cuidadoso, pruebas prolongadas en modo auditoría, gestión de excepciones de controladores y kernel, y mantenimiento continuo de varios conjuntos de políticas. Esto suele llevar a las organizaciones a combinar WDAC con AppLocker para cubrir tanto el cumplimiento de bajo nivel como el control cotidiano del espacio de usuario, lo que termina generando sobrecarga administrativa.

Ivanti Application Control ofrece una alternativa unificada. Mediante Trusted Ownership, Trusted Vendors y la validación de firmas digitales, proporciona un modelo de denegación predeterminada basado en la procedencia, con cobertura coherente en ejecutables, DLL, scripts y paquetes MSI.

En lugar de mantener dos planos de control de Microsoft con ámbitos diferentes, las organizaciones gestionan una única política simplificada que aplica la confianza en función de cómo se introduce el software en el sistema. Esto proporciona muchos de los objetivos prácticos que los clientes intentan lograr con una implementación combinada de WDAC y AppLocker, pero con menor complejidad operativa y un único modelo de confianza cohesionado.

LOLBins y control a nivel de argumentos

Con una cobertura amplia ya establecida, la cuestión pasa a ser cómo gestionar las herramientas legítimas que ya están en todos los equipos y de las que los atacantes suelen abusar.

Los atacantes modernos a menudo evitan utilizar malware tradicional y, en su lugar, recurren a las herramientas ya presentes en todos los dispositivos Windows. Estas herramientas Living off the Land (LOLBins) son legítimas y necesarias para las operaciones normales, lo que dificulta bloquearlas sin afectar a la productividad. Las listas de permitidos tradicionales tienen dificultades en este punto porque un bloqueo amplio interrumpe los flujos de trabajo, mientras que una permisividad amplia deja brechas peligrosas.

Un modelo basado en la procedencia como Trusted Ownership cambia esta dinámica. Incluso si un atacante intenta utilizar una herramienta integrada, el contenido que trata de ejecutar normalmente no procede de un proceso de instalación de confianza. Como Ivanti evalúa el origen de ese contenido, la mayoría de los intentos de uso indebido fallan automáticamente. La herramienta puede ser legítima, pero el contenido que se le pide ejecutar no lo es, y Trusted Ownership lo detiene antes de que se ejecute.

También es importante entender no solo qué herramientas se ejecutan, sino qué se les pide que hagan. Muchos intérpretes y entornos de ejecución, como PowerShell, Python o Java, pueden ser perfectamente seguros en un contexto y arriesgados en otro. Una aplicación empresarial puede depender de Java para iniciar un proceso específico y aprobado, mientras que un archivo JAR descargado por un usuario es un escenario totalmente distinto.

Ivanti aborda esto mediante un enfoque por capas. Un archivo JAR se evalúa primero con Trusted Ownership, que lo bloquea de inmediato si lo introdujo un usuario y no un proceso de implementación controlado. Además, los administradores pueden crear reglas de permiso sencillas que especifiquen exactamente qué comandos de Java están permitidos, garantizando que solo se ejecuten aplicaciones legítimas basadas en Java, mientras que los intentos de iniciar archivos JAR no aprobados se deniegan de forma silenciosa.

El mismo principio se aplica también a otras herramientas. Las políticas pueden aprobar el comportamiento exacto que necesita su organización y bloquear las actividades que quedan fuera de esos límites. Esto evita reglas amplias y frágiles, y mantiene el trabajo diario funcionando sin interrupciones.

El resultado es un enfoque equilibrado y moderno. Trusted Ownership detiene por defecto el contenido que no es de confianza. El refuerzo específico se alinea con las mejores prácticas gubernamentales y de la comunidad para reducir el abuso de técnicas Living off the Land, y los controles sensibles a la intención garantizan que los procesos legítimos sigan funcionando sin abrir puertas a los atacantes.

Este enfoque se alinea estrechamente con las guías actuales de la comunidad y de organismos públicos sobre la mitigación de técnicas Living off the Land. Agencias como CISA, NSA, FBI y el Australian Cyber Security Centre hacen hincapié en reducir las oportunidades de los atacantes para utilizar herramientas integradas, controlando cómo se usan y restringiendo el contenido no confiable sobre el que actúan. Sus guías conjuntas destacan que los ataques LOTL dependen del abuso de herramientas nativas e insisten en la necesidad de controles que limiten ese uso indebido sin bloquear procesos legítimos del sistema.

El modelo de Ivanti refleja estas guías. Trusted Ownership bloquea automáticamente el contenido no confiable del que dependen los atacantes, mientras que un pequeño número de restricciones específicas aborda el reducido conjunto de herramientas que requieren atención adicional.

Trusted Ownership en acción: escenarios reales

Estos son algunos ejemplos operativos de cómo funcionan Ivanti Application Control y Trusted Ownership en la práctica.

Se copia una aplicación portátil en el perfil de usuario. Ivanti la bloquea porque es propiedad del usuario. AppLocker solo la bloquea si existen reglas coincidentes. Sin las reglas de ruta o editor adecuadas, el comportamiento puede variar.
Un adjunto de correo electrónico inicia un script de PowerShell desde Descargas. Ivanti lo deniega debido a la propiedad del usuario. AppLocker depende de las reglas de script y, en eventos de bloqueo, fuerza PowerShell al modo Constrained Language Mode, que seguirá ejecutando el script.
Abuso de herramientas del sistema operativo como rundll32 o mshta. Ambos modelos necesitan refuerzo de denegación específico. Ivanti lo combina con el control de procedencia, que por lo general reduce el número de excepciones necesarias. AppLocker depende de conjuntos de denegación seleccionados y requiere ajustes periódicos.
Una actualización de proveedor entrega nuevos archivos firmados. Ivanti permite la actualización cuando llega a través del canal de implementación de confianza gracias a Trusted Ownership. AppLocker puede adaptarse a esto con reglas de editor, pero la reutilización de firmas en varios productos o las rutas de instalación poco habituales suelen generar mantenimiento adicional y una confianza más amplia de lo previsto.
Un usuario descarga un JAR e intenta ejecutarlo con Java. Ivanti bloquea el intento porque el JAR ha sido introducido por el usuario y no supera Trusted Ownership. Si es necesario, los administradores pueden permitir solo la invocación aprobada exacta haciendo coincidir la línea de comandos completa. AppLocker no puede comparar argumentos y depende de reglas de editor, ruta o hash.

Conclusión

El control de procedencia desplaza el control de aplicaciones de un problema de gestión a un modelo de confianza. En lugar de confiar en archivos individuales, confía en el proceso por el que el software llega a un sistema, lo que hace que la seguridad sea escalable y viable.

Trusted Ownership encaja plenamente en este enfoque. No es una lista de bloqueados ni una lista de permitidos clásica, sino un modelo en el que el software que llega mediante un proceso de TI controlado se permite de forma predeterminada, mientras que todo lo que queda fuera de ese proceso se deniega de forma predeterminada. Al aplicar el control sobre el origen y la propiedad, en lugar de sobre archivos ad hoc, Ivanti Application Control e Ivanti Neurons for App Control se alinean mucho mejor con las técnicas de ataque modernas y con la distribución de software actual.

Si se sigue tratando el control de aplicaciones como un ejercicio de gestión de listas, se notará la carga administrativa. Si se trata como un límite de confianza, se obtiene escalabilidad, seguridad y viabilidad operativa.

Cómo quieren los CEO que los CISO comuniquen la estrategia de gestión del riesgo de ciberseguridad

Tue, 17 Feb 2026 13:00:01 Z

La mayoría de los CEO pueden recitar sus indicadores trimestrales y sus ingresos hasta el último decimal, pero, si se les pregunta por la exposición al riesgo cibernético de su organización, las respuestas se vuelven más imprecisas. No es que a los CEO actuales no les importe la seguridad: la ciberseguridad se encuentra entre las principales preocupaciones de los consejos de administración y los equipos ejecutivos. El problema es más profundo: una ruptura fundamental en la forma en que se explican los riesgos de seguridad a los líderes empresariales, que pasa por alto el impacto en sus resultados de negocio.

La falta de competencia no es la causa de la mayoría de los problemas de comunicación entre CISO y CEO. Estos surgen de un problema conocido: la maldición del conocimiento. La maldición del conocimiento es un reto común por el que los expertos —en este caso, los responsables de seguridad— pueden asumir que todos los presentes tienen una comprensión básica de la información y la terminología técnicas, por lo que no explican los riesgos complejos en un lenguaje sencillo ni aportan contexto del mundo real.

El Informe del estado de la ciberseguridad de 2026 de Ivanti pone de relieve esta desconexión. Casi seis de cada diez profesionales de seguridad afirman que sus equipos son solo moderadamente eficaces a la hora de comunicar la exposición al riesgo a la dirección ejecutiva.

Cuando CEO y CISO no hablan el mismo idioma, las vulnerabilidades críticas para el negocio pueden quedar ocultas tras la jerga técnica. Cuando falla la comunicación, las organizaciones pierden tiempo y dinero en inversiones mal orientadas, mientras las brechas de protección pasan desapercibidas hasta que una filtración obliga a abordar la conversación.

Con el aumento de los niveles de amenaza, los ataques habilitados por IA son cada vez más sofisticados y las filtraciones de datos ocupan titulares cada semana. Nunca ha sido tan importante que exista una comunicación clara entre los CISO y la dirección ejecutiva.

Para entender por qué persiste esta brecha de comunicación, debemos examinar tanto los retos fundamentales como las métricas utilizadas para medir el éxito.

Por qué falla la comunicación del riesgo cibernético: la maldición del conocimiento

Esa desconexión entre CEO y CISO no se debe a la falta de datos. De hecho, es lo contrario. Desde la perspectiva del CEO, el reto no es la atención ni la intención, sino ver paneles, métricas, acrónimos y puntuaciones de gravedad sin comprender el impacto de esos resultados en todo el negocio.

Los responsables de seguridad deben asumir que muchas personas presentes no comprenden las implicaciones de términos como puntuaciones CVSS, superficies de ataque y vulnerabilidades de día cero. Los CEO necesitan algo más que paneles llenos de métricas, acrónimos y puntuaciones de gravedad.

Los informes de ciberseguridad deben ir un paso más allá y demostrar las implicaciones financieras, legales y reputacionales de estos resultados para el negocio. Un CISO podría informar de que se han detectado «587 vulnerabilidades críticas este mes», cuando lo que el CEO realmente necesita saber es: «¿Cuáles de ellas amenazan nuestra capacidad para atender a los clientes y cuál es nuestro plan para abordarlas?»

KPI de ciberseguridad que importan a los CEO

Los KPI útiles conectan claramente los esfuerzos de gestión de vulnerabilidades con el riesgo empresarial. Sin embargo, nuestra investigación sobre ciberseguridad revela que los KPI más utilizados por los equipos de seguridad no reflejan el contexto del riesgo.

Actualmente, solo la mitad de las empresas (51 %) realiza un seguimiento de las puntuaciones de exposición de ciberseguridad u otros índices basados en el riesgo. Muchos equipos de seguridad siguen dependiendo de métricas de proceso, como el tiempo medio de remediación (47 %) o el porcentaje de exposiciones remediadas (41 %).

Métricas como el MTTR, la velocidad de aplicación de parches y el porcentaje remediado son importantes para los equipos de seguridad, pero miden la eficiencia operativa, no la exposición del negocio ni el posible impacto financiero. Por sí solas, pueden parecer tranquilizadoras mientras ocultan la verdadera pregunta: ¿estamos gestionando nuestro riesgo de forma eficaz?

Estas métricas, que se centran en la velocidad y la cobertura, pueden parecer positivas por sí mismas, pero aportan poco para demostrar si los esfuerzos actuales de remediación realmente mejoran la postura de riesgo. Importa menos la rapidez con que se remedian las vulnerabilidades y cuántas se abordan. Lo que importa más es si se están abordando los problemas adecuados.

Una comprensión compartida entre los equipos de seguridad, el consejo de administración y la alta dirección exige situar las métricas difíciles de interpretar en un contexto de consecuencias reales. Para los CEO, esto significa alinearse con su CISO en torno a los riesgos más importantes para su organización concreta: ¿es usted una entidad financiera que se enfrenta con frecuencia a sofisticados esquemas de fraude, estrictos requisitos de cumplimiento como PCI-DSS y SOX, y la amenaza constante de ransomware dirigido a los datos financieros de los clientes?¿Es usted una organización sanitaria que debe proteger una red en expansión de dispositivos médicos conectados, manteniendo al mismo tiempo rigurosos estándares de cumplimiento para proteger datos confidenciales de pacientes?

Ilustremos la diferencia entre un informe ejecutivo de seguridad que se basa únicamente en métricas técnicas y otro que añade contexto e impacto empresarial.

Lo que dice el CISO:

«Hemos descubierto 11.000 vulnerabilidades».
«El MTTR se ha reducido de 25 a 15 días».
«Hemos alcanzado una tasa de remediación del 88 % en CVE críticas».

Lo que el CEO realmente necesita saber:

«Hemos identificado diez vulnerabilidades críticas que podrían afectar a sistemas generadores de ingresos».
«Si sufriéramos un ataque hoy, podríamos restaurar las operaciones críticas en seis horas, frente a las 48 horas del año pasado».
«Esta protección nos permite avanzar en la expansión en la UE sin riesgos de cumplimiento adicionales».

Crear un marco de apetito de riesgo a nivel ejecutivo

La comunicación ejecutiva depende de marcos compartidos y de un punto de referencia común sobre cómo se define, mide y analiza el riesgo. Para eliminar incoherencias y confusiones, todas las partes interesadas deben participar en la creación y aplicación de un marco de apetito de riesgo.

Uno de los principales objetivos de estas conversaciones es ayudar a los líderes empresariales a comprender que el objetivo del programa de ciberseguridad no es estar completamente «libre de riesgos»; es imposible que cualquier organización moderna lo esté por completo. En otras palabras, los CEO deben ser capaces de distinguir entre su apetito de riesgo y su postura de riesgo.

1. Apetito de riesgo: cuánto riesgo está dispuesta a tolerar actualmente su empresa para alcanzar sus objetivos generales.

2. Postura de riesgo: la realidad de la exposición al riesgo actual de la organización.

La mayoría de las organizaciones ya reconoce la necesidad de formalizar cuánto riesgo cibernético está dispuesta a aceptar. La investigación de Ivanti muestra que más del 80 % de las organizaciones cuenta con un marco de apetito de riesgo documentado.

Sin embargo, menos de la mitad de las organizaciones afirma que estos marcos se siguen de cerca en las operaciones diarias. Cuando los marcos existen sobre el papel, pero no guían las decisiones reales, es muy probable que el apetito de riesgo y la postura de riesgo de su organización no estén alineados.

Cómo la gestión de la exposición salva la brecha de comunicación

La gestión de la exposición es un enfoque basado en el riesgo que identifica, prioriza y valida de forma continua el alcance de las amenazas potenciales en toda la superficie de ataque. Practicar la gestión de la exposición ayuda a unir a los responsables de seguridad y a los líderes ejecutivos en torno a una estrategia única e integral que reorienta la ciberseguridad hacia el riesgo crítico para el negocio.

En lugar de tratar todas las vulnerabilidades por igual, la gestión de la exposición se centra en identificar y priorizar los mayores riesgos de la organización mediante estas preguntas:

¿Qué exposiciones actuales están explotando los actores de amenazas en entornos reales?
¿Qué activos deben priorizarse en función de las operaciones empresariales actuales?
¿Qué activos, si se vieran comprometidos, tendrían el mayor impacto en términos de daños reputacionales, para los clientes o legales?

El informe de investigación de Ivanti muestra que casi dos tercios de las organizaciones ya invierten en gestión de la exposición, y que la comprensión por parte de la dirección ha aumentado año tras año. Pero la ejecución sigue rezagada: solo alrededor de una cuarta parte de las organizaciones califica su capacidad para evaluar la exposición al riesgo como excelente.

Para cerrar esa brecha y poner en práctica la gestión de la exposición de forma eficaz, los CISO deben articular la comunicación ejecutiva en torno a tres principios

1. Traduzca las señales técnicas al contexto empresarial. En lugar de informar de recuentos de vulnerabilidades, explique qué exposiciones afectan a sistemas generadores de ingresos, datos de clientes o entornos regulados.

2. Priorice las amenazas emergentes por impacto, no por volumen. Los ejecutivos no necesitan hacer seguimiento de cada nueva técnica de ataque. Necesitan entender qué situaciones podrían interrumpir materialmente el negocio y hasta qué punto está preparada la organización para responder.

3. Use escenarios, no hojas de cálculo. Las narrativas que conectan causa, impacto y resultado, respaldadas por datos, ayudan a los líderes a interiorizar el riesgo y tomar decisiones más rápidas.

Este enfoque transforma su estrategia de mitigación del riesgo, pasando de una defensa reactiva a una toma de decisiones proactiva.

El camino a seguir

Cuando los ejecutivos y los responsables de seguridad hablan el mismo idioma, la maldición del conocimiento puede superarse y la ciberseguridad se convierte en un habilitador estratégico que protege el valor del negocio, impulsa el crecimiento y transforma la fortaleza en seguridad en una ventaja competitiva.

La maldición del conocimiento puede superarse: una métrica traducida, una conversación centrada en el negocio y una decisión clara cada vez.

Gestión de la exposición frente a gestión de vulnerabilidades: ¿cuál ofrece una reducción real del riesgo?

Thu, 29 Jan 2026 13:00:01 Z

La gestión de vulnerabilidades lleva años prestando servicio a las organizaciones y al sector de la ciberseguridad. Es una práctica eficaz que ha ayudado a las empresas a defender su superficie de ataque y a impedir que los actores de amenazas exploten vulnerabilidades.

Pero la tecnología y la infraestructura de TI han evolucionado. La gestión de vulnerabilidades ya no puede responder a los desafíos que plantea esta evolución. Ahora, la gestión de la exposición ofrece un enfoque aún más holístico de la seguridad de endpoints que cubre las áreas en las que la gestión de vulnerabilidades se queda corta.

Analicemos las diferencias para que pueda decidir cómo proteger su organización.

¿Qué es la gestión de vulnerabilidades?

La gestión de vulnerabilidades es una práctica de ciberseguridad que incluye la identificación, evaluación, priorización y remediación continuas y proactivas de las vulnerabilidades que los hackers pueden utilizar para infiltrarse en su organización.

No obstante, es importante señalar que existen dos tipos diferentes de gestión de vulnerabilidades:

Gestión de vulnerabilidades tradicional

Gestión de vulnerabilidades basada en el riesgo

Consiste en intentar remediar el mayor número posible de vulnerabilidades. Esto suele traducirse en un esfuerzo considerable y en expectativas de éxito poco realistas, al tiempo que genera una falsa sensación de seguridad.

Una práctica evolucionada de gestión de vulnerabilidades que tiene en cuenta el riesgo al priorizar las vulnerabilidades. Esto permite a las organizaciones aplicar parches a las vulnerabilidades críticas que suponen una amenaza real, protegiendo su organización frente a los actores de amenazas y, al mismo tiempo, garantizando una postura de seguridad sólida y una gestión eficaz de los recursos.

Un enfoque de gestión de vulnerabilidades basada en el riesgo va más allá de la gestión de vulnerabilidades tradicional y aporta a su organización las siguientes ventajas:

Supervisa continuamente las vulnerabilidades para ofrecer una seguridad proactiva.
Identifica exposiciones explotadas activamente.
Permite realizar esfuerzos de remediación eficaces.
Reduce el riesgo.
Ayuda a las organizaciones a alcanzar el cumplimiento normativo.

Aunque la gestión de vulnerabilidades basada en el riesgo cubre muchos aspectos, sigue sin ofrecer el enfoque holístico de ciberseguridad que las organizaciones necesitan para mantenerse protegidas y seguras. Ahí es donde entra en juego la gestión de la exposición.

¿Qué es la gestión de la exposición?

La gestión de la exposición es una práctica de ciberseguridad en evolución que proporciona visibilidad integral de toda la superficie de ataque. Permite a los equipos de TI y seguridad identificar exactamente dónde puede estar expuesta su organización, e incluye priorización basada en el riesgo, remediación y mucho más. La gestión de la exposición se centra en mantener el apetito de riesgo que la propia organización ha definido. Por tanto, abarca cuatro fases:

Al igual que la gestión de vulnerabilidades basada en el riesgo, la gestión de la exposición ayuda a priorizar qué vulnerabilidades y exposiciones deben abordarse primero en función del riesgo real, pero va más allá al tener en cuenta lo que resulta más relevante para su empresa concreta. Este enfoque de ciberseguridad garantiza que las exposiciones de mayor riesgo se remedien de forma proactiva, antes de que los atacantes puedan explotarlas.

Gestión de la exposición frente a gestión de vulnerabilidades: ¿cuál es la diferencia?

La gestión de la exposición representa la siguiente evolución más allá de la gestión de vulnerabilidades tradicional. Mientras que la gestión de vulnerabilidades se centra principalmente en identificar y abordar debilidades en servidores y endpoints, la gestión de la exposición amplía este alcance al ofrecer visibilidad completa de toda la superficie de ataque.

Entre las principales diferencias se incluyen las siguientes:

La gestión de la exposición está diseñada para tipos de activos más recientes: Los entornos de TI modernos son cada vez más complejos e incluyen ahora activos como aplicaciones de software como servicio (SaaS), dispositivos IoT, infraestructura en la nube y mucho más. La gestión de la exposición está diseñada para tener en cuenta estos tipos de activos más recientes, lo que garantiza que los equipos de TI y seguridad puedan identificar los riesgos allí donde existan dentro de la organización. Al hacerlo, la gestión de la exposición proporciona una comprensión completa de todos los posibles puntos de entrada. Esto permite a las organizaciones gestionar y reducir el riesgo con más eficacia que nunca.
La gestión de la exposición entiende la realidad y promueve un enfoque basado en el apetito de riesgo: Como hemos visto, la gestión de vulnerabilidades se centra en aplicar parches a las vulnerabilidades. Aunque la gestión de vulnerabilidades basada en el riesgo ofrece priorización del riesgo y orquestación de la remediación, esta práctica no reconoce que no es realista que una organización aplique parches a todas las vulnerabilidades. El término apetito de riesgo hace referencia a la medida, definida por la propia organización, de cuánto riesgo está dispuesta a aceptar. Se trata de un enfoque mucho más realista que alinea a toda la organización en torno a KPI compartidos para medir el éxito de forma coherente entre equipos.
La gestión de la exposición va más allá de las CVE y el CVSS: La gestión de vulnerabilidades se centra principalmente en las vulnerabilidades y exposiciones comunes (CVE). Aunque las CVE son un objetivo importante para la mayoría de las organizaciones, no son los únicos catalizadores que los actores de amenazas pueden utilizar para causar daños a su organización. Los hackers también pueden aprovechar las siguientes exposiciones (que la gestión de vulnerabilidades no cubre) para infiltrarse en su organización:
Configuraciones incorrectas.
seguridad de las aplicacionesProblemas de
Políticas de sistemas de TI.
Controles de acceso privilegiado.

Volviendo al enfoque holístico, la gestión de la exposición cubre todos estos activos modernos. Además, la gestión de vulnerabilidades depende en gran medida del Common Vulnerability Scoring System (CVSS) para priorizar la remediación. Aunque el CVSS es una medida sólida de la gravedad, proporciona una perspectiva eficaz ajustada al riesgo.

El riesgo es un factor importante que debe tenerse en cuenta, ya que incluye si una vulnerabilidad se ha explotado, si está vinculada a ransomware/malware o si está generando tendencia en ese momento. No tener en cuenta el riesgo crea una falsa sensación de urgencia con el CVSS, lo que lleva a los equipos de TI y seguridad a perder tiempo y recursos en vulnerabilidades que no son realmente urgentes.

Cómo proteger su organización

Ahora que hemos repasado las diferencias entre la gestión de la exposición y la gestión de vulnerabilidades, es el momento de aprovechar las ventajas que ofrece la gestión de la exposición. Descubra cómo el portfolio de gestión de la exposición de Ivanti puede impulsar a sus equipos de TI y seguridad.

Secuestro de DLL: riesgos, ejemplos reales y cómo prevenir ataques

Wed, 17 Dec 2025 14:00:02 Z

Ha habido bastante expectación en torno a CVE-2025-56383 (publicada el 26 de septiembre de 2025), una vulnerabilidad de secuestro en Notepad++ v8.8.3 en la que un archivo DLL puede sustituirse para ejecutar código malicioso.

La CVE ha sido cuestionada por varias partes, pero no estamos aquí para pronunciarnos al respecto. Sí queremos, en cambio, hablar del secuestro de DLL y analizar la amenaza muy real que supone para una organización. Veamos qué es el secuestro de DLL y qué medidas puede adoptar para mantener sus DLL protegidas.

Qué es el secuestro de DLL y cómo se produce

El secuestro de DLL (también conocido como ataque de precarga de DLL) es una vulnerabilidad de seguridad en la que un archivo legítimo y de confianza de una biblioteca de vínculos dinámicos (DLL) de una aplicación Windows se sustituye por uno malicioso.

Este método aprovecha la forma en que las aplicaciones cargan archivos DLL, que contienen código y datos utilizados por varios programas. Al cargar una DLL maliciosa, un actor de amenazas puede ejecutar su propio código con los mismos privilegios que la aplicación legítima, lo que deriva en escalada de privilegios, persistencia y evasión de defensas.

Cuando se inicia un programa, a menudo necesita cargar varias DLL para realizar funciones específicas, normalmente desde directorios del sistema de confianza. Sin embargo, si una aplicación no controla cuidadosamente dónde busca estas DLL, podría cargar una DLL maliciosa desde una ubicación insegura o predecible (es decir, el directorio de trabajo actual o un recurso compartido de red). Esto puede ocurrir si la aplicación no especifica la ruta completa a la DLL o si la busca en un directorio al que un atacante puede acceder o modificar.

Aunque este tipo de ataque no es nuevo, sigue siendo eficaz por su sencillez. Y aunque este problema concreto afecta a aplicaciones Windows, es importante señalar que vulnerabilidades similares pueden afectar a otros sistemas operativos (como Linux y macOS, que utilizan carga dinámica para bibliotecas compartidas).

El secuestro de DLL introduce múltiples riesgos de seguridad, entre ellos:

Robo de datos: La DLL maliciosa puede interceptar y robar datos confidenciales, como contraseñas o información personal.
Sistemas comprometidos: El atacante puede obtener control sobre el sistema, lo que podría dar lugar a nuevos ataques o a la instalación de malware adicional.
Malware: La DLL maliciosa puede actuar como canal para propagar malware e infectar otras partes del sistema o de la red.

Una DLL puede secuestrarse de varias formas; estas son algunas de las técnicas más habituales:

Orden de búsqueda de DLL inseguro: Los atacantes colocan DLL maliciosas en directorios que se buscan antes que la ubicación de la DLL legítima.
Manipulación de rutas relativas: Las DLL maliciosas se cargan cuando las aplicaciones utilizan rutas relativas.
Redirección de DLL: Técnicas como la manipulación de rutas redirigen el proceso de carga de DLL.
Permisos débiles: Los atacantes sustituyen DLL legítimas por otras maliciosas en directorios con permisos débiles.
Secuestro de DLL fantasma: Los atacantes aprovechan aplicaciones que cargan DLL inexistentes colocando DLL maliciosas con el mismo nombre en los directorios de búsqueda.

Estas posibles vulnerabilidades ponen de relieve la importancia de las prácticas de codificación segura y la gestión de permisos de directorio a la hora de prevenir esta forma de ataque.

Cómo prevenir el secuestro de DLL y mantener sus DLL protegidas y seguras

Aunque el secuestro de DLL sigue siendo una amenaza, existen prácticas recomendadas que puede seguir e implementar para reducir el riesgo y lograr un entorno de TI más seguro y protegido.

Carga segura de DLL:

Utilizar rutas completas: Especifique siempre la ruta completa a la DLL al cargarla. Esto garantiza que la aplicación cargue la DLL desde una ubicación de confianza (y no desde un directorio inseguro).
Configurar la ruta de búsqueda segura: Utilice la función SetDllDirectory en Windows para añadir directorios de confianza a la ruta de búsqueda y excluir los inseguros. Esto puede ayudar a evitar que la aplicación cargue DLL desde ubicaciones inesperadas.

Comprobaciones de integridad de archivos:

Firmas digitales: Asegúrese de que las DLL estén firmadas con una firma digital y verifique la firma antes de cargar la DLL. Esto puede ayudar a confirmar que la DLL no ha sido manipulada.
Verificación de hash: Utilice funciones hash criptográficas para verificar la integridad de los archivos DLL. Si el hash de la DLL no coincide con el valor esperado, es posible que el archivo se haya modificado.

Permisos de usuario:

Principio de mínimo privilegio: Ejecute las aplicaciones con el mínimo privilegio necesario. Esto limita el posible daño de un secuestro de DLL, ya que el código malicioso tendrá menos permisos para ejecutar acciones perjudiciales.
Control de cuentas de usuario (UAC): Active UAC en sistemas Windows para solicitar permiso a los usuarios antes de ejecutar aplicaciones con privilegios elevados. Esto puede ayudar a evitar cambios no autorizados en los archivos del sistema.

Control de aplicaciones y gestión de privilegios:

Aplicaciones conocidas y de confianza: El control de aplicaciones garantiza que solo puedan iniciarse aplicaciones conocidas y de confianza, lo que elimina el riesgo de introducir aplicaciones no autorizadas.
Control de privilegios: Una gestión eficaz de privilegios es crucial para prevenir el secuestro de DLL. Al garantizar que las aplicaciones cuenten con los derechos y privilegios correctos para iniciarse, limita la capacidad de los usuarios no autorizados para introducir archivos maliciosos. Este control actúa como una barrera clave, ya que restringe el acceso que necesita un atacante para explotar el mecanismo de búsqueda de DLL y, por tanto, mejora la seguridad de su entorno.

Software de seguridad:

Antivirus y antimalware: Utilice software antivirus y antimalware de confianza para detectar y prevenir la carga de DLL maliciosas. Estas herramientas pueden analizar archivos y comportamientos maliciosos conocidos.
Sistemas de detección de intrusiones (IDS): Implemente IDS para supervisar actividades inusuales, como cambios inesperados en archivos DLL o intentos de cargar DLL desde ubicaciones inseguras.

Gestión de parches:

Mantener el software actualizado: Actualice periódicamente las aplicaciones y los sistemas operativos con los parches de seguridad más recientes. Muchas vulnerabilidades de secuestro de DLL se corrigen mediante actualizaciones, por lo que conviene mantenerse al día para ayudar a protegerse frente a amenazas conocidas.
Aplicación automatizada de parches: Utilice una herramienta automatizada de gestión de parches para garantizar que todos los sistemas se mantengan actualizados sin intervención manual. Esto reduce la ventana de oportunidad para que los atacantes exploten vulnerabilidades conocidas, incluidas aquellas que podrían utilizarse para el secuestro de DLL. Este enfoque proactivo ayuda a mantener la integridad de sus aplicaciones y sistemas operativos, lo que dificulta mucho más que los atacantes inyecten DLL maliciosas.

Al implementar estas prácticas recomendadas, puede reducir significativamente el riesgo de secuestro de DLL y mejorar la seguridad general de sus aplicaciones y sistemas.

Combine las herramientas y tácticas adecuadas para prevenir el secuestro de DLL

El secuestro de DLL ha sido una forma de ataque persistente durante años, lo que demuestra que sigue siendo eficaz y que, por tanto, continuará siendo un problema para las organizaciones.

Prepare su organización para el futuro utilizando las prácticas recomendadas mencionadas anteriormente junto con soluciones probadas como Ivanti Neurons for App Control para ayudar a mantener sus DLL seguras. Funcionalidades como Trusted Ownership detectan y bloquean la ejecución de una DLL secuestrada al garantizar que la propiedad de los elementos coincida con su lista aprobada de propietarios de confianza.

Además, mantenga sus aplicaciones actualizadas para limitar la exposición a vulnerabilidades conocidas. Elimine el riesgo de error humano automatizando la aplicación de parches con Ivanti Neurons for Patch Management, lo que garantiza que los sistemas se actualicen y protejan automáticamente.

ITAM: su inesperada primera línea de defensa frente a las ciberamenazas

Tue, 16 Dec 2025 14:00:02 Z

Cuando se habla de ciberseguridad, muchas personas piensan en firewalls, sistemas de detección de intrusiones o protección de endpoints de última generación. Sin embargo, bajo estos sofisticados escudos existe una base esencial (y a menudo poco reconocida): una gestión sólida de activos de TI (ITAM).

Para los CIO que guían a organizaciones de tamaño medio y grandes empresas en un panorama digital cada vez más peligroso, ITAM no solo ofrece claridad operativa, sino también una potente primera línea de defensa frente a las ciberamenazas.

A continuación, analizaremos cómo una ITAM completa aporta visibilidad crítica sobre el entorno tecnológico de su organización, refuerza sus defensas frente a ciberamenazas en constante evolución, respalda el cumplimiento normativo y acelera las operaciones de seguridad. Siga leyendo para descubrir cómo convertir ITAM en una parte esencial de su estrategia puede ayudar a evitar brechas costosas y a construir una verdadera ciberresiliencia.

Los ciberataques globales aumentaron un 30 % interanual, y los ataques de ransomware registran ahora una media de 20 a 25 incidentes importantes al día.

Por qué ITAM es importante: los retos de ciberseguridad empiezan con una visibilidad limitada

Las ciberamenazas explotan casi siempre las debilidades que las organizaciones no pueden ver. La TI en la sombra, los dispositivos obsoletos, el software no autorizado y los puntos de acceso no autorizados son vulnerabilidades invisibles que se escapan por las grietas de la seguridad tradicional. Un inventario completo de activos no es solo una buena práctica operativa: es el punto de partida para una gestión eficaz del ciberriesgo.

A pesar de que el 90 % de las organizaciones afirma contar con sólidas capacidades de detección, el 57 % sufrió igualmente incidentes de seguridad graves debido a la falta de visibilidad completa.

Tenga en cuenta esto: en el Data Breach Investigations Report 2023, Verizon señaló que una proporción significativa de los incidentes de intrusión se originó en activos desatendidos: servidores que no se parchearon porque se habían olvidado, endpoints aprovisionados sin visibilidad sobre su ciclo de vida, etc.

En este punto, ITAM actúa como un sistema de alerta temprana de enorme valor. Al proporcionar un mapa en tiempo real y continuamente actualizado de todos los activos de hardware, software y cloud, permite a los líderes de TI detectar los riesgos antes que los atacantes.

Los beneficios de ITAM para la ciberresiliencia

A continuación, veremos cómo los distintos beneficios de una ITAM sólida se traducen en una postura de seguridad más fuerte para su organización.

La gestión del ciclo de vida elimina los eslabones débiles

Los activos no solo suponen riesgos en el momento de su adquisición. El ciclo de vida (desde la incorporación, el mantenimiento y la actualización hasta su retirada final) está lleno de oportunidades para una gestión deficiente que pueden convertirse en posibles puertas de entrada para los adversarios cibernéticos. Sistemas obsoletos sin soporte del proveedor, software al final de su vida útil que sigue ejecutando aplicaciones críticas, dispositivos dados de baja sin borrado de datos: todo ello es habitual en entornos complejos.

El 45 % de las organizaciones no tiene claro si conoce todas las aplicaciones en uso, lo que crea puntos ciegos que los atacantes aprovechan.

Una ITAM sólida garantiza que cada activo se rastree, se evalúe periódicamente y se retire de forma segura, cerrando tanto exposiciones accidentales como ataques sofisticados dirigidos a infraestructuras heredadas.

El cumplimiento normativo demuestra el control y evita sanciones

Cada vez más, los CIO se enfrentan a entornos regulatorios que exigen demostrar el control sobre los activos de TI. Marcos como NIST, ISO 27001 y el RGPD ponen el énfasis en la visibilidad de los activos como requisito previo para un control eficaz de los datos confidenciales y la infraestructura crítica. Una práctica de ITAM madura se ajusta directamente a estos requisitos, proporcionando la documentación y la supervisión demostrable necesarias para auditorías e investigaciones regulatorias.

Más del 80 % de las brechas están relacionadas con carencias en la gestión de la superficie de ataque, impulsadas por activos vulnerables expuestos a Internet y prácticas deficientes de inventario de activos.

Por ejemplo, en el marco del RGPD, la capacidad de identificar y remediar rápidamente activos vulnerables que procesan datos personales no es solo una buena práctica de seguridad: es una necesidad legal.

La colaboración entre ITAM y seguridad: mucho más que el seguimiento del inventario

La verdadera ITAM va más allá de mantener listas. La gestión integrada de activos aporta contexto directamente a las herramientas de operaciones de seguridad. Los escáneres de vulnerabilidades dependen de inventarios precisos para detectar exposiciones. La respuesta a incidentes requiere saber con exactitud qué sistemas están implicados. La aplicación de políticas de seguridad se basa en una comprensión clara de las funciones y relaciones de los activos.

A modo de ejemplo, una entidad financiera redujo a la mitad su tiempo de respuesta a incidentes tras integrar los datos de ITAM en su plataforma SIEM, lo que permitió a los equipos de seguridad localizar y aislar de inmediato los activos afectados durante una brecha. El valor aquí es medible y reproducible.

Una ciberdefensa resiliente requiere una gestión sólida de activos

La gestión de activos de TI no es simplemente higiene operativa. Es un componente esencial de una estrategia de ciberseguridad proactiva y resiliente. Para los CIO, invertir en una sólida solución de ITAM puede marcar la diferencia entre una seguridad superficial y una mitigación real del riesgo.

Si desea descubrir cómo nuestra solución de ITAM puede reforzar la postura de seguridad de su organización desde la base, póngase en contacto con nuestro equipo hoy mismo y dé el primer paso para construir una verdadera ciberresiliencia.

¿Está la IA en la sombra transformando discretamente la postura de seguridad de su entorno laboral?

Mon, 15 Dec 2025 14:00:01 Z

Las herramientas de IA han experimentado un ascenso meteórico en el entorno laboral. Lo que antes era territorio de perfiles tecnológicos muy especializados ahora es habitual: el informe Technology at Work 2025 de Ivanti reveló que el 42 % de los trabajadores de oficina afirma utilizar herramientas de IA generativa, como ChatGPT, en el trabajo, 16 puntos más que el año anterior.

¿El problema? Estos aumentos de productividad se producen sin visibilidad oficial. Entre quienes declararon utilizar herramientas de IA generativa, el 46 % afirma que algunas —o todas— las herramientas que utilizan no las proporciona la empresa. Además, uno de cada tres trabajadores oculta a sus empresas las herramientas de productividad basadas en IA.

Las herramientas de IA generativa pueden multiplicar la productividad. Pero también suponen un riesgo para la seguridad de los datos, especialmente cuando se utilizan sin supervisión de la empresa.

¿Qué es la IA en la sombra?

El uso no autorizado de la IA no es más que otra variante de la TI en la sombra (es decir, el uso de tecnología sin aprobación de TI).

Los riesgos que introduce la IA en la sombra son similares a otros riesgos de la TI en la sombra, pero con una capa adicional de preocupación: la enorme cantidad de datos propios que la IA generativa necesita para ser eficaz. Las herramientas gratuitas de IA generativa (y también algunas de pago) pueden utilizar los datos de una organización o las búsquedas de los empleados para entrenar su modelo, lo que amplifica el riesgo de fugas de datos e incumplimiento normativo.

La reciente revelación de que las conversaciones compartidas de ChatGPT eran rastreables por los motores de búsqueda (aunque OpenAI cambió rápidamente de rumbo) debería servir de llamada de atención: sin los controles adecuados, los terceros pueden utilizar sus datos de formas con las que usted no está de acuerdo. Algunas herramientas gratuitas, incluido ChatGPT, pueden configurarse para cumplir las políticas de seguridad, pero eso sencillamente no es posible cuando los empleados las utilizan de forma encubierta.

Las herramientas gratuitas como ChatGPT no son el único riesgo de la IA en la sombra. Una fuente inesperada es, de hecho, el software existente. Con la carrera por añadir funciones de IA, herramientas que antes podrían haber sido aprobadas por TI ahora pueden plantear nuevos riesgos y, si los equipos de seguridad de la información no conocen ni evalúan estas nuevas funciones, en la práctica eluden los procesos de gestión de riesgos de terceros.

Por qué es crucial un enfoque que priorice el riesgo en la IA

Ya se trate de IA generativa o de otras herramientas, la TI en la sombra es consecuencia de no contar con una forma definida y razonable de probar herramientas o realizar el trabajo. Dado que la IA no va a desaparecer, las empresas deben abordar su adopción de forma proactiva, porque prohibir herramientas no significa que los empleados no vayan a intentar utilizarlas para aumentar su productividad y facilitar su trabajo.

Dedico la mayor parte de mi tiempo a evaluar riesgos, incluidos los que plantean las herramientas de IA. A menudo tenemos que evaluar el riesgo en relación con una oportunidad de mejorar el negocio; en este caso, los aumentos de productividad de los empleados y los impactos de segundo orden (como la satisfacción de los empleados o disponer de tiempo para trabajar en proyectos más estratégicos).

En resumen, debemos preguntarnos: ¿existe alguna forma de introducir las herramientas que piden los empleados y aprovechar las ventajas que ofrecen manteniendo el riesgo en un nivel aceptable?

Aquí es donde entra en juego un enfoque que prioriza el riesgo. Un enfoque que prioriza el riesgo en la adopción de la IA se centra en los datos que deben introducirse en la IA y en cómo gestiona esos datos el tercero. Este enfoque es similar a la gestión de riesgos de proveedores, lo que permite a las organizaciones utilizar prácticas y procesos consolidados, pero adaptados a preguntas específicas sobre IA.

Entre las preguntas clave que conviene plantearse se incluyen:

¿Se utilizarán nuestros datos para entrenar el modelo de IA?
¿Durante cuánto tiempo se conservan nuestros datos?
¿Qué protecciones existen para reducir el riesgo de que nuestros datos queden expuestos?
¿Quién tiene los derechos sobre la propiedad intelectual generada mediante el uso de la IA?

Minimizar la proliferación de la IA es una parte fundamental de este trabajo. A medida que más proveedores introducen herramientas de IA especializadas —y a medida que incorpora más proveedores y concede a sus herramientas de IA acceso a sus datos—, el riesgo aumenta. Esto también se aplica a las herramientas existentes que de repente incorporan IA sin cambios de coste ni de contrato, lo que dificulta mantener un inventario preciso de herramientas de IA.

Adopción de un marco de gobernanza de la IA en Ivanti

En Ivanti, combatimos la IA en la sombra con un enfoque que prioriza el riesgo y que empieza y termina con el compromiso de los empleados.

Sacar el uso de la IA de la sombra

Aunque nunca fomentaríamos la IA en la sombra, los empleados que la utilizan tienen conocimientos valiosos que compartir sobre cómo integrar la IA en los flujos de trabajo. Por eso, en lugar de prohibir todo uso de la IA, debemos asegurarnos de que los empleados dispongan de una vía clara para solicitar herramientas de IA que puedan utilizar en el trabajo y de que existan oportunidades periódicas para un diálogo abierto.

Fomentar un diálogo abierto hace que los empleados se sientan cómodos hablando de qué herramientas les ayudan a tener éxito y, en última instancia, significa que las utilizarán —o utilizarán herramientas equivalentes— de forma segura. Esto brinda a los empleados la oportunidad de ser socios activos en el desarrollo de una gobernanza adecuada, en lugar de intentar sortear las restricciones.

Un enfoque medido para la implementación y adopción de la IA

Una vez aprobada una herramienta, es importante garantizar una implementación adecuada y comprender a qué datos se le ha dado acceso. Esto es especialmente importante si se tiene en cuenta el riesgo para la gobernanza y la seguridad de los datos que las herramientas de IA generativa plantean a las organizaciones. Cuando analizamos la IA desde la perspectiva de la gobernanza de datos, podemos abordar muchas partes del riesgo asociado a la IA.

En Ivanti adoptamos un enfoque medido: dedicamos un equipo a realizar pruebas controladas de herramientas de IA generativa con otros equipos. Después establecemos ciclos de feedback, y la adopción se despliega gradualmente para evitar interrupciones.

Creación de un ciclo de feedback para las herramientas de IA

Debemos preguntarnos de forma constante:

¿Cómo utilizan la IA los empleados de Ivanti?
¿Les gusta?
¿Qué feedback tienen?
¿Cómo podemos mejorar la herramienta?

Esta conversación continua garantiza que utilicemos la IA de forma responsable, al tiempo que satisfacemos las necesidades de productividad de los empleados.

No se trata de subirse a la ola de la IA. Se trata de saber si merece la pena: para la empresa y para las personas que la utilizan. La IA en la sombra aumenta la productividad de una persona. Pero si se toma esa productividad y se amplía, se obtiene una mejora significativa para la empresa en su conjunto.

Combatir de forma proactiva la IA en la sombra

La idea central es que, aunque la IA, y en particular la IA en la sombra, plantea riesgos nuevos y preocupantes, ha llegado para quedarse. Los empleados que utilizan la IA fuera de los canales oficiales no tienen malas intenciones; más bien intentan beneficiar a la empresa, aunque no lo estén haciendo de la forma adecuada.

Un enfoque proactivo que prioriza el riesgo en la adopción de la IA reconoce esta realidad. En lugar de prohibiciones reactivas que solo fomentan que se eludan las normas, debemos implicar a los empleados para comprender los problemas que intentan resolver con la IA, de modo que podamos ofrecerles opciones seguras que cumplan nuestros requisitos de seguridad y privacidad de datos.

Por qué SELinux es importante en la seguridad empresarial

Thu, 23 Oct 2025 14:03:35 Z

Al evaluar productos de ciberseguridad, es fácil centrarse en funciones superficiales como paneles, alertas e integraciones. Pero la verdadera fortaleza suele encontrarse a un nivel más profundo, en la propia arquitectura. Una capacidad integrada que demuestra principios rigurosos de diseño de seguridad es Security-Enhanced Linux (SELinux).

Desarrollado originalmente por la Agencia de Seguridad Nacional de EE. UU. (NSA) y puesto a disposición de la comunidad de código abierto, SELinux es un marco de control de acceso obligatorio (MAC) integrado en el kernel de Linux. Aplica reglas estrictas basadas en políticas que rigen cómo las aplicaciones, los servicios y los usuarios interactúan con los recursos del sistema, lo que lo convierte en una potente defensa frente a la escalada de privilegios, el movimiento lateral y los exploits de día cero.

Si el producto de ciberseguridad que está evaluando incluye SELinux, especialmente en modo enforcing, es un claro indicador de madurez arquitectónica y de contención proactiva de amenazas.

¿Qué hace que SELinux sea diferente y mejor?

SELinux etiqueta cada proceso y archivo con un contexto de seguridad y utiliza políticas predefinidas para controlar cómo interactúan. A diferencia de los controles de acceso tradicionales, que dependen de los permisos de usuario, SELinux aplica políticas de seguridad a todos los usuarios y procesos, incluso a aquellos con privilegios de root (administrador).

Esto es especialmente importante porque impide que los atacantes aprovechen el acceso root para moverse lateralmente, exfiltrar datos o desactivar controles de seguridad. En esencia, SELinux elimina el estatus de «superpoder» de root, aplicando límites de seguridad definidos por políticas, no por privilegios.

Esto significa que, aunque un atacante obtenga acceso privilegiado (también conocido como root), SELinux puede impedirle ejecutar acciones no autorizadas que se aparten de la política preestablecida. Este nivel de seguridad va más allá de la detección para abarcar la prevención en el nivel del sistema operativo.

Cómo funciona SELinux

SELinux se ejecuta en varios modos:

Deshabilitado: No está activo; no hay aplicación de seguridad.
Permisivo: Registra las infracciones, pero no las bloquea; resulta útil para pruebas.
Enforcing: Bloquea activamente las acciones no autorizadas en función de la política.
Aplicación estricta: Hace referencia al modo enforcing combinado con una política estricta que se aplica de forma predeterminada.

Los productos que ejecutan SELinux en modo de aplicación estricta ofrecen protección en tiempo real de los procesos y recursos del sistema. La superficie de ataque se minimiza, lo que dificulta considerablemente que los atacantes se desplacen por el sistema. Cada usuario, servicio y daemon está sujeto a un control de acceso obligatorio basado en el mínimo privilegio. La aplicación estricta suele utilizarse en entornos de alta seguridad (por ejemplo, gobierno, finanzas o defensa), donde ningún proceso es de confianza por defecto y cada interacción debe estar permitida explícitamente por la política.

Aunque no configurará SELinux usted mismo, conviene entender cómo proveedores como Ivanti lo utilizan para reforzar sus productos:

1. Inicio en modo permisivo: Comenzamos observando el comportamiento del sistema bajo las políticas de SELinux sin bloquear nada.

2. Pruebas exhaustivas: Registramos infracciones, identificamos operaciones legítimas y ajustamos las políticas para evitar falsos positivos.

3. Desarrollo de políticas personalizadas: Las políticas se adaptan a la arquitectura del producto y a sus casos de uso.

4. Validación en laboratorio en modo enforcing: Antes del lanzamiento, probamos SELinux en los modos enforcing y de aplicación estricta en condiciones simuladas del mundo real.

Este proceso garantiza que SELinux mejore la seguridad sin interrumpir la funcionalidad, y que los usuarios obtengan una protección óptima sin comprometer el rendimiento. Además, el proceso descrito anteriormente se realiza para cada versión; es decir, a medida que el software evoluciona a versiones más recientes, la política de SELinux debe probarse, ajustarse y repetirse con cada nueva versión del producto de software.

Este proceso requiere tiempo y exige importantes recursos de desarrollo para ejecutarse correctamente. Solo los proveedores de seguridad más comprometidos y proactivos configuran SELinux con aplicación estricta.

Ejemplo real: despliegue de Oracle Linux

Oracle Linux admite SELinux en modo enforcing y se utiliza ampliamente para proteger entornos de bases de datos Oracle y cargas de trabajo en Oracle Cloud Infrastructure. SELinux ayuda a aislar procesos, aplicar el mínimo privilegio y proteger datos sensibles frente al acceso no autorizado, incluso en despliegues empresariales complejos.

Para los compradores, esto significa que los productos creados sobre Oracle Linux con SELinux habilitado, incluido Ivanti Connect Secure, ya están reforzados frente a muchas clases de ataques. (Puede encontrar más detalles en la guía oficial de Oracle.)

Tecnología de seguridad que aporta valor empresarial

Cuando SELinux está integrado en una solución de ciberseguridad, la tecnología aporta beneficios estratégicos alineados con las prioridades empresariales.

Preparación para auditorías y cumplimiento: SELinux registra cada intento de acceso, tanto si se permite como si se deniega, creando una completa pista de auditoría. La aplicación de SELinux y la pista de auditoría ayudan a cumplir requisitos normativos como CIS Level-1/2 Hardening, STIG, NIST-800 y otras normativas que exigen el refuerzo del sistema.
Control de acceso granular: Se aplican reglas detalladas a nivel de proceso, lo que limita el acceso incluso para usuarios root. Esto reduce el riesgo de escalada de privilegios y amenazas internas, algo especialmente importante en entornos con datos sensibles o roles de usuario complejos.
Superficie de ataque reducida: SELinux aísla procesos y aplica el acceso de mínimo privilegio, lo que evita el movimiento lateral dentro del sistema. Esta estrategia de contención es fundamental para limitar el radio de impacto de cualquier brecha. SELinux bloquea acciones no autorizadas en el nivel del sistema operativo, lo que dificulta que los atacantes exploten vulnerabilidades, incluidas las de día cero.
Garantía de nivel empresarial: Los proveedores como Ivanti que utilizan SELinux en sus productos demuestran un compromiso significativo con las mejores prácticas de seguridad. Este enfoque respalda la gestión de riesgos, refuerza la confianza y diferencia claramente la solución en un mercado competitivo.
Estabilidad operativa: Cuando las políticas están correctamente ajustadas, SELinux opera de forma silenciosa en segundo plano, aplicando seguridad sin afectar al rendimiento, lo que resulta ideal para entornos críticos donde el tiempo de actividad es clave.

Reflexiones finales sobre el valor de SELinux

Los compradores que evalúan productos de ciberseguridad deben mirar más allá de las funciones superficiales y preguntarse qué protege el sistema en su núcleo. SELinux es una de esas tecnologías subyacentes que aplica protección real de forma discreta, bloqueando acciones no autorizadas (incluso de usuarios privilegiados) y conteniendo las amenazas antes de que se propaguen.

Su presencia en un producto indica una arquitectura reforzada, contención proactiva de amenazas y un proveedor que se toma en serio la integridad del sistema. No tendrá que configurarlo usted mismo, pero se beneficiará de él cada vez que un exploit no consiga avanzar.

El compromiso de Ivanti con la seguridad

Ivanti fue una de las primeras empresas en adherirse al compromiso «Secure by Design» de CISA en 2024. Como parte de este esfuerzo, Ivanti ha invertido considerablemente en reforzar el producto Connect Secure, modernizar su sistema operativo e integrar la seguridad en cada capa del desarrollo.

En el centro de la filosofía de desarrollo de Ivanti se encuentra nuestro ciclo de vida de desarrollo de software seguro (SSDLC), que habilita los siete elementos clave del diseño de software seguro: seguridad como código (SaC), seguro de forma predeterminada, mínimo privilegio, separación de funciones (SoD), minimización de la superficie de ataque (ASA), mediación completa y fallo seguro. Además, Ivanti también sigue su propio y estricto estándar de desarrollo de aplicaciones seguras, que exige el cumplimiento de los estándares de verificación de seguridad de aplicaciones de OWASP (ASVS). En conjunto, estos marcos rigurosos garantizan que cada función del producto se diseñe e implemente considerando la seguridad como una prioridad, proporcionando a los clientes soluciones que cumplen los estándares más exigentes del sector.

Descubrimiento de la superficie de ataque: cómo identificar la superficie de ataque de su organización

Mon, 18 Aug 2025 09:54:55 Z

Al igual que el césped después de una buena lluvia, su superficie de ataque crecerá rápidamente si no se controla. Y ese aumento del tamaño de la superficie de ataque conlleva un incremento del riesgo de ciberseguridad. Aunque el riesgo no puede eliminarse por completo, porque las superficies de ataque evolucionan constantemente, sí puede gestionarlo para mantener sus niveles generales de riesgo alineados con su apetito de riesgo.

¿Por qué es tan importante el descubrimiento de la superficie de ataque?

La gestión del riesgo de ciberseguridad comienza con la identificación de la superficie de ataque de su organización. Más concretamente, debe identificar qué se oculta bajo la superficie: los endpoints, las vulnerabilidades y otros vectores de ataque que exponen su entorno.

Los principales marcos de seguridad coinciden en que el descubrimiento de la superficie de ataque es esencial para una postura de seguridad sólida. Por ejemplo, la primera función del Marco de Ciberseguridad del National Institute of Standards and Technology (NIST CSF), versión 1.1 es Identificar, y el NIST afirma: “Las actividades de la función Identificar son fundamentales para un uso eficaz del Marco”. Del mismo modo, CIS Controls v8 contiene los siguientes controles:

Control 1: inventario y control de activos empresariales
Control 2: inventario y control de activos de software
Control 7: gestión continua de vulnerabilidades

En pocas palabras, no puede defender aquello que no sabe que tiene. Pero ¿cómo saber qué tiene?

¿Cómo empiezo con el descubrimiento de la superficie de ataque?

El descubrimiento de la superficie de ataque exige adoptar la perspectiva de un atacante sobre su organización para encontrar activos explotables y vulnerabilidades asociadas.

Su superficie de ataque tiene tres componentes: una superficie de ataque digital, una superficie de ataque física y una superficie de ataque humana. Aquí nos centraremos principalmente en descubrir su superficie de ataque digital, aunque también abordaremos brevemente los otros dos aspectos.

Su superficie de ataque digital incluye activos de TI tradicionales —hardware, como endpoints y servidores, así como aplicaciones de software— y activos externos expuestos a Internet, como aplicaciones web, direcciones IP, nombres de dominio, certificados SSL y servicios en la nube.

El primer paso consiste en contabilizar cada elemento de su superficie de ataque digital e identificar las brechas de visibilidad. Puede clasificar cada elemento como:

Conocidos conocidos: Activos cibernéticos que sabe que forman parte de su superficie de ataque.
Desconocidos conocidos: Activos cibernéticos que sabe que forman parte de su superficie de ataque, pero sobre los que puede no tener visibilidad o que no tiene bajo gestión.
Desconocidos desconocidos: Activos cibernéticos que pueden formar parte de su superficie de ataque o no: no lo sabe.
N/A: Activos cibernéticos que sabe con un 100 % de certeza que no forman parte de su superficie de ataque.

Para obtener una visión más completa de los elementos de su superficie de ataque, utilice nuestra lista de comprobación editable de la superficie de ataque para realizar el inventario.

Herramientas para descubrir y gestionar su superficie de ataque

El siguiente paso, después de clasificar sus tipos de activos, es determinar qué herramientas o enfoques le permitirán cerrar las brechas de visibilidad y convertir sus desconocidos conocidos y desconocidos desconocidos en conocidos conocidos.

Existen soluciones más específicas que se engloban bajo el amplio concepto de gestión de la superficie de ataque: gestión de la superficie de ataque de activos cibernéticos (CAASM), gestión de la superficie de ataque externa (EASM) y servicios de protección frente al riesgo digital (DRPS). Estas herramientas agregan resultados para identificar vulnerabilidades con mayor facilidad, y algunas también cuentan con capacidades para priorizarlas y corregirlas, lo que permite actuar con rapidez a partir de la información sobre la superficie de ataque y reducir el riesgo.

Sin embargo, las organizaciones han necesitado descubrir y gestionar sus superficies de ataque digitales desde antes de que existieran las soluciones ASM. En lugar de soluciones ASM, muchas organizaciones han utilizado —y siguen utilizando— otros enfoques para hacerlo.

Enfoque	Descripción	Ventajas	Inconvenientes
Herramientas de descubrimiento de activos	Buscan e inventarían los activos de hardware y software que se conectan a su red.	Ya están implementadas en la mayoría de las organizaciones. Son mejores que las hojas de cálculo.	Pueden tener puntos ciegos, como la TI en la sombra, sistemas de terceros y aplicaciones de línea de negocio.
Simulación de brechas y ataques (BAS)	Prueba automáticamente vectores de amenaza para obtener una comprensión más profunda de las vulnerabilidades de la postura de seguridad y validar los controles de seguridad.	Genera informes sobre brechas de seguridad y prioriza la corrección en función del riesgo.	Solo se centra en ataques conocidos. No proporciona corrección.
Gestión de la postura de seguridad en la nube (CSPM)	Comprender los cambios en las configuraciones de la nube.	Proporciona visibilidad en tiempo real de las configuraciones de la nube.	No revela cuándo las configuraciones se desvían del cumplimiento ni el posible impacto de las amenazas emergentes.
Base de datos de gestión de la configuración (CMDB)	Realizar un seguimiento de los cambios realizados en los sistemas.	Ya está implementada en la mayoría de las organizaciones.	No revela cuándo las configuraciones se desvían del cumplimiento ni el posible impacto de las amenazas emergentes.
Enfoque desarrollado internamente	Combina hojas de cálculo, scripts y procesos manuales para gestionar la superficie de ataque.	Económico o gratuito desde una perspectiva puramente de coste, sin tener en cuenta las horas de los analistas.	Consume mucho tiempo y es propenso a errores. No es escalable ni funciona en tiempo real.
Gestión de activos de TI (ITAM)	Realiza el seguimiento y la supervisión de los activos durante todo su ciclo de vida.	Ya está implementada en la mayoría de las organizaciones. Es mejor que las hojas de cálculo.	Solo cubre activos conocidos y gestionados, mientras pasa por alto aspectos desconocidos o no gestionados de la superficie de ataque.
Pruebas de penetración (por ejemplo, herramientas automatizadas de pruebas de penetración y pruebas de penetración como servicio)	Identifican vulnerabilidades en su red y sus aplicaciones mediante la simulación de un ciberataque.	Proporcionan ejemplos de la postura de seguridad y de las prioridades presupuestarias asociadas.	Solo se centran en la primera fase de la cadena de ciberataque: el reconocimiento. Además, los resultados suelen ser puntuales y tan buenos como los encargados de realizar la prueba de penetración que llevan a cabo la simulación.
Red teaming	Proporciona una visión completa de la postura de ciberseguridad de una organización mediante la simulación de un ciberataque contra redes, aplicaciones, medidas de protección físicas y empleados.	Va más allá de las pruebas de penetración al centrarse en otras fases de la cadena de ciberataque. También va más allá de la superficie de ataque digital y aborda las superficies de ataque física y humana.	Los resultados suelen ser puntuales y tan buenos como los encargados de realizar la prueba de penetración que llevan a cabo la simulación.
Inteligencia de amenazas	Acceso a información sobre amenazas y otros problemas de ciberseguridad.	Proporciona a los expertos en seguridad inteligencia sobre amenazas y vulnerabilidades.	Orientada a organizaciones con operaciones de seguridad muy maduras, formadas por personal cualificado y amplios recursos.
Herramientas de gestión de vulnerabilidades (por ejemplo, escáneres)	Identifican y gestionan vulnerabilidades en su infraestructura y sus aplicaciones.	Ya están implementadas en la mayoría de las organizaciones.	Sin visibilidad de los activos desconocidos. Cantidades abrumadoras de datos.

Aunque estos métodos no ofrecen todas las capacidades de una solución ASM diseñada específicamente, siguen desempeñando funciones importantes en las prácticas de TI y seguridad de una organización.

De hecho, las herramientas CAASM no pueden funcionar sin datos procedentes de herramientas de descubrimiento de activos, ITAM, gestión de vulnerabilidades o gestión de parches. Del mismo modo, EASM complementa los servicios de inteligencia de amenazas y pruebas de seguridad enumerados anteriormente.

¿Cómo identifico la superficie de ataque física de mi organización?

El primer componente principal de la superficie de ataque física de su organización se solapa con su superficie de ataque digital. Se denomina superficie de ataque de endpoints y está compuesta principalmente por todos los endpoints que se conectan a su red: ordenadores de sobremesa, portátiles, dispositivos móviles y dispositivos IoT. Las herramientas y técnicas que utiliza para descubrir su superficie de ataque digital también se aplican aquí.

El segundo componente principal de su superficie de ataque física son sus oficinas, centros de datos y otras instalaciones. De nuevo, las técnicas ya utilizadas para identificar la superficie de ataque digital también se solapan con la superficie de ataque física. En este caso, se trata del componente de pruebas de penetración física del red teaming.

¿Cómo identifico la superficie de ataque humana de mi organización?

La identificación de su superficie de ataque humana comienza revisando el organigrama. Cualquier persona asociada a su organización que pueda acceder a información confidencial —o impedir que otros accedan a ella— contribuye a su superficie de ataque humana. Esto incluye no solo empleados a tiempo completo, sino también empleados a tiempo parcial, miembros del consejo, contratistas, partners, proveedores, suministradores, trabajadores temporales y otros perfiles.

El red teaming, una práctica utilizada para identificar elementos de las superficies de ataque digital y física, también puede utilizarse para identificar un componente importante de la superficie de ataque humana: la susceptibilidad de los empleados a la ingeniería social.

La asignación inadecuada de privilegios de usuario es otro factor importante que contribuye a las superficies de ataque humanas. Revisar los sistemas y datos a los que tienen acceso las personas que contribuyen a su superficie de ataque humana, así como los niveles de acceso que poseen, es otra forma de identificar partes de esa superficie.

Ya he identificado la superficie de ataque de mi organización. ¿Y ahora qué?

Descubrir su superficie de ataque es el primer paso en el camino hacia su objetivo final: corregir las vulnerabilidades que representan el mayor riesgo para su organización. En conjunto, este proceso se denomina gestión de la exposición.

El descubrimiento de la superficie de ataque, como ya hemos comentado, es uno de los fundamentos de su estrategia de seguridad: si no sabe que está ahí, no puede protegerlo. La gestión de la exposición añade otro pilar fundamental: determinar su apetito de riesgo. Esto define cuánto riesgo está dispuesta a asumir su organización para alcanzar sus objetivos. Puede utilizar esta plantilla editable para su declaración de apetito de riesgo.

Una vez abordados estos dos elementos fundamentales, puede evaluar las vulnerabilidades que ha descubierto en su superficie de ataque para determinar cuánto riesgo suponen para su organización y si se encuentran dentro de su apetito de riesgo, un proceso que explicamos en profundidad en esta guía para la evaluación objetiva del riesgo cibernético.

Las vulnerabilidades que quedan fuera de su apetito de riesgo son sus prioridades de corrección, lo que le permite centrar sus esfuerzos donde tendrán el mayor impacto.

¿Qué significa realmente la ciberseguridad proactiva? Medidas para proteger su organización

Mon, 04 Aug 2025 19:26:10 Z

El Informe sobre el estado de la ciberseguridad 2025 de Ivanti reveló algo nada sorprendente: que las organizaciones declaran una brecha de preparación significativa (es decir, la brecha entre el nivel de amenaza percibido y su grado de preparación) en todos los vectores de amenaza y vulnerabilidades sobre los que les preguntamos.

Aunque los equipos de seguridad dedican acertadamente recursos a crear resiliencia para poder responder a los ataques y recuperarse de ellos con rapidez, cerrar esas brechas de preparación requiere medidas de ciberseguridad proactiva.

Ciberseguridad reactiva frente a proactiva: ¿cuál es la diferencia?

La ciberseguridad proactiva hace referencia a lo que se hace antes de un ciberataque para mejorar la postura de seguridad y reducir la superficie de ataque; la ciberseguridad reactiva interrumpe un ataque que ya ha vulnerado sus sistemas, lo contiene y minimiza el daño que puede causar.

No son en absoluto mutuamente excluyentes. La seguridad proactiva reduce el riesgo, pero no lo elimina. “Reactiva” puede tener una connotación ligeramente negativa, pero las capacidades que permiten responder a un ataque, por mucho que se haya reducido la exposición al riesgo, son de vital importancia.

Ejemplos de medidas de ciberseguridad proactiva

La seguridad proactiva es una filosofía, no un plan. Se basa en la idea de que tomar medidas para minimizar la exposición mucho antes de que un riesgo se materialice es la mejor forma de aprovechar el tiempo y los recursos de seguridad.

Dicho esto, existen capacidades específicas que puede desarrollar para adoptar esa filosofía, entre ellas, aunque desde luego no exclusivamente, el análisis de vulnerabilidades, la gestión de la superficie de ataque, la gestión de vulnerabilidades, la validación de la exposición, la gestión de parches, la gestión de configuraciones y la formación de usuarios.

Gestión de la superficie de ataque

La gestión de la superficie de ataque tiene como objetivo comprender todos los puntos de entrada de una organización —digitales, físicos o humanos— que los hackers pueden utilizar para acceder a su entorno de TI.

La superficie de ataque incluye dispositivos (conocidos y desconocidos), pero el entorno va más allá de los dispositivos. También incluye aplicaciones, software, cuentas de redes sociales y otros espacios o activos digitales utilizados por personas asociadas a la empresa.

Relacionado:Lista de comprobación de la superficie de ataque

Análisis de vulnerabilidades

El análisis de vulnerabilidades es exactamente lo que parece: escáneres especializados evalúan redes y activos de TI en busca de vulnerabilidades que puedan explotarse y las señalan para que los equipos de seguridad las aborden. Dado que existen miles de vulnerabilidades conocidas (y cada día aparecen más), el análisis de vulnerabilidades resulta más eficaz cuando está automatizado.

Los análisis externos de vulnerabilidades revisan una red desde fuera hacia dentro para tratar de identificar formas en que un hacker podría acceder a ella. Los análisis internos adoptan el punto de vista de alguien que ya ha entrado en la red y de las vulnerabilidades que podría explotar desde dentro.

Gestión de vulnerabilidades

El análisis de vulnerabilidades y la gestión de la superficie de ataque alimentan el ciclo más amplio y completo de gestión de vulnerabilidades. Se trata de un proceso continuo en el que las vulnerabilidades se identifican y se clasifican con un determinado nivel de prioridad antes de que los equipos decidan cuál es la mejor forma de resolverlas.

Un enfoque predeterminado para la gestión de vulnerabilidades consiste en priorizar por gravedad, pero este enfoque puede sobrevalorar algunas vulnerabilidades y pasar por alto otras. Añadir contexto de amenazas —¿se está explotando activamente esta vulnerabilidad?— y contexto de riesgo —¿qué perjuicio supondría para mi organización la explotación de esta vulnerabilidad?— ofrece una visión más clara de la verdadera prioridad.

Validación de la exposición

La validación de la exposición comprueba la viabilidad de un ataque y la solidez de sus contramedidas mediante la ejecución de escenarios de ataque. Este enfoque también se denomina seguridad ofensiva. Los dos métodos más habituales son las pruebas de penetración y el red teaming.

Las pruebas de penetración (o pen testing) consisten en que hackers éticos intenten hackear su sistema y, después, ofrezcan comentarios sobre qué funcionó bien y qué áreas requieren más mejoras. El pen testing también puede realizarse con herramientas automatizadas.
El red teaming, similar al pen testing, consiste en hacer que hackers éticos lleven a cabo un ciberataque planificado con el objetivo de descubrir dónde pueden mejorarse sus defensas. El red teaming es una simulación basada en escenarios, mientras que el pen testing implica buscar el mayor número posible de vulnerabilidades diferentes.

La validación adversarial de la exposición, o AEV, también está surgiendo como una práctica en la que se utiliza software para realizar simulaciones de ataque de forma continua y autónoma con el fin de demostrar la existencia de exposiciones.

Gestión de parches

Una vez que las vulnerabilidades se han identificado mediante la gestión de la superficie de ataque y el análisis de vulnerabilidades, se han priorizado mediante la gestión de vulnerabilidades y se han validado posteriormente mediante la validación de la exposición, la pregunta es: ¿cómo debemos reaccionar? La gestión de parches es una forma de responder a las vulnerabilidades y cerrarlas, en concreto las vulnerabilidades de software para las que existen parches.

La gestión de parches es un objetivo ideal para la automatización, sobre todo cuando se combina con la gestión de vulnerabilidades basada en riesgos. Los flujos de trabajo que avanzan automáticamente desde la detección hasta la toma de decisiones y el despliegue acortan el tiempo medio de remediación y minimizan los errores humanos.

La gestión de parches sí tiene un punto ciego importante: la TI en la sombra. Sin un inventario preciso del software que utilizan los empleados, es imposible hacer cumplir la aplicación de parches. Por eso el componente de descubrimiento de la gestión de la superficie de ataque es tan crítico.

Gestión de configuraciones

La gestión de configuraciones, al igual que la gestión de parches, es una forma de responder a vulnerabilidades identificadas; en este caso, vulnerabilidades que afectan a los propios dispositivos, no al software que se ejecuta en ellos. La configuración se refiere a las medidas de ciberseguridad proactiva que se establecen a nivel de dispositivo, como la aplicación de la autenticación multifactor o el cifrado. Aunque estas medidas puede aplicarlas individualmente el usuario final, se imponen con mayor eficacia mediante software de gestión de endpoints.

De nuevo, al igual que ocurre con la gestión de parches, la TI en la sombra complica la situación. Los dispositivos desconocidos y no gestionados pueden no cumplir los estándares de seguridad de su organización: no hay forma de saberlo. Y, como sucede con la gestión de parches, el componente de descubrimiento de la gestión de la superficie de ataque es crítico. Al identificar dispositivos que antes eran desconocidos e incorporarlos a la gestión, los equipos de TI pueden hacer cumplir las normas.

Formación de usuarios

Su superficie de ataque no es únicamente digital: también tiene un componente humano. El phishing y otras formas de ingeniería social aprovechan las vulnerabilidades humanas, a menudo encadenándolas con exposiciones digitales (vulnerabilidades de software, configuraciones incorrectas, etc.) para lanzar un ataque. Formar a los empleados ayuda a minimizar las exposiciones, igual que lo hace remediar las vulnerabilidades digitales.

Cómo conseguir apoyo para las medidas de ciberseguridad proactiva

Conseguir apoyo para las medidas de ciberseguridad proactiva es, en cierto modo, más difícil que para las medidas de ciberseguridad reactiva. La amenaza aún no se ha materializado, por lo que a las partes interesadas que no pertenecen al área de seguridad les resulta más difícil comprender las concesiones necesarias, como interrupciones temporales del negocio u otros aspectos que dificultan la productividad, al menos a corto plazo. La formación de usuarios exige tiempo en agendas ya de por sí ocupadas. El despliegue de parches puede dejar aplicaciones sin conexión o requerir resolución de problemas.

Para conseguir y mantener el apoyo a este tipo de medidas, los equipos de seguridad deben procurar minimizar la interrupción que puede causar la remediación (por ejemplo, mediante el despliegue por anillos, que implementa actualizaciones de software en “anillos” cada vez más amplios, identificando problemas y resolviéndolos en cada paso antes de extenderlas a toda la base de usuarios).

Un ejercicio de evaluación de riesgos también puede ayudar a que una amenaza que aún no se ha materializado resulte real para otras partes interesadas. Una medición objetiva de su exposición y del coste de los riesgos asociados —especialmente si puede cuantificar esa exposición en términos financieros— puede marcar la diferencia entre una aceptación a regañadientes y un verdadero apoyo a la seguridad proactiva.

Relacionado:Evaluar objetivamente el riesgo cibernético: guía para evaluaciones de riesgo basadas en datos

Por qué es importante la ciberseguridad proactiva

Una estrategia de ciberseguridad proactiva no está reñida con la seguridad reactiva: una organización sana cuenta con capacidades sólidas para abordar el riesgo antes y después de que se materialice. Pero las medidas preventivas mejoran su postura de riesgo y hacen que las ocasiones en que un riesgo llega a materializarse sean menos frecuentes y estén más espaciadas. Las medidas de ciberseguridad proactiva, como la gestión de la superficie de ataque, la aplicación de parches, las configuraciones adecuadas y la concienciación de los usuarios, son inversiones claras en la seguridad a largo plazo de su organización.

Por qué no puede permitirse ignorar los ataques a la cadena de suministro de software

Mon, 05 May 2025 12:34:43 Z

Informe sobre el estado de la ciberseguridad 2025 de Ivanti reveló que solo 1 de cada 3 organizaciones se siente preparada para protegerse frente a las amenazas a la cadena de suministro de software. Dado que los atacantes se centran cada vez más en las dependencias de terceros, los ataques a la cadena de suministro pueden convertirse en un punto débil crítico para la ciberseguridad si las organizaciones siguen pasándolos por alto.

El riesgo creciente de los ataques a la cadena de suministro de software

Las superficies de ataque no dejan de ampliarse rápidamente, y un vector clave de esa expansión son las cadenas de suministro de software de las organizaciones. Las empresas modernas dependen de numerosas aplicaciones, herramientas y dependencias de software dentro de su propia infraestructura tecnológica. Según un informe de 2024 de BetterCloud, una sola organización utiliza una media de 112 aplicaciones SaaS. Y esa red no hace sino volverse más compleja. De media, cada aplicación de software tiene 150 dependencias, de las cuales el 90 % son dependencias indirectas, que concentran la gran mayoría de las vulnerabilidades.

El número de actores de amenazas que atacan dependencias de terceros ha aumentado rápidamente en los últimos años, hasta el punto de que el 75 % de todas las cadenas de suministro de software notificaron ataques en 2024. Las amenazas a la cadena de suministro de software también se han vuelto más sofisticadas, ya que los atacantes buscan cualquier debilidad que puedan explotar en el código de un proveedor. Sin embargo, los equipos de seguridad suelen tener dificultades para evaluar correctamente todos sus componentes de software.

La investigación de Ivanti sobre ciberseguridad reveló que, aunque el 84 % de los líderes de las organizaciones afirman que es «muy importante» supervisar la cadena de suministro de software, casi la mitad (48 %) aún no ha identificado los componentes más vulnerables de su propia cadena de suministro. Esta falta de diligencia debida deja a las empresas expuestas a importantes riesgos financieros y reputacionales.

Tipos comunes de ataques a la cadena de suministro de software

Según Gartner, el 45 % de las organizaciones habrá sufrido un ataque a la cadena de suministro de software en 2025. A continuación se ofrece un breve resumen de algunos de los tipos más comunes de vulnerabilidades de la cadena de suministro de software a los que apuntan los atacantes:

Ataques a servidores upstream son los ataques a la cadena de suministro más comunes. Se producen cuando los hackers comprometen un sistema situado «aguas arriba» de los usuarios, como un repositorio de código, e inyectan una carga maliciosa o malware. A continuación, esta carga se propaga a los usuarios «aguas abajo» a través de, por ejemplo, una actualización de software.
Ataques midstream hacen referencia a incidentes en los que los atacantes comprometen sistemas intermediarios, como herramientas de desarrollo de software, en lugar de la base de código original.
Ataques de confusión de dependencias intentan engañar a un desarrollador o sistema para que descargue una dependencia de software comprometida desde una fuente externa. Algunos métodos habituales de ataque incluyen usar para una carga de software malicioso un nombre similar al de una biblioteca interna de confianza. La versión maliciosa suele integrarse en la compilación del software en lugar de la dependencia legítima.
Ataques a certificados de firma de código se producen cuando los hackers inyectan software malicioso en certificados digitales de firma de código destinados a verificar la seguridad y autenticidad del software. Estos ataques se producen cuando los actores de amenazas comprometen el entorno de desarrollo mediante ingeniería social u otra táctica.
Ataques a la infraestructura de CI/CD se dirigen a canalizaciones de desarrollo automatizadas mediante la introducción de malware, por ejemplo clonando repositorios auténticos de GitHub con fines maliciosos.

Ejemplos recientes de ataques a la cadena de suministro

No hace falta investigar demasiado en las noticias para encontrar ejemplos reales de este tipo de ataques que han llegado a situaciones críticas. Estos son algunos incidentes de ataques a la cadena de suministro de los últimos años que atrajeron la atención mundial.

Ataque de ingeniería social a Okta
- En octubre de 2023, Okta, proveedor de servicios de gestión de identidades y accesos, sufrió una grave filtración de datos en su sistema de soporte al cliente después de que cuatro clientes distintos de Okta fueran víctimas de ataques de ingeniería social dirigidos a su mesa de servicio de TI. Los atacantes utilizaron estas credenciales administrativas para lanzar varios ataques aguas abajo que dieron lugar al acceso no autorizado a los datos de miles de clientes de Okta, incluidos 1Password, BeyondTrust y Cloudflare.
Ataque de ransomware a Kaseya
- En este caso de julio de 2021, los hackers explotaron seis vulnerabilidades de día cero en la herramienta de gestión remota de Kaseya y utilizaron estas vulnerabilidades para distribuir una carga maliciosa de ransomware mediante una actualización de software que infectó a cientos de proveedores de servicios gestionados (MSP) y a sus clientes. El ataque paralizó las operaciones de casi 2000 empresas en todo el mundo y ocupó titulares cuando los atacantes exigieron un asombroso rescate de 70 millones de dólares (que finalmente no se pagó).
Ataque de CI/CD a Codecov
- En enero de 2021, actores maliciosos se infiltraron en la popular herramienta de pruebas de código Codecov, que en aquel momento utilizaban más de 29 000 clientes. Los atacantes obtuvieron acceso no autorizado al script Bash Uploader de Codecov e introdujeron código malicioso que después utilizaron los clientes de Codecov en sus canalizaciones de CI/CD. Codecov no detectó ni notificó el ataque hasta abril de 2021, lo que significa que estos actores maliciosos pudieron haber tenido acceso a datos sensibles en miles de sistemas de clientes durante meses.
- Cada una de estas brechas en la cadena de suministro provocó daños en cascada y de gran alcance tanto al proveedor explotado como a sus miles de clientes y más allá.

Impactos graves de los ataques a la cadena de suministro

No se debe subestimar la magnitud del daño que provocan los ataques a la cadena de suministro de software. Cada uno de los ataques anteriores causó daños financieros y reputacionales significativos, y llevó a muchas organizaciones a replantearse su enfoque de la seguridad de los proveedores.

Impactos financieros

Cybersecurity Ventures predice que el coste anual global de los ataques a la cadena de suministro de software para las empresas alcanzará la asombrosa cifra de 138 000 millones de dólares en 2031, frente a los 60 000 millones de 2025. Estas pérdidas abarcan desde la pérdida de ingresos y los costes de remediación hasta los honorarios legales y posibles sanciones por incumplimiento normativo. Tras su filtración de datos de 2023, las acciones de Okta cayeron un 11 %. Tras otra importante filtración de datos en 2022, Okta se enfrentó después a una demanda de los accionistas afectados y tuvo que pagar 60 millones de dólares.

Impactos operativos

Los ataques a la cadena de suministro pueden provocar que miles de clientes sufran interrupciones y apagados de sistemas, paralizando operaciones críticas y causando retrasos que afectan a otros proveedores. Veamos solo algunas de las instituciones afectadas por la brecha de Kaseya. En Suecia, un gran minorista de alimentación se vio obligado a cerrar 800 tiendas durante el fin de semana, y los ferrocarriles estatales también sufrieron interrupciones. Once colegios y más de 100 guarderías de Nueva Zelanda también tuvieron que detener todas sus operaciones en línea y recurrir a papel y bolígrafo hasta que se pudo resolver el incidente.

Daño reputacional

Una reputación dañada públicamente puede hacer retroceder a una empresa en términos de confianza con sus clientes y accionistas. Las empresas pueden perder proveedores y la fidelidad de clientes que tardaron años en consolidar. En marzo de 2023, el popular software de comunicaciones empresariales 3CX se vio comprometido cuando los hackers inyectaron código malicioso en su aplicación, lo que potencialmente expuso datos sensibles de más de 600 000 clientes y generó meses de atención negativa en los medios y críticas públicas hacia la empresa.

¿Dónde termina la responsabilidad? Deuda técnica y responsabilidad compartida

Dado que se espera que las amenazas a la cadena de suministro de software aumenten en frecuencia y gravedad, es imprescindible que las empresas establezcan responsabilidades claras y adopten prácticas recomendadas de seguridad estrictas para los proveedores externos y la ciberseguridad de la cadena de suministro de software.

¿Quién es responsable de la seguridad del software?

Actualmente, muchas organizaciones carecen de procesos estrictos y estandarizados para evaluar la seguridad de los proveedores externos. Además, muchos clientes y proveedores ni siquiera están alineados sobre quién asume la responsabilidad de gestionar la seguridad del software de terceros.

El Informe sobre tendencias del estado de la ciberseguridad analizó organizaciones con distintos niveles de capacidades de ciberseguridad para desarrollar nuestra Escala de madurez en ciberseguridad. Esta escala iba desde organizaciones menos maduras (niveles 1 y 2) hasta organizaciones con capacidades de ciberseguridad más avanzadas (nivel 4).

A través de esta investigación, constatamos que las organizaciones menos maduras solían creer con mayor frecuencia que la ciberseguridad era responsabilidad exclusiva del proveedor. Sin embargo, las organizaciones con los niveles más altos de preparación en ciberseguridad defendían una responsabilidad compartida entre el proveedor de software y el cliente.

Cómo protegerse frente a las amenazas a la cadena de suministro de software

La seguridad de la cadena de suministro de software es una parte esencial de una estrategia de ciberseguridad integral y proactiva.

Reforzar su cadena de suministro de software y defenderse frente a posibles ataques exige que las organizaciones traten a todos los proveedores y componentes de terceros como una extensión de toda su superficie de ataque. Estas son nuestras principales recomendaciones para que las organizaciones se aseguren de estar mejor preparadas para prevenir ataques a la cadena de suministro, así como para detectar cualquier posible amenaza a la cadena de suministro y responder ante ella.

1. Gestión rigurosa de proveedores y evaluación de riesgos

Aplique la diligencia debida antes de asociarse con proveedores de software. Busque proveedores que cumplan los estándares del sector y dispongan de una política publicada de divulgación de vulnerabilidades. Las auditorías periódicas, las revisiones de código y la evaluación proactiva tanto por parte del proveedor como del cliente son claves para mitigar los riesgos.

Nuestra investigación muestra que las organizaciones con los niveles más avanzados de ciberseguridad son las más propensas a aplicar la diligencia debida al evaluar la ciberseguridad de sus proveedores externos, por ejemplo:

Incorporar cuestionarios de evaluación de seguridad (SAQ) en su evaluación.
Considerar las certificaciones de seguridad de los proveedores, como ISO 27001 y SOC 2.
Revisar los estándares de cumplimiento específicos del sector.
Asegurarse de que los proveedores cuenten con planes de respuesta a incidentes y procesos para gestionar posibles brechas de seguridad.
Solicitar una lista de materiales de software (SBOM) para comprender los componentes de código abierto y de terceros utilizados en su software.

2. Supervisión continua y remediación proactiva en todas las dependencias

Es clave emplear herramientas y procesos automatizados de detección de amenazas para supervisar y evaluar todos sus componentes de software. Las dependencias, especialmente en los componentes de software de código abierto, a menudo se pasan por alto y suponen un importante riesgo de vulnerabilidad si no se supervisan y actualizan periódicamente.

Las herramientas de IA y automatización pueden proporcionar información en tiempo real sobre el rendimiento de dispositivos, aplicaciones y redes para detectar posibles problemas. Las soluciones de autorrecuperación y remediación automatizada ofrecen formas eficaces de resolver problemas con una intervención humana mínima o nula.

3. Comunicación periódica con proveedores externos

Una piedra angular para establecer la responsabilidad mutua en la seguridad de la cadena de suministro de software es la comunicación frecuente y abierta entre clientes y proveedores externos. Los equipos de seguridad y TI deben mantenerse informados sobre cualquier actualización de software, parches para corregir vulnerabilidades conocidas y cualquier amenaza de seguridad emergente.

Más información sobre la seguridad de la cadena de suministro de software

¿Quiere saber más? Lea el Informe sobre tendencias del estado de la ciberseguridad completo para obtener información detallada sobre las amenazas de ciberseguridad más urgentes de la actualidad y las estrategias para una gestión proactiva del riesgo.

Cómo convertir la evaluación cuantitativa de riesgos en acciones

Tue, 15 Apr 2025 13:50:58 Z

Resumen
La evaluación cuantitativa de riesgos traduce el riesgo de ciberseguridad a términos financieros.
Puede utilizar el resultado de una evaluación cuantitativa de riesgos para decidir su respuesta al riesgo: evitarlo, aceptarlo, transferirlo o mitigarlo.
Un marco de apetito de riesgo le permite gestionar casos con matices o ambiguos en los que la respuesta al riesgo adecuada no está clara.
En conjunto, estos procesos ayudan a las organizaciones a equilibrar los imperativos de seguridad con los objetivos de negocio.

La evaluación cuantitativa de riesgos ofrece un enfoque objetivo para el análisis de riesgos, pero comprender el riesgo es solo el primer paso. En este artículo se explica cómo interpretar los resultados y convertir esos conocimientos en decisiones significativas en un entorno real.

(Aunque este artículo no aborda cómo realizar un análisis cuantitativo de riesgos, puede profundizar en el proceso en nuestra Guía para la evaluación de riesgos basada en datos.)

Comprender la cuantificación del riesgo

Empecemos por lo básico: ¿qué es exactamente la evaluación cuantitativa de riesgos?

¿Qué es la cuantificación del riesgo?

La evaluación cuantitativa de riesgos (a veces abreviada como QRA) asigna un valor monetario a un riesgo de ciberseguridad en función de su impacto potencial y su probabilidad. Plantea la pregunta: Si este activo queda expuesto a través de esta vulnerabilidad, ¿cuánto nos costará? A diferencia de los métodos cualitativos, que clasifican los riesgos en categorías de gravedad, un enfoque cuantitativo ofrece una visión más objetiva.

¿Por qué es importante? Las evaluaciones cualitativas de riesgos de ciberseguridad dejan mucho más margen a la interpretación. Traducir el riesgo al lenguaje del negocio —es decir, a cifras económicas— elimina gran parte de esta ambigüedad y ayuda a los líderes ajenos al ámbito de la seguridad a comprender qué significa realmente un riesgo “alto” en su contexto.

¿Cómo encaja la cuantificación del riesgo en una estrategia de ciberseguridad más amplia?

Cuantificar el riesgo es una herramienta esencial para gestionar la exposición, pero no es el objetivo final. Más bien, sienta las bases para tomar decisiones de mitigación del riesgo.

Por ejemplo, cuando se puede presentar la exposición al riesgo como, por ejemplo, “1,5 millones de dólares en daños potenciales debido a que un proveedor utiliza comunicaciones en la nube sin cifrar”, resulta más fácil sopesar las opciones para responder a ese riesgo, algo que analizaremos con más detalle más adelante en este artículo.

Interpretar el análisis cuantitativo de riesgos: elementos clave

Hay algunos elementos clave de un análisis cuantitativo de riesgos que es importante comprender para interpretar los resultados.

Valor del activo (AV): Lo que vale para su organización el activo que se protege.
Factor de exposición (EF): El porcentaje del valor del activo que puede perderse o verse comprometido si el riesgo se materializa.
Tasa anualizada de ocurrencia (ARO): La frecuencia con la que se espera que ese riesgo se materialice cada año. (Puede ser inferior a 1 en el caso de riesgos que se materializan menos de una vez al año).

Estas tres cifras permiten calcular:

Pérdida única esperada (SLE): El valor financiero que se perdería en un único evento de amenaza si el riesgo se materializa. Este valor se calcula mediante la fórmula AV x EF.
Pérdida anual esperada (ALE): El valor financiero que se perdería anualmente si el riesgo se materializa. Este valor se calcula mediante la fórmula SLE x ARO.
ALE residual: El valor financiero que se perdería anualmente si el riesgo se materializa después de aplicar mitigaciones. Las mitigaciones reducen el EF, la ARO o ambos, pero, por lo demás, los cálculos siguen siendo los mismos.

La ALE es el principal resultado del análisis de riesgos y la cifra más importante que utilizará para sopesar sus opciones de respuesta al riesgo. Pero no es una cifra perfecta, por eso hay un elemento clave más: incertidumbre.

AV, EF y ARO son estimaciones. Lo ideal es que sean estimaciones muy precisas, basadas en una investigación rigurosa, pero siguen siendo estimaciones. El nivel de confianza que debería tener en esas estimaciones suele representarse mediante un nivel de confianza (por ejemplo, 80 %), seguido de una lista de incógnitas.

Del análisis a la práctica: respuesta al riesgo

Hasta ahora hemos explicado cómo interpretar una evaluación cuantitativa de riesgos. Pero el propósito último del análisis de riesgos es decidir qué hacer con ese riesgo.

En términos generales, todas las respuestas al riesgo se encuadran en una de cuatro categorías: evitar, aceptar, transferir o mitigar.

Evitar

Evitar el riesgo significa eliminar por completo la exposición. Es la única respuesta al riesgo que lo reduce realmente a cero. En términos prácticos, esto implica cerrar un proceso o sistema que conlleva riesgo.

Evitar el riesgo es, en la práctica, una opción drástica y rara vez viable. Por ejemplo, se puede reducir a cero el riesgo de phishing cerrando todo el intercambio de correo electrónico externo. Si se trabaja en asuntos de seguridad nacional, puede que merezca la pena. Para la mayoría de organizaciones, esto paralizaría las operaciones empresariales.

Su análisis de riesgos podría respaldar esta respuesta en dos situaciones: si la ALE es tan extrema que ninguna estrategia de mitigación puede reducirla a un nivel aceptable, o si existe una alternativa equivalente al proceso o sistema que conlleva riesgo y que reduciría el EF o la ARO a cero.

Aceptar

Aceptar el riesgo significa optar por no hacer nada. Aunque a primera vista pueda parecer poco razonable, es una opción que merece una consideración seria.

Hay un escenario muy claro en el que aceptar el riesgo es la mejor opción: cuando el coste de la mitigación supera la ALE residual (es decir, la ALE después de la mitigación). En esta situación, proteger a su organización cuesta más de lo que podría perder.

Pero también hay situaciones más matizadas en las que la aceptación tiene sentido. Estas tienen en cuenta el coste de oportunidad de mitigar un riesgo, ya sea centrado estrictamente en el equipo de seguridad o como coste de oportunidad para el negocio en su conjunto.

Ningún equipo de seguridad dispone de recursos ilimitados. La aceptación es una opción razonable (aunque incómoda) si optar por mitigar este riesgo implica desviar recursos de una exposición más preocupante. Especialmente cuando la estrategia de mitigación es muy manual y requeriría muchas horas de personal para implementarse, ¿qué dejan de hacer esas personas para poder dedicar su tiempo a este esfuerzo?

También hay que considerar un coste de oportunidad más amplio: las oportunidades a las que el negocio tendría que renunciar para mitigar o evitar el riesgo. En otras palabras, la aceptación puede tener sentido cuando la oportunidad de negocio es mayor que la ALE. Este podría ser el caso si, por ejemplo, se abre un centro de datos en un país extranjero para ofrecer servicios en la nube a un nuevo mercado. Aunque esto expone a la organización a nuevos riesgos de seguridad, existe un beneficio empresarial claro.

Transferir

Transferir el riesgo significa trasladar la carga a otra parte, normalmente mediante un seguro de ciberseguridad. En términos generales, transferir el riesgo a un seguro es una opción cuando el seguro cuesta menos que la ALE, aunque hay algunas consideraciones importantes.

En primer lugar, el seguro solo cubre el coste financiero de un incidente de seguridad. Los incidentes de seguridad también llevan asociados daños legales y reputacionales. Si la ALE tuvo en cuenta estos daños y les asignó un valor monetario (como idealmente debería haber hecho), deberá desglosar esa cifra para analizar únicamente los costes financieros inmediatos. Transferir el riesgo tiene sentido cuando el riesgo financiero es alto, pero los riesgos legales y reputacionales son bajos.

En segundo lugar, es casi seguro que el seguro exigirá que tenga implantados algunos controles de seguridad, y también podría dejar de cubrir incidentes recurrentes. Esto significa que tendrá que sumar el coste de esos controles al coste del seguro, lo que posiblemente cambie el cálculo. También significa que transferir el riesgo a un seguro solo puede ser una medida temporal para un riesgo con una ARO alta.

Mitigar

La mitigación es la respuesta más proactiva: permite reducir la exposición aplicando controles de seguridad, parcheando vulnerabilidades, corrigiendo configuraciones incorrectas, etc.

La mitigación no eliminará su exposición; la única forma de hacerlo es evitar el riesgo por completo. En cambio, la mitigación reduce el riesgo mediante medidas para disminuir el EF, la ARO o ambos. Después puede calcular una nueva ALE, conocida como ALE residual.

En general, la mitigación es una opción sólida cuando la diferencia entre la ALE original y la ALE residual es mayor que el coste de la mitigación.

Incorporar el apetito de riesgo (o cómo gestionar los casos límite)

No todas las evaluaciones de riesgos ofrecen una elección de respuesta evidente. Siempre habrá casos en los que los márgenes entre dos opciones sean estrechos o el nivel de incertidumbre sea alto. Incorporar el apetito de riesgo le ayudará a interpretar esos casos límite. El apetito de riesgo no suele formar parte de un análisis de riesgos, pero es un marco útil para interpretar dicho análisis.

(Si su organización aún no tiene documentado su apetito de riesgo, puede utilizar esta plantilla editable de declaración de apetito de riesgo como punto de partida).

El apetito de riesgo es el nivel de riesgo que una organización está dispuesta a aceptar para alcanzar sus objetivos. Un apetito de riesgo alto significa estar abierto a aceptar mayores riesgos a cambio de posibles mayores recompensas, mientras que un apetito de riesgo bajo significa que se prefiere reducir el riesgo todo lo posible. El apetito de riesgo existe en múltiples dimensiones: puede haber un apetito alto por el riesgo operativo, pero un apetito bajo por el riesgo de cumplimiento normativo.

Dentro de cada una de estas dimensiones (riesgo de seguridad, riesgo de cumplimiento normativo, riesgo de innovación, etc.), hay varios factores clave que considerar:

Capacidad de riesgo es la cantidad máxima de riesgo que una organización puede asumir, normalmente determinada por los recursos financieros, las capacidades operativas y las restricciones normativas.
Tolerancia al riesgo es una desviación aceptable respecto a su objetivo.
Umbrales de riesgo son “líneas rojas” que indican la necesidad de cambiar de estrategia.

El umbral entre la tolerancia y la capacidad, o incluso entre distintos grados de tolerancia, puede ayudarle a ordenar las zonas grises, donde no está claro cuál es la respuesta al riesgo adecuada.

Convertir los conocimientos en acción

Comprender una evaluación cuantitativa de riesgos es solo el primer paso; el verdadero valor está en utilizar esos conocimientos para actuar. Ya sea mediante la evitación, aceptación, transferencia o mitigación del riesgo, el objetivo es el mismo: equilibrar los riesgos de seguridad con las prioridades del negocio para poder actuar con decisión.

Preguntas frecuentes
¿Qué es la evaluación cuantitativa de riesgos?La evaluación cuantitativa de riesgos, a veces abreviada como QRA, es un proceso formal para asignar un valor financiero a un riesgo de ciberseguridad en función de su impacto potencial y la probabilidad de que ocurra.
¿Qué es la pérdida anual esperada? La pérdida anual esperada es el principal resultado de una evaluación cuantitativa de riesgos. Es el valor financiero que se perdería anualmente si este riesgo se materializa. Se calcula mediante la fórmula Pérdida única esperada (SLE) x Tasa anualizada de ocurrencia (ARO), donde la pérdida única esperada es Valor del activo (AV) x Factor de exposición (EF).
¿Qué es el apetito de riesgo?El apetito de riesgo es el nivel de riesgo que una organización está dispuesta a aceptar para alcanzar sus objetivos. Influye en las decisiones de respuesta al riesgo al proporcionar un marco para evaluar las compensaciones entre los riesgos de seguridad y las prioridades del negocio.

Cómo pueden los responsables de TI evaluar las afirmaciones sobre software seguro desde el diseño

Mon, 24 Feb 2025 16:47:03 Z

Republicado con permiso de CIO.com

No es ningún secreto que las ciberamenazas van en aumento. El coste de la ciberdelincuencia notificada en EE. UU. aumentó un 22 % durante 2023, hasta superar los 12.500 millones de dólares, según el Internet Crime Complaint Center del FBI. Uno de los problemas son las debilidades que los enfoques tradicionales de codificación y seguridad han perpetuado en el software. Para combatir estos riesgos, ahora existe un esfuerzo coordinado por crear software que sea seguro desde el diseño. Por ejemplo, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA) ha definido un conjunto de medidas que los proveedores pueden adoptar para demostrar que están aplicando principios de seguridad desde el diseño.

Sin embargo, sin estándares y métricas exigibles, a los responsables de TI y seguridad les resulta difícil evaluar si los proveedores están aplicando este enfoque seguro desde el diseño y cómo lo hacen. Estas son algunas medidas que pueden adoptar.

Incorporar prácticas de seguridad desde el diseño en las evaluaciones de riesgos de seguridad

La evaluación de riesgos de proveedores es un proceso estándar mediante el cual las empresas identifican y evalúan los posibles peligros asociados a los productos y operaciones de un proveedor. Los responsables de TI y seguridad pueden utilizar este proceso para centrarse en los principios y las prácticas de seguridad desde el diseño, afirma Michael Riemer, Field Chief Information Security Officer de Ivanti.

«Para nosotros, como proveedor de software, significa asumir plena responsabilidad sobre nuestros propios productos», afirma Riemer. «Hay que examinar toda la arquitectura de la solución y tener en cuenta la seguridad en todos los ámbitos, como el diseño de la arquitectura, el almacenamiento, la conectividad, el uso, etc.»

Como parte de la evaluación de riesgos de seguridad, las empresas también deberían considerar exigir un informe SOC 2 Tipo 2. Este tipo de evaluación ofrece más garantías sobre cómo protege un proveedor los datos y la información de los clientes. Implica una auditoría de ciberseguridad realizada por un tercero que evalúa cómo funcionan los controles y las prácticas de seguridad internos del proveedor durante un periodo prolongado.

Estas son algunas preguntas clave que todo proveedor debería poder responder:

¿Con qué frecuencia realizan pruebas de penetración?
¿Qué tipos de pruebas de penetración se realizan?
¿Realizan análisis de código tanto estático como dinámico?

Evaluar las prácticas de codificación

Las prácticas de codificación tradicionales son secuenciales: un equipo trabaja en un módulo, luego lo pasa al siguiente equipo, y así sucesivamente. Pero esto mantiene las debilidades que se introducen en la base de código, señala Riemer. Al reestructurar los equipos en «pods» o grupos, cada uno con un arquitecto de seguridad dedicado, las debilidades pueden eliminarse desde el principio. Este fue un cambio importante para Ivanti, afirma Riemer. Los proveedores deberían poder demostrar estos cambios organizativos y las nuevas prácticas.

Evaluar la transparencia de la seguridad desde el diseño

Los proveedores deben poder hacer públicos sus objetivos de seguridad desde el diseño, y demostrar que informan o informarán sobre las métricas de forma periódica. Los clientes también deben poder realizar un seguimiento del progreso del proveedor en todos sus módulos de software.

«Hemos creado objetivos específicos y establecido una línea de referencia y métricas», afirma Riemer. «Nos estamos responsabilizando de nuestro avance en seguridad desde el diseño. Estas métricas mostrarán qué módulos de software hemos analizado y hasta qué punto han profundizado los análisis para identificar y corregir prácticas de codificación débiles.»

Conclusión

Los responsables de negocio y de TI pueden utilizar los principios de seguridad desde el diseño para evaluar los avances logrados por sus proveedores de software en la creación de código que sea intrínsecamente más seguro. La seguridad desde el diseño permite a estos responsables minimizar los riesgos empresariales.

Cómo pueden colaborar los CIO y los CISO para mejorar la productividad de la plantilla y la seguridad

Mon, 24 Feb 2025 16:46:54 Z

Publicado de nuevo con permiso de CIO.com

Muchas organizaciones siguen teniendo dificultades para adaptarse a los requisitos del trabajo flexible, a la vez que mantienen la ciberseguridad empresarial. Una razón clave es que los CIO y los directores de seguridad de la información (CISO) no siempre están alineados sobre cómo posibilitar un trabajo productivo y seguro.

Los requisitos del trabajo flexible implican cambios tanto para los equipos de ITOps como para los de SecOps. Pero, en la práctica, los equipos de TI y seguridad suelen trabajar por separado, sin conocimientos, datos, objetivos, prioridades ni prácticas comunes. Por ello, ambos equipos pueden centrarse en sus propias prioridades independientes, lo que también significa que los datos relacionados con la productividad y la seguridad de los trabajadores de la información quedan atrapados en silos.

«Los clientes nos dicen que, para las personas de operaciones de TI y de operaciones de seguridad, hay alineación en teoría, pero a menudo solo en la alta dirección», afirma Corinna Fulton, vicepresidenta de Marketing de Soluciones de Ivanti. «No está llegando a sus respectivas organizaciones en forma de ejemplo desde el liderazgo, procesos, etc. Y puede que el CIO y el CISO ni siquiera vean esta brecha».

Esta falta de alineación en los niveles directivos está generando una desconexión en lo que respecta a la experiencia del empleado. El informe Everywhere Work 2024 de Ivanti reveló que el 40 % de los empleados de oficina y el 49 % de los profesionales de TI considerarían cambiar de empleo para obtener más flexibilidad en el trabajo, lo que demuestra su importancia, especialmente para los trabajadores más jóvenes. Además, solo el 57 % de los empleados de oficina afirma que podría acceder fácilmente a las mismas herramientas si tuviera que trabajar en remoto mañana, aunque más del 90 % de los líderes encuestados creen que sus empleados remotos tienen todo lo que necesitan para ser productivos. Está claro que los líderes de TI y seguridad tienen mucho trabajo por delante para satisfacer las expectativas de trabajo flexible de empleados y líderes empresariales.

De lo contrario, mantener esa falta de alineación conduce a la frustración, las debilidades de seguridad y una productividad subóptima. «En última instancia, se está afectando a los ingresos», afirma Fulton. «Tanto el CIO como el CISO quieren evitarlo».

Cómo pueden los CIO y los CISO construir una colaboración eficaz

Para integrar los esfuerzos de TI y seguridad con el fin de posibilitar un trabajo flexible seguro y productivo, estos líderes pueden empezar con seis acciones:

Definir con precisión los riesgos reales asociados al trabajo flexible. Teniendo en cuenta la tolerancia al riesgo de la organización, los CIO y los CISO deben aclarar el nivel de riesgo aceptable, cómo minimizarlo y qué procesos de mitigación pueden establecerse conjuntamente. Este acuerdo es la base para alinear los objetivos y prioridades de TI y seguridad, afirma Fulton.
Establecer un conjunto común de estándares y métricas concretos. Esto puede utilizarse para evaluar los riesgos del trabajo flexible. Un ejemplo básico es el «tiempo de resolución», desde el momento en que SecOps identifica un riesgo hasta que ITOps lo resuelve por completo. El enfoque común propicia una respuesta coordinada y eficaz.
Hacer un inventario de la infraestructura de trabajo flexible. La gestión de activos de TI ha pasado de ser un simple inventario a convertirse en un facilitador de la productividad y la seguridad, afirma Fulton. Saber con qué se cuenta permite identificar posibles vulnerabilidades y tomar medidas para corregirlas.
Eliminar los silos de datos. La visibilidad en todas las fuentes de datos clave es esencial para que los equipos de TI y seguridad puedan acceder a un conjunto común de datos relevantes para la productividad y la seguridad de los empleados, y comprenderlo. Ponga en marcha un programa por fases para acceder a estos datos tan necesarios desde silos aislados.
Crear una hoja de ruta conjunta de TI y seguridad. Determine cómo y cuándo se implementarán los objetivos y prioridades comunes. Después, comunique esta hoja de ruta a ambos equipos para orientar su comprensión y garantizar que todo el mundo trabaje hacia los mismos objetivos.
Considerar el impacto en el personal. Tenga en cuenta el efecto que las políticas de TI y seguridad tendrán en los trabajadores de la información. Coordinarlas con las necesidades y preferencias de los usuarios finales es clave para optimizar la productividad de los empleados y la seguridad empresarial.

En resumen

Los CIO y los CISO pueden tomar medidas concretas para superar las barreras que impiden un trabajo productivo y seguro mediante el establecimiento de una estrategia y una estructura comunes que permitan a sus organizaciones trabajar juntas.

Comprender el apetito de riesgo: un componente fundamental de la gestión de la exposición

Mon, 10 Feb 2025 14:44:03 Z

El riesgo es inherente a cualquier empresa. Lo que marca la diferencia es cómo lo entiende y lo gestiona una organización.

Desde los retos operativos hasta la volatilidad del mercado, los cambios normativos y los avances tecnológicos, las empresas se enfrentan a un amplio abanico de incertidumbres que pueden generar crecimiento o provocar pérdidas.

Para gestionarlas de forma eficaz, una empresa debe establecer un marco que le ayude a determinar cuánto riesgo está dispuesta a aceptar para alcanzar sus objetivos. Aquí es donde entra en juego el concepto de «apetito de riesgo».

Pero, para definir su apetito de riesgo, una empresa debe ver y comprender todos los riesgos a los que se enfrenta. Y, para los equipos de seguridad que están sentando las bases de su estrategia de gestión de la exposición, definir el apetito de riesgo de su organización es un paso fundamental.

¿Qué es el apetito de riesgo?

El apetito de riesgo es el nivel de riesgo que una organización está dispuesta a aceptar para alcanzar sus objetivos. Definirlo establece límites para la organización sobre qué riesgos asumirá y en qué medida. Un apetito de riesgo alto implica estar dispuesto a aceptar mayores riesgos a cambio de recompensas potencialmente mayores, mientras que un apetito de riesgo bajo implica que la organización prefiere reducir el riesgo tanto como sea posible.

Pensemos en una startup tecnológica que quiere invertir en investigación y desarrollo de vanguardia. Puede adoptar un mayor apetito de riesgo para lograr innovaciones disruptivas y revolucionarias, sabiendo que las posibles recompensas compensan la incertidumbre. Por el contrario, una gran corporación bien consolidada podría tener un menor apetito de riesgo, centrarse en un crecimiento sostenido y evitar proyectos que pudieran perjudicar de forma significativa su posición en el mercado o su reputación.

El apetito de riesgo es tanto cuantitativo como cualitativo

El apetito de riesgo nunca es estático; es una medida dinámica que debe ajustarse en función de factores como el sector, el tamaño y la situación de la empresa, los objetivos estratégicos, los requisitos normativos y el entorno general del mercado.

Tampoco se trata solo de cifras: el apetito de riesgo combina factores cuantitativos y cualitativos.

Por un lado, una empresa puede tener elementos medibles, como la cantidad de pérdidas que está dispuesta a tolerar, sus ratios de deuda y el tipo de retorno de la inversión (ROI) al que aspira. También puede tener que considerar aspectos subjetivos, como el posible efecto sobre la reputación de la empresa, las consideraciones éticas y hasta qué punto sus decisiones se alinean con sus valores fundamentales.

¿Por qué es importante definir el apetito de riesgo?

Prácticamente cualquier organización que quiera tener éxito debe asumir riesgos calculados. Pero, sin una comprensión clara de su apetito de riesgo, puede derivar hacia una toma de decisiones incoherente, reactiva o excesivamente prudente. Esto puede traducirse en oportunidades perdidas o pérdidas empresariales. Por eso definir el apetito de riesgo es esencial:

Para alinear la estrategia y la gestión de riesgos

Contar con un apetito de riesgo claramente definido proporciona un marco estratégico que alinea las prácticas de gestión de riesgos con los objetivos empresariales generales. Cuando una empresa sabe cuánto riesgo está dispuesta a aceptar, puede buscar oportunidades que se ajusten a su apetito de riesgo y evitar otras que podrían exponerla a un riesgo indebido.

Para mejorar la toma de decisiones

Definir el apetito de riesgo permite a líderes y responsables tomar decisiones informadas al comprender con claridad qué constituye un riesgo aceptable. También establece expectativas sobre los comportamientos de asunción y evitación de riesgos en toda la organización, lo que ayuda a los responsables a evaluar las compensaciones entre riesgo y recompensa en distintos escenarios.

Para generar confianza entre las partes interesadas

Un apetito de riesgo claramente definido transmite a inversores, reguladores, empleados y otras partes interesadas que la organización da prioridad a la gestión de riesgos. También demuestra un enfoque metódico y fiable para equilibrar riesgo y recompensa, lo que refuerza aún más la confianza de las partes interesadas.

Para promover la coherencia

Cuando todas las personas de una organización tienen claro cuánto riesgo es permisible, les resulta más fácil tomar decisiones coherentes porque todas entienden qué se considera una apuesta aceptable. Esto reduce la probabilidad de trabajar con objetivos contrapuestos o incluso de avanzar en direcciones opuestas. Por ejemplo, un departamento jurídico podría frenar la gran idea de un equipo de marketing si no comparten la misma noción de riesgo aceptable.

Para respaldar una supervisión eficaz del riesgo

Cuando las empresas definen su apetito de riesgo, pueden implantar sistemas para supervisar los niveles de riesgo en toda la organización, desde las finanzas hasta las operaciones. Así, pueden detectar posibles problemas de forma temprana y asegurarse de que las actividades se mantengan dentro de los límites de lo que se considera seguro o, al menos, aceptable. Definir y supervisar indicadores clave de riesgo (KRI) proporciona alertas tempranas si alguien se acerca demasiado a esos límites.

¿Cómo define una empresa su apetito de riesgo?

Normalmente, una organización lo hace redactando una declaración de apetito de riesgo (RAS). Las primeras partes de una RAS exponen los objetivos estratégicos de la empresa y los riesgos asociados.

Una empresa puede querer convertirse en el proveedor de software líder de su sector. Debe enumerar los objetivos estratégicos que son esenciales para alcanzar esa meta y también los riesgos asociados a ellos. Por ejemplo, Ivanti se dedica a ofrecer servicios de TI basados en la nube y soluciones de gestión de la seguridad. Eso significa que nuestra declaración de apetito de riesgo debe catalogar todos los riesgos asociados a esa línea de negocio y explicar cómo los gestionaremos.

Este es un ejemplo de cómo podría ser una sección de una declaración de apetito de riesgo para un proveedor de software:

Apetito de riesgo general
[Empresa XYZ] adopta un enfoque equilibrado del riesgo, reconociendo que no todos los riesgos son iguales y que cierto nivel de riesgo es necesario para alcanzar nuestros objetivos estratégicos.
Riesgo de innovación Tenemos un apetito de riesgo alto para invertir en tecnologías avanzadas y soluciones innovadoras que diferencien nuestros productos en el entorno competitivo. Entendemos que esto exige aceptar cierto grado de incertidumbre en I+D y en el desarrollo de productos.
Riesgo operativo Mantenemos un apetito de riesgo de bajo a moderado. Aunque aspiramos a la excelencia operativa, priorizamos iniciativas que mejoren la eficiencia y la calidad del servicio sin comprometer nuestros estándares de entrega.
Riesgo de seguridad Tenemos un apetito de riesgo extremadamente bajo ante amenazas y brechas de seguridad. Nuestro compromiso con la seguridad de la red y la protección de datos es primordial, e invertimos de forma significativa en proteger nuestros sistemas y los datos de nuestros clientes.
Riesgo de cumplimiento Tenemos un apetito de riesgo bajo ante el incumplimiento de requisitos legales y normativos. Garantizar la adhesión a las leyes, normas y mejores prácticas pertinentes en todas las áreas operativas es fundamental.

Apetito de riesgo general [Empresa XYZ] adopta un enfoque equilibrado del riesgo, reconociendo que no todos los riesgos son iguales y que cierto nivel de riesgo es necesario para alcanzar nuestros objetivos estratégicos.
Riesgo de innovación	Tenemos un apetito de riesgo alto para invertir en tecnologías avanzadas y soluciones innovadoras que diferencien nuestros productos en el entorno competitivo. Entendemos que esto exige aceptar cierto grado de incertidumbre en I+D y en el desarrollo de productos.
Riesgo operativo	Mantenemos un apetito de riesgo de bajo a moderado. Aunque aspiramos a la excelencia operativa, priorizamos iniciativas que mejoren la eficiencia y la calidad del servicio sin comprometer nuestros estándares de entrega.
Riesgo de seguridad	Tenemos un apetito de riesgo extremadamente bajo ante amenazas y brechas de seguridad. Nuestro compromiso con la seguridad de la red y la protección de datos es primordial, e invertimos de forma significativa en proteger nuestros sistemas y los datos de nuestros clientes.
Riesgo de cumplimiento	Tenemos un apetito de riesgo bajo ante el incumplimiento de requisitos legales y normativos. Garantizar la adhesión a las leyes, normas y mejores prácticas pertinentes en todas las áreas operativas es fundamental.

La RAS debe definir los riesgos que tendrían el mayor impacto en la organización, no los riesgos cotidianos que simplemente forman parte de la actividad empresarial. Debe contemplar múltiples escenarios de riesgo; por ejemplo, una estrategia concreta puede implicar riesgo en la cadena de suministro, como los efectos de depender de un proveedor o los peligros de exposición normativa si un proveedor gestiona de forma inadecuada los datos de los clientes.

También debe definir la cantidad de riesgo financiero que una empresa está dispuesta a asumir. Si entre sus objetivos está ofrecer un nuevo producto o servicio, siempre existe la posibilidad de fracasar en el mercado.

Componentes del apetito de riesgo

Estos son factores clave que deben tenerse en cuenta al definir el apetito de riesgo:

Capacidad de riesgo

Hace referencia a la cantidad máxima de riesgo que una organización puede soportar. Esto lo determinan los recursos financieros, las capacidades operativas y las restricciones normativas. Y la capacidad de riesgo difiere del apetito de riesgo: una organización puede tener capacidad para asumir un determinado nivel de riesgo, pero optar por no hacerlo en función de su apetito de riesgo.

Tolerancia al riesgo

Mientras que la capacidad de riesgo se refiere a cuánto riesgo puede soportar una organización, la tolerancia al riesgo es una desviación aceptable respecto a su objetivo. Incluso puede establecer distintas tolerancias para distintas áreas. Por ejemplo, una organización puede estar dispuesta a asumir riesgos con un nuevo producto, pero ser reacia al riesgo en la gestión de datos de clientes.

Umbrales de riesgo

Ya hemos mencionado la supervisión del riesgo y los KRI, ya que se utilizan para evitar que una empresa cruce los umbrales de riesgo: las «líneas rojas» que representan un exceso de riesgo. Cruzar un umbral de riesgo podría requerir un cambio de planes, el aumento de las medidas de seguridad o incluso la paralización completa de la actividad.

Relacionado: informe de investigación de Ivanti: Alinear perspectivas: la gestión del riesgo cibernético en la alta dirección

¿Por qué es importante el apetito de riesgo en la gestión de la exposición?

Hubo un tiempo en que mitigar el riesgo digital era mucho más sencillo que hoy. Esto se debe a que las superficies de ataque de la mayoría de las grandes organizaciones se han ampliado enormemente con el tiempo. La incorporación de más dispositivos y aplicaciones, utilizados por empleados en más lugares, ha transformado el entorno de trabajo y ampliado el panorama de amenazas digitales.

Es una de las razones por las que la investigación de Ivanti reveló que más de la mitad de los profesionales de TI no confían demasiado en poder prevenir un incidente de seguridad perjudicial en los próximos 12 meses. Más de uno de cada tres incluso afirma estar menos preparado para detectar amenazas y responder a incidentes que hace un año.

La gestión de vulnerabilidades tradicional se ha centrado durante mucho tiempo en remediar de forma reactiva vulnerabilidades de software y hardware, así como otras CVE, pero normalmente solo aplica análisis intermitentes. Sin embargo, el escenario actual de ciberamenazas exige un nuevo enfoque.

La gestión moderna de la exposición se centra en encontrar y remediar riesgos y vulnerabilidades de forma continua y proactiva en toda la superficie de ataque digital. Ya procedan de activos de TI expuestos, endpoints y aplicaciones no protegidos, recursos basados en la nube u otros vectores. ¿Qué hace que la gestión de la exposición y el apetito de riesgo estén tan estrechamente relacionados?

Evaluar la exposición según niveles de riesgo aceptables: La gestión de la exposición implica cuantificar los niveles de riesgo asociados a distintas exposiciones. Al definir el riesgo aceptable, las organizaciones pueden comparar el posible impacto de distintos riesgos con su apetito de riesgo.
Asignar recursos en función del riesgo: Las organizaciones deben priorizar qué exposiciones suponen la mayor amenaza para sus estrategias, una evaluación que solo pueden realizar con una comprensión clara de su apetito de riesgo. Esa priorización les permite concentrar recursos en mitigar las más críticas, a menudo con la ayuda de una herramienta avanzada de RBVM.
Ajustar el apetito de riesgo: A medida que cambia el entorno empresarial o surgen nuevos riesgos, puede ser necesario ajustar el apetito de riesgo. Los datos y conocimientos que las organizaciones descubren como parte de su práctica de gestión de la exposición les ayudan a tomar decisiones informadas sobre esos ajustes.
Garantizar el cumplimiento: Muchos sectores tienen requisitos normativos relacionados con la gestión de riesgos, que a su vez influyen en el apetito de riesgo de una organización. La gestión de la exposición implica identificar y abordar riesgos que podrían provocar incumplimientos.

Relacionado: informe de investigación de Ivanti: Gestión de la superficie de ataque

Analizar el riesgo de seguridad desde la perspectiva de la gestión de la exposición

Una diferencia destacada entre la gestión de la exposición y otras prácticas de seguridad es que la gestión de la exposición no solo incluye priorizar la remediación de los riesgos que suponen el mayor riesgo para la organización, sino también definir activamente qué riesgos se encuentran dentro de la tolerancia al riesgo de la organización. Por ejemplo, una empresa de comercio electrónico puede estar dispuesta a aceptar mayores riesgos de seguridad para mantener su sitio en funcionamiento durante el Black Friday: para ella, la compensación merece la pena.

En lugar de considerar cada riesgo potencial como una crisis que necesita remediación inmediata, las organizaciones deben priorizarlos en función de las necesidades del negocio. En este marco, la mayoría de los riesgos no son malos: se trata de cómo se reacciona ante ellos, cómo se controlan y cómo se mitigan para llevarlos a un nivel aceptable.

Cómo la gestión de parches basada en riesgos prioriza los exploits activos

Fri, 03 Jan 2025 18:10:36 Z

La resistencia al cambio siempre está presente, especialmente si cree que los procesos que tiene implantados son eficientes y eficaces. Muchas organizaciones piensan así de sus procedimientos de gestión del software hasta que sufren una brecha o un incidente de seguridad y se preguntan qué ha fallado.

La realidad es que la mayoría de los programas de gestión de parches se basan en suposiciones y recomendaciones, en lugar de en datos sobre vulnerabilidades explotadas activamente. La gestión de parches basada en riesgos es la respuesta a este problema.

En este artículo encontrará:

Qué falla al mantener las prioridades habituales.
Qué es la gestión de parches basada en riesgos.
Por qué es el momento idóneo para adoptar la gestión de parches basada en riesgos.

Los problemas de la priorización habitual de parches

Las actualizaciones de funciones de software, las correcciones de seguridad, las correcciones de errores, las mejoras de rendimiento y muchos otros tipos de versiones de software existen desde los inicios del sector. Los proveedores suelen asignar una clasificación de gravedad u otra puntuación a cada una de ellas para indicar a los clientes qué consideran más importante.

Por desgracia, no existe ningún estándar sectorial asociado a estas clasificaciones, por lo que tenemos que comparar y priorizar las versiones para desplegarlas en nuestros sistemas basándonos en recomendaciones. Además, estas clasificaciones rara vez se actualizan para tener en cuenta el contexto de amenazas activas, aunque las vulnerabilidades cambien.

Pasar por alto una vulnerabilidad explotada activamente

Aunque son mejor que nada, las clasificaciones de gravedad de los proveedores suelen quedarse cortas. Pensemos en la vulnerabilidad Follina (CVE-2022-30190) publicada en mayo de 2022. Esta vulnerabilidad en la Herramienta de diagnóstico de soporte técnico de Microsoft Windows (MSDT) permite la ejecución remota de código.

Follina fue objeto de ataques durante varios meses antes de que Microsoft respondiera finalmente con varias actualizaciones. De forma alarmante, Microsoft solo asignó a esta vulnerabilidad una puntuación de 7.8 en Common Vulnerability Scoring System (CVSS) v3 y una gravedad de Importante. Si solo aplicaba parches en función de una gravedad Crítica, se le habría pasado por alto, dejando una brecha importante en su superficie de ataque.

Y lo que es peor, la puntuación CVSS de Follina se mantuvo en 7.8 incluso después de que se revelara que la vulnerabilidad se estaba explotando activamente para distribuir el ransomware Bisamware, lo que exponía a las organizaciones que la habían pasado por alto a un riesgo aún mayor.

Información sobre la amenaza de ransomware asociada a CVE-2022-30190 mostrada en Ivanti Neurons for VULN KB

Limitaciones de CVSS

Las clasificaciones de gravedad se «complementan» con puntuaciones CVSS de FIRST. A cada CVE se le asigna un número CVSS, como el 7.8 otorgado a CVE-2022-30190 en el ejemplo anterior.

Uno de los principales objetivos al calcular el número CVSS real es garantizar la estandarización, de modo que todas las CVE se puntúen de forma coherente y puedan compararse con precisión. Cuanto mayor sea la puntuación CVSS de una vulnerabilidad y del parche asociado, más crítico será desplegarlo en la mayoría de los entornos.

En el caso de actualizaciones de software que abordan varias CVE, normalmente se tiene en cuenta el valor CVSS más alto para la priorización. Pero ¿es realmente preciso ese valor?

Los resultados de un análisis de puntuaciones CVSS en un artículo reciente mostraron que existe una discrepancia en casi el 20 % de las puntuaciones CVSS (25 000). Este análisis se basó en una comparación de las puntuaciones notificadas en la National Vulnerability Database (NVD) del NIST y las comunicadas directamente por los propios proveedores.

Incoherencias en la gravedad asignada por los proveedores

Un punto importante que conviene tener en cuenta es que, históricamente, los proveedores han asignado su propia terminología a la gravedad (por ejemplo, crítica, importante). Usar la puntuación de gravedad del proveedor como mecanismo de priorización puede funcionar bien al comparar todos los parches de un proveedor determinado, pero no siempre ofrece una comparación precisa de parches entre distintos proveedores. De hecho, muchos utilizan terminología completamente diferente.

Del mismo modo, la gravedad asignada por el proveedor no siempre es un indicador positivo. Muchas vulnerabilidades de día cero solo reciben la calificación de Importante por parte de Microsoft, pero tienen puntuaciones CVSS elevadas. Esto demuestra que aplicar parches usando la gravedad y CVSS para la priorización se basa en suposiciones y recomendaciones, y puede dar lugar a un entorno vulnerable.

¿Por qué priorizar los exploits activos por encima de cualquier otro método de priorización?

Según la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de EE. UU. (CISA), una vulnerabilidad explotada activamente es “one for which there is reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner.” En términos sencillos, una vulnerabilidad bajo explotación activa es aquella que un actor de amenazas ha utilizado para lanzar un ciberataque.

Por tanto, para minimizar el riesgo de un ataque contra su organización, debe priorizar las vulnerabilidades explotadas activamente por encima de todas las demás. La buena noticia es que la mayoría de las vulnerabilidades no se están explotando activamente y, por tanto, suponen poco o ningún riesgo para su organización. Puede identificar las que sí se han explotado mediante la gestión de parches basada en riesgos.

¿Qué es la gestión de parches basada en riesgos?

La gestión de parches basada en riesgos es una extensión de la gestión de vulnerabilidades basada en riesgos, que va más allá de la gravedad asignada por los proveedores y de las puntuaciones CVSS básicas para identificar y cualificar las vulnerabilidades concretas que suponen el riesgo más significativo para una organización. Esto incorpora el contexto de riesgo real al proceso de gestión de parches para que los equipos de TI puedan centrar sus esfuerzos en las actualizaciones con vulnerabilidades explotadas conocidas que más importan para la postura de seguridad de una organización.

¿Cómo puede mi organización adoptar la gestión de parches basada en riesgos?

Para las organizaciones preparadas para adoptar un enfoque de gestión de parches basado en riesgos, un buen punto de partida es el catálogo Known Exploited Vulnerabilities (KEV) de CISA. CISA dio un gran paso adelante para ayudar a priorizar vulnerabilidades cuando presentó la Directiva operativa vinculante 22–01 junto con su catálogo KEV. Cuando se publicó originalmente, el catálogo contenía unas 200 vulnerabilidades explotadas activamente. Desde entonces, ha aumentado hasta casi 900.

CISA elabora la lista con el conocimiento de que las vulnerabilidades que contiene están siendo explotadas en escenarios reales por amenazas activas. Sin embargo, la lista tiene sus limitaciones, ya que actualmente excluye 131 vulnerabilidades asociadas al ransomware.

¿Es el catálogo KEV de CISA el único recurso disponible para la gestión de parches basada en riesgos?

Las organizaciones con prácticas de gestión de parches basada en riesgos más maduras aprovechan metodologías avanzadas de puntuación de riesgos en lugar de CVSS o además de este. Estas metodologías asignan puntuaciones a cada vulnerabilidad identificada en el entorno de una organización, lo que permite ampliar el enfoque basado en riesgos más allá del KEV de CISA.

Muchos proveedores del ámbito de la gestión de vulnerabilidades basada en riesgos han desarrollado metodologías de puntuación propias que representan el riesgo real que supone una vulnerabilidad. Lo hacen ofreciendo clasificaciones de riesgo dinámicas que dan un peso adicional a las vulnerabilidades explotadas activamente.

Por ejemplo, la Vulnerability Risk Rating (VRR) de Ivanti ha asignado a Follina una puntuación de 10, una puntuación que representa con mayor precisión el riesgo que plantea esa vulnerabilidad que su puntuación CVSS de 7.8.

Diferencia entre las puntuaciones VRR y CVSS v3 y los niveles de gravedad de CVE-2022-30190, tal como se muestra en Ivanti Neurons for VULN KB

Por qué es el momento idóneo para adoptar la gestión de parches basada en riesgos

Si cree que se ha quedado atrás con las actualizaciones del sistema o se siente desbordado por los nuevos sistemas y aplicaciones de su empresa, ahora es el momento idóneo para adoptar la gestión de parches basada en riesgos.

Incluso si considera que cuenta con un programa sólido basado en clasificaciones de gravedad y puntuaciones CVSS, es hora de superar la resistencia al cambio e iniciar un nuevo proceso antes de que su empresa sufra las graves consecuencias de una brecha de datos derivada de una vulnerabilidad explotada.

Empiece utilizando el KEV de CISA para priorizar sus actualizaciones y reservar presupuesto para una solución de gestión de vulnerabilidades y parches basada en riesgos. Con las herramientas adecuadas implantadas, puede identificar rápidamente los sistemas de mayor riesgo para aplicarles parches primero y avanzar por la lista para garantizar que sus sistemas estén protegidos.

¿Quiere dar el primer paso? Consulte este eBook, una guía integral para implantar un programa moderno de gestión de parches basada en riesgos.