1. Determinar si se trata de solo un evento (sin malas consecuencias para la organización)  o en realidad es un incidente (con malas consecuencias para la organización, como violación de políticas o estándares de seguridad).
2. Algunos de los indicadores o comportamientos más comunes que pueden ser señal de un incidente son:
   1. Existencia de usuarios desconocidos.
   2. Procesos o conexiones de red extrañas.
   3. Conexiones de red a la escucha.
   4. Llaves de registro inusuales.
   5. Tareas agendadas desconocidas, o servicios corriendo.
3. Tener en cuenta los vectores de ataque, tales como (se mencionan los más comunes):
   1. Dispositivos externos/removibles (usb’s).
   2. Ataques de fuerza bruta (Attrition).
   3. Navegación, Email (Spear phishing, Bussiness Email Compromise).
   4. Explotación de vulnerabilidades (de sistema operativo, aplicaciones).
   5. Pérdida o robo de equipo.
   6. Ataques Man in the Middle (MIM).
4. Las fuentes más comunes donde se puede encontrar indicadores de incidentes son:
   1. Sistemas SIEM.
   2. Software Antimalware y Antispam.
   3. Soluciones de File Integrity Checking.
   4. Servicios de monitoreo e información de seguridad y amenazas de terceros, Open Source (OSINT), Comerciales, Gubernamentales (como CERT’s, ISAC’s, Data Feeds).
   5. Logs de sistemas operativos, así como dispositivos de red (como UTM’s (IDS e IPS), routers, switches).
   6. Personas dentro y fuera de la organización, afines al área de Ciberseguridad.

El equipo de respuesta a incidentes debe trabajar rápido para analizar y validar cada incidente, siguiendo un proceso predefinido y documentado cada paso realizado.

El análisis inicial debe proveer información suficiente para priorizar (triage) actividades subsecuentes, como la contención del incidente y análisis más profundo de los efectos y alcance del incidente.

Las siguientes son recomendaciones para hacer el análisis de incidentes más fáciles y efectivas:

1. Entender comportamientos normales: El equipo de respuesta a incidentes debe analizar las redes, sistemas y aplicaciones de la organización, para entender cuál es su comportamiento normal (Baseline), de tal manera, cuando se presente un comportamiento anormal, sea más fácil de identificar.
2. Crear una política de retención de logs: Crear e implementar esta política que especifique por cuanto tiempo  los logs deben de mantenerse es de gran utilidad en el análisis porque principalmente los incidentes pueden ser descubiertos después de varios días, semanas o meses después de haber ocurrido (UTM’s, Antimalware, Sistemas).
3. Realizar correlación de eventos: La evidencia de un incidente puede ser registrada en logs de varios sistemas (UTM’s, Antimalware, Sistemas operativos, aplicaciones). Recomendado uso de solución SIEM.
4. Mantener todos los relojes de los sistemas sincronizados: Hacer uso de protocolos como NTP, con el fin de mantener la sincronización entre hosts y evitar que los eventos sean inconsistentes en lo que respecta a su hora de ocurrencia, lo que dificulta en gran medida en análisis de incidentes.
5. Hacer uso de motores de búsqueda en internet  para investigar incidentes.
6. Uso de analizadores de tráfico de red para la recolección de datos adicionales (como Wireshark).
7. Filtrado de datos/logs: Una estrategia efectiva es filtrar categorías de datos significativos como eventos críticos e ir avanzando paulatinamente a el análisis de datos menos relevantes (aunque en muchas ocasiones este tipo de eventos revelan información importante sobre el incidente).
8. Priorización del incidente: La priorización en el manejo del incidente es quizas, es el punto más crítico en la toma de decisiones en el proceso del manejo de incidentes.
   Este debe ser priorizado en basandose en datos relevantes, tales como:
   1. Impacto funcional del incidente: Ninguno, Bajo, Medio, Alto.
   2. Impacto del incidente en la información de la organización: Ninguno, Violación de Propiedad, Perdida de Integirdad.
   3. Recuperabilidad del incidente: Regular, No Recuperable.
9. Notificación de incidentes: Definir los contactos y los medios por los cuales el personal debe reportar cualquier incidente de seguridad.

1. Una parte esencial de esta etapa es la toma de las decisiones (por ejemplo, apagar un sistema, desconectarlo de la red, deshabilitar ciertas funciones, etc). El principal objetivo es prevenir un mayor daño y a su vez mantener las evidencias intactas. Las estrategias de contención varían de acuerdo al tipo de incidente. Las organizaciones deben crear estrategias de contención por separado, para cada tipo de incidente mayor, con criterios documentados y claros, para facilitar la toma de decisiones. Criterios para determinar una estrategia apropiada incluyen:
   1. Daño potencial y robo de recursos.
   2. Necesidad de preservación de evidencia.
   3. Disponibilidad de servicios (por ejemplo, conectividad de red, servicios proveídos a terceros).
   4. Tiempo y recursos necesarios para implementar la estrategia.
   5. Efectividad de la estrategia.
   6. Duración de la solución (workaround de emergencia a llevar a cabo por 4 horas, workaround temporal a remover en 2 semanas, solución permanente).
   7. En algunos casos se recomienda redirigir al atacante a un sandbox o honeynet, para que la organización pueda monitorear las actividades del atacante, usualmente para reunir evidencia adicional.
2. Recolección y manejo de evidencia
   1. Es importante documentar claramente como toda la evidencia, incluyendo sistemas comprometidos, ha sido preservada. Para esto es necesario instrumentar una Cadena de Custodia, que documente cuando cualquier evidencia pase de una persona a otra y que incluya detalle y firmas de cada parte involucrada.
   2. La evidencia debe ser conservada a detalle, incluyendo los siguientes datos:
      1. Información de identificación (ubicación, números seriales, modelo, Hostname, IP, MAC del equipo).
      2. Nombre, cargo, no. Telefónico de cada individuo involucrado en la recolección o manejo de evidencia durante la investigación.
      3. Fecha y hora de cada manipulación de evidencia.
      4. Ubicaciones de donde fue guardada la evidencia.
   3. Identificación de los hosts atacados. Los siguientes componentes describen las actividades más comunes para la identificación de hosts atacados:
      1. Validar la dirección IP del host atacante.
      2. Investigación del host atacante a través de motores de búsqueda (search engines).
      3. Uso de bases de datos de incidentes: Diferentes grupos colectan y consolidan datos, como Indicadores de Compromiso (IOC’s) de diferentes organizaciones en bases de datos de incidentes. La compartición de esta información puede realizarse de diferentes maneras, tales como Threat Intelligence Platforms (TIP’s), CERT’s, Black-Lists en tiempo real. La organización puede consultar su propia base de conocimientos o realizar una consulta de los IOC’s identificados en el incidente y posteriormente hacer un rastreo en la red de la organización con la finalidad de identificar y neutralizar los componentes maliciosos del incidente.
      4. Monitorear los canales de comunicación del atacante.

Posterior a la contención de un incidente, la erradicación es necesaria (aunque no siempre o se realiza en la etapa de recuperación) y es importante identificar todos los hosts afectados dentro de la organización para que puedan ser remediados. Algunas de las acciones a realizar en esta etapa son:

1. Eliminar malware.
2. Eliminar usuarios maliciosos o vulnerados.
3. Parcheo de sistemas para mitigar vulnerabilidades utilizadas.
4. Crear nuevas reglas en las soluciones de seguridad.
5. Aplicar un análisis de vulnerabilidades a los sistemas y la red (Pen test).

En esta etapa, administradores restauran los sistemas a su operación normal, confirman si están funcionando de manera correcta y (si aplica) se remedian vulnerabilidades para prevenir incidentes similares. Recuperación incluye acciones tales como:

1. Restaurar sistemas desde respaldos limpios.
2. Restaurar sistemas desde cero.
3. Instalación de parches.
4. Cambiar contraseñas en sistemas locales y recursos de red.
5. Administradores deben monitorear sistemas para asegurarse de su funcionamiento normal.
6. Continuar probando los sistemas restaurados.
7. Documentar los pasos llevados a cabo.
8. Recuperación permite a la contención empezar de nuevo, si la actividad maliciosa es detectada de nueva cuenta.

Una de las partes más importantes de la Respuesta a Incidentes es también comúnmente omitida: aprender y mejorar. El equipo de respuesta a incidentes debe evolucionar, tomando conciencia y conocimiento de las nuevas amenazas, tecnologías y lecciones aprendidas.

Mantener una reunión de “Lecciones Aprendidas”, con todas las partes involucradas en un incidente, puede ayudar en gran medida a mejorar las medidas de seguridad y el propio proceso de respuesta a incidentes. Preguntas a ser respondidas en estas reuniones son:

1. ¿Qué sucedió exactamente y en qué momento (fechas y horas)?
2. ¿Qué tan bien se desempeñó el equipo en la atención del incidente? ¿Se siguieron los procesos documentados? ¿Fueron los adecuados?
3. ¿Qué información fue necesitada en primera instancia?
4. ¿Se tomaron pasos o acciones que pudieron haber inhibido la recuperación?
5. ¿Qué podría hacer el equipo de manera diferente la próxima vez que ocurra un incidente similar?
6. ¿Cómo podría ser mejorado el mecanismo de compartición de información con otras organizaciones?
7. ¿Qué acciones correctivas se pueden aplicar para prevenir incidentes similares futuros?
8. ¿Qué indicadores deben ser observados en el futuro para detectar incidentes similares?
9. ¿Qué herramientas o recursos adicionales se necesitan para detectar, analizar y mitigar futuros incidentes?
10. Otra actividad importante en esta etapa es crear un “Reporte de seguimiento del Incidente“. Este reporte podrá ser usado como referencia para ayudar al manejo de futuros incidentes similares.
11. Uso de la información colectada: El estudio de las características del incidente puede revelar la existencia de vulnerabilidades y amenazas sistemáticas, así como cambios en las tendencias de incidentes. Esta información puede ser tomada en cuenta para la realización del proceso de análisis de riesgos, lo que a su vez llevará a selección e implementación de controles adicionales.
    Las organizaciones deben focalizarse en colectar información accionable, en lugar de recabar información simplemente porque está disponible. Métricas sugeridas para la recolección de incidentes son:
    1. Número de incidentes atendidos: Se recomienda enfocarse en los incidentes de mayor relevancia o que necesitaron de un mayor esfuerzo por parte del equipo de respuesta a incidentes para su resolución.
    2. Tiempo utilizado por cada incidente.
    3. Análisis objetivo de cada incidente: Con esto se puede determinar qué tan efectiva fue la respuesta y resolución del mismo.
12. Retención de la evidencia: Organizaciones deben establecer una política para definir por cuanto tiempo se resguardará la evidencia de un incidente. GRS (General Records Schedule), especifica que los registros de incidentes deben resguardarse por un periodo de 3 años.