02 - Gestion de Incidentes

Gestión de Incidentes
1
INDICE
Gestión de incidentes: Fuentes de información:
▪ Conceptos. ▪ Avisos de seguridad.
▪ Objetivos de la gestión de incidentes.
▪ Otras fuentes: logs, registros, eventos.
▪ Gestión de incidentes vs. respuesta a incidentes.
▪ Metodologías.
▪ Herramientas.
Role-play:
▪ Ciclo de vida de un incidente. ▪ Utilidad.
Incidentes críticos: ▪ Toma de decisiones.
▪ Valoración de la criticidad.
▪ Niveles.
Avisos de seguridad:
▪ Servicios reactivos: alertas y advertencias.
▪ Servicios proactivos: Comunicados y anuncios.
▪ Otros procesos asociados.
INDICE
▪ Objetivos de la gestión de incidentes. ▪ Otras fuentes: logs, registros, eventos.
▪ Metodologías.
Role-play:
▪ Herramientas.
▪ Toma de decisiones.
Incidentes críticos:
▪ Niveles.
Gestión de incidentes: Conceptos
Un incidente de seguridad informática es la violación o amenaza inminente a la
violación de una política de seguridad de la información implícita o explícita.
También es un incidente de seguridad un evento que compromete la seguridad de
un sistema (confidencialidad, integridad y disponibilidad). Un incidente puede
ser denunciado por los involucrados, o indicado por un único o una serie de
eventos de seguridad informática. [NIST800-61,ISO 27035].
Como ejemplos de incidentes de seguridad podemos enumerar:

▪ Acceso no autorizado
▪ Robo de contraseñas
▪ Robo de información
▪ Denegación de servicio
Gestión de incidentes: Conceptos
La Gestión de Incidentes puede definirse como el conjunto de

acciones y procesos a brindar a las organizaciones, para responder en
forma adecuada a la ocurrencia de incidentes de seguridad o ciber
incidentes que afecten a sus servicios.
INDICE
▪ Metodologías. Role-play:
▪ Herramientas. ▪ Utilidad.
▪ Ciclo de vida de un incidente. ▪ Toma de decisiones.
▪ Niveles.
▪ Otros
▪ Procesos asociados.
Gestión de incidentes: Objetivos
▪ Para las organizaciones, el beneficio más significativo de poseer

una adecuada capacidad de respuesta a ciberincidentes es
abordar su gestión de forma sistemática (es decir, siguiendo una
metodología consistente y consolidada), lo que facilita la adopción
de las medidas adecuadas.
▪ Así, una correcta Capacidad de Respuesta a Ciberincidentes ayuda

a los equipos de seguridad responsables a minimizar la pérdida o
exfiltración de información o la interrupción de los servicios.
▪ Otro de sus beneficios es la posibilidad de utilizar la información
obtenida durante la gestión del ciberincidente para preparar
mejor la respuesta a incidentes de seguridad futuros y, en su
consecuencia, proporcionar una mayor y mejor protección a los
sistemas.
▪ Toda política de gestión de incidentes deberá definir un esquema

de clasificación de los incidentes de seguridad. Si bien es real que
los incidentes pueden ser difíciles de encasillar en un esquema de
clasificación fijo.
▪ La clasificación permite elaborar estadísticas así como también
tomar decisiones a la hora de correr los procesos de preparación.
El esquema de clasificación deberá contemplar al menos los

siguientes aspectos de un incidente:
1. Clasificación por tipo: de un incidente entendemos a una
clasificación en categorías que clasifiquen los aspectos funcionales del
incidente. Algunos ejemplos de esto son por ejemplo:
▪ Acceso no autorizado a sistemas
▪ Denegación de servicio
▪ Divulgación de información sensible
▪ Infección de Malware
2.Clasificación por severidad: La severidad de un incidente es un

elemento de clasificación que debe permitir el potencial impacto del
incidente.
Este impacto puede ser medido de diversas maneras. En algunos
casos será posible establecer una escala monetaria, en otros casos se
podrá establecer una escala de impacto funcional (por ejemplo alta,
media, baja) de acuerdo a la afectación de los servicios.
Procesos de gestión de incidentes

Los procesos definen conjuntos de actividades que son realizadas por
parte del CERT independientemente de que se esté respondiendo a
un incidente o no.
Los procesos que la política de gestión de incidentes deberá definir
comprenderán al menos los siguientes aspectos:
1.Proceso de planificación y preparación para enfrentar incidentes de seguridad
El proceso de preparación incluye todas aquellas actividades de tipo proactivo
que puedan llevarse a cabo para estar mejor preparado para responder y
enfrentar incidentes de seguridad.
Estas actividades incluyen ítems como:
▪ Análisis de alertas y amenazas
▪ Actividades de sensibilización
▪ Actividades de entrenamiento
▪ Ensayos y evaluaciones de seguridad
▪ Definición de procedimientos
▪ Análisis y mejora continua del proceso
2. Proceso de atención/respuesta a incidentes:
El proceso de atención a incidentes agrupa todas las actividades de tipo reactivo que se realizan como
parte de la respuesta a un incidente concreto.
Este proceso incluirá ítems como:

▪ Recepción de reportes de incidentes
▪ Clasificación y valoración de impacto
▪ Relevamiento de sistemas y procesos de negocio afectados así como sus responsables.
▪ Elaboración de un plan de respuesta al incidente con medidas de contención y mitigación recomendadas.
▪ Obtención de avales para ejecución del plan de respuesta, si este lo requiere
▪ Ejecución de las medidas de contención y mitigación
▪ Elaboración de un informe final de cierre.
3. Proceso de mejora continua para enfrentar futuros incidentes
▪ El proceso de mejora continua agrupa todas las actividades que serán
realizadas por parte de la entidad afectada por el incidente para mejorar
su postura de seguridad para enfrentar futuros incidentes.
▪ La experiencia adquirida en la atención al incidente así como toda la
información obtenida durante el curso de la acción podrá permitir la
elaboración de un plan de acciones de mejora a implementar por la
entidad afectada.
▪ El objetivo de este plan de acciones no deberá ser en ningún caso un
objetivo de auditoría o de búsqueda de responsables si no que el objetivo
deberá ser el de fortalecer a la organización para evitar la repetición de
incidentes similares en el futuro.
Proceso de Atención a Proceso de Mejora Continua

Proceso de Planificación y
Incidentes: • Iniciar mejoras en la
Preparación:
• Elaboración de políticas • Detección y reporte de postura de seguridad
eventos de seguridad • Mejorar el plan de atención
• Actualización de
Políticas • Evaluación y decisión a incidentes
• Concienciación y sobre los incidentes de
Entrenamiento seguridad
• Respuesta a incidentes de
seguridad
INDICE
▪ Gestión de incidentes vs. respuesta a
incidentes. Role-play:
▪ Metodologías. ▪ Utilidad.
▪ Herramientas. ▪ Toma de decisiones.
▪ Ciclo de vida de un incidente.
▪ Niveles.
▪ Otros Procesos asociados.
Gestión de incidentes vs Respuesta a incidentes
▪ La respuesta incidentes se engloba dentro de la gestión de

incidentes.
▪ Dentro de la Gestión de Incidentes se encuentra la Repuesta a
Incidentes.
▪ La Gestión de Incidentes en su globalidad, permite desarrollar
correctamente una Respuesta a Incidentes.
Gestión de incidentes vs Respuesta a incidentes
Proceso de Atención a Proceso de Mejora Continua

Proceso de Planificación y
Incidentes: • Iniciar mejoras en la
Preparación:
• Elaboración de políticas • Detección y reporte de postura de seguridad
eventos de seguridad • Mejorar el plan de atención
• Actualización de
Políticas • Evaluación y decisión a incidentes
• Concienciación y sobre los incidentes de
Entrenamiento seguridad
• Respuesta a incidentes de
seguridad
INDICE
Role-play:
▪ Metodologías.
▪ Ciclo de vida de un incidente. ▪ Toma de decisiones
▪ Niveles.
▪ Otros
Metodologías de Gestión de Incidentes de Seguridad
NIST 800-61 R2
Metodología de Incidentes de Seguridad

Marcos de referencia
ISO27035
Metodologías
NIST SP 800-61 R2
Estructura y Servicios del Equipo Procesos y Fases de la Gestión Colaboración y Coordinación
de Respuesta a Incidentes de Incidentes entre organizaciones
▪ Preparación
▪ Modelos de Equipo de Respuesta ▪ Coordinación con
▪ Detección organizaciones externas
▪ Selección del personal del equipo
▪ Contención, erradicación y
▪ Servicios de Gestión Incluidos ▪ Colaboración para el
recuperación intercambio de información
▪ Relación con otras Áreas
▪ Actividades post-incidente
Metodologías NIST SP 800-61 R2
Intercambio de información con partes externas

Las organizaciones necesitan comunicarse con entidades externas y
para ello debe realizarse de una manera apropiada, como por ejemplo
las comunicaciones con las fuerzas policiales. Otro ejemplo de
comunicación es con los ISP.
El equipo de gestión de incidentes debe establecer con el
departamento legal las políticas y procedimientos necesarios en
cuanto al intercambio de información. De lo contrario , la información
sensible, podría llegar a entidades no autorizadas.
Incident Response Structure

Un equipo de respuesta a incidentes debe estar disponible para quien
descubra o sospeche que ha ocurrido un incidente involucrado con la
organización.
Uno o mas miembros del equipo dependiendo de la magnitud del
incidente y de la disponibilidad del personal, gestionara el incidente.
El personal que lo gestione analizará la información, para determinar
el impacto y actuará apropiadamente para limitar el daño y
restablecer el servicio.
Incident Response Structure

El éxito del equipo de respuesta a incidentes dependerá de la
participación y cooperación de los individuos a lo largo de la
organización. A continuación identificaremos el personal designado.
▪ Equipo de coordinación: un equipo de respuesta proporciona a los
otros equipos que no tienen autoridad sobre otros equipos.
▪ Equipo Central de respuesta a incidentes: un equipo de respuesta

a incidentes gestiona incidentes a lo largo de la organización. Este
modelo es efectivo para pequeñas organizaciones y para
organizaciones con poca diversidad geográfica.
▪ Equipo Distribuido de respuesta a incidentes: La organización
tiene múltiples equipos, cada responsable tiene asignado una
parte de la organización. Aunque están distribuidos, es necesario
tener una coordinación central, para no gestionar por duplicado el
mismo incidente.
▪ Empleados: la organización desarrolla todo su trabajo, con

limitaciones técnicas y administrativas.
▪ Parcialmente subcontratada: la organización subcontrata partes del
trabajo de respuesta a incidentes.
▪ Totalmente subcontratada: la organización tiene subcontratado
todo el trabajo de respuesta a incidentes. Este modelo se utiliza
cuando el personal propio de la organización no tiene disponibilidad
o cuando necesita empleados capacitados.
Selección del tipo de equipo:

La necesidad de un equipo 24*7: La mayoría de las organizaciones
necesitan personal que este disponible 24*7. Esto típicamente
significa que un incident handler pueda ser contactado por teléfono,
pero también se le puede pedir que se presente físicamente.

▪ Jornada completa vs Jornada Partida: organizaciones con limitada
financiación, personal o gestión de incidentes, podrían necesitar
personal a tiempo parcial. Cuando una emergencia ocurra, los
miembros del equipo serán contactados rápidamente. El grupo de IT
puede actuar como first responder e iniciar la investigación siempre
y cuando hayan sido entrenados.

Moral del empleado: el trabajo de respuesta a incidentes es muy
estresante, como son las llamadas que tiene que hacer la mayoría de
el equipo. Esta combinación hace que el personal pueda llegar
altamente estresado. Es labor de la organización luchar contra esto,
encontrando gente altamente experimentada.

Coste: el coste es el mayor factor, especialmente si los empleados son
requeridos para estar 24*7. Las organizaciones fallan al no incluir, el
entrenamiento y el coste de esta disponibilidad. El equipo de
respuesta a incidentes trabaja con muchas facetas del equipo de IT
pero sus miembros tiene un conocimiento mucho mas extendido.
También deben saber como se utilizan las herramientas para la
respuesta a incidentes, como el software de forense digital.
Conocimiento del personal: la gestión de los incidentes requiere
conocimiento especializado y experiencia varias áreas técnicas. La
amplitud y profundidad del conocimiento es algo fundamental.

Pérdida de correlación: esta pérdida entre múltiples fuentes de
información es muy importante. Si el sistema de detección de
intrusión registra un intento de ataque contra un servidor web pero el
personal subcontratado no tiene acceso a estos logs, podría ser
incapaz de determinar si el ataque tuvo éxito.
Para ser eficientes, el subcontratado requerirá de permisos para
sistemas críticos y registros de dispositivos de seguridad sobre un
canal seguro. Es posible, que esto incremente los costes y el riesgo de
acceso a información sensible.

Gestionar incidentes en múltiples localizaciones: un trabajo efectivo
requiere a menudo presencia física en las instalaciones de la
organización. Si el subcontratado esta fuera, hay que tener en cuenta
como el equipo puede desplegarse a cualquier instalación y cuanto
cuesta.

Mantener los skills en casa: las organizaciones que tienen
completamente subcontratado la gestión de incidentes, deberían
mantener unos skills básicos en casa. Habrá situaciones donde el
subcontratado no este disponible, por lo que la organización debería
estar preparada para desarrollar su propia gestión de incidentes. El
staff de la organización técnico, debe ser capaz de entender el
significado, las implicaciones técnicas y el impacto de las
recomendaciones del subcontratado.
Servicios de un equipo de respuesta a incidentes. La principal

actividad es desarrollar la respuesta a incidentes, pero raramente se
realiza solamente. También pueden ofrecer:
▪ Detección de intrusiones: el primer TIER asume la responsabilidad
de la detección de intrusiones.
▪ Distribución de recomendaciones: el equipo puede fallar
recomendando dentro de la organización en cuanto amenazas y
vulnerabilidades. Solo un grupo dentro de la organización debe
distribuir recomendaciones de seguridad para anular esfuerzos
duplicados e información errónea.
Servicios de un equipo de respuesta a incidentes:

Educación y Concienciación: son recursos que la mayoría de usuarios
deben conocer para detectar, reportar y responder a los incidentes. La
información debe ser comunicada a través de: workshops, websites
newsletters, posters, etc.
Compartición de información: los equipos a menudo participan en
intercambio de información. Dichos equipos tienen que gestionar la
información de la organización compartiendo esfuerzos que permitan
la resolución del incidente.
NIST SP 800-61 R2
Ciclo de vida de un incidente

La fase inicial contempla la creación y formación de un CERT/CSIRT, el

enteramiento de la utilización de las herramientas y la adquisición de
recursos necesarios.
Durante esta fase de PREPARACIÓN, la organización, atendiendo a lo
dispuesto en previo el correspondiente análisis de riesgos, habrá
identificado y desplegado un determinado conjunto de medidas de
seguridad o controles.
Sin embargo, como es sabido, incluso tras la implantación de tales
medidas, persistirá un riesgo residual, que deberá ser asumido por la
Alta Dirección del organismo, que permitirá minimizar el impacto.
La adecuada implantación de las antedichas medidas ayudará a

detectar las posibles brechas de seguridad de los Sistemas de
Información de la organización y su análisis, en la fases de
▪ DETECCIÓN
▪ ANÁLISIS
Desencadenando los procesos de notificación a los que hubiere lugar.
La organización, en la fase de CONTENCIÓN, ERRADICACIÓN Y

RECUPERACIÓN del incidente –y atendiendo a su peligrosidad- deberá
intentar, en primera instancia, mitigar su impacto, procediendo
después a su eliminación de los sistemas afectados y tratando
finalmente de recuperar el sistema al modo de funcionamiento
normal.
▪ Durante esta fase será necesario, cíclicamente, persistir en el análisis
de la amenaza, de cuyos resultados se desprenderán,
paulatinamente, nuevos mecanismos de contención y erradicación.
Tras el incidente, en la fase de ACTIVIDAD POST-INCIDENTE, los

responsables del organismo emitirán un Informe del incidente que
detallará su causa originaria y su coste (especialmente, en términos
de compromiso de información o de impacto en los servicios
prestados) y las medidas que la organización debe tomar para
prevenir futuros incidentes de naturaleza similar.
Incident Handling Checklist
Incident Handling Checklist
Metodologías ISO/IEC 27035
ISO/IEC 27035 :Norma que especifica los lineamientos para una

efectiva gestión de incidentes de seguridad, establecida como tal en el
año de 2011 por la ISO. En un SGSI (Sistema de Gestión de Seguridad
de la Información) la implementación de políticas y controles no
garantizan una total protección de la información y de los sistemas
que la procesan. Posterior a su despliegue se encuentra un riesgo
residual, el cual se puede materializar por la existencia de alguna
vulnerabilidad por pequeña que sea y donde los controles
implementados son inefectivos.
La gestión de incidentes se encuentra organizada en 5 fases:
▪ Planear y Preparar: En esta fase de planea y se define la política de gestión de incidentes de
seguridad, alineada a la política de seguridad de la información y de análisis de riesgos, además
de concientizar a la gerencia. Se debe definir un equipo de respuesta a incidentes de seguridad
de la información
▪ Detección y Reporte: Es la detección y el registro o reporte del incidente, donde se realiza la
recolección asociada al incidente. Es la primera fase del proceso operacional de la gestión.
▪ Evaluación y Decisión: Es la evaluación de la información recolectada y un análisis para validar si
el evento reportado es un incidente de seguridad.
▪ Respuesta: Respuesta al incidente de seguridad, con el análisis forense si fue necesario
realizarlo, dependiendo de la decisión tomada en la fase de Evaluación y Decisión, y la
respectiva entrega del reporte a las personas involucradas.
▪ Lecciones Aprendidas: Se identifican las lecciones aprendidas del incidente de seguridad y la
mejora del proceso o del SGSI. De ser necesario validar el proceso de gestión de incidentes para
implementar mejoras, debido a la lección aprendida del resultado del incidente de seguridad.
Dentro de los objetivos que debe tener toda área de Seguridad de la

Información es el definir controles y procedimientos para el manejo
de los incidentes de seguridad de la información en la organización.
Estas acciones desde el enfoque corporativo, promueven el
cumplimiento de un objetivo principal: ayudar a contener y/o
administrar el impacto de los incidentes para reducir costos directos o
indirectos causados por los mismos.
La norma ISO 27035:2011 ha definido dentro del proceso de gestión
de incidentes de seguridad de la información 5 fases, vistas
anteriormente.
Fase 1: Planificación y preparación

Generalmente esta es la fase en que se especifica la mayor parte de la
documentación del modelo. Para la entidad ,específicamente para los
incidentes seguridad, el modelo propuesto dentro de esta fase define:
▪ Política de Gestión de Incidentes de Seguridad de la Información
(Procedimiento y esquema del proceso de Gestión de Incidentes de
Seguridad de la Información.
▪ Establecimiento del ISIRT (Information Security Incident Response
Team - Equipo de respuesta a Incidentes de Seguridad de la
Información)
Fase 2: Detección y reporte.

El personal definido por la Dirección de Seguridad es el responsable
de detectar y reportar de manera inmediata a través de los canales o
medios definidos al Gestor de Incidentes de Seguridad de la
Información y al administrador o dueño del sistema o sistemas
afectados, cualquier incidente de seguridad derivado de los eventos
identificados que puedan impactar de forma negativa la integridad,
confidencialidad y disponibilidad de los activos.
Además entre otras funciones tales como:
Además entre otras funciones tales como:

▪ Monitorear todos los eventos que puedan ser causales de
incidentes de seguridad de la información.
▪ Recolectar la información necesaria sobre los eventos que
produzcan incidentes de Seguridad de la Información.
▪ Gestionar (Detectar, reportar y tratar) las vulnerabilidades que se
identifiquen sobre la infraestructura tecnológica.
Fase 3: Evaluación y decisión.

Según la información contenida en el formato de reporte de
Incidentes de Seguridad, el Gestor de incidentes, junto con el ISIRT,
deben validar si el incidente reportado es un incidente de seguridad.
Evaluación de los Incidentes
El Gestor del Incidente de Seguridad de la Información evalúa la información asociada a los
eventos reportados como incidentes, la analiza y define el alcance del incidente (Sistema de
información, infraestructura tecnológica, infraestructura física) o la información misma procesada
en estos sistemas.
Durante la evaluación es necesario solicitar información como:
▪ En qué consiste el incidente de seguridad de la información, según los eventos identificados
▪ Identificación de los activos afectados (Sistemas de Información, Información, Procesos)
▪ Cómo fue causado, y qué o quién lo causó
▪ Fecha y hora de ocurrencia. Frecuencia de la ocurrencia.
▪ Impacto real del incidente sobre el negocio.
▪ Tratamiento temporal del incidente.
Priorización del incidente

Esta etapa busca clasificar el incidente tomando en cuenta el impacto
sobre los servicios y sistemas afectados y acordando la asignación de
prioridad para todos los recursos necesarios para su contención y
recuperación, incluyendo el personal adecuado para el tratamiento
del incidente dentro del ISIRT.
Previo al tratamiento del incidente, es indispensable priorizar el

incidente teniendo en cuenta los siguientes factores:
▪ Impacto al negocio: Incidentes contra los sistemas de TI que
soportan las principales funcionalidades del core del negocio. El
impacto no sólo debe ser tenido en cuenta en el instante actual, sino
también en la probabilidad futura de la concurrencia del incidente.
▪ Impacto en la Información: El grado de afectación de la

confidencialidad, integridad y disponibilidad de la información de la
Entidad.
▪ La información que se procesa en los sistemas del alcance de este
procedimiento, es sensible y confidencial para la Entidad, por lo cual
cualquier incidente que afecte los criterios anteriormente
nombrados es valorado como Crítico.
▪ Recuperación del incidente: El tamaño del incidente y los sistemas

afectados (su infraestructura, redes y sistemas), determinará la
cantidad de tiempo y recursos que deben ser destinados para la
recuperación de ese incidente.
▪ Para aquellos casos donde no es posible la recuperación de un
incidente, se pone a consideración del ISIRT, destinar recursos para
la gestión prolongada del incidente, teniendo en cuenta que
generalmente en estos tipos de incidentes, se asignan recursos
para trabajar en asegurar y evitar la materialización de los
incidentes en un futuro.
Para asignar una calificación de severidad para un incidente es

necesario determinar por cada incidente, el impacto funcional actual
y futuro, del incidente si no es contenido inmediatamente (NIST -
2012).
Posterior a la identificación del impacto, se debe asignar una criticidad

de los sistemas o recursos involucrados en el incidente, de acuerdo a
la siguiente tabla:
Para determinar el resultado total de la severidad para un incidente,

la persona definida por el ISIRT para la priorización del incidente debe
utilizar la siguiente fórmula:
▪ Severidad general / Score del Efecto = Entero ((Valuación Actual del
efecto *2.5) + (Valuación proyectada efecto * 2.5) + (Valuación
criticidad del sistema * 5)).
Con el resultado se indica la valoración del incidente de la siguiente

manera:
Fase 4 : Respuesta
Posterior a la evaluación y las decisiones tomadas por el ISIRT como resultado de
la fase anterior, en esta fase y dependiendo de la valoración del incidente, el ISIRT
debe definir un conjunto de actividades de forma casi inmediata a la detección
del incidente, como:
▪ Identificar las acciones de respuesta inmediata para el tratamiento del
incidente.
▪ Definir y documentar controles de emergencia según los resultados de la
evaluación del incidente.
▪ Notificar los interesados (stakeholders) sobre los resultados de la evaluación
del incidente y las acciones sugeridas para una pronta recuperación (controles
de emergencia).
Tan pronto las respuestas inmediatas han sido implementadas, se

debe determinar la causa o las causas del incidente y su posterior
erradicación.
Ejemplo de erradicación: la ausencia de instalación de un parche de
seguridad sobre los sistemas afectados, algún desarrollo mal
implementado sobre los sistemas, la detección de un ataque de
denegación de servicio por la identificación de múltiples eventos
ejecutados desde direcciones IP.
Algunas actividades en esta fase incluyen:

▪ Determinar los signos y causa de incidentes
▪ Localizar la versión más reciente de copias de seguridad de los
sistemas afectados.
▪ Mejora de las defensas mediante la implementación de técnicas de
protección.
▪ Realización de análisis de vulnerabilidad para encontrar nuevas
vulnerabilidades introducidas por la causa raíz.
Fase 5: Lecciones aprendidas

La última fase del proceso operativo de gestión de incidentes de
seguridad se lleva a cabo cuando se tiene la certeza que el incidente
ha sido solucionado o cerrado.
Se tiene conocimiento del estado del incidente con la elaboración por
parte del ISIRT de un reporte, donde se identifique la causa o causas
del incidente, las actividades realizadas, las medidas que fueron
adoptadas y los resultados de la implementación de esas medidas.
▪ El ISIRT completará cualquier documentación que no se hizo durante el
incidente, además de aquella información que sea beneficiosa para el
tratamiento de futuros incidentes.
Dentro de las actividades que se deben realizar son:
▪ Ejecución de un análisis forense (si así lo considera el ISIRT) sobre los
sistemas impactados por el incidente.
▪ Identificación de las lecciones aprendidas y de las nuevas
vulnerabilidades identificadas durante la evaluación y plan de respuestas
del incidente.
▪ Validación de mejoras en la implementación de controles de seguridad
de la información en los sistemas afectados.
▪ Identificar y valoración de los riesgos identificados según los resultados

de la evaluación de los incidentes.
▪ Identificar mejoras en el proceso de gestión de incidentes de seguridad
de la información
▪ Actualización de los incidentes de seguridad de la información
gestionados para posteriores informes o insumos para otros procesos de
la Dirección de Seguridad de la Información o el área que bajo
justificación y demanda lo requiera.
▪ Comunicación de los resultados a los stakeholders de los sistemas
afectados por el incidente, teniendo en cuenta que la clasificación de la
información compartida es confidencial.
ISO/IEC 27035 vs NIST SP 800-61
Similitud en el ciclo de vida del incidente

Ambos estándares están basados en un enfoque cíclico. Esto es crítico
para la gestión de incidentes.
Vamos a comparar las fases en los ciclo de vida del incidente:
Ciclo de vida del incidente en NIST SP 800-61
▪ Preparación
▪ Detección y Análisis
▪ Contención, Erradicación y Recuperación
▪ Actividad Post-Incidente
Ciclo de vida del incidente en ISO 270035
▪ Planear y preparar
▪ Detección y reporte
▪ Evaluación y Decisión
▪ Respuestas
▪ Lecciones Aprendidas
Diferencias en los nombres de las fases:

NIST resalta análisis junto con detección. ISO resalta reporte junto
con detección. Ambos ciclos, tienen análisis y reporte, pero la
diferencia es importante.
ISO recalca la importancia de la comunicación del incidente, aunque
NIST tiene un capitulo en cuanto al intercambio de información, si se
resalta en el ciclo de vida del incidente esto ayuda a incrementar la
concienciación en este asunto.
Diferencias en los nombres de las fases:

ISO no define en el ciclo, en que cosiste una respuesta. NIST es mucho
mas claro, indicando las tres subfases: Contención, Erradicación y
Recuperación.
Por otro lado, ISO remarca “Lecciones aprendidas” el cual es
importante en términos de concienciación, como una parte muy
importante del ciclo: aprender de los incidentes.
Equipo de respuesta a incidentes y procedimientos

Ambos estándares, dan recomendaciones detalladas respecto al
equipo de gestión a incidentes, y procedimientos/políticas de gestión
de incidentes.
Estos dos elementos son críticos para la gestión de incidente, no las
herramientas técnicas.
Incident handling check-list NIST

Como hemos visto, el NIST tiene un checklist que contiene 9 pasos
para la gestión de incidentes. El checklist podría ser, el primero
camino a escoger para empezar en la gestión de incidentes. Es simple
de usar y puede ser usado inmediatamente.
Guía de categorización de incidentes en ISO 27035

Esta guía puede ser utilizada para organizaciones de tamaño medio
grande donde hay muchos incidentes y donde se necesita análisis
estadísticos para ver el histórico.
La guía de clasificación es detallada y contiene exactamente formulas
y explicaciones claras. Las guías pueden ser aplicadas, directamente.
INDICE
▪ Metodologías.
▪ Herramientas. Role-play:

▪ Niveles.
▪ Otros
Herramientas
Es indispensable analizar qué tipo de herramienta se ajusta a las

necesidades de la empresa en la gestión de incidente de seguridad
informática, para así poder tomar acciones correctivas y preventivas
en busca de una mejora continua y que este no origine sucesos de
seguridad repetitivos en la empresa.
Poder detectar mediante auditorias, informes y log de seguridad
cualquier eventualidad de seguridad informática que perjudiquen,
dañen o ponga en indisponibilidad los activos informáticos o la
información de la empresa y ser resueltos en el menor tiempo
posible.
Herramientas
Para poder llevar un control de lo anterior se debe pensar en una

herramienta de gestión de incidentes que sea capaz de registrar y
clasificar los incidentes, clasificándolos según su criticidad para
proceder a tomar acciones correctivas y mitigar los riesgos que traen
consigo los incidentes.
Herramientas
Log Análisis, gestión de logs, SIEM:

OSSIM (Open Source Security Information Management): colección de
herramientas con motor de correlación de logs.
Herramientas
Instrusion Detection System (IDS) – Network & Host Based:

monitorizan equipos y el trafico real.
▪ Snort
▪ Suricata
▪ BroIDS
▪ OSSEC
Herramientas
NetFlow Analyzers: examinan el trafico actual dentro de una red,

permitiendo seguir una actividad en particular o amenaza.
▪ Ntop
▪ Nfsen
▪ Nfdump
Herramientas
Vulnerability Scanners: identifica vulnerabilidades y permite evaluar

partes de la organización y remediaciones.
▪ OpenVAS
Herramientas
Webproxies: permite controlar el acceso a las páginas webs. Puede

llegar a ser fundamental en caso de una investigación forense.
▪ Squid Proxy
▪ IPFire
Herramientas
Availability Monitoring: permite la monitorización de activos y

controlar el tiempo que está caído.
▪ Nagios
Herramientas
FIDO: herramienta libre de Netflix que automatiza el proceso de

respuesta a incidentes evaluando y respondiendo al malware. El
principal propósito de FIDO es gestionar el esfuerzo manual de
evaluar las amenazas a mano.
Es una plataforma que está integrada con el resto de herramientas de
seguridad, respondiendo frente a ataques de una red.
Herramientas: FIDO
Herramientas
nightHawkResponse
Herramienta que permite representar la información proporcionada
por Mandiant Redline. -> extracción de información de los Hosts.
Esta aplicación permite controlar múltiples investigaciones sobre
cientos de endpoints.
Herramientas
INDICE
▪ Metodologías.

▪ Niveles.
Ciclo de Vida de un Incidente
Vamos aplicar el ciclo de Vida del NIST sobre una APT

Ciclo de Vida de un incidente
Preparación
¿Por qué gastar mis recursos en prepararme para responder ante un
Ciberataque, cuando puedo invertir en mantener a los atacantes
fuera?
▪ No importa la fortaleza de las defensas
▪ Medios y determinación acompañan a los atacantes sofisticados
▪ Si un ataque tiene éxito, ¿Cómo va a responder la organización?:
construir un equipo, construir un plan.
¿Me NO
preparo?
SI
Preparación
Las organizaciones que invierten tiempo y recursos en prepararse para una
brecha le irá mucho mejor en los esfuerzos de respuesta y erradicación.
Preparación
1. Creación de políticas y procedimientos de gestión de incidentes.
2. El staff debe estar entrenado para incidentes reales
3. Procedimientos de erradicación
4. Procedimientos de contención
5. Procedimientos de respuesta
Detección y Análisis
El componente principal de cualquier análisis es la recolección y
análisis en sí de la evidencia. En un ataque de APT, el propósito
principal del análisis es proveer información para la elaboración del
plan de erradicación y contención.
Debe ser el cuestionamiento inicial y desprenderá las siguientes preguntas en
análisis:
▪ ¿Los atacantes pertenecen a un grupo hacktivista?
▪ ¿Son patrocinados por alguien (competidor, gobierno, tercero, etc.)?
▪ ¿Es un individuo o un grupo colaborando en conjunto para realizar el ataque?
▪ ¿Estos ataques pueden ser identificados por alguna entidad de gobierno o de
inteligencia?
▪ ¿Tienen apoyo por alguien interno de la organización?
▪ ¿Están realizando el ataque desde las instalaciones de la empresa?
▪ ¿Están utilizando algún proveedor o tercero como un vector de ataque?
Identificar los sistemas que son atacados pueden ayudar a identificar qué tipo de información están
buscando.
▪ ¿Los atacantes alcanzaron sus objetivos?
▪ ¿Qué equipos fueron comprometidos?
▪ ¿Qué información fue comprometida?
▪ ¿Existen equipos o servidores infectados con malware?
La organización debe estar preparada para dar respuesta a las siguientes preguntas:
▪ ¿Qué información se llevaron?
▪ ¿Qué impacto tiene si la información es divulgada?
▪ ¿Qué tipo de declaraciones se manejarán ante la prensa en caso de que el ataque se haga público?
¿De donde vienen los ataques? Las siguientes preguntas ayudarán a
tener un mejor entendimiento del ataque:
▪ ¿Cuál fue el vector inicial de ataque?
▪ ¿Qué otras rutas de ataque fueron consideradas?
▪ ¿Qué puertas traseras (backdoors) pudieron dejar habilitadas?
▪ ¿Qué otros recursos exploraron?
▪ ¿Qué repositorios de información pudieron dejar habilitados?
La organización debe reconsiderar los siguientes cuestionamientos:
▪ ¿Dónde somos vulnerables?
▪ ¿Dónde están nuestros datos sensitivos?
▪ ¿Cuándo fue la última vez que se actualizaron los inventarios de
datos?
¿Qué atacaron? Los siguientes preguntas ayudarán a determinar el
motivo de los ataques:
▪ ¿Qué tipo de información buscaban?
▪ ¿El patrón del ataque puede decirnos cuáles fueron sus motivos?
▪ ¿Por qué no se identificó el ataque inicial?
▪ ¿Por qué no se identificaron las actividades subsiguientes del
ataque?
¿Los atacantes siguen dentro de la organización? Los siguientes
preguntas ayudarán a responder:
▪ ¿Qué accesos lograron?
▪ ¿Qué tipo de información expuesta pudo ayudar a realizar el
ataque?
▪ ¿Pueden tener acceso persistente a los sistemas?
▪ ¿Qué información están obteniendo?
▪ ¿Cómo están sacando información de la organización?
Contención, Erradicación y Recuperación

¿Comúnmente, cuál es la primer actividad que hacemos al identificar
un ataque?
▪ Desconectar
▪ Apagar
▪ Bloquear
¿Son actividades suficientes para erradicar la causa raíz de un
incidente de seguridad? ¿Entendemos realmente el alcance del
ataque y lo que ha sido comprometido?
Las 3 grandes fases que una organización preparada debe realizar

para la erradicación de un ciberataque son:
1. Planear la erradicación
2. Ejecutar el plan
3. Monitorear los reintentos de acceso
Una erradicación bien coordinada y planeada debe considerar:

Determinar la Conocer las
Crear el equipo Desarrollar el
fecha de técnicas, tácticas
de erradicación procedimiento
erradicación del y procedimientos
del evento del evento
evento del atacante (TTP)
Conocer las
Establecer
técnicas, tácticas
protocolos de
y procedimientos
comunicación
del atacante (TTP)
Mientras se ejecuta el plan de erradicación
BLOQUEAR LOS
EJECUTAR UN RECONSTRUIR LOS
COMANDOS Y EL
CAMBIO DE SISTEMAS PROPAGAR IoC
CONTROL DEL
CONTRASEÑAS COMPROMETIDOS
ATACANTE
POST Incidente
▪ ¿Qué tipo de información se necesito con más prisa?
▪ ¿Qué debería hacer el staff diferente para la próxima vez e un incidente
similar?
▪ ¿Cómo podía ser mejorado el intercambio de información con otras
organizaciones?
▪ ¿Qué acciones preventivas pueden prevenir incidentes en el futuro?
▪ ¿Qué indicadores deben ser monitorizados para detectar incidentes
similares?
▪ ¿Qué herramientas adicionales o recursos se necesitan para detectar,
analizar y contener futuros incidentes?
INDICE
▪ Metodologías.
▪ Niveles.
▪ Otros
Incidentes Críticos: Valoración de la Criticidad
El único estándar que ofrece un sistema de valoración del incidente es

la ISO 27035.
Vamos a exponer otro sistema de valoración aportado por el Centro
Criptográfico Nacional de España [CCN-STIC-817]
Incidentes Críticos: Valoración de la Criticidad
Los factores que podemos considerar a la hora de establecer criterios de clasificación
son, entre otros [CCN-STIC-817]:
▪ Tipo de amenaza: código dañino, intrusiones, fraude, etc.
▪ Origen de la amenaza: Interna o externa.
▪ La categoría de seguridad de los sistemas afectados.
▪ El perfil de los usuarios afectados, su posición en la estructura de la organización y, en
su consecuencia, sus privilegios de acceso a información sensible o confidencial.
▪ El número y tipología de los sistemas afectados.
▪ El impacto que el incidente puede tener en la organización, desde los puntos de vista
de la protección de la información, la prestación de los servicios, la conformidad legal
y/o la imagen pública.
▪ Los requerimientos legales y regulatorios.
Incidentes Críticos: Valoración de la criticidad
Antes de valorar, hay que CLASIFICACIÓN DE LOS CIBERINCIDENTES

tipificar los incidentes dentro de
Clase de Ciberincidente Descripción Tipo de ciberincidente
un grupo para determinar la
criticidad y sus niveles. Virus
Gusanos
Troyanos
Software cuyo objetivo es infiltrarse o
dañar un ordenador, servidor u otro Spyware
Código dañino dispositivo de red, sin el
conocimiento de su responsable o Rootkit
usuario y con finalidades muy
diversas. Ransomware (secuestro
informático)
Herramienta para Acceso
Remoto Remote Access
Tools (RAT)
CLASIFICACIÓN DE LOS CIBERINCIDENTES
Denegación [Distribuida]
del Servicio DoS
Ataques dirigidos a poner
Fallo (Hardware/Software)
fuera de servicio los
sistemas, al objeto de causar
Disponibilidad daños en la productividad Error humano
y/o la imagen de las
instituciones atacadas.
Sabotaje
Identificación
de
Ataques dirigidos a recabar Vulnerabilidades
información fundamental
que permita avanzar en Sniffing
Obtención de ataques más sofisticados, a
información través de ingeniería social o Ingeniería Social
de identificación de
vulnerabilidades.
Phishing
Compromiso de cuenta
de Usuario
Defacement
Ataques dirigidos a la Cross Site Scripting
explotación de Cross-Site Request
vulnerabilidades de diseño, Forgery (CSRF)
Intrusiones de operación o de Inyección SQL
configuración de diferentes Spear Phising
Pharming
tecnologías, al objeto de
Ataque de fuerza Bruta
introducirse de forma
fraudulenta en los sistemas Inyección de Ficheros
de una organización. Explotación SW
Explotación HW
Acceso NO AUTORIZADO
Incidentes relacionados MOIFICACIÓN Y

BORRADO NO
con el acceso y fuga
AUTORIZADO DE
(Confidencialidad), INFORMACIÓN
Compromiso a la modificación o borrado
información (Integridad) de la
información no publica.
Publicación no
autorizada de
información
Suplantación/Spoofing
Uso de recursos no autorizados

Incidentes relacionados con
Fraude acciones fraudulentas
derivadas de suplantación de Uso ilegítimos de credenciales
identidad en todas sus
variantes
Violaciones de derechos de
propiedad intelectual
SPAM
Ataques Dirigidos a dañar la

imagen de la organización o ACOSO/EXTORSION
Contenido Abusivo a utilizar sus medios
electrónicos para otros usos MENSAJES OFENSIVOS
ilícitos (tales como la
publicidad, la extorsión o en
general la PEDERASTIA/RACISMO/
APOLOGIA A LA
ciberdelincuencia)
VIOLENCIA
Abuso de privilegios por

usuarios
Incidentes Relacionados por Acceso a servicios no

violaciones de usuarios de autorizados
Política de Seguridad las políticas de seguridad
aprobadas por la Sistema desactualizado
organización
OTROS
Incidentes Críticos: Niveles
Según el CCN de España[CCN-STIC-817]:

NIVEL AMENAZA
CRITICO Ciberespionaje
Nivel Criticidad
1 BAJA
Interrupción de los Servicios IT / Exfiltración
MUY ALTO
de datos / Compromiso de los servicios 2 MEDIA
3 ALTA
Toma de control de los sistemas / Robo y
ALTO publicación o venta de información sustraída / 4 MUY ALTA
Ciberdelito / Suplantación
5 CRITICA
Logro o incremento significativo de
capacidades ofensivas /
MEDIO
Desfiguración de páginas web / Manipulación
de información
Ataques a la imagen / menosprecio /

BAJO
Errores y fallos
Según el CCN de España[CCN-STIC-817], el impacto potencial se

define como estimación del daño que podría causar un incidente de
seguridad. Nivel Descripción
No hay impacto apreciable sobre el sistema
L0 – IRRELEVANTE
No hay daños reputacionales apreciables
L1 – BAJO La categoría más alta de los sistemas de información
afectados es BÁSICA
El incidente precisa para resolverse menos de 1 JP13
Daños reputacionales puntuales, sin eco mediático
L2 – MEDIO La categoría más alta de los sistemas de información
afectados es MEDIA
Afecta a más de 10 equipos con información cuya máxima
categoría es BÁSICA
El incidente precisa para resolverse entre 1 y 10 JP
Daños reputacionales apreciables, con eco mediático
(amplia cobertura en los medios de comunicación)
Nivel Descripción
La categoría más alta de los sistemas de información afectados es ALTA
Afecta a más de 50 equipos con información cuya máxima categoría es BÁSICA
Afecta a más de 10 equipos con información cuya máxima categoría es MEDIA
L3 – ALTO
El incidente precisa para resolverse entre 10 y 20 JP
Daños reputacionales de difícil reparación, con eco mediático (amplia cobertura en los
medios de comunicación) y afectando a la reputación de terceros
Afecta a sistemas clasificados RESERVADO
Afecta a más de 100 equipos con información cuya máxima categoría es BÁSICA
Afecta a más de 10 equipos con información cuya máxima categoría es ALTA
L4 – MUY ALTO El incidente precisa para resolverse entre 20 y 50 JP
Daños reputacionales a la imagen del país (marca España)
Afecta apreciablemente a actividades oficiales o misiones en el extranjero
Afecta apreciablemente a una infraestructura crítica
Nivel Descripción
Afecta a sistemas clasificados SECRETO
Afecta a más de 50 equipos con información cuya máxima categoría es ALTA
Afecta a más de 10 equipos con información clasificada RESERVADO
L5 CRITICO
El ciberincidente precisa para resolverse más de 50 JP
Afecta apreciablemente a la seguridad nacional
Afecta gravemente a una infraestructura crítica
INDICE
▪ Herramientas.
▪ Utilidad.
▪ Niveles.
Avisos de Seguridad
Los servicios de un CERT o ISIRT pueden estar agrupados en tres

categorías:
1. Servicios proactivos: su objetivo es mejorar la infraestructura y los
procesos de seguridad, ante cualquier incidente o evento que sea
detectado.
2. Servicios Reactivos: su objetivo es responder a las peticiones de
ayuda desde el CERT, reportar incidentes y abordar incidentes.
3. Servicios de Gestión de Seguridad: servicios que mejoran
seguridad de la organización.
INDICE
▪ Niveles.
Servicios reactivos: alertas y advertencias
Definición de Servicios Reactivos según ENISA:

▪ El servicio de alertas y advertencias que ofrece el CERT involucra
vulnerabilidades de seguridad, alertas de intrusión, virus y
acciones recomendadas para lidiar con el problema. La alerta o
advertencia es enviada como reacción.
Servicios reactivos: alertas y advertencias
Servicios Reactivos según ENISA:

▪ Incident Handling – Incident analysis – Incident response on site –
Incident response support – Incident response coordination
▪ Vulnerability Handling – Vulnerability analysis – Vulnerability
response – Vulnerability response coordination
▪ Artifact Handling – Artifact analysis – Artifact response – Artifact
response
Servicios proactivos: anuncios
Servicios Proactivos según ENISA:

▪ Announcements
▪ Technology Watch
▪ Security Audits or Assessments
▪ Configuration and Maintenance of Security Tools Applications, and
Infrastructures
▪ Development of Security Tools
▪ Intrusion Detection Services
▪ Security-Related Information Dissemination
Otros: Servicios Gestión de la Seguridad
Servicios Reactivos según ENISA:

▪ Risk Analysis
▪ Business Continuity and Disaster Recovery Planning
▪ Security Consulting
▪ Awareness Building
▪ Education/Training
▪ Product Evaluation or Certification
INDICE
▪ Gestión de incidentes vs. respuesta a
incidentes.
▪ Metodologías.
Role-play:
▪ Ciclo de vida de un incidente. ▪ Toma de decisiones.
▪ Niveles.
Fuentes de Información: Avisos de Seguridad
Los avisos de seguridad están orientados a usuarios con

conocimientos técnicos avanzados, como por ejemplo
administradores de sistemas, que quieran disponer de información
práctica relevante que facilite la prevención, protección y respuesta
ante incidentes de seguridad, con la mayor rapidez posible.
Fuentes de información: Avisos de Seguridad
Ejemplo del CERTSI (CERT Seguridad e Industria de España):

Fuentes de información: Avisos de Seguridad
Ejemplo del CoICERT de Colombia:

INDICE
▪ Metodologías.
Role-play:
▪ Herramientas.
▪ Utilidad.
▪ Niveles.
▪ Otros
Otras fuentes de log
Para explicar las fuentes de log, vamos a ver los Incidente Response
Methodologies(IRM). Aquí veremos guías de como enfrentarnos a un
incidente que ya está categorizado.
Las siguientes guías son del CERT Société Générale(inglés):
IRM-1: Worm Infection IRM-9: Smartphone Malware
IRM-2: Windows Intrusion IRM-10: Social Engineering
IRM-3: Unix Intrusion IRM-11: Information Leakage
IRM-4: DDoS IRM-12: Insider Abuse
IRM-5: Malicious Network Behaviour IRM-13: Phishing
IRM-6: Website Defacement IRM-14: Scam

IRM-7: Windows Malware Detection IRM-15: Trademark Infringement
IRM-8: Blackmail
IRM-1 –WORM Infection

IRM-1 –WORM Infection
1. Preparation:
▪ Define actors, for each entity, who will be involved into the crisis cell.
These actors should be documented in a contact list kept permanently
up to date.
▪ Make sure that analysis tools are up, functional (Antivirus, IDS, logs
analysers), not compromised, and up to date.
▪ Make sure to have architecture map of your networks.
▪ Make sure that an up to date inventory of the assets is available.
▪ Perform a continuous security watch and inform the people in charge of
security about the threat trends.
2. Identification
Detect the infection
▪ Information coming from several sources should be gathered and analyzed:
▪ Antivirus logs
▪ Intrusion Detection Systems
▪ Suspicious connection attempts on servers
▪ High amount of accounts locked
▪ Suspicious network traffic Fuentes de Log
▪ Suspicious connection attempts in firewalls
▪ High increase of support call
▪ High load or system freeze
▪ High volumes of e-mail sent
2. Identification
Identify the infection
Analyze the symptoms to identify the worm, its propagation vectors and countermeasures.
Leads can be found from :
▪ CERT’s bulletins;
▪ External support contacts (antivirus companies, etc.) ;
▪ Security websites (Secunia, SecurityFocus etc.)
Notify Chief Information Security Officer. Contact your CERT if required.
Assess the perimeter of the infection

Define the boundaries of the infection (i.e.: global infection, bounded to a subsidiary, etc.).
If possible, identify the business impact of the infection.
3. Contention
The following actions should be performed and monitored by the crisis
management cell:
▪ Disconnect the infected area from the Internet.
▪ Isolate the infected area. Disconnect it from any network.
▪ If business-critical traffic cannot be disconnected, allow it after
ensuring that it cannot be an infection vector or find validated
circumventions techniques.
3. Contention
Neutralize the propagation vectors. A propagation vector can be anything
from network traffic to software flaw. Relevant countermeasures have to
be applied (patch, traffic blocking, disable devices, etc.)
For example, the following techniques can be used:
- Patch deployment tools (WSUS),
- Windows GPO,
- Firewall rules,
- Operational procedures
4. Remediation
Identify
Identify tools and remediation methods.
The following resources should be considered:
▪ Vendor fixes (Microsoft, Oracle, etc.)
▪ Antivirus signature database
▪ External support contacts
▪ Security websites
Define a disinfection process. The process has to be validated by an external structure, like your
CERT for example.
Test
Test the disinfection process and make sure that it properly works without damaging any service.
4. Remediation
Deploy
Deploy the disinfection tools. Several options can be used:
- Windows WSUS
- GPO
- Antivirus signature deployment
- Manual disinfection
Warning: some worms can block some of the remediation deployment
methods. If so, a workaround has to be found.
Remediation progress should be monitored by the crisis cell
5. Recovery
Verify all previous steps have been done correctly and get a management
approval before following next steps.
1. Reopen the network traffic that was used as a propagation method by the
worm.
2. Reconnect sub-areas together
3. Reconnect the mobile laptops to the area
4. Reconnect the area to your local network
5. Reconnect the area to the Internet
All of these steps shall be made in a step-by-step manner and a technical
monitoring shall be enforced by the crisis team.
6. Aftermath
Report
A crisis report should be written and made available to all of the actors of the crisis management cell.
The following themes should be described:
▪ Initial cause of the infection
▪ Actions and timelines of every important event
▪ What went right
▪ What went wrong
▪ Incident cost
Capitalize
Actions to improve the worm infection management processes should be defined to capitalize on this
experience.
IRM-2 –Windows Intrusion

2. Detection
Unusual Accounts
Look for unusual accounts created, especially in the Administrators group:
C:\> lusrmgr.msc or C:\> net localgroup administrators or net
localgroup administrateurs
Unusual Files
- Look for unusually big files on the storage support, bigger than 5MB. (can be an indication of a system
compromised for illegal content storage)
- Look for unusual files added recently in system folders, especially C:\WINDOWS\system32.
- Look for files using the “hidden” attribute:
C:\> dir /S /A:H
- Use “windirstat” if possible.
2. Detection
Unusual Registry Entries
Look for unusual programs launched at boot time in the Windows registry, especially:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunonceEx
Use “HiJackThis” if possible. (Also have a look in your Startup folder)
Unusual Processes and Services
Check all running processes for unusual/unknown entries, especially processes with
username “SYSTEM” and “ADMINISTRATOR”:
C:\> taskmgr.exe (or tlisk, tasklist depending on Windows release)
INDICE
▪ Herramientas.
▪ Utilidad.
▪ Toma de decisiones
▪ Niveles.
Role Play: Utilidad
¿Qué es el Role Play?

Role Play: Utilidad
El Role Play es una técnica de dinámica de grupo. También se conoce

como técnica de dramatización, simulación o juego de roles.
Consiste en que dos o más personas representen una situación o caso
concreto de la vida real, actuando según el papel que se les ha
asignado y de tal forma que se haga más vivido y auténtico.
El objetivo citado se logra no sólo en quienes representan los roles,
sino en todo el grupo que actúa como observador participante por su
compenetración en el proceso. Los actores trasmiten al grupo la
sensación de estar viviendo el hecho como si fuera en la realidad.
Role Play: Utilidad
Role Play: Utilidad
Esta actividad nos puede servir para afrontar los distintos roles que se
pueden ocasionar en la gestión de incidentes, para analizar las
tensiones que surgen en la gestión de incidentes y para adecuar
convenientemente la tolerancia al estrés y para TOMAR
DECISIONES.
También valdrá para valorar el nerviosismo asumible como un
aspecto positivo.
Role Play: Utilidad
▪ Permite a los integrantes del CERT nuevos comportamientos en un

clima de riesgo limitado ya que no se trata de una situación real y
hemos establecido una normas previamente que nos facilitan asumir
el role play.
▪ Los integrantes del CERT se dan cuenta de lo que hacen, de cómo lo
hacen y de las consecuencias de sus comportamientos.
▪ Los integrantes del CERT identifican formas diferentes de reaccionar
y su grado de eficacia respectiva.
Role Play: Roles
Según la guía de ENISA Good Practice for Incident Management

podemos encontrar los siguientes roles en un CERT:
▪ Duty officer : tiene que cuidar todas acciones de peticiones
entrantes y llevar a cabo periódicamente o puntualmente
actividades dedicadas a su rol.
Tareas: asegurase de que todos los incidentes tienen un propietario y
se gestionan. Estar disponible durante las horas de servicio…
Role Play: Roles
Triage officer: tiene que lidiar con todos los incidentes que son
reportados hacia o para el equipo. Necesita decidir si un incidente
debe ser gestionado por el equipo, cuando se gestiona y quien va ser
la persona que lo gestione. Tiene que estar puesto al día en cuento a
tendencias actuales de seguridad.
Tareas: revisar nuevos incidentes, realizar triaje en términos de
origen, severidad, impacto. Asignar incidentes, reportar problemas
cuando haya exceso de incidentes.
Role Play: Roles
Incident handler: es un rol crucial en el equipo de gestión a

incidentes. Tiene que lidiar con incidentes, analizar información, crear
workarounds, resolver el incidente, aplicar digital forensics y
comunicar claramente el progreso que ha hecho al incident manager.
Role Play: Roles
Incident manager: es el responsable de la coordinación de toda la

gestión de incidentes. Él representa al equipo fuera de su equipo.
Reporta al CISO o CIO.
Copyright
IHACKLABS LTD.
HM Revenue & Customs
Registrar of Companies for England and Wales
Company Number 10246354
All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other
electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain
other noncommercial uses permitted by copyright law.
161

02 - Gestion de Incidentes

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

02 - Gestion de Incidentes

Încărcat de

Drepturi de autor:

Formate disponibile

Gestión de Incidentes

Como ejemplos de incidentes de seguridad podemos enumerar:

La Gestión de Incidentes puede definirse como el conjunto de

▪ Para las organizaciones, el beneficio más significativo de poseer

▪ Así, una correcta Capacidad de Respuesta a Ciberincidentes ayuda

▪ Toda política de gestión de incidentes deberá definir un esquema

El esquema de clasificación deberá contemplar al menos los

2.Clasificación por severidad: La severidad de un incidente es un

Procesos de gestión de incidentes

Este proceso incluirá ítems como:

Proceso de Atención a Proceso de Mejora Continua

▪ La respuesta incidentes se engloba dentro de la gestión de

Proceso de Atención a Proceso de Mejora Continua

Metodología de Incidentes de Seguridad

Intercambio de información con partes externas

Incident Response Structure

Incident Response Structure

▪ Equipo Central de respuesta a incidentes: un equipo de respuesta

▪ Empleados: la organización desarrolla todo su trabajo, con

Selección del tipo de equipo:

Selección del tipo de equipo:

Selección del tipo de equipo:

Selección del tipo de equipo:

Selección del tipo de equipo:

Selección del tipo de equipo:

Selección del tipo de equipo:

Servicios de un equipo de respuesta a incidentes. La principal

Servicios de un equipo de respuesta a incidentes:

Ciclo de vida de un incidente

La fase inicial contempla la creación y formación de un CERT/CSIRT, el

La adecuada implantación de las antedichas medidas ayudará a

La organización, en la fase de CONTENCIÓN, ERRADICACIÓN Y

Tras el incidente, en la fase de ACTIVIDAD POST-INCIDENTE, los

ISO/IEC 27035 :Norma que especifica los lineamientos para una

Dentro de los objetivos que debe tener toda área de Seguridad de la

Fase 1: Planificación y preparación

Fase 2: Detección y reporte.

Además entre otras funciones tales como:

Fase 3: Evaluación y decisión.

Priorización del incidente

Previo al tratamiento del incidente, es indispensable priorizar el

▪ Impacto en la Información: El grado de afectación de la

▪ Recuperación del incidente: El tamaño del incidente y los sistemas

Para asignar una calificación de severidad para un incidente es

Posterior a la identificación del impacto, se debe asignar una criticidad

Para determinar el resultado total de la severidad para un incidente,

Con el resultado se indica la valoración del incidente de la siguiente

Tan pronto las respuestas inmediatas han sido implementadas, se

Algunas actividades en esta fase incluyen:

Fase 5: Lecciones aprendidas

▪ Identificar y valoración de los riesgos identificados según los resultados

Similitud en el ciclo de vida del incidente

Diferencias en los nombres de las fases:

Diferencias en los nombres de las fases:

Equipo de respuesta a incidentes y procedimientos

Incident handling check-list NIST

Guía de categorización de incidentes en ISO 27035

Incidentes críticos: ▪ Toma de decisiones.

Es indispensable analizar qué tipo de herramienta se ajusta a las

Para poder llevar un control de lo anterior se debe pensar en una

Log Análisis, gestión de logs, SIEM:

Instrusion Detection System (IDS) – Network & Host Based:

NetFlow Analyzers: examinan el trafico actual dentro de una red,

Vulnerability Scanners: identifica vulnerabilidades y permite evaluar