Tema 5. Detección y Documentación de Incidentes de Ciberseguridad PDF

# Tema 5. Detección y documentación de incidentes de ciberseguridad ## 5.1. Introducción a la unidad formativa La unidad formativa 5 “Vuelta a la normalidad" muestra las principales actividades post-incidente relacionadas con el post-análisis del incidente y las lecciones aprendidas que derivan, e...

# Tema 5. Detección y documentación de incidentes de ciberseguridad ## 5.1. Introducción a la unidad formativa La unidad formativa 5 “Vuelta a la normalidad" muestra las principales actividades post-incidente relacionadas con el post-análisis del incidente y las lecciones aprendidas que derivan, el informe final y la comunicación del incidente y la implantación de capacidades de ciberresiliencia en la organización. A continuación, se describen los bloques en que se ha dividido. * **Análisis del incidente y lecciones aprendidas:** muestra la investigación post-incidente, el proceso de lecciones aprendidas y las acciones de mejora y la recopilación y retención de evidencias. * **Informe final y comunicación de ciberincidentes:** explica el seguimiento y la realización del informe final del incidente, plantillas a implantar en la organización para este propósito. Además, muestra el plan de comunicación para un ciberincidente. * **Implantación de capacidades de ciberresiliencia:** desarrollo cómo a partir de las lecciones aprendidas se pueden implantar medidas proactivas y preventivas para dotar de ciberresiliencia a la organización, de tal forma que se enfrente de manera adecuada a futuros y desconocidos incidentes de seguridad. Esta unidad formativa se complementa con una actividad relacionada con la adopción de medidas de ciberresiliencia enfocadas al engaño mediante la utilización de una honeynet. ## 5.2. Análisis del incidente y lecciones aprendidas ### Investigación posincidente Una vez finalizada la fase de recuperación, es necesario investigar el incidente de ciberseguridad** más a fondo con objeto de averiguar lo que realmente ocurrió, sacar lecciones aprendidas, mejorar los controles, procesos y procedimientos y compartir datos con las diferentes partes interesadas.** Los aspectos claves que deben cubrir esta investigación son: * Realizar un análisis de la causa del problema. * Llevar a cabo la identificación de la causa raíz. * Cuantificar el impacto empresarial del incidente (por ejemplo, en términos de impacto financiero, de reputación, de gestión o de impacto en el cumplimiento regulatorio). * Identificar a los autores del incidente de ciberseguridad, sin bien es cierto que resulta cada vez más complicado y costoso determinar la autoría. ### Lecciones aprendidas Todos los incidentes de ciberseguridad, como cualquier otro incidente, deben cerrarse adecuadamente. Además, **es muy importante que se aprendan las lecciones de cada incidente para evaluar futuras mejoras.** Los incidentes de ciberseguridad pueden poner de manifiesto graves deficiencias en la estrategia o práctica de seguridad. **Una revisión posterior al incidente es una actividad muy útil porque muestra datos reales e impactos reales, ayudando a la organización a evaluar su plan de respuesta a los ciberincidentes y su presupuesto.** Todos los incidentes de ciberseguridad deben ser revisados formalmente tras la resolución del incidente para verificar si los mecanismos de seguridad o controles de mitigación necesitan ser puestos en marcha o adaptados para prevenir incidentes similares en el futuro. Algunas de las cuestiones que caben preguntarse y obtener respuesta son: * ¿Cómo actuaron el personal y la dirección en la gestión del incidente? * ¿Qué harían el personal y la dirección de forma diferente la próxima vez que se produzca un incidente de ciberseguridad similar? * ¿Se siguieron el plan y los procedimientos de gestión de incidentes de ciberseguridad? ¿Fueron adecuados? * ¿Qué información se necesitaba antes? * ¿Se dispuso de la información a tiempo? Si no, ¿habría sido posible tenerla antes y cómo? * ¿Hubo alguna medida o acción que pudiera haber impedido la recuperación? * ¿Podría mejorarse el intercambio de información con otras organizaciones? * ¿Qué medidas correctoras podrían evitar incidentes similares en el futuro? * ¿Existen precursores o indicadores que deban controlarse para detectar más fácilmente incidentes similares en el futuro? * ¿Qué herramientas o recursos adicionales se necesitan para detectar, analizar y mitigar futuros incidentes de ciberseguridad? * ¿Tiene el equipo de respuesta de ciberseguridad la autoridad organizativa adecuada para responder al incidente? * ¿Debería contratar a más personas o contratar a una empresa de consultoría, un abogado, etc, en caso de un futuro incidente de ciberseguridad? * ¿Cómo se pueden incorporar los resultados a nuestra metodología de evaluación de riesgos? * ¿Qué lecciones hemos aprendido? * ¿Qué indicadores deberían vigilarse en el futuro para detectar incidentes similares? Una parte esencial del seguimiento de un incidente de ciberseguridad es documentar, comunicar y aprovechar las lecciones aprendidas. Este debe verse como un proceso continuo a través del cual se puede colaborar y aprender de los errores, incidentes y experiencias anteriores. La comunicación a todas las partes interesadas debe ser clara, concisa y centrada en la resolución del problema y la mejora del control. Debe identificar claramente las lagunas de seguridad existentes y proponer medidas para mitigarlas. Debe crearse un plan de acción que explique cómo la organización aprovechará las lecciones aprendidas del incidente para ser más resistente frente a futuros ataques de ciberseguridad. El plan de acción debe incluir proyectos o iniciativas técnicas y no técnicas, que ayuden a reducir las posibilidades de éxito de un atacante y a responder de una forma más rápida y eficaz. El análisis del incidente de ciberseguridad debe tener en cuenta si fueron carencias técnicas las que contribuyeron al éxito del atacante o si las deficiencias de las personas o de los procesos fueron las principales responsables. Cada acción debe asignarse a una persona determinada y se le debe asignar una prioridad y una fecha de finalización adecuadas. El estado de todas las acciones debe ser supervisado para garantizar que se completan de manera oportuna y eficaz. ## 5.3. Informe final y comunicación de ciberincidentes ### Seguimiento e Informe final del incidente Es importante documentar todos los incidentes y las medidas que se han tomado, y mantener toda esta documentación. Incidentes similares pueden volver a ocurrir y pueden que requieran los mismos procedimientos de gestión, o que un pequeño incidente resulte ser parte de un incidente mayor que se descubre más tarde. Además, también es necesario informar del incidente a las partes interesadas, tanto internas como externas. Utilizar los resultados de la revisión posterior al incidente para determinar con qué partes interesadas hay que ponerse en contacto. A nivel interno, la alta dirección de la organización debe considerarse siempre una parte interesada relevante y, por tanto, recibir un informe documentado sobre lo ocurrido y las medidas adoptadas. La alta dirección y/o las personas de la organización encargadas de analizar los riesgos en la organización (por ejemplo, un comité de riesgo operativo o equivalente) deben ser informados de cualquier incidente de ciberseguridad. Debe redactarse un informe documentado para todos los incidentes de ciberseguridad y conservarse junto con otros informes de incidentes de ciberseguridad. Puede basar este informe en las conclusiones de la revisión posterior al incidente de los incidentes. Una vez que se ha gestionado con éxito un incidente de ciberseguridad, a menudo será necesario informar formalmente tanto a las partes interesadas. Las preguntas clave que hay que tener en cuenta son las siguientes: * ¿Cuáles son nuestros requisitos de información? * ¿A quién debo informar? * ¿De qué debo informar? * ¿En qué formato informo? * ¿Cuál es el objetivo de los informes? Una vez que se haya respondido a estas preguntas, el informe en si debería incluir: * Una descripción completa de la naturaleza del incidente, su historia y las medidas adoptadas para recuperarlo. * Una estimación realista del coste financiero del incidente, así como otras repercusiones en la empresa, como en términos de daños a la reputación, pérdida de control de la gestión o deterioro del crecimiento * Recomendaciones sobre los controles mejorados o adicionales necesarios para prevenir, detectar, remediar o recuperarse de los incidentes de ciberseguridad de forma más eficaz. ### Plantilla informe posincidente El informe de análisis posterior al incidente proporciona información muy valiosa a las partes interesadas con un resumen del incidente, el impacto en la organización, así como las lecciones aprendidas y las áreas de mejora. En todos los incidentes graves es más que recomendable la elaboración de un informe de análisis posterior al incidente. En aquellos que se consideren leves dependerá de la organización y sus procesos de mejora continua. La siguiente tabla muestra un ejemplo de este tipo de informes. | **Información del incidente** | **Descripción** | **Fecha/Tiempo** | | :--------------------------------------- | :--------------------------------------------------------------------------------------------- | :------------------------------------ | | Número de ticket | | | | Identificador | | | | Evento detectado | Ocurrido / Detectado | | | Regla activada o evento del SIEM | | | | Unidad de negocio afectada | | | | Sistema TI afectado | | Ticket creado / Ticket cerrado | | Comentarios | "Comentarios sobre el calendario de eventos para incluir la notificación a las partes interesadas internas y a las externas" | | | **Evaluación de la severidad e impacto** | **Descripción** | | :--------------------------------------- | :------------------------------------ | | Nivel de severidad funcional | Valor de la severidad | | Nivel de severidad en la información | Valor de la severidad | | Nivel de severidad en la recuperación | Valor de la severidad | | Nivel global de severidad | Valor de la severidad | | ¿Incidente mayor? | | | Vector de ataque | | | **Información de la amenaza y análisis de las causas** | **Descripción** | | :--------------------------------------- | :---------------------------------------------------------------------------------------------------------- | | Causa raíz | "Causa o causas subyacentes a un incidente, como una vulnerabilidad no parcheada, falta de controles del sistema o de acceso" | | caracterización de la amenaza | "Interna/externa, directa/indirecta" | | Otros ticket o eventos relacionados | "Lista de tickets relacionados" | | Reincidencia | | | Comentarios | "¿Había ocurrido antes el incident?" <br/> "Comentarios sobre el origen y el destino del incidente o la amenaza, así como la forma en que se aprovecharon las vulnerabilidades o la falta de controles de seguridad. Incluir también si el incidente o la amenaza se propagó a otras áreas de la red y cómo". | | **Fuentes de ataque** | **Sistemas afectados por el incidente** | | :---------------------------------- | :----------------------------------------------------------------------------------------------------------------- | | Funciones principales de los sistemas afectados | "Servidor web, controlador de dominio, servidor de aplicaciones, servidor de base de datos, etc" | | Sistemas operativos de los sistemas afectados | "Versión, pack service, parches, configuración, etc" | | Software de seguridad en los sistemas afectados | "Antivirus, firewall, EDR, etc" | | Localización física | “Ciudad, sede, edificio, sala, puesto de trabajo, etc” | | **Destinos del ataque** | **Usuarios afectados por el incidente** | | :---------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | | Posición y nombre de los usuarios | | | Permisos y niveles de acceso | "Usuario, dirección, administrador de dominio, administrador de sistemas, super administrador, etc" | | **Recuperación y remediación** | **Descripción** | | :------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ¿Cómo ha sido el contenido el incidente? | "Enumerar las actividades y relaciones con otras partes utilizadas para contener el incidente". | | ¿Cómo ha sido el incidente erradicado? | "Enumerar las actividades, relaciones con otras partes y tecnologías utilizadas para remediar el incidente y garantizar que ningún otro activo de los sistemas de la organización pueda verse afectado". | | ¿Cómo se ha recuperado? | "¿Se ha recuperado del incidente o está en curso la recuperación? ¿Cuánto tiempo duró la recuperación? ¿Qué recursos se utilizaron para la recuperación? ¿Ha requerido la recuperación ayuda adicional (por ejemplo, reutilización de otro personal, apoyo de terceras partes)?" | | **Comentarios generales** | **Descripción** | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | | | "Enumerar cualquier nota adicional, como las áreas de mejora y las prácticas que deben mantenerse para responder y recuperarse adecuadamente de futuros incidentes". | ### Métricas A modo de ejemplo, se presentan métricas susceptibles de ser recogidas en cada fase del marco de la respuesta a incidentes: * Tiempo de detección * Tiempo para informar * Tiempo de creación * Tiempo de acuse de recibo * Tiempo de notificación * Tiempo de validación * Tiempo de respuesta * Tiempo de contención * Tiempo para remediar * Tiempo de verificación * Tiempo de resolución * Información sobre el incidente ### Comunicación Algunas organizaciones están obligadas a informar a determinadas autoridades. Los departamentos gubernamentales tienen la responsabilidad de notificar los incidentes informáticos (incluidos los incidentes de ciberseguridad). En muchos casos también puede ser beneficioso informar voluntariamente a otras partes interesadas importantes, como: * Organismos encargados de hacer cumplir la ley * Equipos de respuesta a emergencias informáticas (CSIRT) * Organismos reguladores con sectores de mercado particulares * Organismos internacionales especializados, como el NIST 0 ENISA * Socios colaboradores * Organizaciones especializadas. Cuando se produce un incidente de ciberseguridad real, el equipo de respuesta a incidentes de ciberseguridad debe elaborar inmediatamente un plan de comunicación concreto para el incidente específico. Haga este plan de comunicación basado en los preparativos generales que ya realizó durante la fase de preparación. Básicamente se deberá responder a las preguntas que figuran a continuación, así como coordinar todas las comunicaciones externas. ¡Piensa antes de comunicar! **WHOM** With whom will your organisation communicate? **WHAT** What info will your organisation communicate? **WHEN** When will your organisation communicate? **WHO** Who will communicate? ## 5.4. Implantación de capacidades de ciberresiliencia ### Principios básicos Los métodos de acceso a la infraestructura tecnológica de cualquier organización se han ampliado drásticamente. Los servicios en la nube, las redes sociales, los dispositivos móviles y las políticas de dispositivos móviles y las políticas de "traiga su propio dispositivo" (BYOD) han desplazado el perímetro corporativo clásico basado en cortafuegos, dispositivos y aplicaciones hasta los datos más sensibles que deben ser protegidos. Los atacantes, cada vez más creativos, expertos y agresivos siguen llevando el mundo de las amenazas a nuevas áreas. Así, el panorama de las amenazas seguirá evolucionando, con nuevos e innovadores métodos de ataque capaces de adaptarse a los entornos objetivo elegidos. Además, los futuros ataques utilizarán cada vez más herramientas automatizadas para comprometer cientos de miles de ordenadores en todo el mundo. Incluso en el mundo actual no será posible prevenir todos los incidentes de ciberseguridad. A medida que los atacantes se adaptan y cambian, las organizaciones tendrán que adaptarse y cambiar también. Por lo tanto, hay que prepararse para un ataque ejecutado por un grupo avanzado, sofisticado, organizado, bien financiado y persistente. La forma de estar preparado es implementar capacidades de ciberresiliencia. Entendemos ciberresiliencia, como la capacidad de anticipar, resistir, recuperarse y adaptarse a condiciones adversas, ataques o compromisos en sistemas que incluyen recursos cibernéticos. Esta definición puede aplicarse a una variedad de entidades, incluyendo: * Un sistema * Un mecanismo, componente o elemento del sistema * Un servicio compartido, una infraestructura común o un sistema de sistemas identificado con una misión o función empresarial * Una organización completa * Un sector de infraestructuras críticas * Una nación La resistencia cibernética está surgiendo como un elemento clave en cualquier estrategia eficaz para la garantía la misión, la garantía de negocio o la resistencia operativa. Para estar mejor preparado, se debe considerar cómo: * Proteger sus datos más importantes en un entorno comprometido * Dificultar el éxito de los atacantes * Detectar que se está planeando un ataque, o que ya está en marcha * Responder a los sofisticados ataques actuales. ### Características Los aspectos claves que debe tener una estrategia de ciberresiliencia en cualquier organización son: * Centrarse en la misión o las funciones empresariales * Apoyar las misiones de la organización o las funciones de negocio con el fin de maximizar la capacidad de las organizaciones para completar las misiones críticas o esenciales o las funciones de negocio a pesar de la presencia de un adversario en sus sistemas e infraestructuras que amenazan los sistemas de misión crítica y los componentes del sistema. Desde la perspectiva de la ciberresiliencia, los elementos del sistema o los sistemas constituyentes que son menos críticos para la eficacia de la misión o del negocio pueden ser sacrificados para contener un ciberataque y maximizar la seguridad de la misión. * Asumir un entorno cambiante. Se producen cambios continuos en el entorno de las amenazas, el entorno operativo y el entorno técnico. Los actores de las APT aprenden de la experiencia. Sus motivos pueden cambiar en respuesta a factores económicos y políticos, y sus TTPs pueden convertirse en herramientas básicas para los actores de nivel inferior. Las formas de utilizar la tecnología por parte de los individuos y las organizaciones cambian debido a acontecimientos como la pandemia de COVID-19, la disponibilidad más amplia o más rentable de servicios como la computación en la nube, y la creciente familiaridad con las nuevas tecnologías y su aceptación. El entorno técnico sigue evolucionando, por ejemplo, con la rápida convergencia de la tecnología de la información y la tecnología operativa, la creciente madurez de la inteligencia artificial y el aprendizaje automático, y la transición a las arquitecturas de confianza cero. Estos cambios pueden interactuar de muchas maneras, aumentando la complejidad y reduciendo la transparencia de los sistemas, servicios, infraestructuras y ecosistemas. Desde la perspectiva de la ciberresiliencia, los cambios pueden presentar simultáneamente riesgos y oportunidades. La gestión de los riesgos debe tener en cuenta este entorno cambiante. * Centrarse en los efectos de la amenaza persistente avanzada. La definición de ciberresiliencia abarca todas las amenazas a los sistemas que contienen recursos cibernéticos. Sin embargo, el análisis de la ciberresiliencia centra grandes esfuerzos en los efectos que la APT puede tener en el sistema de interés y, por tanto, en las misiones o funciones empresariales, la organización o las partes interesadas externas. Además de los efectos inmediatamente detectables (por ejemplo, la destrucción de datos, el mal funcionamiento de un CPD, la denegación de servicio), la APT puede producir efectos que son detectables sólo después de la observación prolongada o el análisis forense del sistema de interés (por ejemplo, la escalada de privilegios, la modificación o fabricación de datos o servicios, la exfiltración de datos). La inclusión de la ciberresiliencia en la ingeniería de seguridad de sistemas busca mitigar tales efectos, independientemente de cuándo o si pueden ser detectados. Los recursos asociados a la APT, su naturaleza sigilosa, su enfoque persistente en el objetivo de interés y su capacidad de adaptación frente a las acciones de los defensores la convierten en una amenaza altamente peligrosa. Además, la APT puede aprovechar o hacer que su comportamiento parezca resultado de otras anomalías, como un error humano, un fallo de infraestructura o un desastre natural. Al centrarse en las actividades de las APT y sus efectos potenciales, los ingenieros de sistemas producen sistemas que pueden anticipar, soportar, recuperarse y adaptarse a una amplia y diversa serie de condiciones adversas y tensiones. * Asumir que el adversario comprometerá o vulnerará el sistema o la organización. Una suposición fundamental es que no siempre se pueden mantener a los atacantes fuera de un sistema o detectarlo y eliminarlo rápidamente de ese sistema, a pesar de la calidad del diseño del sistema, la eficacia funcional de los componentes de seguridad y la fiabilidad de los componentes objetos del ataque. Este supuesto reconoce que los sistemas modernos son entidades grandes y complejas, y que los atacantes siempre podrán encontrar y explotar debilidades y defectos en los sistemas (por ejemplo, vulnerabilidades sin parches, configuraciones erróneas), entornos de operación (por ejemplo, ingeniería social, vulnerabilidad de los usuarios) y cadenas de suministro. Como resultado, un atacante puede penetrar en el sistema de una organización y lograr una presencia dentro de la infraestructura de esta. * Asumir que el atacante mantendrá su presencia en el sistema u organización. Se asume que la presencia del adversario puede ser un problema persistente y a largo plazo y reconoce que la naturaleza sigilosa de la APT hace que sea difícil para una organización estar segura de que la amenaza ha sido erradicada. También reconoce que la capacidad de adaptación de la APT implica que las mitigaciones que antes tenían éxito pueden dejar de ser efectivas. Por último, reconoce que la naturaleza persistente de la APT significa que incluso si una organización ha logrado erradicar su presencia, puede volver. En algunas situaciones, el mejor resultado que una organización puede lograr es contener el código malicioso del ataque o frenar su movimiento lateral para que la organización sea capaz de lograr su misión principal antes de perder su capacidad de misión crítica o esencial. En cualquier organización, su capacidad de respuesta a incidentes de ciberseguridad formaría parte de una estrategia de ciberresiliencia más amplia, que podría incluir: * Identificar métodos para evitar que el incidente de ciberseguridad se produzca, por ejemplo, mediante la conciencia situacional de la ciberseguridad, conocimiento de la situación (por ejemplo, utilizando inteligencia de ciberseguridad), análisis de datos y realización de test adecuados en escenarios realistas. * Realizar la identificación de amenazas de ciberseguridad y el seguimiento y evolución. * Integrar las actividades de respuesta a incidentes de ciberseguridad en las iniciativas corporativas, de los sectores de mercado relacionados y del gobierno, incluyendo la colaboración con una amplia gama de otras organizaciones. * Realizar test periódicos del proceso de respuesta de gestión de incidentes de ciberseguridad, utilizando escenarios realistas * Desplegar controles técnicos mejorados para detectar y permitir respuestas efectivas a las amenazas y ataques cibernéticos. * Evaluar continuamente cómo se puede responder a los incidentes de ciberseguridad de forma más rápida, ágil y eficaz. ### Técnicas Las técnicas, en este contexto, son un conjunto de prácticas y tecnologías que pretender conseguir los objetivos de ciberresiliencia que se persiguen. La siguiente tabla muestra las principales técnicas que pueden ser utilizadas. | **TÉCNICA** | **PROPÓSITO** | | :---------------------- | :----------------------------------------------------------------------------------------------------------------------- | | Conciencia situacional | Mejorar la comprensión de las dependencias entre los recursos CIS y el resto. Revela patrones o tendencias en el comportamiento del atacante | | Protección coordinada | Conseguir que las salvaguardas sean un obstáculo de creciente dificultad a medida que el ataque progresa | | Engaño | Engañar u ocultar activos críticos al atacante haciendo que éste no esté seguro de cómo proceder, retrasando el efecto del ataque, aumentando el riesgo de ser descubierto, haciendo se desvíe o desperdicie sus recursos | | Diversidad de medidas | Limitar la posibilidad de la pérdida de funciones críticas debido al fallo de componentes críticos comunes | | Posiciona- | Dificultar la capacidad de un adversario para localizar, eliminar o corromper los activos de la misión o de la empresa, y hacer que el adversario dedique más tiempo y esfuerzo a encontrar los activos críticos de la organización, aumentando así la probabilidad de que el adversario revele su presencia, sus acciones y su artefacto antes de tiempo | | miento dinámico de activos críticos | | | No persistencia | Reducir la exposición a la corrupción de la información, la modificación o el compromiso. Restringir la intrusión y el avance del adversario y eliminar potencialmente el malware o los recursos dañados del sistema | | Restricción de | Limitar el impacto y la probabilidad de que las acciones no intencionadas de las personas autorizadas comprometan la información o los servicios | | privilegios | | | Segmentación | Limitar la capacidad del adversario para obtener credenciales | | Redundancia | Minimizar las conexiones entre los servicios de misión crítica y los no críticos | | Impredecibili- | Reducir las consecuencias de la pérdida de información o servicios. Facilitar la recuperación de los efectos de un evento cibernético adverso. Limitar el tiempo durante el cual los servicios críticos son negados o limitados | | dad | | ### Implementación de capacidades Este apartado muestra algunos enfoques a la hora de implementar las técnicas vista en el apartado anterior. Entendamos por enfoque de ciberresiliencia el conjunto de tecnologías y procesos que implementa las capacidades objetivo. La siguiente tabla enumera para cada técnica de ciberresiliencia, los enfoques representativos que pueden utilizarse para implementar la técnica y ejemplos representativos de tecnologías y prácticas relativamente maduras, aunque deben entenderse como no exhaustivo ni completo. | **TÉCNICA** | **ENFOQUE** | **EJEMPLOS** | | :---------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Conciencia situacional | Conocimiento de los recursos dinámicamente <br/> Conocimiento de amenazas en tiempo real | Mantener un mapa de red en tiempo real <br/> Integrar el estado de salud de los activos <br/> Ingesta de incidentes y amenazas | | Protección coordinada | Defensa en profundidad monitorizada <br/> Análisis de consistencia | Combinar sistemas de detección de intrusión a nivel de red y de host <br/> Implantar niveles incrementales de protección para el acceso a recursos críticos <br/> Emplear herramientas unificadas de gestión de acceso de identidades y credenciales | | Engaño | Orquestación <br/> Auto-retos <br/> Ofuscación <br/> Desinformación <br/> Confusión <br/> Diversidad arquitectónica | Coordinar la gestión de incidentes con los procesos de negocio y continuidad del negocio <br/> Realizar las modificaciones de software de forma consistente y coordinada <br/> Llevar a cabo análisis de cobertura de sensores desplegados <br/> Utilizar ciber playbooks <br/> Realizar test del hardware <br/> Realizar ejercicios de entrenamiento <br/> Llevar a cabo test de penetración y ejercicios de red team <br/> Emplear inyección de fallos en la infraestructura <br/> Encriptar datos almacenados <br/> Encriptar datos en tránsito <br/> Utilizar redes privadas virtuales <br/> Emplear máscaras, hash <br/> Añadir información de relleno a la información útil <br/> Crear falsos tokens y credenciales <br/> Establecer honeypots, honeynets <br/> Mantener un entorno de engaño <br/> Desplegar diferentes SSOO <br/> Realizar auditorías de sistema y de logs <br/> Soportar múltiples protocolos estándar <br/> Utilizar múltiples fuentes de datos | | Diversidad de medidas | Diversidad de la información <br/> Diversidad de caminos <br/> Redistribución de la sensorización y demás activos <br/> Funcionalidad distribuida <br/> Información no persistente <br/> Servicios no persistentes <br/> Conectividad no persistente | Emplear protocolos de comunicación alternativos <br/> Utilizar canales fuera de banda <br/> Recolocar los sensores <br/> Redistribuir las funciones en diferentes sistemas <br/> Borrar la información de alta valor después de ser procesada <br/> Utilizar passwords de un solo uso para activos críticos <br/> Refrescar servicios utilizando virtualización <br/> Emplear finalización de sesión por inactividad <br/> Implementar redes definidas por software <br/> Emplear desconexión de red por inactividad | | Restricción de | Restricción de privilegios basado en confianza <br/> Acceso basado en atributo <br/> Privilegios dinámicos | Implementar mínimo privilegio <br/> Emplear restricciones de acceso basado en localización <br/> Requerir multi-autorización para servicios críticos <br/> Emplear control de acceso basado en rol, en atributo <br/> Utilizar máscaras dinámicas <br/> Emplear aprovisionamiento de cuentas dinámico <br/> Implementar revocación dinámica de accesos | | privilegios | | | | Segmentación | Propósito | Utilizar listas de usuarios permitidos para instalación de software <br/> Utilizar lista de usuarios para restringir comunicaciones a determinadas direcciones <br/> Asegurar que las cuentas privilegiadas no son utilizadas para funciones no privilegiadas | | Redundancia | Restricción <br/> Backup protegido <br/> Replicación | Configurar solo capacidades esenciales <br/> Proteger el sistema de backup <br/> Incrementar la monitorización durante las operaciones de restauración <br/> Mantener más de un almacén de datos <br/> Proporcionar mecanismos alternativos de seguridad <br/> Implementar un servicio de resolución de nombres redundante | | Impredecibili- | Impredecibilidad temporal <br/> Impredecibilidad contextual | Requerir reautenticación a intervalos aleatorios <br/> Realizar las tareas rutinarias a diferentes horas del día <br/> Cambiar roles y responsabilidades <br/> Utilizar enmascaramiento aleatorio | | dad | | | Tabla 36. Implementación de capacidades de ciberresiliencia. Fuente: basado en Ross et al., 2021.