Tema 4. Implementación de Medidas de Ciberseguridad PDF

# Tema 4. Implementación de medidas de ciberseguridad ## Los indicadores basados en la IP y el dominio Los indicadores basados en la IP y el dominio pueden bloquearse en función del tráfico de red, añadiéndolos a listas de acceso, políticas de cortafuegos o proxy. Por lo tanto, es importante tene...

# Tema 4. Implementación de medidas de ciberseguridad ## Los indicadores basados en la IP y el dominio Los indicadores basados en la IP y el dominio pueden bloquearse en función del tráfico de red, añadiéndolos a listas de acceso, políticas de cortafuegos o proxy. Por lo tanto, es importante tener la capacidad necesaria para implementar estos cambios ad hoc. ## Recuperación Cuando hablamos de recuperación, nos referimos a la restauración del sistema o sistemas para volver a la normalidad y (si es el caso) remediar las vulnerabilidades para evitar incidentes similares. Hay múltiples formas de restaurar tras un incidente de ciberseguridad. Todas ellas tienen un impacto diferente en el tiempo de recuperación, las limitaciones de costes o la pérdida de datos. La siguiente tabla muestra los escenarios de recuperación genéricos a los que nos podemos enfrentar: | ESCENARIOS | Tiempo de recuperación | Coste | Pérdida de información | Observaciones | |:---------------------------------------------|:-----------------------|:----------|:-----------------------|:-----------------------------------------------------------------------------------| | Limpieza de los artefactos maliciosos y reemplazo de los archivos comprometidos con versiones "limpias" | Rápido | Balance adecuado coste/efectividad | | Pueden quedar partes comprometidas sin descubrir | | Restauración desde backup | Normal | Balance adecuado coste/efectividad | | Solo posible si se tiene una adecuada política de backups | | Reconfiguración del sistema desde cero | Lento | Muy costoso | Se puede perder información | Es la única forma de asegurar al 100% que la infraestructura está limpia | _Tabla 27. Escenarios de recuperación. Fuente: elaboración propia._ En esta fase de recuperación, a modo resumen, se deben llevar al menos las siguientes actividades: - Reconstrucción de sistemas infectados (a menudo a partir de fuentes "limpias" conocidas) - Sustitución de los archivos comprometidos por versiones limpias - Eliminación de las restricciones temporales impuestas durante el periodo de contención - Restablecer las contraseñas de las cuentas comprometidas - Instalación de parches, cambio de contraseñas y refuerzo de la seguridad del perímetro de la red, como los conjuntos de reglas de los cortafuegos - Probar a fondo los sistemas, incluidos los controles de seguridad - Confirmar la integridad de los sistemas y controles empresariales El tipo de recuperación no sólo dependerá del tiempo y los medios económicos que tenga a su disposición. También dependerá del daño que el incidente haya causado a la infraestructura. Por ejemplo, es posible que la copia de seguridad esté infectada, incluso la copia de seguridad más antigua puesto que se hizo después de que el atacante entrara en el sistema. Por lo tanto, es importante comprobar que las copias de seguridad están libres de virus, rootkits y puertas traseras antes de restaurar. Si no se dispone de una copia de seguridad limpia, hay que reinstalar el sistema desde cero, incluyendo el sistema operativo. Después de restaurar el sistema, hay que eliminar las vulnerabilidades que permitieron al atacante acceder al sistema. Esto incluirá acciones como: instalar parches, tanto a nivel de sistema operativo como de las aplicaciones, cambiar las contraseñas, cambiar las cuentas, reforzar la seguridad del perímetro de la red, por ejemplo, cambiando las políticas de los cortafuegos, las listas de control de acceso del router frontera, etc., y bloquear servicios no necesarios. También hay que tener en cuenta que una vez que un activo ha sido atacado con éxito lo más probable es que vuelva a ser atacado, o que otros activos de la organización pueden ser atacados de manera similar. Por lo tanto, se debe considerar la posibilidad de mejorar las defensas, por ejemplo, realizando una mayor supervisión en el sistema de logs y de monitorización del tráfico de la red. Por último, antes de volver a poner el sistema en operación, debe validarse desde el punto de vista de la seguridad como de las funciones empresariales. En cuanto a la seguridad, el sistema puede validarse con un escáner de vulnerabilidades, la comprobación de configuraciones seguras del software, pruebas de pentesting, etc. ## Recuperación a incidentes comunes La siguiente tabla muestra los incidentes de ciberseguridad más habituales, las vulnerabilidades explotadas para perpetrar el ataque y las acciones de recuperación. | Incident type | Definition | Possible target | Vulnerabilities that might be exploited | Possible reactions | |:------------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------| | Social engineering: (spear) phishing, vishing (phone phishing) | Manipulating and tricking someone into revealing information (e.g. password or financial information) that can be used to attack systems or networks | CEO Accounting | Password cracked or sniffed, Unpatched system vulnerabilities, Social engineering, Careless users or weak procedures | Patch vulnerabilities or block exploitation, Check for malware (rootkits, backdoors, Trojans, etc.), Change passwords or inactivate accounts, Forensic evidence gathering, Block (network) access to the targeted resources | | (Spear) phishing, vishing (phone phishing) | Attempt to acquire sensitive information (e.g., customer logins & passwords) from customers by impersonating a legitimate and trusted person or organization. | Customer information, Credit card information, Applications creating or processing payments, Websites and Services | | | | Unauthorised access | When a person gains logical or physical access without permission to a network, system, application, data, or other IT resource. | | | | | Denial of service | Any attack that prevents or impairs the authorised use of networks, systems or applications by exhausting resources. | Mail system Network appliances, Application servers, Websites and Services | Spam filter weaknesses, Unpatched system vulnerabilities, Weak configuration of systems or appliances | Block traffic, Contact ISP, Disconnect infected system(s) | | Malicious code attack | A malicious code attack is any (large-scale) infection or threat of infection by a virus, worm, Trojan horse, or other code-based malicious entity. | Any server or even appliance in the network could be the target of a malicious code attack, but some systems have a higher risk profile (e.g. systems directly or indirectly connected to the outside world), Any end user workstations could be targeted via e-mail, USB storage devices, visits to websites and web applications, etc. | Unpatched system vulnerabilities (e.g. Flash or JavaScript), Anti-virus not installed, not active or signature file not up to date, Inappropriate or imprudent user behaviour (e.g. using infected USB memory device) | Block malicious web traffic, Apply patches, Update anti-virus signature files, Run virus clean-up tool if available, Run vulnerability assessment tool to list vulnerable resources, Completely reinstall infected system, Shut down vulnerable services, Shut down or disconnect infected system(s) | | Ransomware: is a type of malware that restricts access to the computer system that it infects, and demands a ransom paid to the creator(s) of the malware in order for the restriction to be removed. Some forms of ransomware encrypt files on the system's hard drive while some may simply lock the system and display messages intended to coax the user into paying. | | | | | | Inappropriate usage | An inappropriate usage incident is any incident involving an internal employee or contractor violating a code of conduct or a computer policy. Inappropriate behaviour is not always malicious and targeted. Sometimes a user will simply act carelessly or even be completely unaware of the policy or code of conduct he/she has infringed. The inappropriate behaviour will sometimes constitute a serious security incident in itself, but it can also be the cause of or trigger for a serious incident (like malware infection, loss of critical data). | Payment transactions, Credit card information, Customer commercial and personal information, Confidential Information in general | Weak management or control of confidential data, Bad user password management, Lack of segregation of duties, accumulation of access rights, Lack of application security or monitoring, Lack of procedures or control to enforce policies and codes of conduct | Inform and get advice from Compliance and/or the legal department, Inactivate users or withdraw access rights, Make forensic coples of logs and other crucial information to trace and prove what happened | | Fraud | Fraud is a kind of inappropriate behaviour that is Inherently malicious in nature and aimed at personal enrichment by abusing company systems, applications or information. | Personal information about employees or customers (protected by privacy laws or concerns), Credit card Information, Customer com-mercial information, Confidential balance sheet information, Confidential information about company strategy, on-going projects and decisions, etc. | Improper handling of portable storage devices (USB memory stick, CD, back-up tape, etc.), Improper handling of mobile equipment (laptop, PC, smartphone, etc.), Improper handling of confidential printed information, Breach of clean desk policy | Check logs and other information for traces of the infringement, Assess the level of protection of the data, if any (encryption, password protection, specific device required to read the data), Inform and get advice from Compliance and/or the legal department or from your external legal adviser, Inform Communications department and management, define a communication strategy | | Data loss or theft | This is an incident that involves the loss or theft of confidential information. Information can be confidential because of the value it has for the company, or because it is protected by internal or external regulations. Data loss incidents can have a big financial impact, due to possible financial liability or damage done to the company image, should the information itself or the fact that is has been lost become public or known to the wrong people. | | | Inform the owner of the lost or stolen data, Inform police (in case of theft) | | Brand abuse | This is an incident where someone is abusing your brand and registered trademarks. | Registration of DNS names containing the brand, Spoofing of website designs, Spoofing of e-mail addresses and e-mail templates | Not applicable | Request a takedown of the website, Inform customers about its existence | _Tabla 28. Principales incidentes y forma de neutralizarlos. Fuente: Centre for Cyber Security Belgium, s. f._ ## Recomendaciones A la hora de enfrentarse a esta fase es importante seguir las siguientes recomendaciones: - Limitar el alcance de la respuesta para confirmar que la operación de recuperación puede ejecutarse en un tiempo asumible por la organización (planificar las tareas más críticas en fin de semana para tener en cuenta las contingencias y acciones correctivas). - Evitar las distracciones. Aplazar las inversiones en seguridad a largo plazo como la implantación de nuevos sistemas de seguridad grandes/complejos o sustitución de soluciones antimalware hasta después de la operación de recuperación. Todo lo que no tenga un impacto directo e inmediato en la operación de recuperación es una distracción. - Nunca restablecer todas las contraseñas a la vez. Los restablecimientos de contraseñas deben centrarse primero en las cuentas comprometidas conocidas (de la investigación) y potencialmente cuentas de administrador/servicio. Si se justifica, las contraseñas de los usuarios deben restablecerse sólo de forma escalonada y controlada. - Consolidar la ejecución de las tareas de recuperación. A menos que nos enfrentemos a una amenaza inminente de perder datos críticos para el negocio, se debería planificar una operación consolidada para remediar rápidamente todos los recursos comprometidos (hosts, cuentas, etc.) en lugar de remediar los recursos comprometidos a medida que se encuentren. - Comprimir esta ventana de tiempo dificultará a los atacantes adaptarse a la nueva situación y mantener la persistencia. - Utilizar las herramientas existentes: investigar y utilizar las capacidades de las herramientas ya desplegadas (despliegue de software, antimalware, etc.) antes de intentar desplegar y aprender una nueva herramienta durante una recuperación. - Evitar informar al adversario. En la medida de lo posible, se deben tomar medidas para limitar la información disponible para los adversarios sobre la operación de recuperación. # Métricas de recuperación A lo largo del proceso de recuperación la recopilación de métricas específicas puede ayudar a mejorar la recuperación e informar sobre la mejora continua. Este proceso también requiere la capacidad de determinar dónde las métricas que se han identificado pueden ser más beneficiosas para la actividad de recuperación e identificar qué actividades no se pueden medir de forma precisa y repetible. Es fundamental garantizar que las métricas proporcionen información útil que respalde una mejora sin que sea perjudicial para la recuperación. Las organizaciones deben decidir cuándo y cómo utilizar las métricas durante la recuperación porque pueden ser un beneficio o un obstáculo. En el caso de las actividades bien definidas y repetibles, las métricas pueden ayudar a medir el progreso, así como proporcionar una valiosa retroalimentación para mejorar la actividad. ## Ejemplo de métricas de recuperación La siguiente tabla proporciona algunas consideraciones sobre aspectos de la recuperación de ciberincidnetes, describiendo un área general a medir y algunos ejemplos de métricas (por ejemplo, coste, tiempo, evaluación de daños, número de incidentes). Es importante tener en cuenta que la resiliencia es un área muy subjetiva de la ciberseguridad, por lo que comparar las métricas de recuperación entre organizaciones o incluso dentro de una misma entidad puede producir resultados engañosos. | Área de recuperación | Métrica | |:------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Evaluación de los daños y costes del incidente** | Costes debidos a la pérdida de ventaja competitiva por la divulgación de información confidencial o de propiedad [en dólares], Costes legales [dólares], Costes de hardware, software y mano de obra para ejecutar el plan de recuperación [en dólares], Costes relacionados con la interrupción del negocio, como el tiempo de inactividad del sistema; por ejemplo, pérdida de productividad de los empleados, pérdida de ventas, etc. [tiempo en horas, días o semanas), Otros daños consecuentes, como la pérdida de reputación de la marca o de la confianza de los clientes por la divulgación de los datos de los clientes (número de pérdidas actuales o futuras de dinero de socios comerciales, anunciantes y clientes) | | **Mejora de la evaluación de riesgos de la organización** | Frecuencia y/o alcance de los ejercicios y pruebas de recuperación [número de veces al año], Número de incidentes significativos relacionados con la TI que no se identificaron en la evaluación de riesgos [número de incidentes], Dependencias del sistema identificadas con precisión [número de activos no identificados], Lagunas identificadas durante los ejercicios o pruebas de recuperación que ayudan a informar e impulsar la mejora en las demás funciones del CSF [número de lagunas) | | **Calidad de las actividades de recuperación** | Número de interrupciones del negocio debidas a incidentes de los servicios de TI [número de funciones del negocio], Porcentaje de partes interesadas en el negocio satisfechas con la prestación de servicios de Tl que cumplen con los niveles de servicio acordados [satisfacción del cliente], Porcentaje de servicios de Tl que cumplen los requisitos de tiempo de actividad [acuerdo de nivel de servicio], Porcentaje de restauraciones exitosas y oportunas a partir de copias de seguridad o medios alternativos [número de sistemas y veces], Número de eventos de recuperación que han alcanzado los objetivos de recuperación [número de eventos de recuperación con éxito] | _Tabla 30. Métricas de recuperación. Fuente: elaboración propia._ # 4.4. Procedimientos y planes de contención y recuperación ## Plan de recuperación Un componente crítico de la recuperación ante ciberincidentes cibernéticos es tener guías y manuales de respuesta a incidentes o playbook que faciliten la recuperación y salvaguarden los activos de la organización. La planificación de la recuperación incluye el desarrollo de procesos y procedimientos lo suficientemente flexibles como para garantizar la restauración oportuna de los sistemas y otros activos afectados por futuros eventos cibernéticos, y también lo suficientemente completos como para quitar los casos de uso frecuente representados en un playbook. Aunque los detalles de un plan de recuperación deben ser desarrollados por cada organización, un plan de recuperación típico incluye los siguientes temas: - **Autoridad**. Nombre e información de punto de contacto de dos o más miembros del personal de gestión que pueden activar el plan. - **Miembros del equipo de recuperación**. Información sobre el punto de contacto de los miembros designados del equipo que han revisado, practicado y están preparados para implementar el plan. - **Acuerdos de nivel de servicio o SLA** - **Información sobre los compromisos escritos existentes para proporcionar un nivel de servicio concreto (por ejemplo, porcentaje de disponibilidad, tiempo de inactividad máximo permitido, suministro de ancho de banda garantizado).** Esto puede incluir un contrato de apoyo externo preestablecido que pueda ayudar y aumentar el equipo de recuperación de la organización en caso de un evento cibernético importante. - **Detalles y procedimientos específicos de recuperación** - **Documentación detallada del sistema de información en cuestión, con diagramas cuando corresponda.** Estos detalles pueden prescribir las actividades específicas de recuperación que debe realizar el equipo de recuperación, incluidos los detalles de restauración de la aplicación o los métodos para activar medios alternativos de procesamiento (por ejemplo, servidores de copia de seguridad). - **Comunicaciones fuera de banda.** Capacidad para comunicarse con las partes interesadas críticas de la empresa, de la Tl y de la seguridad de las TI, incluidas las partes externas como los equipos de respuesta a incidentes y de recuperación, sin utilizar los sistemas de producción existentes, que suelen estar vigilados por adversarios avanzados. - **Plan de comunicación.** Cualquier procedimiento específico de notificación y/o escalado que se aplique a este sistema de información. Por ejemplo, algunos sistemas afectan a usuarios ajenos a la organización, y puede ser necesario involucrar al personal jurídico, de relaciones públicas y de recursos humanos para gestionar las expectativas y la divulgación de información sobre el incidente y el progreso de la recuperación. - **Detalles sobre el almacenamiento fuera de las instalaciones:** detalles sobre cualquier acuerdo para almacenar registros o medios específicos en una ubicación fuera de línea o fuera de las instalaciones. Esto es especialmente importante dada la amenaza creciente del ransomware que cifra los datos y mantiene la clave de descifrado como rehén a cambio de un pago. - **Soluciones operativas.** Procedimientos aprobados de solución si el sistema de información no puede ser restaurado dentro del objetivo de tiempo de recuperación (RTO). - **Detalles de la recuperación de las instalaciones.** Información relevante para la recuperación de una instalación física, como una oficina o un centro de datos. Dichos detalles pueden incluir procesos de notificación al personal, información sobre la ubicación alternativa y detalles del circuito de comunicaciones. - **Infraestructura, hardware y software:** detalles sobre el acceso a la infraestructura, el hardware y el software para proporcionar servicios intermedios utilizados durante el proceso de recuperación. Los ejemplos incluyen un sistema de gestión de identidades, una red de recuperación, un sistema de mensajería y un sistema de puesta en producción para validar la integridad de los datos recuperados de las copias de seguridad y restaurar el sistema con el fin de instaurar la confianza en la infraestructura. ## Procesos de recuperación De acuerdo con el programa de seguridad de la información aprobado para toda la organización, se deben desarrollar y aplicar los procesos de recuperación que ayudarán a garantizar la restauración oportuna de las capacidades o servicios afectados por los eventos cibernéticos. Un enfoque para esto puede incorporar: - **Guía de recuperación o playbook con las principales fases para incluir procedimientos, etapas y criterios de salida bien definidos para cada etapa, como la notificación a las partes interesadas.** - **Procesos y procedimientos técnicos específicos que se espera que se utilicen durante la recuperación.** Esto permite tanto un enfoque flexible que puede adaptarse a diferentes situaciones con la especificidad técnica requerida para garantizar que las acciones clave se lleven a cabo de una manera eficiente. Los procedimientos deben automatizarse en la medida de lo posible para reducir los errores en un entorno operativo difícil, como es el caso de las operaciones de recuperación. Basándose en el catálogo de servicios, infraestructuras y aplicaciones, y en los objetivos de recuperación definidos, el equipo de planificación de la recuperación debe determinar los requisitos específicos de continuidad para identificar las posibles opciones estratégicas empresariales y técnicas. El equipo también puede identificar formas en las que la automatización podría ayudar a la recuperación. Implicar a las partes interesadas en esta actividad ayuda a garantizar que los participantes en la recuperación entienden sus funciones, y también mejora la repetibilidad y la coherencia de los procesos de recuperación. Además de crear y mejorar la relación entre los miembros del equipo, la participación en este modelo recordará a los responsables de los sistemas empresariales las amenazas realistas y ayudará a integrar el pensamiento de ciberseguridad en la organización. Los equipos de recuperación deben integrar procedimientos específicos de recuperación basados en los procesos utilizados en la organización. Estos procedimientos pueden incluir acciones técnicas como: - la restauración de los sistemas a partir de copias de seguridad limpia - la reconstrucción de los sistemas desde cero - la mejora del sistema de gestión de identidades y de los límites de confianza - la sustitución de los archivos comprometidos por versiones limpias - la instalación de parches - la corrección de errores de configuración del software - la protección de las aplicaciones y los servicios - el cambio de contraseñas - el aumento de la intensidad de la supervisión y el refuerzo de la seguridad del perímetro de la red (por ejemplo, conjuntos de reglas de cortafuegos, listas de control de acceso a los dispositivos de red) Los procedimientos también deben incluir acciones no técnicas que impliquen cambios en el negocio, medidas organizativas, modificación e incorporación de procesos, el comportamiento y las políticas y procedimientos de TI, de seguridad y de negocio. ## Criterios de inicio y fin de la recuperación Dependiendo de la gravedad y la naturaleza del incidente y de las operaciones de recuperación, la decisión de iniciar los procesos de recuperación puede ser tomada no por el personal de recuperación, sino por el equipo de respuesta a incidentes de la organización, el CISO, los propietarios del negocio y/u otro personal involucrado en la toma de decisiones para hacer frente a los ciberincidentes. El acuerdo y la coordinación de estos criterios, especialmente en lo que se refiere a los plazos, es de vital importancia para lograr una recuperación exitosa. Por ejemplo, comenzar la recuperación antes de que la respuesta de la investigación haya logrado una comprensión clave de la huella y los objetivos del adversario puede alertar al adversario de que se ha descubierto una infiltración, desencadenando un cambio de táctica que haría fracasar la operación de recuperación. Dicho cambio podría significar la pérdida de indicadores y visibilidad de las actividades del adversario, lo que daría lugar a una menor capacidad para descubrir los recursos afectados. Una respuesta coordinada ayudará a lograr un equilibrio entre una investigación forense eficaz y el restablecimiento de los servicios empresariales. Este equilibrio es una decisión única basada en las necesidades de identificar la causa raíz y restaurar rápidamente los servicios y sistemas al estado operativo. Para lograr ese equilibrio, la organización debe definir y documentar formalmente las condiciones en las que se invocará el plan de recuperación, quién tiene la autoridad para invocar el plan y cómo se notificará al personal de recuperación la necesidad de realizar actividades de recuperación. ## Determinación de la causa raíz y estrategia de contención Identificar la(s) causa(s) raíz de un ciberincidente es importante para planificar las mejores acciones de respuesta, contención y recuperación. Aunque siempre es deseable conocer la causa raíz completa, los adversarios están incentivados a ocultar sus métodos, por lo que no siempre es posible descubrir la causa raíz completa. Las organizaciones deben ajustar sus políticas, procesos y procedimientos de detección y respuesta a incidentes para hacer hincapié en la determinación de la causa raíz. Aunque la búsqueda de la causa raíz puede continuar por separado, hay casos en los que la recuperación se iniciará antes de que se determine dicha causa. Una recuperación eficaz depende de que se aborden todas las partes de un ciberincidente, por lo que si se pasan por alto una o varias vulnerabilidades o configuraciones erróneas (por ejemplo, credenciales de cuentas comprometidas utilizadas para restaurar servicios críticos), el personal de recuperación puede dejar inadvertidamente puntos débiles que los adversarios pueden volver a explotar inmediatamente. Los fallos de eliminación y contención pueden permitir que partes de un ataque permanezcan en los sistemas de la organización, causando más daños sin que el atacante llegue a actuar. La investigación de la causa raíz también puede ser valiosa para identificar debilidades sistémicas previamente desconocidas que deben ser abordadas en toda la organización. Un ejemplo de esto es una ruta de acceso previamente desconocida a un activo a través de una dependencia de seguridad, como una herramienta de gestión de sistemas, o una cuenta de servicio de exploración de seguridad. ## Comunicaciones durante la recuperación El equipo de recuperación debe desarrollar un plan de comunicación completo. La planificación eficaz de las comunicaciones es importante por numerosas razones, entre ellas: - Las declaraciones realizadas en el fragor de la recuperación pueden tener importantes repercusiones legales o reglamentarias. Entender, desde un punto de vista legal, qué se puede decir a quién y cuándo requerirá una amplia planificación y un debate previo. Puede haber requisitos específicos sobre lo que se puede comunicar a organizaciones externas, incluidos los medios de comunicación. El tiempo también será un factor importante, ya que las investigaciones están todavía en curso. - Las principales partes interesadas deben conocer suficiente información para que entiendan sus responsabilidades durante la fase de recuperación y puedan mantener la confianza en las capacidades del equipo de recuperación. La planificación, las pruebas y la mejora continua ayudarán a definir los mensajes adecuados para cada tipo de parte interesada (por ejemplo, socio externo, cliente, gerente). - Es posible que los miembros individuales del equipo de recuperación no dispongan de suficiente información para informar de forma precisa y oportuna sobre el estado y las actividades de recuperación. Acordar de antemano quién va a comunicar la información a quién es un aspecto crítico del plan de comunicación. ## Compartir insights Las organizaciones deben compartir la información relevante sobre ciberamenazas. Por ejemplo, una organización que acaba de recuperarse de una nueva e importante amenaza podría documentar sus pasos de recuperación y compartirlos con otras organizaciones para que éstas puedan recuperarse de la misma amenaza o de amenazas similares mucho más rápidamente o, en algunos casos, puedan detectar eventos cibernéticos más rápidamente y quizás prevenirlos por completo. El intercambio de información sobre la recuperación se ha hecho necesario en respuesta a los adversarios que comparten sus metodologías, herramientas y otra información entre sí para beneficio mutuo. Las organizaciones no deben compartir la información de recuperación hasta que hayan realizado las actividades de planificación y preparación necesarias, como la definición de sus metas, objetivos y alcance de la información compartida, y el establecimiento de reglas de intercambio de información (NIST SP 800-150, Guide to Cyber Threat Information Sharing). # Playbook Un playbook o manual de instrucciones de respuesta a un ciberincidente debería contener las partes que se describen seguidamente. | PLAYBOOK RECUPERACIÓN INCIDENTES | | |:------------------------------------|:---------| | **Precondiciones para una recuperación efectiva** | | | - Conjunto de procesos formales de recuperación. | | | - Determinación de la criticidad de los recursos de la organización (por ejemplo, personas, instalaciones, componentes técnicos, servicios externos) que son necesarios para cumplir la misión. | | | - Mapas de dependencia funcional y de seguridad para comprender el orden de prioridad de la restauración. | | | - Relación de la tecnología y el personal que será responsable de definir y aplicar los criterios de recuperación y los planes asociados. | | | - Plan de comunicaciones de recuperación completo con consideraciones de comunicaciones internas y externas totalmente integradas, incluyendo criterios de intercambio de información. | | | **Fase de recuperación táctica** | | | **Inicio** | | | - Informe del equipo de respuesta a incidentes para comprender el alcance del ciberincidente. | | | - Determinación de la criticidad y el impacto del ciberincidente. | | | - Enfoque y conjunto de acciones específicas. | | | - Aumento de la vigilancia y las alertas de la red y los sistemas. | | | - Comprender la motivación del adversario. | | | - Identificar la huella del adversario en la infraestructura, los canales de mando y control, y las herramientas y técnicas. | | | - Informar a todas las partes de que se han iniciado las actividades de recuperación. | | | - Utilizar toda la información disponible recopilada para crear el plan de restauración. | | | **Ejecución** | | | - Comenzar a ejecutar el restablecimiento validando e implementando contramedidas de remediación en coordinación con el equipo de respuesta a incidentes y otro personal de seguridad de la información. | | | - Restablecer los servicios empresariales de back-up y alternativos y comunicar el estado de restablecimiento a las partes predefinidas. | | | - Hacer un seguimiento del tiempo real en que los servicios críticos no estuvieron disponibles o disminuyeron, comparando la interrupción real con los niveles de servicio y los tiempos de recuperación acordados. | | | - Documentar cualquier problema que surja, cualquier indicador de compromiso y las dependencias recientemente identificadas. | | | - Coordinarse con los representantes de la dirección, los altos cargos, los recursos humanos y el departamento jurídico para discutir las actividades de notificación apropiadas. | | | - Iniciar los pasos adicionales de recuperación, incluyendo las interacciones y servicios externos para restablecer la confianza y proteger a los integrantes. | | | **Finalización** | | | - Validar que los activos restaurados son totalmente funcionales y cumplen con la postura de seguridad requerida por el equipo de seguridad de la organización. | | | - Comprobación que se han cumplido los criterios de finalización de la recuperación táctica. | | | - Retirada del equipo de recuperación y hacer que el personal vuelva a sus funciones normales. | | | - Seguimiento de la infraestructura para detectar la posible persistencia de actividades maliciosas e informar al equipo de respuesta a incidentes y de recuperación de cualquier evidencia. | | | - Análisis de las métricas recogidas durante el evento. | | | **SI/NO** | | | **Fase de recuperación estratégica** | | | - Apoyar a los distintos equipos de comunicación en su interacción con los usuarios internos, clientes y otras partes interesadas externas. | | | - Cerrar el círculo con las entidades externas que han participado durante la fase táctica. | | | - Desarrollar un plan para corregir la causa raíz del ciberincidente. | | | - Implementar cambios para reforzar la seguridad de la organización. | | | **Métricas** | | | - Una vez completada la recuperación, revise las métricas que se recogieron. | | | - Revisada la consecución de los hitos clave y las suposiciones que se hicieron antes de la recuperación. | | | **Lecciones aprendidas** | | | - Implantar un Plan de mejoras | | _Tabla 31. Playbook recuperación ante ciberincidentes. Fuente: elaboración propia._