Giddens Anthony Consecuencias de La Modern Id Ad OCR

PREPARACIÓN PARA
EL EXAMEN CISM
Juan Herrera, CISA, CRISC, CSXF, COBIT5, ISO2700LA

Quito, 4 de Enero de 2019
juan.herrera@leveltech.com.ec
©Copyright 2016 ISACA. Todos los derechos reservados.

 Consultor Experto en Ciberseguridad

Responsable líder de servicios de Auditoría Informática y Consultoría en Seguridad de la
Información, Ethical Hacking, Gestión de TI y Riesgos Tecnológicos.
 Tiene 22 años de experiencia en Auditoría Informática y Seguridad de la Información, en
importantes empresas nacionales y multinacionales de los sectores bancario, manufac-
turero, comercial, seguros, servicios y tecnología.
 Actualmente está cursando el Doctorado en “Seguridad Informática” en la EPN-FIS.
 Es MSc. en Ingeniería Eléctrica con mención en Conectividad y Redes de Telecomunicaciones.
 Certificación como Auditor Líder en Sistemas de Gestión de Seguridad ISO 27001
 Posee Certificación COBIT 5 Foundation y Ciberseguridad Fundamentos (CSXF)
 Formación especializada en BIG DATA y Machine Learning.
 Formación PMP y en Pruebas de Calidad de Software (ISTQB).
 Obtuvo en el 2006 el Certified Information System Auditor, CISA y en el 2011 el Certified Risk Information
System and Control, CRISC, dados por ISACA Internacional.
 Trabajó por 5 años en Deloitte como Auditor Informático y Consultor de Riesgo Empresarial.
 Es especialista en gestión y seguridades de plataformas tecnológicas y Ethical Hacking.
 Posee un Diplomado Superior en Plataformas Operativas para Internetworking.
 Es Ingeniero de Sistemas graduado en la Escuela Politécnica Nacional.
 Profesor Principal a TP de la FIS- Escuela Politécnica Nacional de las Cátedras CISA y CISM desde 2010
 Ex-Presidente miembro fundador del Capítulo Quito, Ecuador - Information Systems Audit and Control
Association (ISACA).
 Es Microsoft Certified Systems Administrator en ambientes de Redes Windows Server 2008, MCSA.
Perfil Profesional mail: juan.herrera@leveltech.com.ec – cel: 0996021505
Referencia al examen CISM
 Este dominio representa el 19% del examen

CISM (aproximadamente 28 preguntas).
Dominio 1:
Dominio 4: Gestión
Gobierno de
de incidentes de
seguridad de la
seguridad de la
información (24%)
información (19%)
Dominio 3:
Desarrollo y gestión Dominio 2: Gestión
del programa de de riesgos de
seguridad de la seguridad de la
información (27%) información (30%)
3 ©Copyright 2016 ISACA. Todos los derechos reservados.

Dominio 4
Gestión de incidentes de
seguridad de la información

Quito, 4 de Enero de 2019
juan.herrera@leveltech.com.ec
©Copyright 2016 ISACA. Todos los derechos reservados.

Dominio 4
Planificar, establecer y administrar la

capacidad de detectar, investigar,
responder y recuperarse de incidentes
de seguridad de la información para
minimizar el impacto en el negocio.

Dominio 4 (cont.)
 Este dominio explica los conocimientos

esenciales que se requieren para establecer un
programa efectivo para responder y
subsiguientemente gestionar los incidentes que
amenazan los sistemas y la infraestructura de la
información de una organización.

Objetivos del dominio
 Garantizar que el candidato a CISM cuente con

los conocimientos necesarios para:
– Identificar, analizar, gestionar y responder con
eficacia a eventos inesperados que pudieran tener
efecto adverso en los activos de información de la
organización y/o en la capacidad de ésta para operar.
– Identificar los componentes de un plan de respuesta
a incidentes.
– Evaluar la eficacia de un plan de respuesta a
incidentes.
– Entender la relación entre un plan de respuesta a
incidentes, un plan de recuperación ante desastres y
un plan de continuidad del negocio.

Capítulo 4 - Gestión de Incidentes
de Seguridad de la Información
Definición: Capacidad de gestionar efectivamente
eventos perjudiciales inesperados (incidentes) con el
objetivo de minimizar los impactos y mantener o
restaurar las operaciones normales dentro de los
límites de tiempo definidos.
Objetivo: Desarrollar políticas y procedimientos para

responder y recuperarse de eventos perjudiciales y
destructivos de Seguridad de Información.
8 © ISACA. Todos los derechos reservados.

Conceptos de respuesta a
incidentes
• La gestión de incidentes implica:

 Detección y reporte
 Priorización de emergencias
 Análisis
 Respuesta a incidentes
• Una gestión eficaz de incidentes garantiza que se detecten,
registren y gestionen los incidentes para limitar los impactos.
• La respuesta a incidentes abarca la planificación, coordinación
y ejecución de estrategias y acciones apropiadas de
mitigación, contención y recuperación.

Visión General de la Gestión de
Incidentes
• Propósito
 Habilitar al negocio a continuar las operaciones en el caso
de incidentes de seguridad
 Sobrevivir a una Interrupción de los Sistemas de
Información
• Rigurosos planes requeridos
• Compromiso de los recursos necesarios
• Claro Proceso para determinar como responder a los
incidentes de seguridad
• Compromiso de la alta dirección
Visión General de la Gestión de
Incidentes
• Conocimiento de prácticas relevantes
 Equipo de respuesta a emergencias informáticas
 Gestión de incidencias
 Informática Forense
• Entendimiento de una interacción potencial con los
Gobiernos
 Federal, Estatal / Provincias, Municipal/ Local

Gestión de Incidentes – Tareas
1. Establecer y mantener una definición de la organización de jerarquía de

gravedad de los incidentes de seguridad de la información que permita
identificar, clasificarlos y responder con precisión a los incidentes.
2. Establecer y mantener un plan de respuesta a incidentes para asegurar
una respuesta eficaz y oportuna a los incidentes de seguridad de la
información.
3. Desarrollar e implementar procesos para garantizar la identificación
oportuna de los incidentes de seguridad de la información.
4. Establecer y mantener procesos para investigar y documentar los
incidentes de seguridad de la información para poder responder
adecuadamente y determinar sus causas, adhiriéndose a los requisitos
legales, reglamentarios y de la organización.
5. Establecer y mantener el escalamiento de incidentes y los procesos de
notificación para garantizar que las partes interesadas correspondientes
estén involucradas en la gestión de respuesta a incidentes.

Gestión de Incidentes – Tareas
6. Organizar, capacitar y equipar a los equipos para responder eficazmente

a los incidentes de seguridad de la información de manera oportuna.
7. Probar y revisar periódicamente el plan de respuesta a incidentes para
garantizar una respuesta eficaz a los incidentes de seguridad de la
información y mejorar la capacidad de respuesta
8. Establecer y mantener los planes y procesos de comunicación para
gestionar la comunicación con entidades internas y externas.
9. Realizar revisiones posteriores al incidente para determinar el origen de
los incidentes de seguridad de la información, desarrollar acciones
correctivas, reevaluar riesgos, evaluar la efectividad de la respuesta y
tomar las medidas correctivas adecuadas.
10. Establecer y mantener la integración entre el plan de respuesta a
incidentes, el plan de recuperación de desastres y el plan de continuidad
del negocio.

1 — Establecer una Definición de
Incidentes de Seguridad
Establecer y mantener una definición de la organización

de jerarquía de gravedad de los incidentes de
seguridad de la información que permita identificar,
clasificarlos y responder con precisión a los
incidentes.

Identificando Incidentes
• Dificultad en determinar • Los incidentes incluyen:

 Internet Control Message  Ataques de código malicioso
Protocol (Ping) sweep  Acceso no autorizado
“events”
 Uso no autorizado de servicios
 Falsos Positivos
 Cambios no autorizados a sistemas,
 Nivel dispositivos de red o información
 Pequeña interrupción?  Ataques de DoS/DDoS
 Nivel de abuso?
 Uso inapropiado
 Vigilancia y Espionaje
 Ingeniería social / engaños
 Fuego, inundación, pérdida de
calefacción, ventilación, aire
acondicionado
© ISACA. Todos los derechos reservados.
Gestión y respuesta
• La gestión de incidentes es un subconjunto de la gestión

de riesgos.
• Las metas de la gestión de incidentes son:
 Contener el impacto disruptivo en niveles manejables
 Restaurar las operaciones normales dentro de marcos de
tiempo aceptables
• La gestión de incidentes está determinada por el apetito
de riesgo.
• La respuesta a incidentes abarca las capacidades
operativas de la gestión de incidentes.

Clasificación de incidentes
• Clasificar los incidentes:

 Habilita una respuesta
apropiada por cada
incidente
 Mejora la efectividad de
los costos
 Hace más fácil el diseño de
controles detectives
• Los incidentes están
clasificados de acuerdo a
causa y efecto

Qué puede salir mal
• Incidentes que ocurren sin que nadie los note

• Definición no clara de eventos VS incidentes
• Planes pueden rápidamente entrabarse con las políticas
• Detalles insuficientes pueden resultar en planes que fallan

2 – Desarrollar Planes para
Responder
Establecer y mantener un plan de respuesta a incidentes
para asegurar una respuesta eficaz y oportuna a los
incidentes de seguridad de la información

Visión General de Proceso de
Respuesta
• Recuperar la información para confirmar el incidente
• Identificar el alcance y la magnitud del ambiente
afectado (p.ej. redes, máquinas / sistemas, aplicaciones)
• Determinar el grado de pérdida, modificación o daño (si
lo hubiere)
• Identificar posibles rutas o medios de ataque
• Respaldar todas las posibles fuentes de evidencia o
información relevante.
• Determinar si el manejo del incidente o la respuesta
mediante DRP/BCP es la requerida junto con el
correspondientes seguimiento.

Planes de Respuesta a Incidentes
Preparación Identificación Contención
Erradicación Recuperación Evaluación

Planes de Respuesta a Incidentes
• Requiere procedimientos escritos

 Pasos a seguir
 Equipos involucrados
 Decisiones de la Alta Gerencia
• Necesita entendimiento sobre la ejecución de la respuesta
primaria y acciones forenses
 Asegurar que la cadena de custodia es mantenida y verificable.
 Respuesta inicial en producción
 Donde sea posible trabajar con datos de respaldo no datos de
producción.
 Método verificable de creación de respaldos y rastros de auditoría.

El Proceso de Planeación
• Conocer el apetito de riesgo de la organización y sus

metas, es el primer paso:
Determinar cómo su organización define una
respuesta “aceptable” a incidentes.
Analizar la brecha o diferencia entre las capacidades
actuales y las deseadas.
Desarrollar un plan para cerrar las brechas usando
buenas prácticas.
• Asegurarse de tener en cuenta los recursos necesarios.
• Usar lenguaje claro para evitar confusiones.
Ejecución de Planes de Respuesta
• Cuando un incidente ocurre:

 Asignar un facilitador o director
 Dirigir las tareas, supervisar su ejecución, reunirse con la
alta gerencia y tomar decisiones si es necesario.
 El gerente de seguridad de información puede o no ser el
facilitador.
 Incluir un observador que registre el progreso y
documente las excepciones.
 No involucrado en la recuperación excepto en su tarea de
observador y documentador.

Documentar Incidentes
• Registrar todas las acciones en una bitácora que incluya:

 Un resumen del incidente
 El estado actual del incidente
 Acciones ejecutadas
 Fecha y hora de cada acción
 Información de contacto de las partes involucradas
 Una lista de la evidencia obtenida durante la
investigación del incidente.
 Comentarios de cualquiera de los involucrados
 Siguientes pasos

• Inhabilidad de detectar un incidente

• Toma de decisiones inicial puede fallar
• Sistemas IDS pueden generar falsos positivos
• No ser conscientes del alcance del problema

• Análisis de Riesgo débiles o no existentes

• Falta de recursos
• Falta de compromiso de la Gerencia
• Dificultad identificando los recursos de negocio
requeridos
• Falta de un entendimiento claro del proceso
• Los procedimientos pueden ser inadecuados
• En el calor del momento nadie toma notas
3 — Desarrollar Procesos para la
Identificación Oportuna
Desarrollar e implementar procesos para garantizar la
identificación oportuna de los incidentes de
seguridad de la información.

Detectar Incidentes de Seguridad
• Mecanismos a emplear
 Monitorear sitios de internet donde se reportan los
incidentes identificados
 Monitorear noticias y organizaciones de usuarios
 Monitorear proveedores de hardware y software
• Considerar servicios que proveen notificaciones de
eventos relacionados a seguridad para las
organizaciones.
• Implementar servicios automatizados de detección.
 Servicios de detección de intrusos implementados a lo
interno de la organización

Analizar Incidentes
• Analizar y evaluar el impacto

• Modificar la seguridad del programa si es necesario
 Requiere información detallada
 Archivos de registro (Logs)
 Filtrar la información y convertirla en algo útil
 Se requieren fuertes destrezas de análisis
 Aspectos clave incluyen:
 Reportes resumidos y ejecutivos que separen el trigo de la
paja
 Notificación de eventos críticos
 Un acuerdo en la definición de “incidente”

Conceptos de tecnología para
respuesta a incidentes
• Principios de seguridad (triada CID, no repudio)
• Conceptos de riesgo (vulnerabilidad, impacto, etc.)
• Protocolos de red y dispositivos
• Sistemas operativos (configuración, métodos de
ataque común, revisión de bitácoras, etc.)
• Código malicioso (virus, gusanos, caballos de Troya,
APTs)
• Desarrollo (incluye lenguajes de programación)

Estado actual de la respuesta a
incidentes
• Identificar lo que ya existe para la
Encuestas
Autoevaluación
Evaluación externa
• Identificar tendencias, eventos e
impactos
• Llevar a cabo un análisis de brechas
para determinar los recursos
requeridos o las áreas de mejora
Eficacia y eficiencia
• Un plan de respuesta a
incidentes debe ser eficaz
y eficiente.
 Haga todo lo que sea
necesario para gestionar el
riesgo.
 Haga tan poco como sea
posible más allá de lo que
se necesita para manejar
un riesgo.
• La clave es saber lo que es
razonablemente probable
para un evento dado.

Sistemas para la gestión de
incidentes
Sistemas distribuidos Sistemas centralizados
para la gestión de para la gestión de
incidentes incidentes
• Consiste en múltiples • Reúna los datos de
capacidades distintas capacidades
específicas de para un análisis
detección de común
incidentes. • Ejemplo: SIEM
• Ejemplo: IDS (basado
en la red y el host)

SIEM
• Un SIEM eficaz debe:

 Consolidar y correlacionar datos provenientes de varios
sistemas
 Identificar incidentes reales o posibles
 Notificar al personal
 Priorizar incidentes con base en el impacto al negocio
 Dar seguimiento a los incidentes hasta que se hayan cerrado
 Proporcionar seguimiento y notificaciones del estado de los
incidentes
 Integrarse con los principales sistemas de gestión de TI
 Implementar directrices de mejores prácticas

Consideraciones sobre el sistema
de gestión de incidentes
• Algunas consideraciones para los sistemas de gestión
de incidentes incluyen:
 Costos operativos: En ausencia de un sistema
automatizado de gestión de incidentes, el personal debe
realizar estas tareas manualmente. Los costos de
capacitación y mantenimiento son mayores y el riesgo
de error humano es mayor.
 Costos de recuperación: Un sistema automatizado
puede detectar y escalar incidentes más rápido que un
proceso manual, reduciendo el daño adicional.

• Los incidentes pueden ocurrir sin que nadie se de

cuenta

4 – Establecer la Capacidad de
Investigación
Establecer y mantener procesos para investigar y
documentar los incidentes de seguridad de la
información para poder responder adecuadamente y
determinar sus causas, adhiriéndose a los requisitos
legales, reglamentarios y de la organización.

Investigación
• Para cada tipo de evento, el plan de respuestas a

incidentes debe tener:
 Una serie clara de pasos para la investigación inicial
 Estimaciones de tiempo para cuantificar el tiempo que
debe tomar cada paso
 ¿Quién debe realizar el paso (por rol)?
• Un enfoque estructurado
es importante.

Respuesta en Vivo
• Requerida en situaciones donde una rápida

investigación es requerida
 Perímetro de Red Comprometido
 Servidor de Internet Comprometido
• Herramientas de Respuesta
 Netcat
 “Scripts” para recolectar la información

Recolectar Evidencia
• Toda la información relacionada al evento debe ser

registrada y los datos del incidente conservados
• Poseer conocimiento de:
 Los requerimientos para colectar y preservar evidencia
 Reglas de evidencia
 Admisibilidad de la evidencia
 Calidad y suficiencia de la evidencia

Entrevistas
• Preguntas iniciales
 Quién descubrió el incidente?
 Cómo se descubrió el incidente?
 Cuándo ocurrió?
 Cuál fue o es el nivel del daño?
 Dónde se inició el ataque?
 Cuáles técnicas fueron utilizadas para comprometer el
sistema?
 ¿Quién está involucrado? (si se conoce)

Habilidades personales Habilidades
Habilidades técnicas
• Comunicación • Habilidades de base
• Habilidades de técnica
redacción • Habilidades para el
• Liderazgo tratamiento de
• Habilidades de incidentes
presentación
• Habilidades de equipo
• Resolución de
problemas
• Gestión del tiempo

Informática Forense
• La informática forense se refiere a la obtención de evidencias.

• La acusación legal es una opción si la evidencia se obtiene y se
almacena correctamente.
 Muchos métodos de contención y erradicación pueden
impedir la recolección apropiada de evidencia.
 Documentación inadecuada puede derivar en fallas.
• Haga una lluvia de ideas sobre los escenarios que podrían
requerir un análisis forense y escribirlos en el plan.
• Identifique tipos de informática forense que pueda ser
ejecutada internamente vs. contratar a expertos externos.

Informática Forense
• Para asegurar admisibilidad de evidencia, usar

herramientas forenses
 Crear una copia del “flujo de bits” de la evidencia
 Encase
 Unix/Linux utility
• Desarrollar todas las pruebas y el análisis de datos
contra la copia y nunca contra el original.
 La evidencia original tiene que mantenerse sin cambios
 Guardar un registro sobre la “cadena de custodia” de la
evidencia

• Herramientas débiles o inexistentes

• Herramientas incorrectas
• Pobre entendimiento del proceso de entrevistas
• Recolección de evidencia inapropiada

5 – Establecer Procesos de
Escalamiento y Comunicación
Establecer y mantener el escalamiento de incidentes y
los procesos de notificación para garantizar que las
partes interesadas correspondientes estén involucradas
en la gestión de respuesta a incidentes

Escalamiento
• A menudo, la investigación no determina la

necesidad de nuevas acciones e inicia el "fin de la
emergencia”.
• Escalar un incidente siempre que se descubra un
motivo de preocupación O el plazo para completar
una tarea se exceda.
• El plan de respuesta a incidentes debe identificar a
las personas a ser notificadas junto con los nuevos
pasos para completar la respuesta en curso.

Escalamiento
• Incluye priorización de la información del evento y

del proceso de decisiones
• Determinar cuando alertar a varios grupos
 Alta dirección
 El público
 Accionistas y partes interesadas
 Jurídico
 Recursos humanos
 Clientes y proveedores

Priorización de emergencias
• Priorización de emergencias: Un proceso que consiste en

clasificar, categorizar, priorizar y asignar reportes/eventos
entrantes.
• Típicamente hay tres categorías:
 Problemas que no se pueden resolver fácilmente
 Problemas que pueden esperar
 Problemas que pueden atenderse eficientemente con
recursos disponibles
• Utilice BIAs y planes de recuperación para guiar este
proceso.

Notificación
• Utilizar un proceso eficaz y oportuno de notificación de

incidentes relacionados con la seguridad
 Tener un proceso definido para el personal de atención a los
usuarios para identificar posibles incidentes de seguridad
 Definir responsabilidades y comunicarlas al personal clave
 Liderazgo de TI
 Centro de soporte (help desk)
 Dueños del Negocio
• Tomar acciones
 Se necesita ser decidido durante el evento

Notificaciones externas
• Algunos eventos pueden

requerir la comunicación a
personas ajenas a la
organización.
• El incumplimiento de los
requisitos de comunicación
puede resultar en sanciones.
• Consultar con personal
jurídico, de recursos
humanos, etc. para asegurar
que las personas adecuadas
estén informadas.
Notificación
• El tiempo es esencial.
• Los procedimientos de respuesta a incidentes deben
identificar claramente quién necesita ser notificado y
las mejores formas de contactarlos.
• Las actividades de notificación sólo son efectivas si
las personas comprenden sus responsabilidades y las
realizan eficientemente.

• Los incidentes pueden ocurrir y las personas

equivocadas reciben la notificación
• Confusión puede sobrevenir al decidir a quién llamar
• Un alto gerente puede no estar disponible y nadie
sabe qué acción se debe ejecutar

6 – Organizar y Entrenar Equipos
Organizar, capacitar y equipar a los equipos para

responder eficazmente a los incidentes de seguridad
de la información de manera oportuna

Equipos de Respuesta y
Recuperación
• Equipo de respuesta a las Emergencias
• Gestión de incidentes
• Red
• Administradores del Sistema
Operativo
• Administradores de la base de datos
• Sistemas de aplicación
• Equipo de seguridad

Equipos de respuesta a incidentes
• Los IRTs pre-diseñados

ayudan a reunir a las
personas con las
habilidades útiles.
 Dependiendo del incidente,
algunas habilidades
especializadas pueden ser
necesitadas.
• Los IRTs pueden estar
centralizados, distribuidos o
en un modelo híbrido.
• La estructura del IRT debe
ser revisada y aprobada por
la alta dirección.

Organización de equipos de
• IRT Central: Un solo IRT maneja todos los incidentes
• IRT Distribuido: Cada uno de los diferentes equipos
es responsable de un segmento lógico o físico de la
infraestructura
• IRT de coordinación: Un equipo central proporciona
orientación a los IRT distribuidos, desarrolla políticas
y normas, proporciona capacitación y ejercicios y
coordina la respuesta
• IRT Externo: Una parte del IRT puede estar
tercerizado con terceros

Composición del equipo
• Un IRT común incluye:
 Gerente de seguridad de la información
 Comité directivo / consejo asesor (solo posición de gobierno)
 Miembros permanentes / dedicados del equipo
 Miembros virtuales / temporales del equipo
• Otros puestos incluyen:

 Gerente de respuesta a incidentes
 Administrador de incidentes
 Investigador
 Especialistas de seguridad de TI
 Especialistas/representantes de TI
 Gerentes de negocio
 Áreas Legal, RH, PR
 Especialista en gestión de riesgos
59  Gerente de seguridad física/instalaciones

Equipos multidisciplinarios
• Los incidentes se extienden

más allá de los sistemas de
información.
 Los incendios, los cortes de
energía o los desastres
naturales pueden afectar a
toda la organización.
 Otros incidentes pueden
involucrar a las áreas de legal,
RH, etc.
• Un punto permanente en el
IRT puede no ser necesario,
pero un punto de contacto
es útil.

Es bueno saber que
• La rotación de personal es una amenaza persistente para

los planes de respuesta a incidentes y puede ser
especialmente difícil hacer un seguimiento de quiénes
deben ser los puntos de contacto para funciones de
apoyo fuera de la TI y la seguridad de la información.
• Si el IRT necesita ponerse en contacto con uno de estos
grupos, será tiempo sensible, así que revise la
información de contacto de todos los que figuran en el
plan de respuesta a incidentes de forma regular y valide
que éstos siguen siendo las personas correctas para que
estén incluidos en el plan.

• No hay definición de equipos

• Personas incorrectas en equipos incorrectos
• Lista de miembros de equipo desactualizadas

7 – Garantizar Pruebas Periódicas
Probar y revisar periódicamente el plan de respuesta a

incidentes para garantizar una respuesta eficaz a los
incidentes de seguridad de la información y mejorar la
capacidad de respuesta

Garantizar Pruebas Periódicas
• Implementar pruebas periódicas

• Estas pruebas incluyen:
 Desarrollar los objetivos de la prueba
 Evaluar la prueba
 Desarrollar recomendaciones para mejorar los planes de
respuesta y recuperación
 Implementar un proceso de seguimiento que garantice que
se han implementado las recomendaciones
 Asegurar la confidencialidad de los reportes que muestren
resultados críticos o sensibles

El Rol de Pruebas
• Las pruebas incrementan la probabilidad de que el plan funcione por:

 Evaluación de la solidez técnica del plan
 Aumentar la familiaridad de cada participante con el plan
• Las pruebas utilizan tiempo y recursos, por lo que los objetivos y criterios
deben ser claros.
• Enfocarse en:
 Identificar diferencias
 Verificar presunciones
 Validar cronogramas
 Determinar la efectividad de las estrategias
 Evaluar el desempeño del personal
 Determinar la precisión y el uso de la información sobre el plan
Consideraciones sobre las
pruebas
• Probar regularmente los planes de respuesta.
 Al menos anualmente
• Antes de cada prueba:
 Tome medidas para limitar el riesgo de interrupciones.
 Asegurarse de que los gerentes del negocio entiendan y
acepten el riesgo residual.
 Verificar que existan acuerdos de contingencia para
restaurar las operaciones en cualquier punto durante la
prueba si es necesario.

Tipos de pruebas
• Revisión de lista de verificación: Las listas de
verificación para la recuperación son
revisadas para asegurar de que estén
actualizadas.
• Recorridos estructurados: Los miembros del
equipo implementan físicamente los planes
en papel y revisan cada paso.
• Prueba de simulación: El IRT representa una
situación de desastre preparada sin activar el
sitio de recuperación.
• Prueba paralela: El sitio de recuperación se
lleva a un estado de preparación
operacional, pero el sitio primario continúa
normalmente.
• Prueba de interrupción completa: Las
operaciones se cierran en el sitio primario y
se cambian al sitio de recuperación.
Progresión de pruebas
Pruebas de
infraestructura,
Pruebas a la
aplicaciones
infraestructura y
críticas y
la recuperación
Pruebas de participación
de aplicaciones
infraestructura y de los usuarios
críticas
comunicaciones finales
Verificación
sobre la mesa
con
escenarios de
Verificación desastres
sobre la simulados
mesa de los
planes

Categorías de pruebas
• Pruebas en papel: Recorridos en papel para

aumentar la concientización
• Pruebas de preparación: Ensayos en vivo sobre
sistemas reales para identificar deficiencias
• Pruebas operativas completas: Imitar las condiciones
del mundo real, pero no son realmente una
interrupción real

Fases de pruebas
Prueba Prueba posterior

Prueba preliminar
Establezca el Se ejecutan las Se realiza la

escenario para actividades depuración de
la prueba real operativas las actividades
reales para del grupo
probar los
objetivos
específicos

Criterios de evaluación
• Los criterios de evaluación

dependen del tipo de prueba:
 Las pruebas de papel se enfocan en
procesos.
 Las pruebas que involucran sistemas
reales deben equilibrar el proceso con
los resultados demostrados.
• Las pruebas pueden usarse para
resaltar la importancia de seguir los
procedimientos y las habilidades
documentales del IRT.
• Un tercero independiente debe
monitorear y evaluar la prueba.
• Tomar nota de los procedimientos
que no funcionaron.

• Las Pruebas consumen demasiado tiempo – permitir

el tiempo suficiente
• Se pueden dar rivalidades entre los miembros del
equipo cuando las cosas salen mal
• Falta de acción una vez obtenidos los resultados

8 – Comunicación con Entidades
Establecer y mantener los planes y procesos de

comunicación para gestionar la comunicación con
entidades internas y externas.

Comunicación
• El desarrollo de
comunicaciones durante un
incidente quita tiempo de
otras actividades críticas en
el tiempo.
• Los criterios de mensajes
pueden diferir dependiendo
del incidente.
• Las plantillas pueden ayudar
en hacer fácil y rápido las
comunicaciones.

Comunicación
• Una buena comunicación debe ser establecida entre

diversas áreas
 Alta dirección
 Empleados de la empresa
 Departamentos clave – Legal, relaciones con los medios
 Socios de Negocios (ej.:, Proveedores, colaboradores)
 Encargados del cumplimiento de la ley
(Delitos Informáticos)
 El público

• Personal incorrecto dialogando con entidades

externas
• Brindar información incorrecta o perjudicial
• Personas no informadas
• Lo primero que escucha la gente proviene de los
medios noticiosos

9 – Realizar Revisiones
Realizar revisiones posteriores al incidente para

determinar el origen de los incidentes de seguridad de
la información, desarrollar acciones correctivas,
reevaluar riesgos, evaluar la efectividad de la respuesta
y tomar las medidas correctivas adecuadas

Preservar / recolectar evidencias
• Dos opiniones sobre cómo preservar evidencia sobre un

sistema afectado:
 Corte la energía para conservar los archivos de
almacenamiento temporal
 Mantenga la energía para evitar la pérdida del software
malintencionado (malware) / archivos corrompidos
• El análisis debe realizarse en una copia de las unidades
de almacenamiento del sistema.
• Hacer una copia a nivel de bits utilizando un diodo de
protección contra escritura y comparar hashes puede
ayudar a establecer la validez de la investigación.

Documentación
• Son útiles los registros precisos de un incidente a

medida que se desarrolla.
 Las cronogramas claros pueden identificar la causa raíz.
 Los cambios indocumentados pueden introducir riesgos.
 Una cadena ininterrumpida de custodia preserva
evidencia.
• Los formularios estandarizados ayudan a asegurar
que la información correcta sea registrada.

Revisión posterior al incidente
• Tómese el tiempo para

revisar lo que sucedió y
por qué:
 Oportunidades de mejora
en el plan
 Lecciones aprendidas
 Calcular el costo del
incidente
• Utilice un acercamiento
constante y capture la
información mientras sea
reciente.

Análisis de la causa raíz
• Sin identificar la causa raíz de un incidente, pueden ocurrir

incidentes similares.
• Responda las siguientes preguntas:
 ¿Quién está involucrado?
 ¿Qué sucedió?
 ¿Dónde se originó el ataque?
 ¿Cuándo (qué margen de tiempo)?
 ¿Por qué sucedió?
 ¿Cómo se vulneró el sistema o cómo ocurrió el ataque?
 ¿Cuál fue la razón para perpetrar el ataque (es decir, la motivación del
perpetrador)?
• Desarrollar recomendaciones para tratar la causa raíz utilizando un
enfoque basado en riesgos.

Dirigir Revisiones Posteriores al
Evento
• Establecer un equipo de revisión del evento
 Este equipo revisaría la evidencia y desarrollaría
recomendaciones
• Usar una metodología consistente
 Causa Raíz – identificando causas raíz y las medidas
necesarias para prevenir un evento igual o similar en el
futuro
• Desarrollar planes de acción para corregir las
deficiencias
 Asegurar el debido seguimiento de la gerencia

Reporte de la Causa Raíz del
Incidente
• Resumen
 Evento, Hallazgos, Causa Raíz
 Lecciones aprendidas, Estado Actual
• Detalles
 Descripción, clientes/servicios afectados
 Secuencia de eventos con fecha, hora y personas
involucradas
 Duración de la caída del sistema o interrupción del servicio
 Plan de acción

Revisiones
• Datos Útiles
 Costos
 Útiles para planeamiento futuro
 Lecciones aprendidas
 Se requieren para mejoras – personal, educación, manejo
 Métricas
 Número de incidentes of incidentes en un período
específico
 Tiempo por incidente

Es bueno saber que
• "Abordar" una causa raíz no significa necesariamente

"resolverla”.
• La revisión posterior al incidente forma parte del
programa general de gestión del riesgo de la
información y cualquier acción correctiva propuesta
como resultado de la revisión, debe reflejar un
enfoque basado en el riesgo.
• Si el costo de mitigar una vulnerabilidad es mayor
que su impacto potencial, puede ser preferible
aceptar el riesgo o transferirlo a través de un acuerdo
con terceros.
• El equipo se desintegra muy pronto

• “Post mortem” completado pero no se da
seguimiento a las acciones
• No se mantienen las métricas requeridas

10 – Integración de Respuesta a
Incidentes con BCP/DRP
Establecer y mantener la integración entre el plan de
respuesta a incidentes, el plan de recuperación de
desastres y el plan de continuidad del negocio

Respuesta y Continuidad
• Los planes de continuidad del negocio (BCPs)

documentan las formas en que los procesos del negocio
pueden ser restaurados si el curso habitual es
interrumpido.
• BCPs son activados frecuentemente durante las
actividades de respuesta a los incidentes.
• Los BCPs incluyen factores críticos:
 RTO
 RPO
 SDO
 MTO

Factores asociados a la Calidad
• Objetivo de punto de recuperación:

 El último punto "bien conocido" en el que los datos deben
ser restaurados en el caso de que los datos hayan sido
afectados
• Objetivo de entrega del servicio:
 Un indicador del grado de recuperación que es "lo
suficientemente bueno" para las operaciones normales
dentro de un proceso dado para reanudar
• La recuperación que no cumple los umbrales RPO / SDO
no está completa y puede requerir soluciones
alternativas.

Factores asociados al Tiempo
• Objetivo de tiempo de recuperación:

 El tiempo objetivo para reanudar un nivel aceptable de
operaciones
 La recuperación que lleva más tiempo que un RTO
probablemente afecte a la organización a niveles tolerables.
• Máximo tiempo tolerable de interrupción
 El momento en que las soluciones temporales dejan de ser
adecuadas para mantener las operaciones
 La recuperación que excede al MTO está fuera del umbral
tolerable y puede amenazar la supervivencia de la
organización.

Respuesta y Recuperación
• La recuperación es
específica al sistema o datos
afectados.
• Después de una interrupción
importante, las actividades
de recuperación pueden ser
más pronunciadas.
• La recuperación de desastres
documenta la estrategia y
las actividades específicas
necesarias para recuperar
las capacidades de TI en
caso de una pérdida
importante.
Tipos de capacidad de
recuperación
• Sitio espejo: Un sitio alterno que contiene la misma
información que el original
 Configurado para alta disponibilidad
• Hot site: Un sitio externo completamente operativo para el
procesamiento de datos equipado con software de sistemas y
hardware para su uso en caso de un desastre
• Warm site: Es similar a un hot site; sin embargo, no está
completamente equipado con todo el hardware necesario
para la recuperación
• Cold site: Una instalación de respaldo de IS que tiene los
componentes eléctricos y físicos necesarios de una instalación
informática, pero no tiene el equipo de cómputo en su lugar

Pasos Clave DRP/BCP
• Preparar un análisis de impacto al negocio
• Identificar y priorizar los sistemas y otros recursos requeridos
• Elegir las estrategias que sean apropiadas para recuperar al menos
aquellos equipos de sistemas que sean suficientes para soportar los
procesos de negocio críticos hasta que la totalidad de los equipos se
encuentre disponible.
• Desarrollar un plan de recuperación de desastres detallado
• Desarrollar un plan de continuidad de negocios detallado
• Entrenar al equipo y probar los planes
• Actualizar los planes a medida que cambia el negocio y se desarrollan
sistemas
• Conservar los planes para que se pueda acceder a ellos a pesar de que
ocurran fallos en las computadoras o redes
• Auditar los planes
• Los incidentes se tornan en un desastre y el BCP no

es ejecutado
• Falta de coordinación entre grupos
• No hay claridad para determinar cuándo un incidente
se convirtió en desastre

Resumen
• La gestión de incidentes, un subconjunto de la gestión de

riesgos, tiene como objetivo contener el impacto perturbador
de un incidente y restaurar operaciones normales.
• A menudo se clasifican los incidentes con el fin de adaptar
mejor los esfuerzos y las actividades de respuesta.
• Los equipos de respuesta a incidentes reúnen los recursos
necesarios para responder rápidamente a los incidentes y
generalmente se extienden más allá del departamento de TI.
• Las plantillas estandarizadas deben ser usadas donde sea
posible para asegurar la consistencia y agilizar las actividades.

Resumen
• La continuidad del negocio y la respuesta a incidentes

trabajan juntas para asegurar que las operaciones
puedan continuar y ser recuperadas de manera efectiva y
eficiente.
• Pruebe la respuesta a incidentes para obtener confianza
de que funcionará como se espera.
• Realice pruebas periódicas y como fueron diseñadas para
reducir el riesgo de interrupciones inesperadas en las
operaciones normales.
• Utilice los resultados de las pruebas para mejorar el plan
y proporcionar educación y capacitación a los miembros
de IRT.

Resumen
• Los sistemas de gestión de incidentes pueden ayudar a

identificar y contener incidentes en sus etapas iniciales.
• El plan de respuesta a incidentes debe incluir pasos
claros para la investigación de incidentes y criterios para
el escalamiento.
• Tenga en cuenta la preservación de las evidencias como
parte del plan.
• Utilice las revisiones posteriores a los incidentes para
identificar las causas raíz de los incidentes y abórdelas
sobre la base del riesgo.

Giddens Anthony Consecuencias de La Modern Id Ad OCR

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Giddens Anthony Consecuencias de La Modern Id Ad OCR

Загружено:

Авторское право:

Доступные форматы

PREPARACIÓN PARA

Juan Herrera, CISA, CRISC, CSXF, COBIT5, ISO2700LA

©Copyright 2016 ISACA. Todos los derechos reservados.

 Consultor Experto en Ciberseguridad

 Este dominio representa el 19% del examen

3 ©Copyright 2016 ISACA. Todos los derechos reservados.

Juan Herrera, CISA, CRISC, CSXF, COBIT5, ISO2700LA

©Copyright 2016 ISACA. Todos los derechos reservados.

Planificar, establecer y administrar la

5 ©Copyright 2016 ISACA. Todos los derechos reservados.

 Este dominio explica los conocimientos

6 ©Copyright 2016 ISACA. Todos los derechos reservados.

 Garantizar que el candidato a CISM cuente con

7 ©Copyright 2016 ISACA. Todos los derechos reservados.

Objetivo: Desarrollar políticas y procedimientos para

8 © ISACA. Todos los derechos reservados.

• La gestión de incidentes implica:

9 © ISACA. Todos los derechos reservados.

11 © ISACA. Todos los derechos reservados.

1. Establecer y mantener una definición de la organización de jerarquía de

12 © ISACA. Todos los derechos reservados.

6. Organizar, capacitar y equipar a los equipos para responder eficazmente

13 © ISACA. Todos los derechos reservados.

Establecer y mantener una definición de la organización

14 © ISACA. Todos los derechos reservados.

• Dificultad en determinar • Los incidentes incluyen:

• La gestión de incidentes es un subconjunto de la gestión

16 © ISACA. Todos los derechos reservados.

• Clasificar los incidentes:

© ISACA. Todos los derechos reservados.

• Incidentes que ocurren sin que nadie los note

18 © ISACA. Todos los derechos reservados.

19 © ISACA. Todos los derechos reservados.

20 © ISACA. Todos los derechos reservados.

Preparación Identificación Contención

Erradicación Recuperación Evaluación

21 © ISACA. Todos los derechos reservados.

• Requiere procedimientos escritos

22 © ISACA. Todos los derechos reservados.

• Conocer el apetito de riesgo de la organización y sus

• Cuando un incidente ocurre:

24 © ISACA. Todos los derechos reservados.

• Registrar todas las acciones en una bitácora que incluya:

25 © ISACA. Todos los derechos reservados.

• Inhabilidad de detectar un incidente

26 © ISACA. Todos los derechos reservados.

• Análisis de Riesgo débiles o no existentes

28 © ISACA. Todos los derechos reservados.

29 © ISACA. Todos los derechos reservados.

• Analizar y evaluar el impacto

30 © ISACA. Todos los derechos reservados.

31 © ISACA. Todos los derechos reservados.

© ISACA. Todos los derechos reservados.

34 © ISACA. Todos los derechos reservados.

• Un SIEM eficaz debe:

35 © ISACA. Todos los derechos reservados.

36 © ISACA. Todos los derechos reservados.

• Los incidentes pueden ocurrir sin que nadie se de

37 © ISACA. Todos los derechos reservados.

38 © ISACA. Todos los derechos reservados.

• Para cada tipo de evento, el plan de respuestas a

39 © ISACA. Todos los derechos reservados.

• Requerida en situaciones donde una rápida