Ivanti Blog: Publicaciones de

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.

5 razones por las que la preparación para la Directiva NIS2 debe empezar ya, segunda parte: la implementación lleva tiempo

Mon, 28 Aug 2023 17:43:02 Z

En una entrada de blog anterior, analicé las dos áreas principales que debe auditar antes de que la Directiva de Seguridad de las Redes y de la Información (NIS2) actualizada de la Unión Europea se ratifique como ley en octubre de 2024. En concreto, estas auditorías permitirían:

Identificar ya sus brechas respecto a los requisitos de la Directiva NIS2.

Revisar las deficiencias actuales de seguridad en su cadena de suministro.

Ahora que hemos descubierto estas deficiencias de seguridad, debemos corregirlas antes de que se agote el plazo en octubre de 2024.

Por eso, en esta entrada le explicaremos cómo resolver sus problemas de seguridad más débiles antes de que llegue la fecha límite de la Directiva NIS2, abordando estas tres áreas clave:

Informar a la dirección sobre sus brechas de ciberseguridad
Implementar correctamente nuevas medidas de seguridad organizativas y técnicas
Encontrar tiempo para formar a todos sus empleados

1. Informe a la dirección sobre sus brechas y consiga presupuesto para subsanarlas

La Directiva NIS2 impone obligaciones importantes a las organizaciones incluidas en su ámbito de aplicación, lo que puede conllevar costes y recursos considerables. La Directiva también introduce multas y sanciones elevadas por incumplimiento, hasta un máximo de 10 millones de euros o el 2 % de los ingresos anuales globales de una organización (artículo 34).

Además, la nueva directiva puede ampliar la responsabilidad de las entidades a sus representantes individuales en determinadas situaciones. Asimismo, cuando se cumplan ciertas condiciones, las personas que ocupen puestos de dirección podrían ser suspendidas temporalmente (artículo 32-5b).

Por tanto, cumplir la Directiva NIS2 es una necesidad legal y una prioridad estratégica.

Para cumplirla, debe:

Informar a la dirección sobre sus implicaciones y beneficios, y convencerla de que asigne presupuesto y recursos suficientes para implementar el cumplimiento.
Presentar un caso de negocio claro que describa los riesgos del incumplimiento, las oportunidades del cumplimiento y el retorno de la inversión.
Demostrar cómo el cumplimiento mejorará la reputación, la fiabilidad, la competitividad y la resiliencia de su organización.

Informar a la dirección y conseguir presupuesto es una tarea compleja que requiere un argumento persuasivo y basado en evidencias que demuestre el valor de la ciberseguridad para su organización.

Cuanto antes inicie este proceso, más tiempo tendrá para lograr la aceptación y el apoyo de la dirección.

Posibles beneficios empresariales de un caso de negocio para el cumplimiento de NIS2

Estos son algunos posibles beneficios que puede destacar en su caso de negocio:

Reducir los costes operativos al evitar o minimizar las pérdidas derivadas de ciberataques, como tiempos de inactividad, filtraciones de datos, pagos de rescates, demandas, etc.
Aumentar los ingresos atrayendo o reteniendo a clientes que valoran la seguridad, la privacidad, la calidad, etc.
Mejorar la eficiencia optimizando procesos, mejorando el rendimiento, reduciendo errores, etc.
Innovar adoptando nuevas tecnologías, desarrollando nuevos productos o servicios, creando nuevos mercados y mucho más.
Cumplir otras normativas o estándares de ciberseguridad más allá de NIS2, como RGPD, ISO 27001, PCI DSS y otros, ya que los marcos globales suelen solaparse en gran medida con los requisitos de cumplimiento de NIS2.

Posibles fuentes de información para justificar su caso de negocio de cumplimiento de NIS2

Estas son algunas fuentes que puede utilizar para respaldar su caso de negocio:

Estadísticas o datos que muestren la prevalencia, el impacto o el coste de los ciberataques en su sector o región.
Casos prácticos o ejemplos que ilustren cómo otras organizaciones se han beneficiado de cumplir la Directiva NIS2 o normativas similares. Por ejemplo, el informe Enisa NIS Investments 2022 muestra que, para el 62 % de las organizaciones que implementaron la directiva NIS anterior, dichas implementaciones les ayudaron a detectar incidentes de seguridad; para el 21 %, ayudaron durante la recuperación de incidentes de seguridad.
Testimonios o comentarios de clientes, socios, reguladores o expertos que avalen o recomienden cumplir la Directiva NIS2 o normativas similares.
Referencias o indicadores que revelen el rendimiento o el progreso actual o previsto de su ciberseguridad en relación con la Directiva NIS2 o con sus competidores.
Kit de herramientas de ciberestrategia de Ivanti 2023 para conseguir apoyo interno también es un recurso excelente que explica el tiempo hasta la funcionalidad y el coste, cómo una solución ayuda a defenderse frente a determinados tipos de ciberataques, y cómo reaccionar ante las objeciones habituales y superarlas.

Beneficios empresariales generales del cumplimiento de la Directiva NIS2

Algunos de los beneficios de cumplir la Directiva NIS2 incluyen:

Reducir los costes operativos al evitar o minimizar las pérdidas derivadas de ciberataques, como tiempos de inactividad, filtraciones de datos, pagos de rescates, demandas, etc. Según un informe de IBM, el coste medio de una filtración de datos en 2022 fue de 4,82 millones de dólares estadounidenses para las organizaciones de infraestructuras críticas, y el tiempo medio para identificar y contener una brecha fue de 277 días. Si está tomando medidas para cumplir la Directiva NIS2, el tiempo medio dedicado a identificar y contener una brecha será mucho menor, y los costes del ataque serán inferiores.
Aumentar los ingresos atrayendo o reteniendo a clientes que valoran la seguridad, la privacidad, la calidad y factores similares. Según una encuesta de PwC, el 87 % de los consumidores afirma que llevaría su negocio a otra parte si no confía en las prácticas de datos de una empresa, y el 71 % afirma que dejaría de utilizar los productos o servicios de una empresa si descubriera que comparte sus datos sin su permiso, algo que podría ocurrir con una fuga de datos.
Mejorar la eficiencia optimizando procesos, mejorando el rendimiento, reduciendo errores, etc. Accenture ha constatado que las empresas que adoptan tecnologías de seguridad avanzadas pueden reducir el coste de la ciberdelincuencia hasta en un 48 %.
Cumplir otras normativas o estándares que requieren ciberseguridad, como el RGPD, ISO 27001, PCI DSS u otros. Cisco señala que el 97 % de las organizaciones que cumplen el RGPD perciben beneficios como obtener una ventaja competitiva, lograr eficiencia operativa y reducir los retrasos en las ventas. Es probable que puedan conseguirse resultados similares cumpliendo NIS2.

En cuanto al presupuesto, la propuesta de directiva de la Comisión Europea (Anexo 7 - 1.4.3) menciona que, para las empresas incluidas en el ámbito de aplicación del marco NIS2, se estima que necesitarían un aumento máximo del 22 % de su gasto actual en seguridad TIC durante los primeros años posteriores a la introducción del marco NIS2.

Sin embargo, la propuesta también menciona que este aumento medio del gasto en seguridad TIC generaría un beneficio proporcionado de dichas inversiones, en particular gracias a una reducción considerable del coste de los incidentes de ciberseguridad.

2. Implemente correctamente nuevas medidas de seguridad organizativas y técnicas

Tras investigar las brechas y obtener presupuesto, llega el momento de cerrarlas. La Directiva NIS2 exige a las empresas implementar medidas organizativas y técnicas adecuadas para gestionar sus riesgos de ciberseguridad y garantizar un alto nivel de seguridad en sus redes y sistemas de información.

Estas medidas incluyen:

Adoptar políticas y procedimientos para la gestión de riesgos, la respuesta a incidentes, la continuidad del negocio, la protección de datos, etc.
Establecer funciones y responsabilidades para el gobierno, la supervisión, la coordinación y otras áreas de la ciberseguridad.
Proporcionar programas de formación y concienciación para el personal, la dirección, los clientes, etc.
Implementar una ciberhigiene básica como cifrado, autenticación multifactor (MFA), cortafuegos, software antivirus, aplicación de parches, acceso de confianza cero, etc.
Realizar pruebas, monitorización, auditorías y otras medidas de forma periódica.

Implementar esas medidas organizativas y técnicas no es una tarea puntual ni estática. Requiere establecer un proceso continuo y dinámico que se adapte a la evolución de las amenazas, las tecnologías, las normativas y las necesidades empresariales.

Por tanto, para este proceso se aplica el mismo consejo que para los demás puntos que ya hemos tratado: cuanto antes empiece, más tiempo tendrá para implementar las medidas necesarias y garantizar su eficacia y eficiencia.

Recomendaría empezar la implementación al menos en enero de 2024, para estar preparado antes de las vacaciones de verano.

Próximos pasos para las implementaciones de la Directiva NIS2

Estos son algunos posibles pasos que puede dar para implementar medidas organizativas y técnicas:

Desarrollar e implementar un proceso de gestión basado en riesgos que defina sus objetivos, alcance, funciones, responsabilidades, recursos, plazos y métricas para gestionar sus riesgos de ciberseguridad.
Implementar una política de seguridad que establezca sus principios, directrices, estándares y procedimientos para garantizar la seguridad de su red y sus sistemas de información.
Realizar evaluaciones de riesgos para identificar sus activos, amenazas, vulnerabilidades, impactos y probabilidades de ciberataques; y priorizar sus acciones en función de su apetito y tolerancia al riesgo.
Implementar controles de seguridad que protejan su red y sus sistemas de información frente al acceso, uso, divulgación, modificación o destrucción no autorizados. Estos controles pueden clasificarse en tres categorías: preventivos (por ejemplo, cifrado); de detección (por ejemplo, monitorización) y correctivos (por ejemplo, copias de seguridad).
Implementar un plan de respuesta a incidentes que defina sus procesos, funciones, responsabilidades, recursos, herramientas y canales de comunicación para responder a los ciberincidentes de forma eficaz y eficiente.
Implementar un plan de continuidad del negocio que defina sus procesos, funciones, responsabilidades, recursos, herramientas y canales de comunicación para mantener o restaurar sus procesos de negocio críticos durante una interrupción o desastre relacionado con la ciberseguridad.
Implementar un plan de revisión y mejora que defina sus procesos, funciones, responsabilidades, recursos, herramientas y canales de comunicación para evaluar, informar y mejorar periódicamente sus medidas de ciberseguridad.
Implementar los controles técnicos para la gestión de activos y la ciberhigiene básica.

La referencia de la Directiva a la «ciberhigiene básica» es algo imprecisa en el artículo 21, por lo que profundizaremos en ello en otra entrada de blog. Por ahora, piense en medidas de seguridad básicas como:

MFA.
Aplicar parches a su sistema operativo y sus aplicaciones lo antes posible.
Proteger las conexiones de red en redes públicas.
Cifrar todas las unidades (especialmente las extraíbles).
Gestionar privilegios y formar a todos los empleados.
Suscribirse a canales que le proporcionen información sobre los últimos parches y prioridades, como los webinars de Patch Tuesday de Ivanti.

3. Corrija el eslabón más débil: encuentre tiempo para formar a todos los empleados

La Directiva NIS2 reconoce que los factores humanos son cruciales para la ciberseguridad y que los empleados suelen ser el eslabón más débil, además de la primera línea de defensa, a la hora de prevenir o detectar ciberataques.

La Directiva exige a las organizaciones proporcionar programas adecuados de formación y concienciación a sus empleados, usuarios de servicios digitales y otras partes interesadas sobre cuestiones de ciberseguridad.

Formar a todos sus empleados no es una tarea esporádica ni opcional. Requiere un programa periódico y completo que cubra temas como:

Conceptos y terminología básicos de ciberseguridad.
Ciberamenazas y vectores de ataque habituales.
Buenas prácticas y consejos de ciberhigiene.
Políticas y procedimientos de ciberseguridad, relevantes y simplificados para los usuarios finales.
La función y las responsabilidades de cada usuario en la ciberseguridad de la organización.
Cómo notificar incidentes y responder ante ellos.

Es importante señalar que esta formación debe recibirla todo el mundo dentro de la empresa, no solo los empleados de TI. Incluso la dirección debería realizar esta formación.

Una encuesta realizada para Ivanti muestra que muchos empleados ni siquiera conocen la formación obligatoria en ciberseguridad. Solo el 27 % se siente «muy preparado» para reconocer y notificar amenazas como malware y phishing en el trabajo. El 6 % se siente «muy preparado» para reconocer y notificar amenazas como malware y phishing en el trabajo.

En el informe Enisa NIS Investments 2022, Enisa menciona que el 40 % de los OES (operadores de servicios esenciales) encuestados no cuenta con ningún programa de concienciación en seguridad para el personal ajeno a TI.

Es importante supervisar quién no ha recibido aún la formación y actuar al respecto. Formar a todos sus empleados no solo es beneficioso para el cumplimiento, sino también para la productividad, la calidad, la innovación y la satisfacción del cliente.

El mejor consejo sobre NIS2 que podemos ofrecerle

La Directiva NIS2 es una legislación histórica cuyo objetivo es reforzar la ciberseguridad de sectores críticos en la UE. Impone obligaciones importantes a las organizaciones incluidas en su ámbito de aplicación, junto con multas y sanciones elevadas por incumplimiento.

Cumplir la Directiva NIS2 es una tarea compleja. Exige un enfoque proactivo e integral que implique múltiples pasos, partes interesadas y recursos.

Cuanto antes empiece a prepararse, mejor preparado estará cuando entre en vigor en octubre de 2024.

¿El mejor consejo que podemos ofrecerle? No espere hasta entonces: empiece a prepararse para la Directiva NIS2 ahora.

5 razones por las que debe empezar ya a prepararse para la Directiva NIS2, primera parte: las auditorías llevan tiempo

Mon, 28 Aug 2023 17:14:55 Z

Probablemente haya oído hablar de la Directiva de Seguridad de las Redes y de la Información actualizada de la Unión Europea (NIS2). Esta directiva se transpondrá al ordenamiento jurídico en octubre de 2024. Conviene estar preparado, ya que el incumplimiento puede acarrear multas y sanciones elevadas.

Pero quizá piense que octubre de 2024 queda lejos, ¿verdad? Piénselo dos veces.

Al fin y al cabo, ¿cómo puede saber si dispone de tiempo suficiente para prepararse si no sabe en qué medida cumple actualmente la normativa prevista?

Por tanto, de aquí a octubre de 2024 debe auditar su estado actual de ciberseguridad. En concreto:

Identificar las brechas en el cumplimiento de los requisitos de la Directiva NIS2, empezando ya
Revisar las deficiencias actuales de seguridad de su cadena de suministro

En la segunda parte de esta serie, analizaré las tres áreas que deberá abordar para subsanar las brechas que revelen sus auditorías , incluyendo cómo:

Informar a la dirección sobre sus brechas de ciberseguridad.
Implementar correctamente nuevas medidas de seguridad organizativas y técnicas.
Encontrar tiempo para formar a todos sus empleados.

1. Identificar las brechas en el cumplimiento de los requisitos de la Directiva NIS2, empezando ya

La Directiva NIS2 es la legislación sobre ciberseguridad de ámbito europeo que proporciona medidas legales para elevar el nivel general de ciberseguridad en la UE. Moderniza el marco jurídico existente para adaptarse al aumento de la digitalización y a un panorama de amenazas de ciberseguridad en constante evolución.

La directiva amplía el alcance de las normas de ciberseguridad a nuevos sectores y entidades, mejorando las capacidades de resiliencia y respuesta ante incidentes de entidades públicas y privadas, autoridades competentes y de toda la UE.

La Directiva NIS2 establece medidas reforzadas de resiliencia frente a ciberataques para minimizar vulnerabilidades y mejorar la ciberdefensa.

Para cumplir la Directiva NIS2, debe:

Evaluar su postura de ciberseguridad e identificar cualquier brecha o debilidad que pueda exponerle a riesgos cibernéticos.
Mapear sus políticas, procedimientos y controles existentes con los requisitos de la directiva y determinar dónde mejorarlos o actualizarlos.
Evaluar sus capacidades de respuesta ante incidentes y mecanismos de notificación, y asegurarse de que se ajustan a los estándares de la directiva.

Uno de los principales problemas de NIS2 es que indica qué se debe hacer, pero no cómo hacerlo. Afortunadamente, hay varios marcos que pueden ayudarle con el cómo, entre ellos:

En Bélgica, el CCB ha creado un marco Cyberfundamentals basado en varios marcos, con referencias a cómo se relacionan las distintas partes de los marcos con el RGPD y NIS2.

Una vez seleccionado el marco, debe identificar las brechas en relación con el marco elegido y los requisitos de la directiva. Identificar brechas no es una tarea sencilla ni rápida; requiere un análisis exhaustivo y sistemático de la madurez y preparación en ciberseguridad de su organización.

No solo debe revisar su estrategia y sus políticas de ciberseguridad, sino también realizar un análisis de riesgos para identificar los activos más críticos y los riesgos de ciberseguridad que presentan; después, considerar controles de seguridad para reducir la puntuación de riesgo de esos activos esenciales.

Cuanto antes inicie este proceso, más tiempo tendrá para obtener el presupuesto necesario para abordar cualquier problema e implementar los cambios que sean necesarios.

Posibles brechas del entorno NIS2

Algunas de las posibles brechas que puede encontrar en su entorno son:

Falta de una estrategia o política integral de ciberseguridad que cubra todos los aspectos de la gestión de riesgos, la respuesta ante incidentes, la continuidad del negocio, la protección de datos, etc.
Falta de un equipo o función de ciberseguridad dedicado que supervise, coordine y monitorice todas las actividades e iniciativas de ciberseguridad en toda la organización.
Falta de controles o medidas de seguridad adecuados para proteger sus sistemas de red e información frente al acceso, uso, divulgación, modificación o destrucción no autorizados.
Falta de pruebas o auditorías periódicas de sus controles o medidas de seguridad para garantizar su eficacia y el cumplimiento de los requisitos de la directiva.
Falta de programas adecuados de formación o concienciación para su personal, la dirección, otros empleados u otras partes interesadas sobre cuestiones y buenas prácticas de ciberseguridad.
Falta de canales claros de comunicación o notificación para informar a las autoridades o partes pertinentes de cualquier incidente o brecha que afecte a sus servicios.

Posibles soluciones de seguridad para que su entorno cumpla NIS2

Para identificar y corregir estas brechas de seguridad, puede:

Utilizar marcos o modelos de análisis de brechas que le ayuden a comparar su estado actual con el estado deseado e identificar áreas de mejora.
Implementar modelos o estándares de madurez en ciberseguridad que le ayuden a medir su nivel de rendimiento y progreso en ciberseguridad.
Realizar una evaluación de riesgos para identificar sus activos, amenazas, vulnerabilidades, impactos y probabilidades de ciberataques.
Solicitar auditorías o evaluaciones externas que le ayuden a validar su estado de cumplimiento e identificar cualquier debilidad o deficiencia.

2. Revisar las deficiencias actuales de seguridad de la cadena de suministro con tiempo suficiente para coordinar acciones con los proveedores

La Directiva NIS2 también introduce nuevas disposiciones sobre la seguridad de la cadena de suministro (capítulo 0, puntos 54 y 56), reconociendo que las ciberamenazas pueden proceder de proveedores externos o subcontratistas.

La directiva exige a las organizaciones que garanticen que sus proveedores sigan estándares y prácticas de seguridad adecuados (artículo 21-2d) y que monitoricen periódicamente su rendimiento y cumplimiento (artículo 21–3).

No es casualidad. Los ataques a la cadena de suministro van en aumento:

En una investigación de BlackBerry realizada en 2022 con más de 1500 responsables de TI, cuatro de cada cinco encuestados afirmaron haber recibido notificación de un ataque o una vulnerabilidad en su cadena de suministro durante el año. El 77 % afirmó haber descubierto participantes ocultos en su cadena de suministro de software de los que no tenía conocimiento previamente.

Una investigación de Accenture también revela que el 40 % de las brechas de seguridad son indirectas y se producen a través de la cadena de suministro.

Por tanto, proteger su cadena de suministro es esencial para garantizar la continuidad del negocio, la resiliencia, la reputación y la confianza.

Pero en Press Reset: informe sobre el estado de la ciberseguridad en 2023 de Ivanti, constatamos que solo el 42 % de los más de 1300 directivos y profesionales de seguridad encuestados afirmaron estar preparados para protegerse frente a las amenazas de la cadena de suministro, aunque el 46 % las considera una amenaza de alto nivel.

Las amenazas de la cadena de suministro no solo proceden de ataques a proveedores de soluciones como Okta, Kaseya o SolarWinds, sino también de socios conectados directamente a su infraestructura de TI o que pueden iniciar sesión en ella.

Y no olvide los ataques a sus proveedores de recursos, que pueden paralizarlos e impedirles entregar determinados recursos que necesita para sus propias operaciones. Debe estar preparado y contar con proveedores de respaldo disponibles que puedan suministrar esos recursos si su proveedor principal queda fuera de servicio por un ciberataque u otra causa.

La seguridad de la cadena de suministro es una cuestión compleja y exigente que implica múltiples actores, dependencias e interconexiones, y no puede lograrse de la noche a la mañana.

Debe:

Establecer canales de comunicación claros y transparentes con sus proveedores y definir sus expectativas y obligaciones en materia de ciberseguridad.
Realizar auditorías y evaluaciones periódicas de las prácticas de seguridad de sus proveedores y verificar que cumplen los requisitos de la directiva.
Establecer planes de contingencia y soluciones de respaldo en caso de interrupción o compromiso de su cadena de suministro.

Además, debe empezar a interactuar con sus proveedores lo antes posible y trabajar conjuntamente con ellos para garantizar que su cadena de suministro sea segura y resiliente.

Retos de seguridad de la cadena de suministro para NIS2

Estos son algunos de los posibles retos a los que puede enfrentarse al proteger su cadena de suministro:

Falta de visibilidad o transparencia sobre las prácticas, políticas o incidentes de seguridad de sus proveedores.
Falta de confianza o cooperación entre sus proveedores o entre usted y sus proveedores.
Falta de coherencia o alineación en los estándares, requisitos o expectativas de seguridad en toda su cadena de suministro.
Falta de recursos o capacidades para monitorizar, auditar o verificar el rendimiento o el cumplimiento en materia de seguridad de sus proveedores.
Falta de planes de contingencia o soluciones de respaldo para mitigar cualquier interrupción o compromiso de su cadena de suministro, o recuperarse de ellos.
Falta de información sobre lo que espera de las prácticas de seguridad de sus proveedores.

Soluciones de seguridad de la cadena de suministro para NIS2

Para superar estos retos de seguridad de la cadena de suministro, puede:

Establecer contratos o acuerdos claros con sus proveedores que especifiquen sus obligaciones, responsabilidades y responsabilidades legales en materia de seguridad.
Desarrollar criterios, directrices o marcos de seguridad comunes que se apliquen a todos los proveedores de su cadena de suministro y se ajusten a los requisitos de la directiva.
Implementar controles, medidas o herramientas de seguridad que le permitan realizar el seguimiento, monitorizar o verificar las actividades, incidentes o estado de cumplimiento de seguridad de sus proveedores.
Crear equipos, comités o foros conjuntos de seguridad que faciliten el intercambio de información, la colaboración y la coordinación entre sus proveedores o entre usted y sus proveedores.
Generar confianza y entendimiento mutuo con sus proveedores mediante comunicación periódica, comentarios y reconocimiento.

Cuando haya completado sus auditorías de la Directiva NIS2, ¿qué viene ahora?

Ahora que ha determinado cuál es su situación actual con respecto a la Directiva NIS2, es el momento de implementar cambios críticos para garantizar el cumplimiento antes de octubre de 2024. Estoy seguro de que abordar las brechas identificadas por sus auditorías requerirá todo el tiempo del que dispone —¡e incluso algo más!— antes de que la normativa se implemente oficialmente en su país.

Pero ¿cómo puede abordar estas brechas de forma sistemática y oportuna? Analizamos las tres áreas de cambios de seguridad que necesitará para NIS2 en nuestra próxima entrada del blog, donde examinaremos cómo:

Informar a la dirección sobre sus brechas de ciberseguridad.
Implementar correctamente nuevas medidas de seguridad organizativas y técnicas.
Encontrar tiempo para formar a todos sus empleados.