Tema 3. Investigación de los incidentes de ciberseguridad PDF

## Tema 3. Investigación de los incidentes de ciberseguridad ### 3.1. Introducción a la unidad formativa La unidad formativa 3 “Detección de incidentes de seguridad” muestra las principales actividades, controles, herramientas y mecanismos para la detección y análisis de ciberincidentes. A continu...

## Tema 3. Investigación de los incidentes de ciberseguridad ### 3.1. Introducción a la unidad formativa La unidad formativa 3 “Detección de incidentes de seguridad” muestra las principales actividades, controles, herramientas y mecanismos para la detección y análisis de ciberincidentes. A continuación, se describen los bloques en que se ha dividido. * Controles, herramientas y mecanismos de monitorización, detección, identificación y análisis de ciberincidentes, muestra los principales mecanismos de monitorización, la importancia de la recopilación de información a través de diferentes fuentes; también explica técnicas de análisis y el proceso de priorización o triage. * Procedimiento de análisis de evidencias y auditorías, explica las actividades que se realizan durante la fase de análisis del incidente, cómo se realiza el análisis de evidencias obtenidas; introduce también las auditorías técnicas de seguridad y el análisis de malware. * Monitorización, detección, identificación y análisis de OSINT, explica el concepto OSINT y cómo obtener conocimiento a través de la recopilación de este tipo de fuente siguiendo el proceso de inteligencia. También relaciona las principales herramientas utilizadas, desde buscadores generales a los especializados, pasando por otras herramientas específicas. Por último, muestra un framework de referencia para OSINT. * Esta unidad formativa se complementa con una actividad relacionada con OSINT, donde el alumno tendrá obtener información de web utilizando la herramienta Google Hacking. ### 3.2. Controles, herramientas y mecanismos de monitorización #### Monitorización y evidencias Para muchas organizaciones la parte más difícil del proceso de respuesta a incidentes es detectar y evaluar con precisión los posibles incidentes de ciberseguridad, determinar si se ha producido un incidente y, en caso afirmativo, el tipo, el alcance y la magnitud del problema. Las causas que motivan esta dificultad se resumen en: * Los incidentes pueden detectarse por muchos medios diferentes, con distintos niveles de detalle y fidelidad. Las capacidades de detección automatizada incluyen desde IDPS (Intrusion Detection and Prevention Systems) basados en la red y en el host, software antivirus, sondas de tráfico, recolectores de eventos y analizadores de registros. Los incidentes también pueden detectarse a través de medios manuales, como los problemas notificados por los usuarios. * El volumen de signos potenciales de incidentes suele ser alto; por ejemplo, no es raro que una organización reciba miles o incluso millones de alertas de sensores de detección de intrusiones al día. * Se necesitan conocimientos técnicos profundos y especializados, así como una amplia experiencia, para realizar un análisis adecuado y eficiente de los datos relacionados con los incidentes. Podríamos afirmar que los cuatro principales retos a los que se enfrentan las organizaciones cuando intentan identificar un incidente de ciberseguridad de una manera rápida, eficaz y coherente son: * Identificar un presunto incidente de ciberseguridad (por ejemplo, supervisar las pruebas de sucesos inusuales, comportamientos anormales y evaluar uno o más puntos de activación) * Analizar toda la información disponible relacionada con el posible incidente de ciberseguridad * Determinar lo que ha sucedido realmente (por ejemplo, un DDOS, un ataque de malware, un hackeo del sistema, un secuestro de sesión o corrupción de datos) * Confirmar que realmente se ha sido objeto de un ataque de ciberseguridad o se ha sufrido una violación relacionada con la ciberseguridad. En una organización, cada día pueden producirse miles de posibles indicios de incidentes, registrados principalmente por los programas de registro y software de seguridad informática. Diferenciamos dos tipos de indicios (también conocidos como desencadenantes o alertas): * Un precursor, que es una señal de que puede producirse un incidente en el futuro * Un indicador, que es una señal de que un incidente puede haber ocurrido o estar ocurriendo ahora. La siguiente tabla muestra algunos ejemplos de precursores e indicadores. | Ejemplos de precursores | Ejemplos de indicadores | |---|---| | Precursores pueden incluir: | Indicadores pueden incluir: | | * Entradas de registro del servidor web que muestran el uso de un escáner de vulnerabilidad. | * Un sensor de detección de intrusiones en la red alerta cuando se produce un intento de desbordamiento del búffer contra un servidor de base de datos. | | * Un anuncio de un nuevo exploit que tiene como objetivo una vulnerabilidad del servidor de correo de la organización. | * El software antivirus alerta cuando detecta que un host está infectado con malware. | | * Una amenaza de un grupo que afirma que el grupo va a atacar a la organización. | * Un administrador del sistema ve un nombre de archivo con caracteres inusuales. | | | * Un host registra un cambio de configuración de auditoría en su registro. | | | * Una aplicación registra múltiples intentos fallidos de inicio de sesión desde un sistema remoto desconocido. | | | * Un administrador de correo electrónico ve un gran número de correos electrónicos rebotados con contenido sospechoso. | | | * Un administrador de red observa una desviación inusual de los flujos de tráfico típicos de la red. | **Tabla 24. Precursores e indicadores. Fuente: elaboración propia.** Algunos de los principales retos a los que se enfrentan las organizaciones suelen estar relacionados con la supervisión de los eventos relevantes en sus sistemas y redes en busca de indicios de un ataque de ciberseguridad. Las organizaciones suelen recopilar muchos datos, pero no tienen los recursos, los conocimientos técnicos o la concienciación para analizar los datos de forma eficaz. En particular, no siempre se da la suficiente importancia a los IDS, que a menudo se consideran una solución de "ajuste y olvido". Las organizaciones pueden creer que vigilan los eventos para detectar ataques sospechosos, pero, aunque tengan un IDS, no: * Supervisan todos los eventos relevantes * Llevan a cabo la supervisión con la suficiente regularidad, o de forma adecuada * Responden a las alertas correctamente (por ejemplo, pasando por alto las alertas indicativas o reaccionando de forma exagerada a las alertas benignas) * Agregan lo que pueden parecer alertas benignas en lo que es un mensaje de amenaza coherente. La siguiente tabla muestra las principales fuentes de registros y alertas. | Fuentes | Alertas | Descripción | |---|---|---| | IDPS | Los productos IDPS identifican los eventos sospechosos y registran los datos pertinentes al respecto, incluyendo la fecha y la hora en que se detectó el ataque, el tipo de ataque, las direcciones IP de origen y destino, y el nombre de usuario (si es aplicable y conocido). La mayoría de los productos IDPS utilizan firmas de ataque para identificar la actividad maliciosa; las firmas deben mantenerse actualizadas para poder detectar los ataques más recientes. El software IDPS a menudo produce falsos positivos, es decir, alertas que indican que se está produciendo una actividad maliciosa, cuando en realidad no ha habido ninguna. Los analistas deben validar manualmente las alertas del IDPS revisando detenidamente los datos de apoyo registrados u obteniendo datos relacionados de otras fuentes. | | SIEM | Los productos de gestión de información y eventos de seguridad (SIEM) centralizan los eventos de seguridad aplicando una capa de inteligencia que correlan estos eventos para detectar incidentes. | | Antivirus and antispam | El software antivirus detecta diversas formas de malware, genera alertas y evita que el malware infecte los hosts. Los productos antivirus actuales son eficaces para detener muchos casos de malware si sus firmas se mantienen actualizadas. El software antispam se utiliza para detectar el spam y evitar que llegue a los buzones de los usuarios. El spam puede contener malware, ataques de phishing y otros contenidos maliciosos, por lo que las alertas del software antispam pueden indicar intentos de ataque. | | Software de comprobación de la integridad de los archivos | El software de comprobación de la integridad de los archivos puede detectar los cambios realizados en archivos importantes durante los incidentes. Utiliza un algoritmo de hash para obtener una suma de comprobación criptográfica para cada archivo designado. Si se altera el archivo y se recalcula la suma de comprobación, existe una probabilidad extremadamente alta de que la nueva suma de comprobación no coincida con la antigua. Al recalcular regularmente las sumas de comprobación y compararlas con los valores anteriores, se pueden detectar los cambios en los archivos. | | Servicios de monitorización de terceros | Estos ofrecen una variedad de servicios de monitorización basados en la suscripción y gratuitos. Un ejemplo son los servicios de detección de fraudes que notifican a una organización si sus direcciones IP, nombres de dominio, etc. están asociados con la actividad de incidentes actuales que involucran a otras organizaciones. También existen listas negras gratuitas en tiempo real con información similar. Otro ejemplo de servicio de monitorización de terceros es una lista de notificación CSIRC; estas listas suelen estar disponibles sólo para otros equipos de respuesta a incidentes. | **Tabla 25. Fuentes de logs y alertas. Fuente: elaboración propia.** ### 3.3. Procedimientos de análisis de evidencias y auditorías técnicas #### Análisis #### Análisis del incidente El análisis de incidentes sería fácil si se garantizara la exactitud de cada precursor o indicador; lamentablemente, no es así. Por ejemplo, los indicadores proporcionados por el usuario, como la queja de que un servidor no está disponible, suelen ser incorrectos. Los sistemas de detección de intrusos pueden producir falsos positivos, es decir, indicadores incorrectos. Estos ejemplos demuestran lo que dificulta la detección y el análisis de incidentes: lo ideal es evaluar cada indicador para determinar si es legítimo. Para empeorar las cosas, el número total de indicadores puede ser de miles o millones al día. Encontrar los verdaderos incidentes de seguridad ocurridos entre todos los indicadores puede ser una tarea realmente compleja y exhausta. Incluso si un indicador es preciso, no significa necesariamente que se haya producido un incidente. Algunos indicadores, como la caída de un servidor o la modificación de archivos críticos, podrían ocurrir por varias razones distintas a un incidente de seguridad, incluido el error humano. Sin embargo, dada la aparición de indicadores, es razonable sospechar que puede estar ocurriendo un incidente y actuar en consecuencia. Determinar si un evento concreto es realmente un incidente es a veces una cuestión de juicio. Puede ser necesario colaborar con otro personal técnico y de seguridad de la información para tomar una decisión. En muchos casos, una situación debe tratarse de la misma manera, independientemente de que esté relacionada con la seguridad. Por ejemplo, si una organización pierde la conectividad a Internet cada 12 horas y nadie sabe la causa, el personal querrá resolver el problema con la misma rapidez y utilizará los mismos recursos para diagnosticar el problema, independientemente de su causa. Algunos incidentes son fáciles de detectar, como una página web obviamente desfigurada CAMBIAR POR desconfigurada. Sin embargo, muchos incidentes no están asociados a síntomas tan claros. Pequeñas señales, como un cambio en un archivo de configuración del sistema, pueden ser los únicos indicadores de que se ha producido un incidente. En la gestión de incidentes, la detección puede ser la tarea más difícil. Los responsables de la gestión de incidentes son los encargados de analizar los síntomas ambiguos, contradictorios e incompletos para determinar lo que ha ocurrido. Aunque existen soluciones técnicas que pueden hacer que la detección más fácil, el mejor remedio es crear un equipo de personal altamente experimentado y competente que pueda analizar los precursores e indicadores de forma eficaz y eficiente y tomar las medidas adecuadas. Sin un personal bien formado y capacitado, la detección y el análisis de incidentes se llevarán a cabo de forma ineficaz y se cometerán costosos errores. El equipo de respuesta a incidentes debe trabajar rápidamente para analizar y validar cada incidente, siguiendo un proceso predefinido y documentando cada paso dado. Cuando el equipo cree que se ha producido un incidente, debe realizar rápidamente un análisis inicial para determinar el alcance del incidente, como qué redes, sistemas o aplicaciones están afectados; quién o qué ha originado el incidente; y cómo se está produciendo el incidente (por ejemplo, qué herramientas o métodos de ataque se están utilizando, qué vulnerabilidades se están explotando). El análisis inicial debe proporcionar suficiente información para que el equipo pueda priorizar las actividades posteriores, como la contención del incidente y un análisis más profundo de los efectos del mismo. Realizar el análisis inicial y la validación es un reto. A continuación, se ofrecen recomendaciones para que el análisis de incidentes sea más fácil y eficaz: * **Perfilar las redes y los sistemas.** La elaboración de perfiles consiste en medir las características de la actividad prevista para poder identificar más fácilmente los cambios que se produzcan. Ejemplos de perfiles son la ejecución de software de comprobación de la integridad de los archivos en los hosts para obtener sumas de comprobación de los archivos críticos y la supervisión del uso del ancho de banda de la red para determinar cuáles son los niveles de uso medio y máximo en varios días y horas. En la práctica, es difícil detectar incidentes con precisión utilizando la mayoría de las técnicas de elaboración de perfiles; las organizaciones deberían utilizar la elaboración de perfiles como una de las diversas técnicas de detección y análisis. * **Comprender los comportamientos normales.** Los miembros del equipo de respuesta a incidentes deben estudiar las redes, los sistemas y las aplicaciones para entender cuál es su comportamiento normal, de modo que se pueda reconocer más fácilmente el comportamiento anormal. Ningún gestor de incidentes tendrá un conocimiento exhaustivo de todos los comportamientos en el entorno, pero los gestores deben saber qué expertos podrían llenar las lagunas. Una forma de obtener este conocimiento es mediante la revisión de las entradas de registro y las alertas de seguridad. Esto puede ser tedioso si no se utiliza el filtrado para reducir los registros a un tamaño razonable. A medida que los responsables se familiarizan con los registros y las alertas, deberían poder centrarse en las entradas sin explicación, que suelen ser más importantes para investigar. Realizar revisiones frecuentes de los registros debería mantener los conocimientos frescos, y el analista debería ser capaz de notar tendencias y cambios a lo largo del tiempo. Las revisiones también dan al analista una indicación de la fiabilidad de cada fuente. * **Crear una política de retención de registros.** La información relativa a un incidente puede quedar registrada en varios lugares, como el cortafuegos, el IDPS y los registros de aplicaciones. Crear e implementar una política de retención de registros que especifique cuánto tiempo deben conservarse los datos de los registros puede ser extremadamente útil en el análisis, ya que las entradas de registro más antiguas pueden mostrar la actividad de reconocimiento o instancias anteriores de ataques similares. Otra razón para conservar los registros es que los incidentes pueden no descubrirse hasta días, semanas o incluso meses después. El tiempo de conservación de los datos de registro depende de varios factores, como las políticas de retención de datos de la organización y el volumen de datos. * **Realizar una correlación de eventos.** La evidencia de un incidente puede ser capturada en varios registros que contienen diferentes tipos de datos. Un registro de firewall puede tener la dirección IP de origen que se utilizó, mientras que un registro de aplicación puede contener un nombre de usuario. Un IDPS de red puede detectar que se ha lanzado un ataque contra un host concreto, ESPACIO en campus pero puede no saber si el ataque ha tenido éxito. El analista puede necesitar examinar los registros del host para determinar esa información. La correlación de eventos entre múltiples fuentes de indicadores puede ser inestimable para validar si se produjo un determinado incidente. * **Mantener todos los relojes de los hosts sincronizados.** Protocolos como el Protocolo de Tiempo de Red (NTP) sincronizan los relojes entre los hosts. La correlación de eventos será más complicada si los dispositivos que informan de los eventos tienen ajustes de reloj inconsistentes. Desde un punto de vista probatorio, es preferible tener marcas de tiempo consistentes en los registros. * **Mantener y utilizar una base de conocimientos de información.** La base de conocimientos debe incluir la información que los gestores necesitan para consultar rápidamente durante el análisis del incidente. Aunque es posible construir una base de conocimientos con una estructura compleja, un enfoque sencillo puede ser eficaz. Los documentos de texto, las hojas de cálculo y las bases de datos relativamente sencillas proporcionan mecanismos eficaces, flexibles y con capacidad de búsqueda para compartir datos entre los miembros del equipo. La base de conocimientos también debe contener información variada, incluyendo explicaciones sobre el **Tabla 26. Fuentes de logs y alertas. Fuente: elaboración propia.** #### Detección En esta fase se deberán detectar los incidentes de ciberseguridad, analizarlos a alto nivel y confirmar qué tipo de incidente realmente se ha producido, si es que se ha producido. Algunos incidentes tienen signos evidentes que pueden detectarse fácilmente, mientras que otros son casi imposibles de detectar. Muchos incidentes de ciberseguridad tienen que ver con el robo de datos críticos /confidenciales -a menudo patrocinados por el Estado u organizados por bandas de cibercriminales- que buscan obtener propiedad intelectual u otra información sensible. Por lo tanto, son en su mayoría no destructivos, discretos y difíciles de detectar (a menudo porque los atacantes han cubierto sus huellas). Los incidentes de ciberseguridad también pueden tener lugar durante un largo periodo de tiempo y/o en diferentes partes de la organización. Los ataques selectivos avanzados pueden pasar desapercibidos durante muchos meses o años, e incluso cuando se descubren suelen ser se supone que no son más que una infección de malware común. Del mismo modo, muchas variantes de troyanos de robo de credenciales pueden pasar desapercibidos durante muchos meses. Hay muchas formas diferentes de identificar un incidente de ciberseguridad (con diferentes niveles de detalle y precisión), que incluyen: * Las alertas generadas por los sistemas de supervisión técnica, como la prevención de la pérdida de datos (DLP), los sistemas de detección de intrusiones (IDS), software antivirus y analizadores de registros * Eventos sospechosos comunicados, por ejemplo, al servicio de asistencia informática por los usuarios; a los gestores de cuentas por terceros (a menudo clientes); o directamente al equipo de seguridad por parte de organismos del sector, sus socios proveedores o el gobierno. * Anomalías detectadas por auditorías, investigaciones o revisiones. Los incidentes de ciberseguridad pueden detectarse en cualquier parte de la organización, o a través de terceros. Por lo tanto, debe asegurarse de que su proceso de respuesta a los incidentes de ciberseguridad es lo suficientemente amplio y hacer hincapié en la importancia de la detección y el análisis de incidentes en toda la organización. Los usuarios a través de los programas de concienciación deben ser parte de este proceso en el sentido de: * Informar de todas las sospechas de violaciones de la ciberseguridad a un punto central (por ejemplo, fallos de información; pérdida de servicios; detección de código malicioso; ataques de denegación de servicio; errores por datos empresariales incompletos o inexactos). * Anotar todos los detalles importantes (por ejemplo, el tipo de violación, los mensajes en pantalla, los detalles de los sucesos inusuales) * Abstenerse de intentar tomar medidas correctivas por sí mismos. Para poder detectar e identificar los incidentes de ciberseguridad, es necesario tener al menos una idea de lo que se está buscando. Por lo tanto, tener una lista de las categorías de incidentes de ciberseguridad que pueden afectar a la organización es necesario. Además, cuando se detecta un ciberincidente a menudo es difícil saber la gravedad de las consecuencias a priori. Las categorías de incidentes permiten priorizarlos y tomar decisiones en consecuencia. La siguiente figura muestra los tipos de incidentes más comunes, pudiendo un incidente pertenecer a más de una categoría.  **Figura 32. Tipos más comunes de incidentes. Fuente: Centre for Cybersecurity Belgium, s. f.** #### Vectores de ataque Los incidentes pueden ocurrir de innumerables maneras, por lo que es inviable desarrollar instrucciones paso a paso para manejar cada incidente. Las organizaciones deben estar preparadas en general para manejar cualquier incidente, pero deben empezar y centrarse en estar preparadas para manejar incidentes que utilizan vectores de ataque comunes. Diferentes tipos de incidentes merecen diferentes estrategias de respuesta. Los vectores de ataque que se enumeran a continuación no pretenden ofrecer una clasificación definitiva de los incidentes, sino que simplemente enumeran métodos comunes de ataque, que pueden utilizarse como base para definir procedimientos de gestión más específicos. * **Medios externos/extraíbles:** un ataque ejecutado desde un medio extraíble o un dispositivo periférico; por ejemplo, un código malicioso que se propaga en un sistema desde una unidad flash USB infectada. * **Desgaste:** un ataque que emplea métodos de fuerza bruta para comprometer, degradar o destruir sistemas, redes o servicios (por ejemplo, un DDoS destinado a perjudicar o denegar el acceso a un servicio o aplicación; un ataque de fuerza bruta contra un mecanismo de autenticación, como contraseñas, CAPTCHAS o firmas digitales). * **Web:** Un ataque ejecutado desde un sitio web o una aplicación basada en la web; por ejemplo, un ataque de secuencias de comandos entre sitios utilizado para robar credenciales o una redirección a un sitio que aprovecha una vulnerabilidad del navegador e instala malware. * **Correo electrónico:** un ataque ejecutado a través de un mensaje de correo electrónico o un archivo adjunto; por ejemplo, un código de explotación disfrazado de documento adjunto o un enlace a un sitio web malicioso en el cuerpo de un mensaje de correo electrónico. * **Suplantación de identidad:** un ataque que implica la sustitución de algo benigno por algo malicioso; por ejemplo, la suplantación de identidad, los ataques de hombre en el medio, los puntos de acceso inalámbricos fraudulentos y los ataques de inyección SQL implican la suplantación de identidad. * **Uso indebido:** cualquier incidente resultante de la violación de las políticas de uso aceptable de una organización por parte de un usuario autorizado, excluyendo las categorías anteriores; por ejemplo, un usuario instala un software para compartir archivos, lo que lleva a la pérdida de datos sensibles; o un usuario realiza actividades ilegales en un sistema. * **Pérdida o robo de equipos:** la pérdida o el robo de un dispositivo o medio informático utilizado por la organización, como un ordenador portátil, un smartphone o un token de autenticación. * **Otros:** un ataque que no encaja en ninguna de las otras categorías. A modo de ejemplo se incluye el siguiente patrón de ataque.  **Figura 33. Patrón de ataque. Fuente: Braverman-Blumenstyk, 2021.** #### Matriz MITRE ATT&CK MITRE ATT & CK es una base de conocimiento accesible a nivel mundial de tácticas y técnicas basadas en observaciones del mundo real de las amenazas a la seguridad cibernética. Se muestran en matrices organizadas por etapas de ataque, desde el acceso inicial al sistema hasta el robo de datos o el control de la máquina. Existen matrices para plataformas de escritorio comunes (Linux, macOS y Windows), así como para plataformas móviles. Tácticas y técnicas es una forma moderna de ver los ciberataques. En lugar de mirar los resultados de un ataque, también conocido como un indicador de compromiso (IoC), los analistas de seguridad deben considerar las tácticas y técnicas que indican que un ataque está en progreso. Las tácticas son el porqué, el objetivo de un ataque. Las técnicas representan cómo un adversario logra el objetivo. El conocimiento común es el uso documentado de tácticas y técnicas por parte de los adversarios. Esencialmente, el conocimiento común es la documentación de procedimientos. Aquellos familiarizados con la ciberseguridad deben estar familiarizados con el término «tácticas, técnicas y procedimientos» o TTP. La siguiente figura muestra parcialmente la matriz de MITRE, apareciendo en las columnas los objetivos (“tácticas") del atacante y en las filas aparecen las técnicas posibles a utilizar para ese objetivo.  **Figura 34. Matriz MITRE ATT&CK. Fuente: MITRE ATT&CK, s. f.**