Tema 2. Auditoría de incidentes de ciberseguridad PDF

# Tema 2. Auditoría de incidentes de ciberseguridad ## Tema 2. Auditoría de incidentes de ciberseguridad **Figura 20. Organización de un CSIRT. Fuente: Enisa, 2020.** - Incident Handling Unit - Threat Analysis Unit - Artifact Analysis Unit - Security Monitoring Unit - Awareness and training Unit...

# Tema 2. Auditoría de incidentes de ciberseguridad ## Tema 2. Auditoría de incidentes de ciberseguridad **Figura 20. Organización de un CSIRT. Fuente: Enisa, 2020.** - Incident Handling Unit - Threat Analysis Unit - Artifact Analysis Unit - Security Monitoring Unit - Awareness and training Unit **Roles** A modo de ejemplo se indica la definición del rol relativo a la respuesta a incidentes: ## Tema 2. Auditoría de incidentes de ciberseguridad **Tabla 13. Definición de perfiles en un CSIRT. Fuente: basado en NICCS, s. f.** | IDENTIFICACIÓN | DESCRIPCIÓN | |---|---| | Capacidades | - Capacidad para diseñar la respuesta a incidentes para modelos de servicios en la nube. - Capacidad para aplicar técnicas de detección de intrusiones basadas en el host y en la red utilizando tecnologías de detección de intrusiones. | | Formación | - Conocimiento de los conceptos y protocolos de las redes informáticas y de las metodologías de seguridad de las redes. - Conocimiento de los procesos de gestión de riesgos (por ejemplo, métodos para evaluar y mitigar los riesgos). - Conocimiento de las leyes, los reglamentos, las políticas y la ética en relación con la ciberseguridad y la privacidad. - Conocimiento de los principios de ciberseguridad y privacidad. - Conocimiento de las ciberamenazas y las vulnerabilidades. - Conocimiento de las repercusiones operativas específicas de los fallos de ciberseguridad. - Conocimiento de las copias de seguridad y recuperación de datos. - Conocimiento de los planes de continuidad del negocio y de recuperación de desastres. | | Habilidades | - Destreza para identificar, capturar, contener e informar sobre el malware. - Destreza para preservar la integridad de las pruebas según los procedimientos operativos estándar o las normas nacionales. - Destreza en la protección de las comunicaciones de red. - Habilidad para reconocer y clasificar los tipos de vulnerabilidades y los ataques asociados. - Conocimiento de la protección de una red contra el malware. (por ejemplo, NIPS, antimalware, restricción/prevención de dispositivos externos, filtros de spam | | Actividades | - Coordinar y proporcionar apoyo técnico experto a los técnicos de ciberdefensa de toda la empresa para resolver los incidentes de ciberdefensa. - Correlacionar los datos de los incidentes para identificar vulnerabilidades específicas y hacer recomendaciones que permitan una rápida reparación. - Analizar archivos de registro de diversas fuentes (por ejemplo, registros de hosts individuales, registros de tráfico de red, registros de cortafuegos y registros de | ## Tema 2. Auditoría de incidentes de ciberseguridad ### 2.5. Procedimientos de actuación en la gestión de incidentes **Introducción** Muchas organizaciones experimentarán un incidente importante y deberán responder a cuestiones difíciles sobre cómo prevenir, detectar y gestionar con éxito un ataque de ciberseguridad antes sus usuarios o clientes. **Figura 21. Disuasión del atacante. Fuente: Microsoft, s. f.** - RUIN ATTACKER'S ECONOMIC MODEL - BREAK THE KNOWN ATTACK PLAYBOOK - RAPID RESPONSE AND RECOVERY - ELIMINATE OTHER ATTACK VECTORS La preparación y ejecución de una respuesta bien planificada puede aumentar el coste operativo de un atacante y reducir drásticamente el impacto comercial de un incidente de ciberseguridad importante para la organización. ## Tema 2. Auditoría de incidentes de ciberseguridad ### Preparación Muchas organizaciones tienen más probabilidades de enfrentarse a desastres relacionados con ciberataques que con desastres naturales como incendios, terremoto o inundación. Una buena preparación para responder a un ciberataque puede reducir significativamente el riesgo empresarial de un ataque y la dificultad de gestionar la respuesta y la recuperación. **Esta sección proporciona los elementos de preparación que tienen el mayor impacto en la respuesta a un ataque de ciberseguridad:** - Tecnología - Operaciones - Legal - Comunicación #### Tecnología La preparación para la respuesta y la recuperación de un incidente importante de ciberseguridad debe incluir pasos para protegerse, detectar y responder a un incidente. ## Tema 2. Auditoría de incidentes de ciberseguridad **Tabla 14. Fuente: elaboración propia.** | Preparación genérica | | |---|---| | Identificar los activos de alto valor (HVA) | Hay que identificar los activos empresariales de importancia crítica y su composición técnica (servidores, aplicaciones, archivos de datos, etc.). Este inventario de componentes HVA es fundamental para que los planes de recuperación para puedan evaluar, contener/aislar y recuperar rápidamente estos activos críticos durante un incidente que se extienda por el entorno de producción. Esta identificación también será útil para priorizar los controles de protección y detección de estos activos e identificar las amenazas que pesan sobre ellos. | | Confirmar un despliegue de software fiable | Validar que puede ejecutar rápidamente scripts/instaladores en todos los puntos finales. Los sistemas de despliegue de software incompletos o poco fiables pueden dificultar significativamente los esfuerzos de recuperación. | | Preparación de investigación | | | Capacidades de detección y supervisión de amenazas | Confirme que tiene acceso a herramientas y habilidades que le permitan detectar atacantes avanzados en su entorno. Estas capacidades están en constante evolución, pero un programa avanzado actualmente incluiría: - Correlación y análisis de eventos - Inteligencia de amenazas integrada - Análisis del comportamiento de usuarios y entidades - Capacidad de detectar tantos indicadores de compromiso para patrones históricos e Indicadores de ataque para las técnicas en evolución - Análisis de aprendizaje automático | | Capacidades de investigación y forense | Confirme que tiene acceso a herramientas y habilidades avanzadas para investigar los ataques dirigidos que incluyen análisis de malware y de la actividad de los ataques que puedan producir una línea de tiempo completa del ataque. Puede obtener acceso a estas capacidades, herramientas y la contratación de analistas, o puede obtener acceso a través de entidades o servicios profesionales. | | Seguimiento y análisis de los costes de respuesta | Para permitir una mejor gestión del riesgo debe llevar un registro de los costes que supone la respuesta al incidente. Esto debería incluir tanto los costes directos (servicios externos, informes de crédito para clientes, etc.) y el coste del tiempo que su equipo dedica a la investigación y recuperación, así como el impacto negativo en el negocio y la misión de la organización. | ## Tema 2. Auditoría de incidentes de ciberseguridad **Tabla 15. Fuente: elaboración propia.** | Preparación para la recuperación | | |---|---| | Capacidad validada de copia de seguridad y recuperación de datos críticos | Prepararse para un ataque destructivo que borre o cifre los datos (como el ransomware) requiere que se haya validado la capacidad de recuperar los datos críticos utilizando una capacidad de copia de seguridad fuera de línea y/o resistente al ransomware. | | Crear documentación técnica/automatizar | Redactar y validar la documentación técnica (y/o automatización) para los procedimientos que se requieren frecuentemente durante un incidente de seguridad, incluyendo: - Procedimientos de recuperación de cuentas comprometidas que incluyan la consideración de Niveles de confianza en el compromiso de la cuenta (uso activo del atacante, credenciales de la cuenta credenciales expuestas en un host comprometido conocido, comportamiento sospechoso de la cuenta, etc.). Cómo validar si las cuentas fueron manipuladas utilizando copias de seguridad fuera de línea, registros de cambios u otros sistemas de registro. Cómo restablecer la contraseña o recrear rápidamente la cuenta. Cómo manejar los posibles conflictos/integración con el sistema de gestión de Identidad durante la recreación de una cuenta. - Procedimientos de recuperación de hosts comprometidos tanto para estaciones de trabajo como para servidores. Esto debería incluir: Procedimientos de reconstrucción del sistema operativo del host (y de las aplicaciones, Procedimientos de limpieza y criterios sobre cuándo limpiar o reconstruir (si la "limpieza" un host se considera aceptable en su organización), Procedimientos de segregación y aislamiento de la red, incluyendo la capacidad de buscar y supervisar los registros de puntos de salida de Internet de los atacantes, bloquear estos en los puntos de salida de Internet, Aislar los activos de alto valor de otros puntos finales en el entorno de producción (como estaciones de trabajo y servidores comprometidos) si es posible. - Procedimientos de segregación y aislamiento de la red, incluyendo la capacidad de: buscar y supervisar los registros de puntos de salida de Internet de los atacantes, aislar los HVA de otros puntos finales en el entorno de producción (como estaciones de trabajo y servidores comprometidos), si es posible. | ## Tema 2. Auditoría de incidentes de ciberseguridad ### Operaciones La gestión de un incidente de ciberseguridad es un reto de complejidades técnicas, variables desconocidas y tensión elevadas. Debido al impacto potencialmente severo en las operaciones de negocio, se puede hacer un claro caso de negocio para desviar esfuerzos, recursos y tiempo para llevar a cabo la planificación y la preparación necesarias para sobrevivir como empresa durante un ciberincidente. Las empresas identifican mayoritariamente la gestión de la continuidad del negocio (BCM) como su principal prioridad junto con la fuga de datos/pérdida de información. **Tabla 16. Características de un programa de respuesta sólido. Fuente: elaboración propia.** - Programa estrechamente integrado con: - Las prioridades y el liderazgo del negocio - Operaciones de TI - Gestión de la continuidad del negocio y recuperación de desastres - Contexto de fuentes internas y externas - Cultura y procesos de aprendizaje continuo: - Realización de posmortems e integración de las lecciones aprendidas - Ejercicios regulares y validación del equipo rojo - Documentación: - Alto nivel de familiaridad con el marco de respuesta por parte de todos los interesados - Instrucciones técnicas detalladas de recuperación (o automatización) para los profesionales de Tl y profesionales de la seguridad - Preparación técnica para incidentes importantes: - Acceso a la competencia técnica con los sistemas de seguridad y los sistemas críticos de la empresa - Acceso a la experiencia en aspectos operativos, de comunicación y legales de incidentes de seguridad (a través de equipos internos y/o asociaciones/retenciones con organizaciones externas). ## Tema 2. Auditoría de incidentes de ciberseguridad **Tabla 17. Preguntas para identificar si estás preparado por una gestión de incidentes. Fuente: elaboración propia.** - ¿Conoce bien sus HVA (procesos, datos, hardware, identidades)? - ¿Tiene actualmente controles mejorados para sus HVAs y las más probables de ataque? - ¿Cuáles son sus vectores de ataque de alta probabilidad? ¿Qué técnicas de ataque son más probables para que los agresores obtengan el acceso inicial y luego comenzar a niveles secundarios de ataque para obtener persistencia o niveles elevados de acceso? - ¿Puede medir el impacto en los recursos y la reputación de sus recursos y la reputación de su empresa si no invierte en la preparación? - ¿Tiene un centro de operaciones de seguridad centrado en detectar y respuesta a las ciberamenazas? - ¿Tiene un equipo de seguridad designado y flujos de trabajo de respuesta para respuesta a las amenazas conocidas? - ¿Tiene un proceso documentado, socializado conocido y ejercitado para respuesta a incidentes? - ¿Recibe su personal la formación y el tiempo adecuados para investigar las ciberamenazas? - ¿Qué eficacia tienen sus herramientas para detectar las ciberamenazas? ### Comunicación De todos los principales costes y riesgos asociados a la gestión de un incidente de seguridad el golpe potencial a la marca y la reputación y la pérdida de confianza de los clientes podría ser el más perjudicial. Según estudios de seguridad la mayoría de consumidores cambiarían de proveedor después de que una empresa sufriera una filtración de datos. Más allá del impacto en la reputación, los incidentes de seguridad mal gestionados y comunicados pueden afectar a la moral de los empleados, así como llevar a la presión regulatoria y a los litigios. **Figura 22. Preguntas para una adecuada comunicación. Fuente: Enisa, 2010.** - WHOM: With whom will your organisation communicate? - WHAT: What info will your organisation communicate? - WHO: Who will communicate? - WHEN: When will your organisation communicate? 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. ## Tema 2. Auditoría de incidentes de ciberseguridad Este plan de comunicación debe estar basado en las actividades generales que ya realizó durante la fase de preparación. Básicamente debe responder a las preguntas que figuran a continuación. Piense antes de ¡comunicar! ### Legal El asesoramiento jurídico desempeña un papel cada vez más importante en el desarrollo y la ejecución de programas proactivos de ciberseguridad. Al igual que con cualquier régimen de cumplimiento, los abogados especializados en ciberseguridad proporcionan asesoramiento legal en relación con los deberes legales, contractuales y obligaciones legales, contractuales y reglamentarias, así como recomendaciones para gestionar y mitigar el riesgo legal que pueda resultar de auditorías, investigaciones o litigios. Los reguladores esperan ahora que las organizaciones se preparen para un incidente y tengan presenta la aplicación de la normativa. ### Política La política que rige la respuesta a los incidentes está muy adaptada a la organización. Sin embargo, la mayoría de las políticas incluyen los mismos elementos clave: - Declaración de compromiso de la dirección - Propósito y objetivos de la política - Alcance de la política (a quién y qué se aplica y en qué circunstancias) - Definición de los incidentes de seguridad informática y términos relacionados - Estructura organizativa y definición de funciones, responsabilidades y niveles de autoridad; debe incluir la autoridad del equipo de respuesta a incidentes para confiscar o desconectar equipos y vigilar la actividad sospechosa, los requisitos para notificar determinados tipos de incidentes, los requisitos y directrices para las comunicaciones externas y el intercambio de información (por ejemplo, qué se puede compartir con quién, cuándo y a través de qué canales), y los puntos de transferencia y escalada en el proceso de gestión de incidentes - Priorización o clasificación de la gravedad de los incidentes - Medidas evaluación - Formularios de notificación y contacto. ### Procedimientos En este apartado se presentan los procedimientos básicos para el tratamiento de un incidente. #### Evaluación de la base de instalación del grupo de clientes atendido Estos procedimientos tienen que ver con la situación real de los sistemas TI que es responsabilidad y al que se atiende. De este modo se podrá evaluar la pertinencia de la información que llegue y filtrarla antes de volverla a distribuir, de modo que el grupo no se vea abrumado con información que le resulte de escasa utilidad. Para este propósito se pueden utilizar desde herramientas sofisticadas con gestión de activos en organizaciones grandes y complejas hasta una hoja Excel en organizaciones más pequeñas. A modo de ejemplo podríamos tener un control de activos (hw y sw) como es que se muestra a continuación: **Tabla 18. Ejemplo control de activos. Fuente: elaboración propia.** | Categoría | Aplicación | Software | Versión | SO | Versión SO | Grupo atendido | |---|---|---|---|---|---|---| | Ordenador personal | Oficimática | Excel | X-X-X | Windows | X-X-X | A | | Ordenador personal | Navegador | Edge | X-X-X | Windows | X-X-X | A | | Red | Router | CISCO | X-X-X | CISCO | X-X-X | B | | Servidor | Serv. aplicaciones | APACHE | X-X-X | Linux | X-X-X | B | | Servidor | Serv. base de datos | SQL-server | X-X-X | Windows | X-X-X | B | #### Generación de alertas, advertencias y comunicados La generación de alertas, advertencias y comunicados sigue siempre el mismo esquema: - Recopilación de información. - Evaluación de la información sobre la pertinencia y la fuente. - Evaluación del riesgo basada en la información recopilada. - Distribución de la información. **Figura 23. Esquema proceso de información. Fuente: adaptado de Lanfranco y Pérez Estévez, s. f.** - Customers - Partners - GOV<>CERT - SKURET - TF-CSIRT - US-CERT - Relevance - Identification - Classification - Risk assessment - Impact analysis - Incident handling - Archiving **Paso 1. Recopilación de información sobre la vulnerabilidad** Por lo general hay dos tipos importantes de fuentes de información que aportan información a los servicios: - Información sobre la vulnerabilidad de los sistemas de TI (propios); - Informes sobre incidentes. Dependiendo del tipo de empresa y de la infraestructura de sus TI, existen numerosas fuentes públicas de información sobre vulnerabilidad: - Listas de correo públicas; - Información sobre vulnerabilidad facilitada por los proveedores de los productos; - Sitios web; - Información publicada en Internet (Google, etc.); - Socios públicos y privados que proporcionan información sobre vulnerabilidad: FIRST, TF-CSIRT, CERT-CC, US-CERT. Toda esta información aumenta el nivel de conocimiento sobre las vulnerabilidades específicas de los sistemas de TI. **Tabla 19. Paso 1. Recopilación de información sobre la vulnerabilidad. Fuente: elaboración propia.** **Paso 2. Evaluación de la información y valoración del riesgo** Con este paso se realizará un análisis del impacto de la vulnerabilidad específica de la infraestructura de TI del grupo de clientes atendido. - **Identificación** - La fuente de la información entrante sobre vulnerabilidad siempre ha de ser identificada, y antes de transmitir la información al grupo atendido se ha de determinar si la fuente es de confianza. En caso contrario, se podrían generar alertas innecesarias que provocarían molestias gratuitas en los procesos empresariales y al final perjudicarían a la reputación de los CSIRT. - **Pertinencia** - La anterior visión general del hardware y el software instalado se puede usar para filtrar la información entrante sobre vulnerabilidad relativa a la pertinencia, a fin de encontrar una respuesta a dos preguntas: ¿Utiliza este software el grupo atendido? y ¿Es esta información pertinente para dicho grupo? - **Clasificación** - Una parte de la información recibida se puede clasificar o marcar como restringida (por ejemplo, los informes sobre incidentes que lleguen de otros equipos). Al manejar la información siempre se han de tener en cuenta las indicaciones del remitente y la propia política de seguridad de la información. Una buena norma básica es no distribuir información si no está claro qué se supone que es; en caso de duda, pedir permiso al remitente para hacerlo. - **Evaluación del riesgo y análisis de las consecuencias** - Existen diversos métodos para determinar el riesgo y las consecuencias de una (posible) vulnerabilidad. El riesgo se define como la oportunidad potencial de que se pueda aprovechar una vulnerabilidad. Algunos de los factores más importantes que cabe tener en cuenta son: - ¿Es bien conocida la vulnerabilidad? - ¿Está muy extendida? - ¿Es fácil de explotar? - ¿Se trata de una vulnerabilidad que se puede explotar de forma remota? Todas estas preguntas ayudan a formarse una idea adecuada de la gravedad de la vulnerabilidad. Para calcular el riesgo se puede recurrir a una fórmula muy sencilla: Impacto = riesgo X daños potenciales Riesgo probabilidad x impacto Los daños potenciales pueden ser: - Acceso no autorizado a los datos; - Denegación de servicio (DOS); - Obtención o ampliación de permisos. **Tabla 20. Paso 2: evaluación de la información y valoración del riesgo. Fuente: elaboración propia.** **Paso 3. Distribución de la información** Cada CSIRT puede elegir entre diferentes métodos de distribución, según las preferencias del grupo de clientes atendido y su propia estrategia de comunicación: - Sitio web; - Correo electrónico; - Informes; - Archivo e investigación. Los avisos de seguridad distribuidos por un CSIRT deberían seguir siempre la misma estructura, para mejorar la legibilidad y permitir que el lector encuentre rápidamente la información pertinente. **Tabla 21. Paso 3: distribución de la información. Fuente: elaboración propia.** ### Tratamiento de los incidentes Como mencionamos en la introducción de este capítulo, durante el tratamiento de los incidentes el tratamiento de la información es muy similar al que se lleva a cabo durante la compilación de alertas, advertencias y comunicados. Sin embargo, la parte de la recopilación de información suele ser diferente, pues normalmente los datos relacionados con incidentes se recogen ya sea con la recepción de informes de incidentes enviados por el grupo de clientes atendido o por otros equipos, ya con la recepción de los comentarios de las partes interesadas durante el tratamiento de un incidente. Por lo general, la información circula (encriptada) por correo electrónico; a veces se hace necesario usar el teléfono o incluso el fax. **Figura 24. Esquema proceso tratamiento de incidentes. Fuente: adaptado de: Lanfranco y Pérez Estévez, s. f.** - Constituents - Incident handling requests - Relevance - Identification - Classification - Triage - Actions - Start Incident ticket - Solve incident - Incident handling report - Archiving **Paso 1. Recepción de los informes de incidentes** Como ya hemos comentado, los comunicados de incidentes llegan al CSIRT por diferentes canales, sobre todo por correo electrónico, pero también por teléfono o fax. Conviene insistir en que es una buena práctica anotar todos los detalles con un formato fijo mientras se recibe el comunicado de incidente, para asegurarse de que no se olvida ningún dato importante. **Tabla 22. Paso 1: recepción de los informes de incidentes. Fuente: elaboración propia.** **Paso 2. Evaluación del incidente** En esta fase se comprueban la autenticidad y la pertinencia del incidente comunicado y éste se clasifica. - **Identificación** - Para evitar acciones innecesarias conviene comprobar que el creador del aviso sea fidedigno y si pertenece al grupo de clientes atendido. - **Pertinencia** - En este paso se comprueba si la petición de tratamiento de incidente procede del grupo de clientes atendido por el CSIRT, o si el incidente comunicado afecta a sistemas de TI del grupo atendido. Si no es así, el comunicado se suele enviar al CSIRT pertinente25. **Tabla 23. Paso 2: evaluación del incidente. Fuente: elaboración propia.** #### Clasificación Con este paso se prepara el triage clasificando el incidente según su gravedad. Un ejemplo se muestra a continuación: **Figura 25. Sistema de clasificación de un incidente. Fuente: First, s. f.** | Incident Categories| Sensitivity| Description| |---|---|---| | Denial of service| S3| DOS or DDOS attack.| | Forensics| SI| Any forensic work to be done by CSIRT.| | Compromised Information| S1| Attempted or successful destruction, corruption, or disclosure of sensitive corporate information or Intellectual Property.| | Compromised Asset| S1, S2| Compromised host (root account, Trojan, rootkit), network device, application, user account. This includes malware-infected hosts where an attacker is actively controlling the host.| | Unlawful activity| S1| Theft/Fraud/Human Safety/Child Pom. Computer-related incidents of a criminal nature, likely involving law enforcement, Global Investigations, or Loss Prevention.| | Internal Hacking| S1, S2, S3| Reconnaissance or Suspicious activity originating from inside the Company corporate network, excluding malware.| | External Hacking| S1, S2, S3| Reconnaissance or Suspicious Activity originating from outside the Company corporate network (partner network, Internet), excluding malware.| | Malware| S3| A virus or worm typically affecting multiple corporate devices. This does not include compromised hosts that are being actively controlled by an attacker via a backdoor or Trojan. (See Compromised Asset)| | Email| S3| Spoofed email. SPAM, and other email security-related events.| | Consulting| S1, S2, S3| Security consulting unrelated to any confirmed incident.| | Policy Violations| S1, S2, S3| Sharing offensive material, sharing possession of copyright material. Deliberate violation of Infosec policy. Inappropriate use of corporate asset such as computer, network, or application. Unauthorized escalation of privileges or deliberate attempt to subvert access controls. | #### Triage El triage es un sistema que utiliza el personal sanitario o de urgencias para racionar recursos médicos limitados cuando el número de personas que precisan asistencia supera los recursos disponibles, con el fin de tratar al mayor número de pacientes posible estableciendo prioridades. El triage es un elemento esencial de la capacidad de gestionar incidentes. El triage resulta decisivo para entender lo que se está comunicando en toda la organización. Es el vehículo por el que toda la información llega a un único punto de contacto, lo que permite adoptar una visión empresarial de la actividad y correlacionar de un modo exhaustivo todos los datos comunicados. El triage permite realizar una evaluación inicial de un informe entrante y lo registra a la espera de que se le dé curso. También constituye un punto de partida para empezar a trabajar con la documentación y con la entrada de datos de un informe o una petición, si no se ha hecho ya en el proceso de detección. La función de triage facilita una instantánea de la situación de toda la actividad comunicada (informes abiertos y cerrados, acciones pendientes, número de informes de cada tipo recibidos). Este proceso puede ayudar a identificar problemas de seguridad potenciales y a establecer prioridades de trabajo. La información recogida durante el triage también se puede usar para determinar pautas de vulnerabilidad e incidentes y generar estadísticas para los ejecutivos de alto nivel. Sólo se deben encargar del triage los miembros del equipo con más experiencia, pues el proceso requiere un conocimiento profundo de las repercusiones potenciales de los incidentes en cada parte del grupo atendido, así como la capacidad de decidir qué miembro del equipo debe encargarse del incidente.